异步JavaScript的进化

async函数近在眼前,但这经过了很长的旅程。不久前我们还在写回调,接着是Promise/A+规范,之后出现 generator函数,现在是async函数。

让我们回头看看异步JavaScript在这些年是如何发展的。

回调

一切都始于回调

异步JavaScript

异步编程,就像我们现在知道在JavaScript中,只能通过该语言的一等公民函数来实现:它们可以像任何其他变量一样传递给其他函数。这就是回调诞生的原因:如果你传递一个函数到另一个函数(或称为高阶函数)作为参数,当工作完成时你可以调用该函数。回调没有返回值,只传值并调用另一个函数。

这些所谓的错误优先(error-first)回调是Node.js自身的核心——核心模块以及NPM上的大多数模块都使用了它。

回调的挑战:

  • 如果使用不当,很容易构建回调地狱或意大利面条式代码。
  • 错误处理很容易被忽视。
  • 不能通过return语句返回值,也不能使用throw关键字。

正因为这些问题,使得JavaScript世界开始寻找可以使异步JavaScript开发变得更容易的解决方案。

答案之一是async 模块。如果你大量使用回调,就会发现并行或顺序运行程序,甚至使用异步函数映射数组会有多复杂。async模块的诞生需要感谢 Caolan McMahon。

使用async,你可以轻松地这样做:

不过,这并不容易阅读和编写,所以有了Promises。

Promises

当今JavaScript的Promise规范可以追溯到2012年,从ES6时可以使用——然而Promises并非从JavaScript社区诞生。这个词于1976年来自 Daniel P. Friedman 。

promise代表异步操作的最终结果。

以前关于Promises的示例看起来像这样:

你会注意到,Promises理所当然地使用了回调。then 和 catch 注册的回调函数要么由异步操作结果触发,要么当无法满足预期条件时调用。Promises的另一个优点是可以链式操作:

在使用Promises时你可能需要在不支持它的运行环境中使用polyfills。一个受欢迎的选择是使用bluebird。这些库可以提供比原生更多的功能,特别是在Promises/A+规范提供的特性受到限制的情况下。

但是你为什么不使用sugar方法?请读 Promises: 扩展的问题。了解Promises的更多信息,请参阅 Promises/A+ 规范。

你可能会问:当大部分库只仅仅公开一个回调接口时,我如何使用Promises?

这很简单——你唯一要做的就是使用一个Promise封装原始的回调函数,像这样:

一些库、框架已经都已经支持,提供一个回调和同时提供Promise接口。如果你今天创建了一个库,同时支持回调和Promise接口是一种很好的实践。你可以很容易地这样做:

甚至更简单,你可以选择从一个仅支持Promise的接口开始,并通过工具提供向后兼容,比如callbackify。Callbackify基本上做了和之前显示的代码片段相同的工作,但方法更简单。

Generators、yield函数

JavaScript Generators是一个相对较新的概念,他们从ES6(也称为ES2015)引入。

是不是很好,当你执行你的函数时,可以在任何时候暂停,计算其他东西,做其他事情,然后返回,带一些返回值并继续?

这正是generator函数为你做的。当我们调用generator函数时它并不会开始运行,我们需要手工迭代。

如果你想更容易地使用generator编写异步JavaScript,你将需要co。

Co是基于generator的控制流,对Node.js和浏览器都适用使用promises,可以让你用更好地方式编写非阻塞代码。

使用co,我们之前的例子可能看起来像这样:

你可能会问:并行操作运行会怎么样?答案可能比你想象的更简单(在底层它只是Promise.all):

Async、await函数

Async函数在ES7引入,目前只能使用像 babel的编译器。(声明:现在我们谈论的是async关键字,而不是async包)

简而言之,使用async关键字,我们可以完成co和generators组合在一起做的事情——hacking编程方式除外。

你可能感兴趣的:(前端开发)