避免地獄async await的使用及原理解析

Posted on by

引言

無論你對async/await的立場如何，我都想向你說明，根據我的經驗，為什麼async/await往往會使代碼復雜度更高，而不是更低。

JavaScript中的async/await功能的效用是基於這樣的想法：異步代碼很難，相比之下，同步代碼更容易。這在客觀上是正確的，但在大多數情況下，我不認為async/await真的能解決這個問題。

謊言和async/await

我用來確定是否要使用某個模式的指標之一是它所帶來的代碼綜合質量。例如，一個模式可能是幹凈的、簡潔的或廣泛使用的，但如果它導致瞭容易出錯的代碼，它就是一個我可能會拒絕的模式。這些模式是雙刃劍，很容易搬起石頭砸自己的腳。

首先，它是建立在一個謊言之上的。

Async/await讓你的異步代碼看起來像同步的一樣。

這是它的賣點。但對我來說，這就是問題所在。它從一開始就為你的代碼所發生的事情設定瞭錯誤的心理模型。同步代碼可能比異步代碼更容易處理，但同步代碼不是異步代碼。它們有非常不同的屬性。

很多時候這不是問題，但當它是問題時，就很難識別，因為async/await正好隱藏瞭顯示它的線索。以這段代碼為例。

同步代碼

const processData = ({ userData, sessionPrefences }) => {
  save('userData', userData);
  save('session', sessionPrefences);
  return { userData, sessionPrefences }
}

Async/Await

const processData = async ({ userData, sessionPrefences }) => {
  await save('userData', userData);
  await save('session', sessionPrefences);
  return { userData, sessionPrefences }
}

Promise

