メインコンテンツへスキップ

レデューサー

非公式ベータ版翻訳

このページは PageTurner AI で翻訳されました（ベータ版）。プロジェクト公式の承認はありません。 エラーを見つけましたか？ 問題を報告 →

Redux FAQ: レデューサー​

2つのレデューサー間で状態を共有するには？ combineReducersは必須ですか？​

Reduxストアの推奨構造は、状態オブジェクトをキーごとに複数の「スライス」または「ドメイン」に分割し、各データスライスを管理する個別のレデューサー関数を用意することです。これは標準的なFluxパターンが複数の独立したストアを持つ方法に似ており、Reduxはこのパターンを容易にするcombineReducersユーティリティ関数を提供します。ただし重要なのは、combineReducersは必須ではないということです。これは単に、各状態スライスに単一のレデューサー関数を持ち、データとしてプレーンなJavaScriptオブジェクトを使用するという一般的なユースケースのためのユーティリティ関数に過ぎません。

多くのユーザーは後で2つのレデューサー間でデータを共有しようとしますが、combineReducersではそれができないことに気づきます。これにはいくつかのアプローチがあります：

  • レデューサーが別の状態スライスのデータを知る必要がある場合、単一のレデューサーがより多くのデータを処理できるように状態ツリー構造を再編成する必要があるかもしれません。

  • 一部のアクションを処理するためのカスタム関数を作成する必要があるかもしれません。これにはcombineReducersを独自のトップレベルレデューサー関数で置き換えることが含まれます。reduce-reducersのようなユーティリティを使用して、ほとんどのアクションを処理するためにcombineReducersを実行しつつ、状態スライスをまたぐ特定のアクションに対してより専門化されたレデューサーを実行することも可能です。

  • 非同期ロジックを持つミドルウェア（redux-thunkなど）はgetState()を通じて全体の状態にアクセスできます。アクションクリエーターは状態から追加データを取得し、各レデューサーが自身の状態スライスを更新するのに十分な情報をアクションに含めることができます。

一般的に、レデューサーは単なる関数であることを覚えておいてください。自由に組織化や分割が可能で、より小さな再利用可能な関数（「レデューサーコンポジション」）に分解することが推奨されます。その過程で、子レデューサーが次の状態を計算するために追加データを必要とする場合、親レデューサーからカスタムの第三引数を渡すことができます。重要なのは、基本ルール(state, action) => newStateに従い、状態を直接変更せず不変的に更新することです。

参考情報​

ドキュメント

ディスカッション

アクションを処理するのにswitch文は必須ですか？​

いいえ。レデューサー内でアクションに応答する方法は自由です。switch文が最も一般的なアプローチですが、if文、関数のルックアップテーブル、この処理を抽象化する関数の作成も問題ありません。実際、Reduxがアクションオブジェクトにtypeフィールドを要求する一方で、レデューサーロジックがアクションを処理するためにそれに依存する必要さえありません。とはいえ、標準的なアプローチはtypeに基づくswitch文またはルックアップテーブルです。

参考情報​

ドキュメント

ディスカッション