成人国产在线小视频_日韩寡妇人妻调教在线播放_色成人www永久在线观看_2018国产精品久久_亚洲欧美高清在线30p_亚洲少妇综合一区_黄色在线播放国产_亚洲另类技巧小说校园_国产主播xx日韩_a级毛片在线免费

資訊專欄INFORMATION COLUMN

精讀《async/await 是把雙刃劍》

2shou / 2861人閱讀

摘要：本周精讀內(nèi)容是逃離地獄。精讀仔細(xì)思考為什么會被濫用，筆者認(rèn)為是它的功能比較反直覺導(dǎo)致的。同時，筆者認(rèn)為，也不要過渡利用新特性修復(fù)新特性帶來的問題，這樣反而導(dǎo)致代碼可讀性下降。

本周精讀內(nèi)容是 《逃離 async/await 地獄》。

1 引言

終于，async/await 也被吐槽了。Aditya Agarwal 認(rèn)為 async/await 語法讓我們陷入了新的麻煩之中。

其實(shí)，筆者也早就覺得哪兒不對勁了，終于有個人把實(shí)話說了出來，async/await 可能會帶來麻煩。

2 概述

下面是隨處可見的現(xiàn)代化前端代碼：

(async () => {
  const pizzaData = await getPizzaData(); // async call
  const drinkData = await getDrinkData(); // async call
  const chosenPizza = choosePizza(); // sync call
  const chosenDrink = chooseDrink(); // sync call
  await addPizzaToCart(chosenPizza); // async call
  await addDrinkToCart(chosenDrink); // async call
  orderItems(); // async call
})();

await 語法本身沒有問題，有時候可能是使用者用錯了。當(dāng) pizzaData 與 drinkData 之間沒有依賴時，順序的 await 會最多讓執(zhí)行時間增加一倍的 getPizzaData 函數(shù)時間，因?yàn)?getPizzaData 與 getDrinkData 應(yīng)該并行執(zhí)行。

回到我們吐槽的回調(diào)地獄，雖然代碼比較丑，帶起碼兩行回調(diào)代碼并不會帶來阻塞。

看來語法的簡化，帶來了性能問題，而且直接影響到用戶體驗(yàn)，是不是值得我們反思一下？

正確的做法應(yīng)該是先同時執(zhí)行函數(shù)，再 await 返回值，這樣可以并行執(zhí)行異步函數(shù)：

(async () => {
  const pizzaPromise = selectPizza();
  const drinkPromise = selectDrink();
  await pizzaPromise;
  await drinkPromise;
  orderItems(); // async call
})();

或者使用 Promise.all 可以讓代碼更可讀：

(async () => {
  Promise.all([selectPizza(), selectDrink()]).then(orderItems); // async call
})();

看來不要隨意的 await，它很可能讓你代碼性能降低。

3 精讀

仔細(xì)思考為什么 async/await 會被濫用，筆者認(rèn)為是它的功能比較反直覺導(dǎo)致的。

首先 async/await 真的是語法糖，功能也僅是讓代碼寫的舒服一些。先不看它的語法或者特性，僅從語法糖三個字，就能看出它一定是局限了某些能力。

舉個例子，我們利用 html 標(biāo)簽封裝了一個組件，帶來了便利性的同時，其功能一定是 html 的子集。又比如，某個輪子哥覺得某個組件 api 太復(fù)雜，于是基于它封裝了一個語法糖，我們多半可以認(rèn)為這個便捷性是犧牲了部分功能換來的。

功能完整度與使用便利度一直是相互博弈的，很多框架思想的不同開源版本，幾乎都是把功能完整度與便利度按照不同比例混合的結(jié)果。

那么回到 async/await 它的解決的問題是回調(diào)地獄帶來的災(zāi)難：

a(() => {
  b(() => {
    c();
  });
});

為了減少嵌套結(jié)構(gòu)太多對大腦造成的沖擊，async/await 決定這么寫：

await a();
await b();
await c();

雖然層級上一致了，但邏輯上還是嵌套關(guān)系，這不是另一個程度上增加了大腦負(fù)擔(dān)嗎？而且這個轉(zhuǎn)換還是隱形的，所以許多時候，我們傾向于忽略它，所以造成了語法糖的濫用。

