async/await or promise

本次更新中，我也将部分代码用了async/await的方式替代了原有的 promise方式，主要是 @/src/permission.js。有兴趣的大家自己可以通过 git-history 自己对比下，可以发现代码阅读性高了不少。 不过本项目中也并没有把所有promise用async/await替代。我来简单说一下我的看法。

 

6 个 Async/Await 优于 Promise 的方面，这篇文章很多人应该都看过，里面大部分观点我都是同意的，大部分复杂场景下async/await的确是更优解。但相对的也不是所有的情况下都是async/await写起来让我更爽的。先说说我最不爽的地方是它的错误处理，try catch让这个代码结构看起来就很奇怪（当然也有很多人很喜欢这种错误处理形式。社区也是相对的解决方案类似go语言的风格，比如 await-to-js

[err, res] = await to(getInfo())
if(err) //do something

这个方案是不错，但还需要引入一个新的库，增加了学习成本，得不偿失。所以以我个人的习惯，当只有一个异步请求，且需要做错误处理的情况下，更倾向于使用 promise。比如

// promise
getInfo()
  .then(res => {
    //do somethings
  })
  .catch(err => {
    //do somethings
  })

// async/await
try {
  const res = await getInfo()
  //do somethings
} catch (error) {
  //do somethings
}

在有嵌套请求的情况下，肯定是 async/await 更直观的。

// promise
a(() => {
  b(() => {
    c()
  })
})

// async/await
await a()
await b()
await c()

当然代码写的好与不好还是取决于写代码的人的。比如一个常见的业务场景：有两个并发的异步请求，在都完成后do something。但很多人会错误的用串行的方式实现了。

//错误
await a()
await b()
//这样变成了 a().then(() => b() )
// a 好了才会执行 b
done()

//正确
await Promise.all([a(), b()])
done()

还有一个小细节async/await打包后的代码其实会比 promise 复杂很多， 当然这个是一个忽略不计得问题。

 

总结：我认为它们两个人并不是or的关系，在特定的业务场景下，选择相对而言代码可读性更好地解决方案。

以上所述纯个人偏爱，并非什么最佳实现。具体该怎么选择还是需要大家更具自己团队的风格或者自己的理解来判断。

作者：花裤衩
链接：https://juejin.cn/post/6844903840626507784
来源：稀土掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。