redux-thunk 和 redux-promise 有什么區別？

Question

據我所知，如果我錯了，請糾正我， redux-thunk是一個中間件，它可以幫助我們在操作本身中調度異步函數和調試值，而當我使用redux-promise時，我無法在不實現自己的情況下創建異步函數作為 Action 的機制會引發僅調度普通對象的異常。

這兩個包之間的主要區別是什么？ 在單個頁面反應應用程序中使用這兩個包或堅持使用 redux-thunk 有什么好處嗎？

Answer 1

redux-thunk允許你的動作創建者返回一個函數：

function myAction(payload){
    return function(dispatch){
        // use dispatch as you please
    }
}

redux-promise允許他們返回一個 promise ：

function myAction(payload){
    return new Promise(function(resolve, reject){
        resolve(someData); // redux-promise will dispatch someData
    });
}

如果您需要異步或有條件地調度操作，這兩個庫都很有用。 redux-thunk還允許您在一個動作創建者中分派多次。 無論您選擇一個，另一個或兩者都完全取決於您的需求/風格。

Answer 2

您可能希望/需要在您的應用程序中同時使用兩者。 從 redux-promise 開始，用於生成 promise 的常規異步任務，然后隨着復雜性的增加擴大規模以添加 Thunks（或 Sagas 等） ：

• 當生活很簡單，而你只是與返回一個承諾的創建者做基本的異步工作，那么redux-promise將改善你的生活並簡化它，快速而簡單。 （簡而言之，當它們解決時，您不需要考慮“解包”您的承諾，然后編寫/發送結果，redux-promise(-middleware) 會為您處理所有無聊的事情。）
• 但是，在以下情況下，生活會變得更加復雜：
• 也許您的動作創建者想要產生幾個承諾，您希望將它們作為單獨的動作分派給單獨的減速器？
• 或者，在決定如何以及在何處分派結果之前，您需要管理一些復雜的預處理和條件邏輯？

在這些情況下， redux-thunk的好處是它允許您將復雜性封裝在您的 action-creator中。

但請注意，如果您的 Thunk 生成並發送 Promise，那么您需要同時使用這兩個庫：

• Thunk 將組成原始動作並調度它們
• 然后redux-promise將在 reducer 處處理由 Thunk 生成的單個 promise 的展開，以避免需要的樣板文件。 （你可以在 Thunks 中做所有事情，用promise.then(unwrapAndDispatchResult).catch(unwrapAndDispatchError) ...但你為什么要這樣做？）

---

總結用例差異的另一種簡單方法： Redux 操作周期的開始與結束：

• Thunks 用於 Redux 流程的開始：如果您需要創建一個復雜的操作，或者封裝一些復雜的操作創建邏輯，請將其排除在您的組件之外，並且絕對排除在 reducer 之外。
• redux-promise用於結束您的流程，一旦一切都歸結為簡單的承諾，您只想解開它們並將它們的已解決/拒絕值存儲在商店中

---

注釋/參考：

• 我發現redux-promise-middleware是對原始redux-promise背后想法的更完整和更易於理解的實現。 它正在積極開發中，並且還得到了redux-promise-reducer良好補充。
• 還有其他類似的中間件可用於組合/排序您的復雜操作：一個非常流行的中間件是redux-saga ，它與redux-thunk非常相似，但基於生成器函數的語法。 同樣，您可能會將它與redux-promise結合使用，因為 sagas 會產生您不想用大量樣板文件手動解包和處理的承諾......
• 這是一篇很棒的文章，直接比較了各種異步組合選項，包括 thunk 和 redux-promise-middleware。 （TL;DR： “Redux Promise Middleware 與其他一些選項相比顯着減少了樣板文件” ...... “我認為我喜歡 Saga 用於更復雜的應用程序（閱讀：“uses”），而 Redux Promise Middleware 用於其他一切。” )
• 請注意，有一個重要的情況，您可能認為您需要調度多個操作，但實際上您不需要，您可以讓簡單的事情保持簡單。 這就是您只希望多個減速器對單個異步調用做出反應的地方，並且您傾向於將多個操作分派給這些多個減速器。 但是，根本沒有理由為什么多個 reducer 不能監控單個動作類型。 您只需要確保您的團隊知道您正在使用該約定，因此他們不會假設只有一個 reducer（具有相關名稱）可以處理給定的操作。

Answer 3

全面披露：我對 Redux 開發相對較新，並且自己也在為這個問題而苦苦掙扎。 我將解釋我找到的最簡潔的答案：

ReduxPromise 在分派操作時返回一個 Promise 作為有效負載，然后 ReduxPromise 中間件解析該 Promise 並將結果傳遞給 reducer。

另一方面，ReduxThunk 強制動作創建者推遲將動作對象實際分派給減速器，直到調用分派。

這是我找到此信息的教程的鏈接： https ://blog.tighten.co/react-101-part-4-firebase。