Why does the Promise constructor need an executor?

Question

When using Promises, why can't triggers for resolve and reject be defined elsewhere in the codebase?

I don't understand why resolve and reject logic should be localized where the promise is declared. Is this an oversight, or is there a benefit to mandating the executor parameter?

I believe the executor function should be optional, and that its existence should determine whether the promise encapsulates resolution or not. The promise would be much more extensible without such mandates, since you don't have to initiate async right away. The promise should also be resettable. It's a 1 shot switch, 1 or 0, resolve() or reject(). There are a multitude of parallel and sequential outcomes that can be attached: promise.then(parallel1) and promise.then(parallel2) and also promise.then(seq1).then(seq2) but reference-privileged players cannot resolve/reject INTO the switch

You can construct a tree of outcomes at a later time, but you can't alter them, nor can you alter the roots (input triggers)

Honestly, the tree of sequential outcomes should be edittable as well.. say you want to splice out one step and do something else instead, after you've declared many promise chains. It doesn't make sense to reconstruct the promise and every sequential function, especially since you can't even reject or destroy the promise either...

side note: not sure if i would use this API client side since not all browsers support it. — Stian Standahl, Jun 06 '16 at 07:35
You may find this useful: [When would someone need to create a deferred](http://stackoverflow.com/questions/32853105/when-would-someone-need-to-create-a-deferred/32857145#32857145) which talks about how the executor can be used for all situations. Also [Promises for promises that are yet to be created without using the deferred antipattern](http://stackoverflow.com/questions/37426037/promises-for-promises-that-are-yet-to-be-created-without-using-the-deferred-ant). — jfriend00, Jun 06 '16 at 07:50
The ability to resolve or reject a promise is a privileged feature that is, by default, only available to the code that creates the promise. The executor sets it up that way. If the executor wants to assign the resolve or reject handler outside the closure, it can do so to enable other code to call it. But, by default, it is private to the executor and this is done on purpose. — jfriend00, Jun 06 '16 at 07:53
I see people saying it's by design, but I don't understand why it's designed that way, how can this be a benefit? — neaumusic, Jun 07 '16 at 03:15
@neaumusic it's encapsulation, no other actor should be responsible for resolving/rejecting a promise they have no business with. Allowing otherwise would make promises nigh unusable, since you'd have _no_ idea whatsoever where something goes wrong, since it can be rejected anywhere. — Creynders, Jun 07 '16 at 09:54

score 17 · Accepted Answer · edited Jul 17 '16 at 15:49

This is called the revealing constructor pattern coined by Domenic.

Basically, the idea is to give you access to parts of an object while that object is not fully constructed yet. Quoting Domenic:

I call this the revealing constructor pattern because the Promise constructor is revealing its internal capabilities, but only to the code that constructs the promise in question. The ability to resolve or reject the promise is only revealed to the constructing code, and is crucially not revealed to anyone using the promise. So if we hand off p to another consumer, say

The past

Initially, promises worked with deferred objects, this is true in the Twisted promises JavaScript promises originated in. This is still true (but often deprecated) in older implementations like Angular's $q, Q, jQuery and old versions of bluebird.

The API went something like:

var d = Deferred();
d.resolve(); 
d.reject();
d.promise; // the actual promise

It worked, but it had a problem. Deferreds and the promise constructor are typically used for converting non-promise APIs to promises. There is a "famous" problem in JavaScript called Zalgo - basically, it means that an API must be synchronous or asynchronous but never both at once.

The thing is - with deferreds it's possible to do something like:

function request(param) {
   var d = Deferred();
   var options = JSON.parse(param);
   d.ajax(function(err, value) { 
      if(err) d.reject(err);
      else d.resolve(value);
   });
}

There is a hidden subtle bug here - if param is not a valid JSON this function throws synchronously, meaning that I have to wrap every promise returning function in both a } catch (e) { and a .catch(e => to catch all errors.

The promise constructor catches such exceptions and converts them to rejections which means you never have to worry about synchronous exceptions vs asynchronous ones with promises. (It guards you on the other side by always executing then callbacks "in the next tick").

In addition, it also required an extra type every developer has to learn about where the promise constructor does not which is pretty nice.

Isn't this already written in your answer to [Difference between defer().promise and Promise](http://stackoverflow.com/a/28692824/1048572)? If you had not answered, I probably would have closed it as a dupe. — Bergi, Jun 06 '16 at 18:01
@Bergi first - I completely forgot about that question! Second - I think the two are pretty different since the question itself is different - the other one is asking about the difference and this one is just about the new API and why it's designed this way. The answer did end up pretty close though. — Benjamin Gruenbaum, Jun 06 '16 at 21:19
Parsing JSON is an example since it will `throw` synchronously and we don't want that to bubble up the synchronous call stack but rather we want that as a part of the promise chain. The constructor reveals inner parts of the object that are not easily exposed elsewhere - it is the revealing side - nothing is "revealed about it". — Benjamin Gruenbaum, Jun 06 '16 at 23:37

jfriend00 · Answer 2 · 2022-10-11T07:10:38.863

FYI, if you're dying to use the deferred interface rather than the Promise executor interface despite all the good reasons against the deferred interface, you can code one trivially once and then use it everywhere (personally I think it's a bad idea to code this way, but your volume of questions on this topic suggests you think differently, so here it is):

function Deferred() {
    var self = this;
    var p = this.promise = new Promise(function(resolve, reject) {
        self.resolve = resolve;
        self.reject = reject;
    });
    this.then = p.then.bind(p);
    this.catch = p.catch.bind(p);
    if (p.finally) {
        this.finally = p.finally.bind(p);
    }
}

Now, you can use the interface you seem to be asking for:

var d = new Deferred();
d.resolve(); 
d.reject();
d.promise;     // the actual promise
d.then(...)    // can use .then() on either the Deferred or the Promise
d.promise.then(...)

Here a slightly more compact ES6 version:

function Deferred() {
    const p = this.promise = new Promise((resolve, reject) => {
        this.resolve = resolve;
        this.reject = reject;
    });
    this.then = p.then.bind(p);
    this.catch = p.catch.bind(p);
    if (p.finally) {
        this.finally = p.finally.bind(p);
    }
}

Or, you can do what you asked for in your question using this Deferred() constructor:

var request = new Deferred();
request.resolve();
request.then(handleSuccess, handleError);

But, it has the downsides pointed out by Benjamin and is not considered the best way to code promises.

Why does the Promise constructor need an executor?

2 Answers2

The past

Linked

Related