關於使用 Thunk 進行 Redux 異步操作的問題

Question

我最近剛接觸 Redux，並決定學習如何實現它。 目前我正在重構我之前的一些學習項目並實現該工具提供的全局狀態邏輯。 問題是，我最近偶然發現了用於異步操作的 thunk 中間件，並對可能是一個簡單的概念誤解但我無法克服的東西感到好奇。
那么，我為什么要分派異步操作？ 我只是看不到這樣做的好處，而不是等待我正在做的任何事情的執行，然后才調度攜帶我想要的數據的動作。

以一個簡單的 fetch 調用為例，我為什么不執行以下操作：
-> 等待獲取數據
->調度獲取的數據

而是這樣做：
->派遣行動
->等待調度動作

可能有一些我不知道的用例，因為對於我這個初學者來說，聽起來像是一些可能不需要它的額外代碼？ 同上。
有人可以幫助我嗎？ =)

Answer 1

是的，正如您所發現的，這是 Dan Abramov 對 thunk 中間件之類存在的原因的原始解釋。

我最近在用 Thunks 編寫邏輯上寫了一個新的 Redux 文檔頁面，其中更詳細地介紹了 thunk 背后的目的以及如何正確使用它們。 我將引用“為什么使用 Thunks？” 部分：

Thunks 允許我們編寫額外的 Redux 相關邏輯與 UI 層分開。 此邏輯可能包括副作用，例如異步請求或生成隨機值，以及需要分派多個操作或訪問 Redux 存儲狀態的邏輯。

Redux reducer 不能包含副作用，但真正的應用程序需要有副作用的邏輯。 其中一些可能存在於組件內部，但有些可能需要存在於 UI 層之外。 Thunk（和其他 Redux 中間件）為我們提供了放置這些副作用的地方。

直接在組件中具有邏輯是很常見的，例如在單擊處理程序或 useEffect 鈎子中發出異步請求，然后處理結果。 但是，通常需要將盡可能多的邏輯移出 UI 層。 這樣做可能是為了提高邏輯的可測試性，保持 UI 層盡可能薄和“表現性”，或者提高代碼重用和共享。

從某種意義上說，thunk 是一個漏洞，您可以提前編寫任何需要與 Redux 存儲交互的代碼，而無需知道將使用哪個Redux 存儲。 這可以防止邏輯被綁定到任何特定的 Redux 存儲實例並使其可重用。

Redux FAQ 條目“為什么我們使用中間件來產生副作用？” 指向有關此主題的其他信息的鏈接。