分割 Reducer 邏輯

對於任何有意義的應用程式，將所有更新邏輯放入單一 reducer 函式中，很快就會變得難以維護。雖然沒有單一規則規定函式應該有多長，但一般而言，函式應該相對較短，理想上只做一件事。因此，將很長或做很多事情的程式碼區塊拆分成較小的區塊，以利於理解，是一種良好的程式設計實務。

由於 Redux reducer 只是一個函式，因此同樣的概念也適用。你可以將一些 reducer 邏輯拆分成另一個函式，並從父函式呼叫那個新函式。

這些新函式通常會屬於以下三種類別之一

包含一些可重複使用的邏輯區塊的小型工具函式，在多個地方需要使用（可能與特定的商業邏輯相關，也可能不相關）
用於處理特定更新案例的函式，通常需要除了典型的 (state, action) 配對之外的其他參數
處理特定狀態區塊所有更新的函式。這些函式通常具有典型的 (state, action) 參數簽章

為清楚起見，這些術語將用於區分不同類型的函式和不同的使用案例

reducer：任何具有簽章 (state, action) -> newState 的函式（亦即，任何可以用作 Array.prototype.reduce 參數的函式）
根 reducer：實際傳遞給 createStore 作為第一個參數的 reducer 函式。這是 reducer 邏輯中必須具有 (state, action) -> newState 簽章的唯一部分。
區塊 reducer：用於處理狀態樹中一個特定區塊更新的 reducer，通常透過將其傳遞給 combineReducers 來完成
案例函式：用於處理特定動作的更新邏輯的函式。這實際上可能是一個 reducer 函式，或者它可能需要其他參數才能正常執行。
高階 reducer：將 reducer 函式作為參數，和/或傳回新的 reducer 函式作為結果的函式（例如 combineReducers 或 redux-undo）

術語「子 reducer」也已在各種討論中使用，表示任何不是根 reducer 的函式，儘管這個術語不是很精確。有些人也可能將某些函式稱為「商業邏輯」（與應用程式特定行為相關的函式）或「工具函式」（與應用程式無關的通用函式）。

將複雜的程序分解為較小、較易理解的部分通常會以術語功能分解來描述。此術語和概念可以泛指應用於任何程式碼。然而，在 Redux 中，使用方法 #3 來建構 reducer 邏輯非常常見，其中更新邏輯會委派給其他函式，而這些函式則根據狀態區塊而定。Redux 將此概念稱為reducer 組合，而且這是目前為止建構 reducer 邏輯最廣泛使用的方法。事實上，它非常普遍，以致於 Redux 包含一個名為 combineReducers() 的實用程式函式，它特別抽象化了根據狀態區塊將工作委派給其他 reducer 函式的程序。然而，重要的是要注意，它並非唯一可使用的模式。事實上，完全有可能使用所有三種方法將邏輯拆分為函式，而且通常也是個好主意。重構 Reducer 部分顯示了一些此動作的範例。