リデューサロジックの分割

実用的なアプリケーションでは、_すべての_更新ロジックを単一のリデューサ関数に記述すると、すぐに保守不能になります。関数の長さに関する絶対的なルールはありませんが、一般的に関数は比較的短く、理想的には単一の責務を持つべきとされています。このため、非常に長いコードや複数の処理を行うコードを、理解しやすい小さな断片に分割するのは良いプログラミング慣習です。

Reduxのリデューサは単なる関数ですから、同じ概念が適用されます。リデューサロジックの一部を別の関数に分割し、親関数から新しい関数を呼び出すことができます。

これらの新しい関数は通常、次の3つのカテゴリのいずれかに該当します：

特定のビジネスロジックに関連するかどうかに関わらず、複数箇所で必要となる再利用可能なロジックを含む小さなユーティリティ関数
特定の更新ケースを処理する関数（通常の(state, action)ペア以外のパラメータを必要とする場合が多い）
状態の特定のスライスに対する_すべての_更新を処理する関数（通常は標準的な(state, action)パラメータシグネチャを持つ）

明確化のため、異なるタイプの関数とユースケースを区別するために以下の用語を使用します：

リデューサ: シグネチャ(state, action) -> newStateを持つ任意の関数（つまりArray.prototype.reduceの引数として使用可能な関数）
ルートリデューサ: createStoreの第一引数として実際に渡されるリデューサ関数。(state, action) -> newStateシグネチャが_必須_な唯一の部分。
スライスリデューサ: 状態ツリーの特定部分の更新を処理するために使用されるリデューサ（通常combineReducersに渡される）
ケース関数: 特定のアクションの更新ロジックを処理する関数（実際のリデューサ関数の場合もあれば、適切に動作するために追加パラメータを必要とする場合もある）
高階リデューサ: リデューサ関数を引数に取り、新たなリデューサ関数を返す関数（例：combineReducersやredux-undo）

"サブリデューサ"という用語も、ルートリデューサ以外の任意の関数を指す文脈で使用されますが、この用語はあまり正確ではありません。一部の関数を"ビジネスロジック"（アプリケーション固有の動作に関連する関数）や"ユーティリティ関数"（アプリケーション非依存の汎用関数）と呼ぶ場合もあります。

複雑なプロセスを小さく理解しやすい部分に分解する手法は、一般に 機能分解（functional decomposition） と呼ばれます。この概念はあらゆるコードに適用可能です。ただしReduxでは、状態のスライスに基づいて更新ロジックを他の関数に委譲するアプローチ（#3）でリデューサロジックを構造化するのが_非常に_一般的です。Reduxはこの概念をリデューサの合成と呼び、これはリデューサロジック構造化において最も広く使われているアプローチです。実際、Reduxには状態スライスに基づく委譲処理を抽象化する専用ユーティリティcombineReducers()が組み込まれているほどです。ただし、これが唯一のパターンではないことに注意することが重要です。実際、これら3つのアプローチすべてを組み合わせてロジックを分割することも可能であり、通常は推奨される方法でもあります。リデューサのリファクタリングセクションに具体的な例が示されています。