摘要：

async can be transformed to promise. So, if we want to understand async, we have to understand promise first.

Normally, promise is easy to understand, especially when using like this:

promise
  .then(() => {
    //
  })
  .then(() => {
    //
  })
  .then(() => {
    //
  })

then after then would make the order of async callbacks clear. Actually we shouldn"t rely on async callbacks order. But a certain execution order would make me feel more comfortable. However, sometimes, things are different.

Normally, I initialize a promise by Promise.resolve() because it seems too troublesome to use Promise constructor like below which I called it RESOLVE in this article.

new Promise((resolve,reject)=>{
  resolve()
})

Also, I would use promise in this article for reference to thenable. Because in most cases, we uses promise and promise is the subset of thenable.

Normally, I used it by Promise.resolve(non-thenable) which is equivalent to RESOLVE(non-thenable)

new Promise((resolve, reject) => {
  resolve(non-thenable)
})

So, it doesn"t matter which one you choose. RESOLVE(non-thenable) or Promise.resolve(non-thenable).

However, when it comes to thenable, things are different. Promise.resolve(thenable) is not equivalent to RESOLVE(thenable)

new Promise((resolve, reject) => {
  resolve(thenable)
})

I explained it carefully in What"s the difference between resolve(promise) and resolve("non-thenable-object")?. And here is the conclusion:

for non-thenable, Promise.resolve(non-thenable) is equivalent to RESOLVE(non-thenable)

for thenable, Promise.resolve(thenable) is not equivalent to RESOLVE(thenable) because RESOLVE(thenable)

new Promise((resolve, reject) => {
  resolve(thenable)
})

is equivalent to

new Promise((resolve, reject) => {
  Promise.resolve().then(() => {
    thenable.then(resolve)
  })
})

according to spec. It"s obviously not equivalent to Promise.resolve(thenable). You can test it by this example:

let p1 = Promise.resolve(1)
Promise.resolve(p1).then(res => {
  console.log(res)
})
p1.then(res => {
  console.log(2)
})
//1
//2

while

let p1 = Promise.resolve(1)
new Promise((resolve, reject) => {
  resolve(p1)
}).then(res => {
  console.log(res)
})
p1.then(res => {
  console.log(2)
})
//2
//1

So, here comes another question. When would we use Promise.resolve(thenable) or RESOLVE(thenable)? It doesn"t seem to be that common.

Yes, indeed. Except async and await.

As we all know or spec says that the result of async returns promise. For example:

(async function(){}()).toString() //"[object Promise]"

And await can be used in async.

So, how does await work in async? According to spec:Await:

We can transform await code

const p1 = Promise.resolve(1)
const async1 = async function() {
  const res1 = await p1
  console.log(res1)
}
async1()
p1.then(() => console.log("after gen"))

to

const p1 = Promise.resolve(1)
const async1 = async function() {
  new Promise(resolve => {
    resolve(p1)
  }).then(res => {
    const res1 = res
    console.log(res1)
  })
}
async1()
p1.then(() => console.log("after gen"))

The result is the same on chrome 70:

after gen
1

However, in chrome canary 73 the former result is

1
after gen

Why?

The reason can be found in https://github.com/tc39/ecma2... Simply say, the spec to await was going to change to:

What"s difference?

The difference is exactly the difference between RESOLVE(thenable) and Promise.resolve(thenable).

In the past and chrome 70, we are using RESOLVE(thenable), so I transformed the code like above. If using this new spec, the code should be transformed to

const p1 = Promise.resolve(1)
const async1 = async function() {
  Promise.resolve(p1).then(res => {
    const res1 = res
    console.log(res1)
  })
}
async1()
p1.then(() => console.log("after gen"))

In this case, chrome 70 and canary 73 would all get

1
after gen

That"s the spec change for await. Hope you both understand the way before and after change.

Now, let"s talk about async. How does async work? According to spec:

The spawn used in the above desugaring is a call to the following algorithm. This algorithm does not need to be exposed directly as an API to user code, it is part of the semantics of async functions.

And the spawn is

function spawn (genF, self) {
  return new Promise(function (resolve, reject) {
    var gen = genF.call(self)
    function step (nextF) {
      var next
      try {
        next = nextF()
      } catch (e) {
        // finished with failure, reject the promise
        reject(e)
        return
      }
      if (next.done) {
        // finished with success, resolve the promise
        resolve(next.value)
        return
      }
      // not finished, chain off the yielded promise and `step` again
      Promise.resolve(next.value).then(
        function (v) {
          step(function () {
            return gen.next(v)
          })
        },
        function (e) {
          step(function () {
            return gen.throw(e)
          })
        }
      )
    }
    step(function () {
      return gen.next(undefined)
    })
  })
}