const processData = ({ userData, sessionPrefences }) =>   save('userData', userData)
  .then(() => save('session', sessionPrefences))
  .then(() => ({ userData, sessionPrefences })

這裡有一些性能問題。我們已經把問題縮小到瞭processData函數上。在這三種情況中，你對優化途徑的假設是什麼？

我看瞭第一種情況，發現我們在兩個不同的地方保存瞭兩塊不同的數據，然後隻是返回一個對象。唯一可以優化的地方是保存函數。沒有任何其他選擇。

我看瞭第二個例子，也有同樣的想法。唯一可以優化的地方是保存函數。

也許隻是因為我對Promise的太熟悉瞭，但我看瞭第三個例子，我很快看到瞭一個機會。我看到我們在連續調用save，盡管其中一個並不依賴於另一個。 我們可以將我們的兩個save調用並行化。

const processData = ({ userData, sessionPrefences }) => Promise.all([
  save('userData', userData),
  save('session', sessionPrefences)
])
  .then(() => ({ userData, sessionPrefences })

同樣的機會也存在於async/await代碼中，隻是因為我們處於異步代碼的思維模式中，所以它被隱藏在明處。在async/await版本中並不是沒有提示。關鍵字async和await應該給我們同樣的直覺，就像第三個版本中的then一樣。但我敢打賭，對許多工程師來說，它並沒有。

為什麼沒有呢？

這是因為我們被教導要以同步的思維方式來閱讀async/await代碼。在第一個同步代碼例子中，我們無法將保存調用並行化，同樣的邏輯（但現在是不正確的），我們來到第二個例子。Async/await將我們的思維置於同步的思維模式中，而這是錯誤的思維模式。

此外，如果我們要在async/await的例子中利用並行化的優勢，無論如何我們必須使用promise。

const processData = async ({ userData, sessionPrefences }) => {
  await Promise.all([
    save('userData', userData), 
    save('session',sessionPrefences)
  ])
  return { userData, sessionPrefences }
}

在我看來，如果一個特定的模式隻在一些常見的情況下工作，那麼它一定有一些非常大的優勢。如果我不得不在一些非常常見的情況下 "退回"到promise模式，那麼我就看不到async/await比promise有什麼優勢。對我來說，在多種范式之間切換的認知負擔並不值得。promise在任何情況下都能完成工作，而且每次都和async/await一樣好，甚至更好。

錯誤處理

處理錯誤對於異步代碼來說是至關重要的。有幾個關鍵的地方，我們必須擔心JavaScript中同步代碼的錯誤處理。這主要發生在我們把一些東西交給本地API，如JSON.parse，或瀏覽器功能，如window.localstorage。

讓我們來看看我們之前的save函數的例子，並應用一些錯誤處理。讓我們假設在我們的同步例子中，save執行瞭一個可能會拋出的操作。這是非常合理的，因為如果保存到sessionstorage，它可能在序列化或試圖訪問sessionstorage的過程中拋出。為瞭處理同步代碼中可能出現的錯誤，我們通常使用try/catch。

同步代碼

const processData = ({ userData, sessionPrefences }) => {
  try {
    save('userData', userData);
    save('session', sessionPrefences);
    return { userData, sessionPrefences }
  } catch (err) {
    handleErrorSomehow(err)
  }
}

根據不同的策略，我們可能重新拋出錯誤，或者在catch塊中返回一些默認值。無論哪種方式，我們都必須在try塊中封裝任何可能拋出錯誤的邏輯。

async/await

由於async/await讓我們 "像看待同步一樣看待async代碼"，我們也使用try/catch塊。捕獲塊甚至會將我們的reject判定為一個錯誤。

const processData = async ({ userData, sessionPrefences }) => {
  try {
    await save('userData', userData);
    await save('session', sessionPrefences);
    return { userData, sessionPrefences }
  } catch (err) {
    handleErrorSomehow(err)
  }
}

看看這個，async/await實現瞭它的承諾。它看起來與同步版本幾乎完全一樣。

現在，有一些編程流派非常倚重try/catches。我覺得它們是一種精神上的負擔。每當有try/catch時，我們現在不僅要擔心函數返回什麼，還要擔心它拋出什麼。我們不僅有分支邏輯，這增加瞭復雜性，而且還必須擔心同時處理兩種不同的范式。一個函數可以返回一個值，也可以拋出。因此，每個函數都要處理這兩方面的問題。這很累人。

try/catch的尷尬

關於try/catch的最後一點。在JavaScript中，你一般不會在很多地方看到擁抱try/catch。與其他語言不同的是，在其他語言中，你會經常看到它，比如Java。JavaScript中的try塊會立即將這部分代碼排除在許多引擎優化之外，因為代碼不能再被分解成確定的片段。換句話說，在JavaScript中，同樣的代碼在被try塊包裹的情況下會比不被包裹的情況下運行得更慢，即使它沒有拋出的可能性。

Promise

讓我們看看Promise在做什麼。

const processData = ({ userData, sessionPrefences }) =>   save('userData', userData)
  .then(() => save('session', sessionPrefences))
  .then(() => ({ userData, sessionPrefences })
  .catch(handleErrorSomehow)

你看到瞭嗎？

.catch(handleErrorSomehow)

是的。這就是它的全部內容。這和其他的方法做的事情完全一樣。我發現這比try/catch塊更容易閱讀。你覺得呢？如果同步代碼也這麼簡單就好瞭……等一下!

const processData = ({ userData, sessionPrefences }) => Promise.resolve(save('userData', userData))
  .then(() => save('session', sessionPrefences))
  .then(() => ({ userData, sessionPrefences })
  .catch(handleErrorSomehow)

好吧，這有缺點，但也超級有趣，你不覺得嗎？這隻是一個小小的提示，讓你思考如果我們想的話，函數式風格的JavaScript會是什麼樣子。但不管怎樣，接受還是不接受。我的目的是說服你使用Promises而不是async/await。而不是承諾Promises全面優於async/await。那就太瘋狂瞭。😏

更關鍵的一點

我想提出的最後一點是。我有時會遇到一些論點，聲稱async/await可以防止callbacks和promises中可能出現的 "回調地獄 "現象。

說實話，我第一次聽到這種論調時，我以為這個人隻是混淆瞭，是想說 "callbacks"。畢竟，promises設計之初的目的之一就是消除 "回調地獄 "的問題，所以我很困惑，人們說promises會導致回調地獄（我的意思是，它畢竟被稱為回調(callbacks)地獄，而不是promises地獄）。

但後來我真的看到瞭一些promise的代碼，它們看起來驚人地像回調地獄。我很困惑，為什麼有人會這樣使用promise。最終，我得出結論，有些人對promise的工作原理有一個非常基本的誤解。

在我討論這個問題之前，首先讓我承認，事實上不可能用async/await創造出金字塔結構的回調地獄，所以它有這個優勢。但是我從來沒有寫過一個超過兩級的promise流，沒有必要。當然有可能，但從來沒有必要。

我發現，每當我在promise鏈中看到 "回調地獄 "時，都是因為人們沒有意識到promise的作用就像一個無限長的流程圖。換句話說，一個像這樣的流程：

const id = 5
const lotsOAsync = () => fetch('/big-o-list')
  .then((result) => {
    if (result.ok) {
      return result.json().then((list) => {
        const {url: itemURL } = data.items.find((item) => item.id === id)
        return fetch(itemURL).then((result) => {
          if (result.ok) {
            return result.json().then((data) => data.name)
          } else {
            throw new Error(`Couldn't fetch ${itemURL}`)
          }
        })
      })
    } else {
      throw new Error(`Couldn't fetch big-o-list`)
    }
  })

真的應該這樣寫：

const id = 5
const lotsOAsync = () => fetch('/big-o-list')
  .then((result) => result.ok ? result.json() : Promise.reject(`Couldn't fetch big-o-list`))
  .then(({ items }) => items.find((item) => item.id === id))
  .then(({url}) => fetch(url))
  .then((result) => result.ok ? result.json() : Promise.reject(`Couldn't fetch ${result.request.url}`))
  .then((data) => data.name)

如果這有點讓人困惑，讓我給你一個更簡單，但更矯情的例子。

回調地獄 🔥

Promise.resolve(
  Promise.resolve(
    Promise.resolve(
      Promise.resolve(
        Promise.resolve(
          Promise.resolve(5)
        )
      )
    )
  )
).then((val) => console.log(val))

promise天堂 👼

Promise.resolve()
  .then(() => Promise.resolve())
  .then(() => Promise.resolve())
  .then(() => Promise.resolve())
  .then(() => Promise.resolve())
  .then(() => Promise.resolve(5))
  .then((val) => console.log(val))

這兩個例子在創建promise的數量和順序方面都是一樣的（以及它們實際上脫離現實，但這是出於學術目的，所以我們允許它）。然而，後一個比前一個更有可讀性。

如果你習慣於寫與第一個例子更像的promise流，讓我給你提供一個好的小技巧來擺脫這種習慣。

每次你想在你的承諾流中寫一個then或catch，首先確保你返回promise，然後轉到最外層的promise（如果你一直遵循這個規則，那應該隻有一層）並在那裡添加你的then或catch。隻要你在返回，你的值就會冒泡到最外層的promise。這就是你應該做的 "then"。

請記住，你不一定要返回一個Promise來使用then。一旦你在一個promise的上下文中，任何返回的值都會通過它冒泡。Promise、number、字符串、函數、對象，等等。

Promise.resolve(5)
  .then((val) => val + 3)
  .then((num) => String(num))
  .then((str) => `I have ${str} llamas`)
  .then((str) => /ll/.test(str))

這都是完全合法的（盡管有點不合理，但編造的例子是為瞭說清楚🤷♂)

本文參考Why I avoid async/await，有修改。

總結

在我看來，promises

  • 提供更好的提示，表明我們處於異步的心理模型中
  • 在簡單的情況下，對代碼的表達至少與async/await一樣幹凈。
  • 為包括錯誤處理和並行化在內的更復雜的工作流提供瞭一個更幹凈的選擇。

註：特別感謝技術指導dazhao(趙達)對本文的審閱指正。

以上就是避免地獄async await的使用及原理解析的詳細內容，更多關於避免地獄async await原理的資料請關註WalkonNet其它相關文章！

推薦閱讀：