失序的承诺

Question

Given the following code :

p = () ->
  foo 5
  new Promise( (resolve, reject) ->
    console.log 'in promise'
    resolve 'done'
  )

foo = (n) ->
  console.log n
  if(n <= 0) then 0 else foo (n-1)

And then I call it:

p().then (-> console.log 'hi'), (-> console.log 'there')

The output shows:

5
4
3
2
1
0
in promise
hi

First, if I want the entire body of p to occur in the same Promise , must I wrap it in new Promise ( (resolve, reject) ) -> ... ) ?

Second, is it ever possible, by modifying foo , that hi would print before 5/4/3/2/1/0 or in promise ?

Lastly, in which circumstances would the success case of then execute before the p() body fully completes?

Answer 1

First, if I want the entire body of p to occur in the same Promise, must I wrap it in new Promise ( (resolve, reject) ) -> ... )?

Well, yes. If you want the entire body of p to happen in the same promise then you have to put the entire body of p in the same promise. However, as Bergi mentioned in the comments, this still doesn't affect your overall code behavior. Promise construction is a synchronous process, meaning as soon as you create a Promise, the code in its body runs. The part that happens later is the promise resolution (success or fail).

p = () ->
  foo 5                             // happens synchronously
  new Promise( (resolve, reject) ->
    console.log 'in promise'        // happens synchronously
    resolve 'done'                  // happens asynchronously
  )

The following code is equivalent:

p = () -> 
  new Promise( (resolve, reject) ->
    foo 5                           // happens synchronously
    console.log 'in promise'        // happens synchronously
    resolve 'done'                  // happens asynchronously
  )

If you give a more specific use-case, I might be able to give a more specific answer.

Second, is it ever possible, by modifying foo, that hi would print before 5/4/3/2/1/0 or in promise?

Promises resolution, as per specification, always happens asynchronously (in form of microtasks in the Event Loop). This means that all synchronous code, such as your loop in foo , must finish before any promise resolutions happen.

To quote Jake Archibald

Microtasks are usually scheduled for things that should happen straight after the currently executing script, such as reacting to a batch of actions, or to make something async without taking the penalty of a whole new task. The microtask queue is processed after callbacks as long as no other JavaScript is mid-execution, and at the end of each task. Any additional microtasks queued during microtasks are added to the end of the queue and also processed. Microtasks include mutation observer callbacks, and as in the above example, promise callbacks.

Therefore, the only way for you to make things in foo happen after things in p , is to force foo to run asynchronously and after p is finished.

One way to tackle this is to use setTimeout to delay foo 's code after the resolution of the Promise in p . The reason this works is because setTimeout schedules a regular task in the next iteration of the Event Loop while microtasks (and therefore Promises) are specified to run in the same iteration of the Event Loop.

Here's a JS demonstration:

Note : this might not work in every browser. I tested it in Chrome Version 54.0.2840.71. Jake's article has more details about specific browser bugs.

 const foo = (n) => { setTimeout(() => { console.log(n); if (n <= 0) { return 0; } else { return foo(n - 1); } }); } const p = () => { foo(5); return new Promise((resolve) => { console.log('in promise'); resolve('done'); }); } p().then(() => console.log('hi')); /* Output: in promise hi 5 4 3 2 1 0 */ 

Lastly, in which circumstances would the success case of then execute before the p() body fully completes?

In no circumstance because the success case of p().then depends on that internal promise. The success callback passed into then cannot be called until the Promise on which we called then is resolved (either succeeded or failed).

Here's another useful article about tackling these timing situations when writing a JS framework.