However, I think the spawn is the future version which doesn"t apply to chrome 70 because it used Promise.resolve(next.value) instead of RESOLVE(next.value) to transform await. So, I thought the old version or version applied to chrome 70 should be

function spawn (genF, self) {
  return new Promise(function (resolve, reject) {
    var gen = genF.call(self)
    function step (nextF) {
      var next
      try {
        next = nextF()
      } catch (e) {
        // finished with failure, reject the promise
        reject(e)
        return
      }
      if (next.done) {
        // finished with success, resolve the promise
        resolve(next.value)
        return
      }
      // not finished, chain off the yielded promise and `step` again
      /* modified line */
      new Promise(resolve => resolve(next.value)).then(
        /* origin line */
        // Promise.resolve(next.value).then(
        function (v) {
          step(function () {
            return gen.next(v)
          })
        },
        function (e) {
          step(function () {
            return gen.throw(e)
          })
        }
      )
    }
    step(function () {
      return gen.next(undefined)
    })
  })
}

You can tested it by comparing the result of below example.

const p1 = Promise.resolve(1)
const async1 = async function () {
  const res1 = await p1
  console.log(res1)
}
async1()
p1.then(() => console.log("after gen"))

with

const p1 = Promise.resolve(1)
const gen = function* () {
  const res1 = yield p1
  console.log(res1)
}
const async1Eq = function () {
  spawn(gen, this)
}
async1Eq()
p1.then(() => console.log("after gen"))

The result would be:

On chrome 70, with the former spawn, you will get the different result. While you will get the same result with the latter spawn.

In the same way, on chrome 73, with the former spawn, you will get the same result. While you will get the different result with the latter spawn.

As async return value is using a RESOLVE, so it might be a little delay when return promise in async function body. For example:

const p1 = Promise.resolve(1)
const async1 = async () => {
  return p1
}
async1().then(res => {
  console.log(res)
})
p1.then(res => {
  console.log(2)
}).then(res => {
  console.log(3)
})

chrome 70 ,73 all returns

2
3
1

That"s correct. Because spec: Runtime Semantics: EvaluateBody uses RESOLVE in async implementation.

So, why not using Promise.resolve() in async implementation like await? @MayaLekova explained in https://github.com/tc39/ecma2... ,

Deferring the implicit creation of the wrapper promise inside async functions in case we actually need to await on an asynchronous task (which excludes async functions without await or with awaits only on resolved promises) will indeed remove the performance overhead of turning a synchronous function to asynchronous. It will though introduce the possibility to create starvation, for instance if the await statement is in a loop. This possibility outweighs the performance gain IMO, so it"s better not to do it.
Second, if we want to remove the extra tick for chaining native, non-patched promises (introduce "eager" chaining), this will effectively change observable behaviour for applications already shipping with native promises. Think of it as changing the behaviour of line 2 from above to be equivalent to line 3, which will actually introduce further inconsistency.

So, in current situation, we can only transform code above by RESOLVE.

const p1 = Promise.resolve(1)
const async1 = () => {
  return new Promise(resolve => {
    resolve(p1)
  })
}
async1().then(res => {
  console.log(res)
})
p1.then(res => {
  console.log(2)
}).then(res => {
  console.log(3)
})

which is equivalent to

const p1 = Promise.resolve(1)
const async1 = () => {
  return new Promise(resolve => {
    return Promise.resolve().then(() => {
      p1.then(resolve)
    })
  })
}
async1().then(res => {
  console.log(res)
})
p1.then(res => {
  console.log(2)
}).then(res => {
  console.log(3)
})

So, if implementation or spec of async doesn"t change, we may need to avoid return promise in async expect you really know what"s happening.

In the case above, if you really want to avoid the delay, you should avoid using async. You can do it by:

const p1 = Promise.resolve(1)
const async1 = () => {
  return p1
}
async1().then(res => {
  console.log(res)
})
p1.then(res => {
  console.log(2)
}).then(res => {
  console.log(3)
})

which can be written to

const p1 = Promise.resolve(1)
p1.then(res => {
  console.log(res)
})
p1.then(res => {
  console.log(2)
}).then(res => {
  console.log(3)
})

That"s why I love promise instead of async.

I hope you can understand async, await and promise execution order now. When talking about these words, the most important thing is to figure out which resolve it should use.

RESOLVE or Promise.resolve()? RESOLVE(thenable) is different from Promise.resolve(thenable)