理解語法糖

雖然要正確理解 async/await 的真實(shí)效果比較反人類，但為了清爽的代碼結(jié)構(gòu)，以及防止寫出低性能的代碼，還是挺有必要認(rèn)真理解 async/await 帶來的改變。

首先 async/await 只能實(shí)現(xiàn)一部分回調(diào)支持的功能，也就是僅能方便應(yīng)對層層嵌套的場景。其他場景，就要動一些腦子了。

比如兩對回調(diào)：

a(() => {
  b();
});

c(() => {
  d();
});

如果寫成下面的方式，雖然一定能保證功能一致，但變成了最低效的執(zhí)行方式：

await a();
await b();
await c();
await d();

因?yàn)榉g成回調(diào)，就變成了：

a(() => {
  b(() => {
    c(() => {
      d();
    });
  });
});

然而我們發(fā)現(xiàn)，原始代碼中，函數(shù) c 可以與 a 同時執(zhí)行，但 async/await 語法會讓我們傾向于在 b 執(zhí)行完后，再執(zhí)行 c。

所以當(dāng)我們意識到這一點(diǎn)，可以優(yōu)化一下性能：

const resA = a();
const resC = c();

await resA;
b();
await resC;
d();

但其實(shí)這個邏輯也無法達(dá)到回調(diào)的效果，雖然 a 與 c 同時執(zhí)行了，但 d 原本只要等待 c 執(zhí)行完，現(xiàn)在如果 a 執(zhí)行時間比 c 長，就變成了:

a(() => {
  d();
});

看來只有完全隔離成兩個函數(shù)：

(async () => {
  await a();
  b();
})();

(async () => {
  await c();
  d();
})();

或者利用 Promise.all:

async function ab() {
  await a();
  b();
}

async function cd() {
  await c();
  d();
}

Promise.all([ab(), cd()]);

這就是我想表達(dá)的可怕之處?；卣{(diào)方式這么簡單的過程式代碼，換成 async/await 居然寫完還要反思一下，再反推著去優(yōu)化性能，這簡直比回調(diào)地獄還要可怕。

而且大部分場景代碼是非常復(fù)雜的，同步與 await 混雜在一起，想捋清楚其中的脈絡(luò)，并正確優(yōu)化性能往往是很困難的。但是我們?yōu)槭裁匆约和诳釉偬羁幽?？很多時候還會導(dǎo)致忘了填。

原文作者給出了 Promise.all 的方式簡化邏輯，但筆者認(rèn)為，不要一昧追求 async/await 語法，在必要情況下適當(dāng)使用回調(diào)，是可以增加代碼可讀性的。

4 總結(jié)

async/await 回調(diào)地獄提醒著我們，不要過渡依賴新特性，否則可能帶來的代碼執(zhí)行效率的下降，進(jìn)而影響到用戶體驗(yàn)。同時，筆者認(rèn)為，也不要過渡利用新特性修復(fù)新特性帶來的問題，這樣反而導(dǎo)致代碼可讀性下降。

當(dāng)我翻開 redux 剛火起來那段時期的老代碼，看到了許多過渡抽象、為了用而用的代碼，硬是把兩行代碼能寫完的邏輯，拆到了 3 個文件，分散在 6 行不同位置，我只好用字符串搜索的方式查找線索，最后發(fā)現(xiàn)這個抽象代碼整個項(xiàng)目僅用了一次。

寫出這種代碼的可能性只有一個，就是在精神麻木的情況下，一口氣喝完了 redux 提供的全部雞湯。

就像 async/await 地獄一樣，看到這種 redux 代碼，我覺得遠(yuǎn)不如所謂沒跟上時代的老前端寫出的 jquery 代碼。

決定代碼質(zhì)量的是思維，而非框架或語法，async/await 雖好，但也要適度哦。

5 更多討論 
討論地址是：精讀《逃離 async/await 地獄》 · Issue #82 · dt-fe/weekly

如果你想?yún)⑴c討論，請點(diǎn)擊這里，每周都有新的主題，周末或周一發(fā)布。

