将promise转换为异步等待时的时间

Question

I have the following block

return this
        .configure(config => {
          viewModel.configure(config, this);
          return config;
        })
        .then(() => {
          this.activate();
        });

which, is equivalent to following block, suggested by vscode auto promise->async/await conversion:

await this.configure(config => {
  viewModel.configure(config, this);
  return config;
});
this.activate();

My question is are they actually the same in timing? In the promise example, shouldn't the second fn in then() 1 micro task away from the callback that accepts config ?

Extra question for clarity: are the following equal in timing perspective:

Promise.all(tasks)
  .then(() => {
    othertasks.forEach(() => doStuff());
  })
  .then(() => {
    prune();
  });

and:

await Promise.all(tasks);
othertasks.forEach(() => doStuff();
await Promise.resolve();
prune();

Answer 1

EDIT : I should clarify, with regards to Andrea Giammarchi's answer, that my answer was purely and only related to the difference in number of ticks in-between the synchronously executed code, not whether the result of that code as-written is actually equivalent (obviously, the non-awaited promises would yield promises whereas the awaited promises would yield the values)

This would make more sense in the context that me and bigopon had a discussion in a github issue where he accepted VS Code's suggestion to remove a "redundant" .then from a promise chain in a piece of legacy code that happens to be sensitive to subtle timing issues.

I pointed out that this change would cause a particular method to be executed one tick earlier, and that the effects of that could potentially break complex apps relying on these (quirky) timings.

The discussion was then, whether this:

somePromise.then(() => {
   ...
}).then(() => {
   doStuff();
})

Would have the same timings as this:

await somePromise;
doStuff();

To which my answer was: no, the doStuff() in the second snippet would execute one tick earlier.

When someone else suggested that await or .then would actually be executed synchronously if the passed-in promise was already resolved, that motivated me to write this answer and clarify why not.

I do realize that without this context, my answer can seem misleading, but again: it's just to point out the similarity in number of ticks.

Original answer

Example 1

For resolving a value, in plain terms, this:

await something

Is equivalent to this:

Promise.resolve(something).then()

They both result in a pending promise.

Example 2

For queueing a task, this:

await Promise.resolve();
doStuff();

Is equivalent to this:

Promise.resolve().then(() => {
    doStuff();
})

In both cases, doStuff() happens on the next tick.

In order to determine whether a regular .then chain is equivalent to a series of await s, you simply need to count .then and await . If the number of each is the same between two given pieces of code, then the amount of time/ticks/whatever passing between those pieces of code will be the same.

Example 3

Another example, this:

await Promise.resolve();
doStuff();
await Promise.resolve();
doStuff();
await Promise.resolve();
await Promise.resolve();
doStuff();

Is equivalent to this:

Promise.resolve()
.then(() => {
    doStuff();
})
.then(() => {
    doStuff();
})
.then(() => {})
.then(() => {
    doStuff();
})

Note that the Promise.resolve() itself has no effect on the timings. It returns a resolved promise. It's the then() / await that turns it into a pending one.

So I respectfully disagree with amadan and I believe both your examples are equivalent.

What the spec says

7. If promise.[[PromiseState]] is "pending", then

   a. Append fulfillReaction as the last element of the List that is promise.[[PromiseFulfillReactions]].

   b. Append rejectReaction as the last element of the List that is promise.[[PromiseRejectReactions]].

8. Else if promise.[[PromiseState]] is "fulfilled", then

   a. Let value be promise.[[PromiseResult]].

   b. Perform EnqueueJob("PromiseJobs", PromiseReactionJob, « fulfillReaction, value »).

What this says is "if the promise is already pending, simply append the fulfillReaction of that pending promise, but of the promise is fulfilled, then enqueue a new job".

In other words, .then is guaranteed to return a pending promise regardless of whether the promise it is chained on was fulfilled or not .

Answer 2

I think there is quite some confusion in both what happened with VSCode, what you asked as question, and the kind of answer you received.

I'll try to clarify all points as I can, hoping I got the question right.

Let me start saying that ...

Those two blocks are not equivalent

The following piece of code:

this
  .configure(config => {
    viewModel.configure(config, this);
    return config;
  })
  .then(value => `some ${value}`);

is " equivalent " only to this one:

await this
  .configure(config => {
    viewModel.configure(config, this);
    return config;
  })
  .then(value => `some ${value}`);

That is because await has less priority than method chaining/ then concatenation.

(async function (){
  const then = await Promise.resolve(1).then(one => one + one);
  console.log(then); // this is number 2
  const something = await 123;
  console.log(something); // this is number 123
}());

The reason you are rightly confused is that VSCode outsmarted your intent.

  return this
    .configure(config => {
      viewModel.configure(config, this);
      // configure() returns a Promise
      // and config can be a Promise too
      return config;
    })
    .then(() => {
      // but you are not using here the config value
      // or, if it was a promise, whatever value it resolved
      // and you are also not returning any value
      this.activate();
    });

Since VSCode knows that configure is thenable , and its returned value could also be a Promise, which would imply the activate can happen only after config is eventually resolved, it also knows having an extra tick would make no sense because you don't need whatever config returned, either as value or promise, so that activate can be called right away.

Since you were also not returning any value in the last then , the whole return can be dropped.

// only async to wait for
await this.configure(config => {
  viewModel.configure(config, this);
  return config;
});
// with config either value or promise
// there's nothing else to wait for, so
// let's invoke activate without returning
// anything, producing is the same undefined result
this.activate();

To recap what happens inside that await:

(async function (){
  const config = new Promise(res => setTimeout(res, 1000));
  console.time('awaiting');
  const value = await Promise.resolve(1).then(() => {
    return config;
  });
  console.timeEnd('awaiting');
  // awaiting: 1000.XXXms
}());

If you were by any chance using the returned value inside that last then , you would've seen that VSCode could not have dropped it, most-likely readdressed as const value = await ...; this.activate(value); const value = await ...; this.activate(value); which is also still OK.

---

To the previous comment stating:

For resolving a value, in plain terms, this:

await something

Is equivalent to this:

Promise.resolve(something).then()

They both result in a pending promise.

Not sure I read that wrong but that that felt to me quite a misleading statement.

const resolved = await anything means resolved is always a value, never a pending promise.

That's quite possibly the whole point of await : it won't stop awaiting until there is a value.

Example:

(async function (){
  const something = Promise.resolve(Math.random());
  // this logs the random number as typeof number
  console.log(await something);
  // this also logs the random number as typeof number
  console.log(await Promise.resolve(something).then());
  // while this is one is the only pending promise
  console.log(Promise.resolve(something).then());
}());

The reason you eventually see Pending promise in console is that the AIIFE (Asynchronous Immediately Invoked Function Expression) is a promise itself and you can await it elsewhere.

You can see that returning a value or a pending promise will always produce the expected result.

(async function (){
  // instant return, it's just fine
  // return 123;

  // return promise (unnecessary ticks added)
  return Promise.resolve(123).then();
}()).then(console.log);

In both cases the 123 number is logged.

I hope it's clear now, specially for the OP, what happened in VSCode, and, specially, why happened.

Regards.