How to subclass a promise

angularpromise.js

// 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;
}

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.

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.

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.