有了 async/await,你可以丢掉 promise 链了

阅读数:9001 2019 年 1 月 2 日

异步函数可能会一直存在,但有些人认为 async/await 可能会被抛弃。

为什么?

一个常见的误解是 async/await 和 promise 是完全不同的东西。

但其实 async/await 是基于 promise 的。

不要因为你使用了 promise 就被 promise 链给野蛮绑架了。

在本文中,我们将了解 async/await 如何让开发人员的生活变得更轻松,以及为什么要停止使用 promise 链。

让我们来看看一个 promise 链的例子:

复制代码
getIssue()
.then(issue => getOwner(issue.ownerId))
.then(owner => sendEmail(owner.email, 'Some text'))

现在让我们看看 async/await 的等效代码:

复制代码
const issue = await getIssue()
const owner = await getOwner(issue.ownerId)
await sendEmail(owner.email, 'Some text')

它看起来就像简单的语法糖,对吗?

与大多数人一样,我发现自己的代码看起来很简单、干净、易于阅读。但是,在修改代码时,似乎比预期的困难一些。

但这一点也不奇怪,这正是 promise 链的问题所在。下面让我们看看这是为什么。

易于阅读,易于维护

假设我们需要对之前的代码做出一个很小的修改(例如,我们需要在电子邮件内容中提及问题编号,比如“Some text #issue-number”)。

我们该怎么做?对于 async/await 版本,改起来很简单:

复制代码
const issue = await getIssue()
const owner = await getOwner(issue.ownerId)
await sendEmail(owner.email, `Some text #${issue.number}`) // tiny change here

前两行不受影响,第三行只需要稍微改动一点点。

那么 promise 链版本呢?

在.then() 中,我们可以访问 owner,但不能访问 issue。看看,promise 链从这里开始就变得有点混乱了。我们可以试着这样修改:

复制代码
getIssue()
.then(issue => {
return getOwner(issue.ownerId)
.then(owner => sendEmail(owner.email, `Some text #${issue.number}`))
})

正如你所看到的,一个小的调整就需要修改好几行代码(如 getOwner(issue.ownerId))。

代码在不断发生变化

在开发新功能时尤其如此。例如,如果我们需要将异步调用 getSettings() 返回的结果包含在电子邮件内容中,该怎么办?

它可能看起来像这样:

复制代码
const settings = await getSettings() // we added this
const issue = await getIssue()
const owner = await getOwner(issue.ownerId)
await sendEmail(owner.email,
`Some text #${issue.number}. ${settings.emailFooter}`) // minor change here

如果使用 promise 链该怎样实现?可能是这样:

复制代码
Promise.all([getIssue(), getSettings()])
.then(([issue, settings]) => {
return getOwner(issue.ownerId)
.then(owner => sendEmail(owner.email,
`Some text #${issue.number}. ${settings.emailFooter}`))
})

但是,对我来说,这些代码显得有点乱。每当我们需要做出修改时,都需要修改很多代码,这实在太恶心了!

因为我不想再嵌套 then() 调用,我可以并行地调用 getIssue() 和 getSettings(),所以我使用了 Promise.all(),然后进行一些解构。确实,这个版本与 await 版本相比更好,因为它可以并行运行 ,但它仍然难以阅读。

我们是否可以优化 await 版本,让它可以并行运行而不需要牺牲代码的可读性?让我们来看看:

复制代码
const settings = getSettings() // we don't await here
const issue = await getIssue()
const owner = await getOwner(issue.ownerId)
await sendEmail(owner.email,
`Some text #${issue.number}. ${(await settings).emailFooter}`) // we do it here

我删除了 settings 右侧的 await,并在 sendEmail() 前面加上了 await。我创建了一个 promise,但在需要用到这个值之前不需要等待。与此同时,其他代码可以并行运行。就这么简单!

你不需要 Promise.all()

我已经演示了如何在不使用 Promise.all() 的情况下轻松有效地并行运行 promise。这意味着你不再需要 Promise.all() 了,对吧。

有些人可能会争辩说,还有一个情况,也就是当你有一个值数组时,你需要将它映射到一个 promise 数组。例如,你有一个要读取的文件名的数组,或者你需要下载的 URL 的数组,等等。

我认为他们错了。我的建议是使用外部库来处理并发。例如,我会使用 bluebird 中的 Promise.map(),因为它支持设置并发限制。如果我要下载 N 个文件,可以指定同时下载的文件个数不超过 M 个。

你可以在任何地方使用 await

async/await 可以帮你简化你要做的事情。想象一下,如果使用 promise 链,下面这些表达式有多复杂。但是如果使用 async/await,它们就会简单得多。

复制代码
const value = await foo() || await bar()
const value = calculateSomething(await foo(), await bar())

还说服不了你?

假设你对代码可阅读性和易维护性不感兴趣,相反,你更喜欢复杂性,那么好吧。

在代码中使用 promise 链时,开发者每次在调用 then() 时都会创建新函数。这会占用更多内存,而且这些函数总是处在另一个上下文中。因此,这些函数变成了闭包,这使垃圾回收变得更加困难。此外,这些匿名函数通常会污染堆栈跟踪。

现在,我们讨论的是堆栈跟踪:现在有一个提议用于为异步函数实现更好的堆栈跟踪。

只要开发人员坚持只使用异步函数和异步生成器,并且不会手动编写 promise 代码,因为如果使用了 promise 链,就无法实现更好的堆栈跟踪。

这也是总是使用 async/await 的另一个原因!

如何迁移

首先:开始使用异步函数并停止使用 promise 链。

其次,你可能已经发现 Visual Studio Code 可以非常方便地帮你实现迁移。

视频地址:https://twitter.com/umaar/status/1045655069478334464

结论

  • async/await 已得到广泛支持,除非你需要支持 IE。

  • async/await 代码具有更好的可读性和可维护性。

  • 出于一些技术原因,最好是只使用 async/await。

  • 借助 Visual Studio Code 或其他 IDE,你可以轻松地迁移现有的 promise 链代码!

英文原文:https://blog.logrocket.com/promise-chaining-is-dead-long-live-async-await-445897870abc

收藏

评论

微博

发表评论

注册/登录 InfoQ 发表评论

最新评论

zzs 2019 年 01 月 02 日 17:11 1 回复
但是有时候需要并行执行几个await函数,还是需要用到Promise.al()吧
同意你的观点: var n = await x() var m = await y() 跟promise.all(x(), y()) 是完全不一样的,前者是串联,后者是并联 0 回复
略微纠正一下,是await promise.all([x(),y()]) 0 回复
这位老铁似乎没有认真看完文章就发表评论了?我认为文章中已经给出了一个很好的例子作为想法阐述了(个人而言也很喜欢这个想法),就是把await的位子移动一下…简单举例比如你需要fetch两个文件来分别展示,那么在定义两个fetch行为变量前都不需要加await,只要在使用fetch结果的时候加await。因为fetch这个行为是在定义变量时已经进行的所以也可以说是等同于并行异步了。 然后我这里的想法是这个写法一定程度上添加了思考负担,await语法比迭代器更被人接受就是因为它出色的易读性,只要看到await就明白代码会停下,也会思考这里触发一个异步行为;采用了上述写法后产生的一个问题就是我在看到的await与异步行为并不挂钩:我可能有上百个await,但是实际上异步只进行了一次的。我使用Promise.all进行一次数组解构后得到一个普通变量使用,岂不美哉? 然后下一个,我认为promise的意义更多地应该体现于 同步/异步 的转换,他的魅力一方面来源于对同步语句的异步化(这个说话稍显水货但我一时间想不到什么好的用词,其实也就是promise化),我有可能在等一个事件来了我再执行下一步逻辑,这个时候就是用promise来包裹一下(当然,注意文章抨击的promise链不是promise本体);然后另一方面我认为promise.all/race还是有存在意义的,他能以更高的可读性表达一个逻辑的竞态与依赖,上述的写法把await的地点分散之后,假如我想知道什么时候这个异步是保证完成了的,那么我可能得慢慢找,它的第一次await在哪里,而Promise.all就不一样,你只需要这个变量在何处被引用过,引用他的就是Promise.all的地方,也是异步动作终止的地方。 0 回复
查看更多
孔乙己 2019 年 01 月 02 日 11:46 0 回复
看明白了!
没有更多了