文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請注明本文地址：http://systransis.cn/yun/94778.html

相關(guān)文章

  • 前端進(jìn)階資源整理

    摘要：前端進(jìn)階進(jìn)階構(gòu)建項(xiàng)目一配置最佳實(shí)踐狀態(tài)管理之痛點(diǎn)分析與改良開發(fā)中所謂狀態(tài)淺析從時間旅行的烏托邦，看狀態(tài)管理的設(shè)計誤區(qū)使用更好地處理數(shù)據(jù)愛彼迎房源詳情頁中的性能優(yōu)化從零開始，在中構(gòu)建時間旅行式調(diào)試用輕松管理復(fù)雜狀態(tài)如何把業(yè)務(wù)邏輯這個故事講好和 前端進(jìn)階 webpack webpack進(jìn)階構(gòu)建項(xiàng)目(一) Webpack 4 配置最佳實(shí)踐 react Redux狀態(tài)管理之痛點(diǎn)、分析與...

    BlackMass 評論0 收藏0

  • ES6 系列之我們來聊聊 Async

    摘要：標(biāo)準(zhǔn)引入了函數(shù)，使得異步操作變得更加方便。在異步處理上，函數(shù)就是函數(shù)的語法糖。在實(shí)際項(xiàng)目中，錯誤處理邏輯可能會很復(fù)雜，這會導(dǎo)致冗余的代碼。的出現(xiàn)使得就可以捕獲同步和異步的錯誤。如果有錯誤或者不嚴(yán)謹(jǐn)?shù)牡胤?，請?wù)必給予指正，十分感謝。 async ES2017 標(biāo)準(zhǔn)引入了 async 函數(shù)，使得異步操作變得更加方便。 在異步處理上，async 函數(shù)就是 Generator 函數(shù)的語法糖。 ...

    Songlcy 評論0 收藏0

  • 精讀《用 Reduce 實(shí)現(xiàn) Promise 串行執(zhí)行》

    摘要：引言本周精讀的文章是，講了如何利用實(shí)現(xiàn)串行執(zhí)行?？偨Y(jié)串行隊(duì)列一般情況下用的不多，因?yàn)榇袝枞?，而用戶交互往往是并行的。更多討論討論地址是精讀用實(shí)現(xiàn)串行執(zhí)行如果你想?yún)⑴c討論，請點(diǎn)擊這里，每周都有新的主題，周末或周一發(fā)布。 1 引言 本周精讀的文章是 why-using-reduce-to-sequentially-resolve-promises-works，講了如何利用 reduce...

    JinB 評論0 收藏0

  • 精讀《重新思考 Redux》

    摘要：本周精讀內(nèi)容是重新思考。數(shù)據(jù)流對數(shù)據(jù)緩存，性能優(yōu)化，開發(fā)體驗(yàn)優(yōu)化都有進(jìn)一步施展的空間，擁抱插件生態(tài)是一個良好的發(fā)展方向。 本周精讀內(nèi)容是 《重新思考 Redux》。 1 引言 《重新思考 Redux》是 rematch 作者 Shawn McKay 寫的一篇干貨軟文。 dva 之后，有許多基于 redux 的狀態(tài)管理框架，但大部分都很局限，甚至是倒退。但直到看到了 rematch，總算...

    IntMain 評論0 收藏0

  • 精讀《Nodejs V12》

    摘要：更好的安全性隨著的發(fā)布，從升級到了，更安全且更易配置。通過使用，程序可以減少握手所需時間來提升請求性能。提供診斷報告有一項(xiàng)實(shí)驗(yàn)功能，根據(jù)用戶需求提供診斷報告，包括崩潰性能下降內(nèi)存泄露使用高等等。前端精讀幫你篩選靠譜的內(nèi)容。 1. 引言 Node12 發(fā)布有幾個月了，讓我們跟隨 Nodejs 12 一起看看 Node12 帶來了哪些改變。 2. 概述 Node12 與以往的版本不同，帶來...

    CoderStudy 評論0 收藏0

發(fā)表評論

0條評論

最新活動
閱讀需要支付1元查看
<