Understanding JS Promises

Question

I would like to get a deeper understanding of how Promises work internally. Therefore I have some sample code:

var p1 = new Promise(
  function(resolve, reject) {
    window.setTimeout(
      function() {
        resolve('res called')
      }, 2000);
  });


var p2 = new Promise(
  function(resolve, reject) {
    window.setTimeout(
      function() {
        resolve('res called')
      }, 2000);
  });


function chainPromises() {
  return p1.then(function(val) {
    console.log("p1");
    return p2.then(function(val) {
      console.log("p2");
      return val;
    });
  });
}

chainPromises().then(function(val) {
  console.log(val);
});

Here a link to execute this code.

As you would predict, first p1 is resolved, afterwards p2 and in the end the final then prints the resolv value.

But the API ref states the following:

"then" returns a new promise equivalent to the value you return from onFulfilled/onRejected after being passed through Promise.resolve

So it would be interesting to know WHEN exactly the "then" function is executed? Because the final "then" in the code is chained to the chainPromises(), I first thought that it would execute after the function chainPromises() returns something (in this case another promise).

If this would have been the case the "val" of the final "then" function would be the returned promise. But instead, the final "then" waits until all promises inside the first "then" which are returned have been resolved. This absolutely makes sense because in this way, the "then" functions can be stacked, but I do not really get how this is done, since the API spec. does not really cover what "then" returns and when the "then" functions is executed.

Or in other words, why does the final "then" function wait until all the Promises are resolved inside the chainPromises() function instead of just waiting for the first returned object as the API doc says.

I hope I could make clear what I mean.. :)

Answer 1

About Promise resolution

The thing you're witnessing here is called recursive thenable resolution. The promise resolution process in the Promises/A+ specification contains the following clause:

onFulfilled or onRejected returns a value x, run the Promise Resolution Procedure [[Resolve]](promise2, x)

The ES6 promise specification (promises unwrapping) contains a similar clause.

This mandates that when a resolve operation occurs: either in the promise constructor, by calling Promise.resolve or in your case in a then chain a promise implementation must recursively unwrap the returned value if it is a promise.

In practice

This means that if onFulfilled (the then) returns a value, try to "resolve" the promise value yourself thus recursively waiting for the entire chain.

This means the following:

promiseReturning().then(function(){
    alert(1);
    return foo(); // foo returns a promise
}).then(function(){
    alert(2); // will only run after the ENTIRE chain of `foo` resolved
              // if foo OR ANY PART OF THE CHAIN rejects and it is not handled this 
              // will not run
});

So for example:

promiseReturning().then(function(){
    alert(1);
    return Promise.resolve().then(function(){ throw Error(); });
}).then(function(){
    alert("This will never run");
});

And that:

promiseReturning().then(function(){
    alert(1);
    return Promise.resolve().then(function(){ return delay(2000); });
}).then(function(){
    alert("This will only run after 2000 ms");
});

Is it a good idea?

It's been the topic of much debate in the promises specification process a second chain method that does not exhibit this behavior was discussed but decided against (still available in Chrome, but will be removed soon). You can read about the whole debate in this esdiscuss thread. This behavior is for pragmatic reasons so you wouldn't have to manually do it.

In other languages

It's worth mentioning that other languages do not do this, neither futures in Scala or tasks in C# have this property. For example in C# you'd have to call Task.Unwrap on a task in order to wait for its chain to resolve.

Answer 2

Let's start with an easy perspective: "chainPromises" returns a promise, so you could look at it this way:

// Do all internal promises
var cp = chainPromises();

// After everything is finished you execute the final "then".
cp.then(function(val) {
    console.log(val);
});

Generally speaking, when returning a promise from within a "then" clause, the "then" function of the encapsulating promise will be marked as finished only after the internal "then" has finished.

So, if "a" is a promise, and "b" is a promise:

// "a"'s "then" function will only be marked as finished after "b"'s "then" function has finished.  
var c = a.then(function () {
    return b.then(function () {
        console.log("B!");
    };
};

// c is a promise, since "then" always returns a promise.    
c.then(function() {
    console.log("Done!");
};

So the output will be:

B! 
Done!

Notice btw, that if you don't "return" the internal promise, this will not be the case:

// "a"'s "then" function will only be marked as finished without waiting for "b"'s "then" to finish.  
var c = a.then(function () {
    // Notice we're just calling b.then, and don't "return" it. 
    b.then(function () {
        console.log("B!");
    };
};

// c is a promise, since "then" always returns a promise.    
c.then(function() {
    console.log("Done!");
};

Here we can't know what would be outputted first. It could be either "B!" or "Done!".

Answer 3

Please check the below example regarding how promises works:

The Promise object represents the eventual completion (or failure) of an asynchronous operation, and its resulting value.

console.log('person1: shoe ticket');
console.log('person2: shoe ticket');

const promiseGirlFriendBringingTickets = new Promise((resolve, reject) => {
 setTimeout(() => {
  resolve('ticket');
 }, 3000);
});

promiseGirlFriendBringingTickets.then((t) => {
 console.log(`person3: show ${t}`);
})

console.log('person4: shoe ticket');
console.log('person5: shoe ticket');

Answer 4

I do not know how this is done in actual promises libraries, but I was able to re-create this functionality in the following way: 1) each promise has a waitingPromises property; 2) then method returns a new promise, and the original promise's waitingPromises property points to the new promise.

In this way, the chain of .then()s creates a structure that is similar to a linked list or rather a tree (each promise can have several waiting promises). A promise can be resolved only after its 'parent' promise has been resolved. The .then method itself is executed immediately, but the corresponding promise that it creates is resolved only later. I am not sure this is a good explanation and would love to learn about other possible approaches.

Answer 5

Promise then return promise object, not promise's resolved value. I forked your JsFiddle, and added some of mine try this.

promise.then is executed right after that promise object is resolved.

Answer 6

Normally code is synchronous - one statement executes like (fileopen) and there is a guarantee that the next statement will execute immediately afterwards like filewrite()

but in asynchronous operations like nodejs, you should assume that

• you have no idea when the operation will complete.
• You can't even assume that just because you send out one request first, and another request second, that they will return in that order
• Callbacks are the standard way of handling asynchrnous code in JavaScript
• but promises are the best way to handle asynchronous code.
• This is because callbacks make error handling difficult, and lead to ugly nested code.
• which user and programmer not readble easily so promises is the way

Answer 7

You can think of Promise as a wrapper on some background task. It takes in a function which needs to be executed in the background.

The most appropriate place to use a promise is where some code is dependent on some background processing and it needs to know the status of the background task which was executed. For that, the background task itself accepts two callback resolve and reject in order to convey its status to the code which is dependent on it. In layman terms, this code is the one behind it in the promise chain.

When a background task invokes resolve callback with some parameter. it's marking the background operation successful and passing the result of the background operation to the next then block which will be executed next. and if it calls reject, marking it as unsuccessful then the first catch block will be executed. In your custom promise, you can pass an error obj to the reject callback so that next catch block is aware of the error happened in the background task.