Create a gist now

Instantly share code, notes, and snippets.

Embed
How to subclass a promise
// ES6
class AngularPromise extends Promise {
constructor(executor) {
super((resolve, reject) => {
// before
return executor(resolve, reject);
});
// after
}
then(onFulfilled, onRejected) {
// before
const returnValue = super.then(onFulfilled, onRejected);
// after
return returnValue;
}
}
// ES5
function AngularPromise(executor) {
var p = new Promise(function (resolve, reject) {
// before
return executor(resolve, reject);
});
// after
p.__proto__ = AngularPromise.prototype;
return p;
}
AngularPromise.__proto__ = Promise;
AngularPromise.prototype.__proto__ = Promise.prototype;
AngularPromise.prototype.then = function then(onFulfilled, onRejected) {
// before
var returnValue = Promise.prototype.then.call(this, onFulfilled, onRejected);
// after
return returnValue;
}
@rektide

This comment has been minimized.

Show comment
Hide comment
@rektide

rektide Dec 19, 2017

The absurd painful unexpected way this breaks is that you MUST:

  • Accept a function in the constructor
  • Call the function during the lifecycle of the super()

You can not create a Promise that doesn't need an executor passed in. You can't not call the executor. Anyone reasonably versed in extending classes would expect this code to work fine, but it doesnt:

class LifeUniverseEverythingPromise extends Promise{ constructor(){ super(resolve=> resolve(42)) }}

Although you'd expect that you are passing an valid executor to the super (Promise), there's additional magic the runtime is doing & checking. Trying to call .then on an instance of LifeUniverseEverythingPromise would result in: TypeError: Promise resolve or reject function is not callable.

Why? There's super special magic in the Promise spec that this normal, OK looking javascript class-extending does not satisfy. Promise magically demands the runtime track & check information that would not normally be available to the inner Promise implementation if it were a regular Javascript object.

So there are caveats to this gist. Big ones. It's not a base to start from & modify, it's a minimum possible execution path guide that you must adhere to. You can not deviate from this gist (aside from omitting .then), only add to it. I'd really like to see implementations where executor above does not need to be passed in, but alas, the spec has other things in mind. I don't fully understand the spec, but it is 25.4.1.5 that demands this out-of-band context, this sniffing of the original constructor & determinancy of whether it has been executed. Numerous Node.js users have run into this issue already, if anyone is looking for more discussion around this very anomalous irregular limitation in extending a Class.

rektide commented Dec 19, 2017

The absurd painful unexpected way this breaks is that you MUST:

  • Accept a function in the constructor
  • Call the function during the lifecycle of the super()

You can not create a Promise that doesn't need an executor passed in. You can't not call the executor. Anyone reasonably versed in extending classes would expect this code to work fine, but it doesnt:

class LifeUniverseEverythingPromise extends Promise{ constructor(){ super(resolve=> resolve(42)) }}

Although you'd expect that you are passing an valid executor to the super (Promise), there's additional magic the runtime is doing & checking. Trying to call .then on an instance of LifeUniverseEverythingPromise would result in: TypeError: Promise resolve or reject function is not callable.

Why? There's super special magic in the Promise spec that this normal, OK looking javascript class-extending does not satisfy. Promise magically demands the runtime track & check information that would not normally be available to the inner Promise implementation if it were a regular Javascript object.

So there are caveats to this gist. Big ones. It's not a base to start from & modify, it's a minimum possible execution path guide that you must adhere to. You can not deviate from this gist (aside from omitting .then), only add to it. I'd really like to see implementations where executor above does not need to be passed in, but alas, the spec has other things in mind. I don't fully understand the spec, but it is 25.4.1.5 that demands this out-of-band context, this sniffing of the original constructor & determinancy of whether it has been executed. Numerous Node.js users have run into this issue already, if anyone is looking for more discussion around this very anomalous irregular limitation in extending a Class.

@eKoopmans

This comment has been minimized.

Show comment
Hide comment
@eKoopmans

eKoopmans Jan 24, 2018

Hey @rektide, today's you're lucky day! I've got an implementation where executor isn't required (using ES5 syntax). Check out the basic and more advanced versions. Tested and working in Chrome and Node, haven't tried other browsers yet.

Hey @rektide, today's you're lucky day! I've got an implementation where executor isn't required (using ES5 syntax). Check out the basic and more advanced versions. Tested and working in Chrome and Node, haven't tried other browsers yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment