等待承诺链有什么问题？

Question

等待承诺链有什么问题？我正在研究一个Angular 6应用程序，我被告知以下是一个反模式：await someFunction().then(result => {     console.log(result);});我意识到等待承诺链是毫无意义的。如果someFunction（）返回一个promise，那么如果你正在等待它，则不需要一个promise链。你可以这样做：const result = await someFunction();console.log(result);但我被告知等待一个承诺链可能会导致错误，或者它会破坏我的代码中的东西。如果上面的第一个代码片段与第二个代码段完全相同，那么使用哪个代码片段至关重要。第一个片段引入了哪个危险，第二个片段没有？

Answer 1

在引擎盖下，async / await就是承诺。

也就是说，当你有一些看起来像这样的代码时：

const result = await myAsyncFunction();   console.log(result):

这和写作完全一样：

myAsyncFunction().then(data => {
   const result = data; 
   console.log(result); });

之所以 - 你不应该混合async / await和.then链 - 是因为它令人困惑。

最好选择一种风格，并坚持下去。

当你选择一个时 - 你也可以选择异步/等待 - 这更容易理解。

Answer 2

我被告知等待一个承诺链会破坏我的代码中的东西。

不一定，你的两个代码片段确实工作相同（只要someFunction()真正返回一个promise）。

使用哪一个有什么关系。第一个片段引入了哪个危险，第二个片段没有？

理解和维护起来比较困难，混合不同风格会令人困惑。混乱导致错误。

考虑您需要在调用位置添加另一个promise console.log()调用，甚至是函数的条件返回。你可以await像在函数中的其他地方一样使用回调，你需要回调return的结果then，甚至可以return从外部函数？所有这些问题甚至都没有出现在第一个片段中。虽然它们可以很容易地回答您的玩具示例，但在实际代码中可能并不那么容易，而且控制流程更加复杂和嵌套。

所以你应该更喜欢更简洁和干净的。粘到await对一致性，避免then在async function小号¹。

Answer 3

如果你的then代码返回了一个promise而不是调用console.log，那么你的第一个例子就是await，但你的第二个例子不会。

当您使用时async/await，您将在try/catch块中捕获您的拒绝。您的代码将更少嵌套和更清晰。

使用then通常会导致更多嵌套，并且更难以阅读代码。

await无论是否返回，你都可以做任何事情promise。有时这种未来证明调用一种方法可能有一天会变得异步或只返回一个承诺而不声明异步。

缺点是复杂性，性能和兼容性，所有这些都与收益相比显得苍白无力。

我发现，如果你在调用函数后依赖函数的返回值，它是或者最终会异步，那么装饰调用你的函数await会让你心满意足，无论它是当前的异步还是返回一个promise。