Javascript Promises vs Async Await.区别？

我已经在我的应用程序中使用ES6和ES7功能(感谢Babel) - 包括移动和网络.

第一步显然是ES6级别.我学到了很多异步模式,承诺(很有前途),生成器(不确定为什么是*符号)等等,其中,Promises非常适合我的目的.而且我一直在我的应用程序中使用它们.

这是我如何实现基本承诺的示例/伪代码 -

var myPromise = new Promise(
    function (resolve,reject) {
      var x = MyDataStore(myObj);
      resolve(x);
    });

myPromise.then(
  function (x) {
    init(x);
});

随着时间的流逝,我碰到ES7的功能,并将它们作为一个ASYNC和AWAIT关键字/功能.这些结合起来有很大的奇迹.我已经开始取代我的一些承诺了async & await.它们似乎为编程风格增添了很多价值.

同样,这里是我的async,await函数看起来像的伪代码 -

async function myAsyncFunction (myObj) {
    var x = new MyDataStore(myObj);
    return await x.init();
}
var returnVal = await myAsyncFunction(obj);

保持语法错误(如果有的话),他们两个做同样的事情是我的感觉.我几乎能够用异步替换我的大部分承诺,等待着.

我的问题是,为什么异步,等待Promises做类似的工作？async,等待解决更大的问题吗？或者它只是回调地狱的另一种解决方案？正如我之前所说,我能够使用Promises和Async,Await来解决同样的问题.是否存在Async Await解决的具体内容？

附加说明:我一直在我的ReactJS项目和节点模块中广泛使用Async,Awaits和Promises.ReactJS特别是早期的鸟类,并采用了很多ES6和ES7功能.

当Promises做类似的工作时,为什么需要异步,等待？async,等待解决更大的问题吗？

async/await简单地给你一个异步代码的同步感觉.这是一种非常优雅的语法糖形式.

对于简单的查询和数据操作,Promises可以很简单,但是如果遇到复杂的数据操作和涉及的内容的场景,如果代码看起来好像是同步的话,更容易理解发生了什么(换句话说,语法本身就是一种async/await可以绕过的"偶然复杂性"的形式.

如果您有兴趣知道,可以使用像co(和发电机一样)的库来提供同样的感觉.已经开发出类似这样的东西来解决async/await最终解决的问题(原生).

Async/Await在更复杂的场景中提供了更好的语法.特别是,任何处理循环或某些其他结构的东西,比如try/ catch.

例如:

while (!value) {
  const intermediate = await operation1();
  value = await operation2(intermediate);
}

只使用Promises,这个例子会更复杂.

为什么Promises做类似的工作时需要异步等待？异步等待解决更大的问题吗？或只是回调地狱的另一种解决方案？如前所述，我可以使用Promises和Async，Await解决相同的问题。Async Await解决了什么具体问题？

首先，您必须了解async/ await语法只是语法糖，旨在增强承诺。实际上，async函数的返回值是一个承诺。async/ await语法使我们有可能以同步方式编写异步代码。这是一个例子：

承诺链：

function logFetch(url) {
  return fetch(url)
    .then(response => response.text())
    .then(text => {
      console.log(text);
    }).catch(err => {
      console.error('fetch failed', err);
    });
}

Async 功能：

async function logFetch(url) {
  try {
    const response = await fetch(url);
    console.log(await response.text());
  }
  catch (err) {
    console.log('fetch failed', err);
  }
}

在上面的示例中，await等待promise（fetch(url)）被解决或被拒绝。如果承诺被解决，则值将存储在response变量中，如果承诺被拒绝，则将抛出错误并进入程序catch段。

我们已经可以看到，使用async/ await可能比诺言链更具可读性。当我们使用的承诺数量增加时，尤其如此。Promise链接和async/ await解决了回调地狱的问题，您选择哪种方法取决于个人喜好。

充分比较利弊.

简单的JavaScript

优点

不需要任何其他库或技术

表现最佳

提供与第三方库的最佳兼容性

允许创建临时和更高级的算法

缺点

可能需要额外的代码和相对复杂的算法

异步(库)

优点

简化最常见的控制流模式

仍然是一个基于回调的解决方案

很好的表现

缺点

引入外部依赖

对于先进的飞行来说,可能仍然不够

承诺

优点

大大简化了最常见的控制流程模式

强大的错误处理

ES2015规范的一部分

保证延迟调用onFulfilled和onRejected

缺点

需要promisify基于回调的API

引入一小部分性能

发电机

优点

使非阻塞API看起来像阻塞API

简化错误处理

ES2015规范的一部分

缺点

需要一个互补的控制流程库

仍然需要回调或承诺来实现非顺序流

需要thunkify或promisify基于非生成器的API

异步等待

优点

使非阻塞API看起来像阻塞

清晰直观的语法

缺点

需要Babel或其他转发器以及今天使用的一些配置

在需要复杂控制流的情况下,Async/await可以帮助您使代码更清晰,更易读.它还可以生成更多适合调试的代码.并且可以同时处理同步和异步错误try/catch.

我最近写了这篇文章,展示了async/await over promises在一些常见用例中的优势,代码示例为https://hackernoon.com/6-reasons-why-javascripts-async-await-blows-promises-away-tutorial- c7ec10518dd9