Open lihongxun945 opened 6 years ago
对 async/await
是 generator 的语法糖有点疑义。个人认为 async/await
只是一种规范,具体的实现还得看对应的浏览器或者库,虽然 Babel 是转成了 Generator 不过我看 Typescript 是直接转成了 Iterator + Promise 的 https://goo.gl/9hNpcQ
@lizheming 严格来说确实没有任何地方说async/await 一定是generator+promise的语法糖。不过 在MDN中有这么一段话,至少从作用上说,二者比较像:
Just as Promises are similar to structured callbacks, async/await is similar to combining generators and promises.
@lihongxun945 感谢回复,其实文章说的 Generator 做流程控制比较方便这点还是非常认同的,或许是因为这点所以做编译的时候 Babel 选择了 Generator 吧。比较抵抗这个说法其实主要是因为 Babel 编译后需要增加 babel-runtime
库来兼容 Generator 的运行时,所以有时候我会去想其实整个过程完全编译成 Promise 也完全没问题呀,为什么要徒增一个 Generator 呢。后来我去参考 Typescript 的时候发现确实没必要一定依赖 Generator,不过就像你说的 Promise 和 Iterator 对状态维护是比较弱的,需要提供额外支持。
PS. 文章中说的是“其实他就是 Generator
的一个语法糖”,而不是“Generator + Promise 的语法糖”。
@lizheming 嗯嗯,我稍微修改了一下。觉得在babel中这个等式比较合理:async/await == generator + promise 如果不看babel的实现,async/await 更像是 promise 的一个语法糖
@lihongxun945 https://mathiasbynens.be/notes/async-stack-traces 这篇文章从堆栈的角度分析 async/await 和 promise 的异同,证明 async/await
肯定不只是 Promise 的语法糖,我觉得论据论证都很棒,推荐之~
@lizheming :+1: 他是从性能角度分析的,对编译器来说肯定不是语法糖。
最后总结,应该是部署了iterator接口,都可以被for of遍历?
最后总结,应该是部署了iterator接口,都可以被for of遍历?
是的。 实现了 iterator 的对象,就可以被迭代
async/await 是语法 Promise 是对象 这些概念性的东西应该先说清楚
这里重点理解他们三者分别是什么,有什么区别,以及分别适用什么场景
Iterator
Iterator是最简单最好理解的,在很久之前我写过一篇文章 循环的秘密 里面讨论了Iterator原理,有兴趣可以看一下。简单的说,我们常用的
for in
循环,都是通过调用被循环对象的一个特殊函数Iterator
来实现的,但是以前这个函数是隐藏的我们无法访问, 从Symbol
引入之后,我们就可以通过Symbol.iterator
来直接读写这个特殊函数。对于循环语句来说,他并不关心被循环的对象到底是什么,他只负责调用
data[Symbol.iterator]
函数,然后根据返回值来进行循环。所以任何对象只要提供了标准的 Iterator 接口即可被循环,比如我们现在来创造一个自定义的数据:除了这种方式外,我们也可以通过
Generator
来实现一个Iterator
接口。Generator 基本语法
Generator 是ES6引入的新语法,Generator是一个可以暂停和继续执行的函数。简单的用法,可以当做一个Iterator来用,进行一些遍历操作。复杂一些的用法,他可以在内部保存一些状态,成为一个状态机。
Generator 基本语法包含两部分:
yield
关键字返回值下面是一个简单的示例:
由于Generator也存在
Symbol.iterator
接口,所以他也可以被for
循环调用:不过这里要注意一个不同点,调用
next
的时候能得到3
,但是用for
则会忽略最后的return
语句。 也就是for
循环会忽略generator
中的return
语句.另外
yeild*
语法可以用来在Generator
中调用另一个Generator
,参见 yield* MDNGenerator VS Iterator
Generator 可以看做是一个更加灵活的
Iterator
,他们之间是可以互相替代的,但是,Generator
由于可以通过yield
随时暂停,因此可以很方便进行流程控制和状态管理,而Iterator
就可能需要你写更多的代码进行相同的操作:比如 Stack Overflow 上的这个中序遍历代码:
同样的功能用
iterator
实现就会变得麻烦很多。Generator 也是实现简单的状态机的最佳选择,因为他是在函数内部进行
yield
操作,因此不会丢失当前状态:同样的功能如果普通的函数,因为每次都是调用这个函数,所以函数内部并不能保存状态,因此就需要在函数外面用一个变量来保存当前状态:
其实Babel编译
Generator
的时候,也是用了一个Context
来保存当前状态的,可以看看Babel编译后的代码,其中的_context
就是当前状态,这里通过_context.next
的值来控制调用next
的时候应该进入到哪一个流程:当然,如果是很复杂的,非线性状态变化的状态机,我还是会倾向于用一个类来实现。
Generator 异步操作
Generator 的设计,可以很方便执行异步操作,现在我们需要写一个小函数,可以取到用户信息然后打印出来,我们用generator来写就是这样的:
但是,generator本身并不会自动进行
next
操作,也就是,我们如果此时这样调用并不能打印出用户信息:因为
Generator
本身只是一个状态机,他需要由调用者来改变他的状态,所以我们需要额外加一段控制代码来控制fetchUser
进行状态转换:但是写了这些代码之后,
Generator
的实现就变得非常不优雅了,如果我们内部有多个异步操作,控制代码就会变得很长。我们可以选择 co 库来帮我们做这个操作。Async/Await
我最开始接触到 Async/Await 的时候把它当成了一个
promise
的语法糖,但是经过我们对Generator
的理解后,明白了其实他就是Generator
的一个语法糖:async
对应的是*
await
对应的是yield
他只是自动帮我们进行了
Generator
的流程控制而已。和上面的获取用户信息实现一样的功能的话,基本语法如下:
因为有自动的流程控制,所以我们不用手动在ajax成功的时候手动调用
next
。相比于Promise
或者Generator
的实现,代码要明显更加优雅。如果有兴趣的话,可以参考一下
Babel
是如何编译Async/Await
的,简单的说,代码分成了两部分,一部分是编译了一个Generator
,另一部分是通过 promise 实现了generator的流程控制。对于如下代码:
编译后的代码:
所以我们可以大约这么认为: async/await == generator + promise
async/await 并发
我们的代码在执行到await的时候会等待结果返回才执行下一行,这样如果我们有很多需要异步执行的操作就会变成一个串行的流程,可能会导致非常慢。
比如如下代码,我们需要遍历获取redis中存储的100个用户的信息:
由于每次数据库读取操作都要消耗时间,这个接口将会变得非常慢。如果我们把它变成一个并行的操作,将会极大提升效率:
总结
Iterator
是一个循环接口,任何实现了此接口的数据都可以被for in
循环遍历Generator
是一个可以暂停和继续执行的函数,他可以完全实现Iterator
的功能,并且由于可以保存上下文,他非常适合实现简单的状态机。另外通过一些流程控制代码的配合,可以比较容易进行异步操作。Async/Await
就是generator进行异步操作的语法糖。而这个语法糖反而是被使用最广泛的,比如著名的Koa
参考