Redux FAQ: ストア設定
目次
ストア設定
複数のストアを作成してもよいですか?ストアを直接インポートして、コンポーネント内で自分で使用してもよいですか?
オリジナルの Flux パターンでは、アプリ内に複数の「ストア」があり、それぞれが異なるドメインデータの領域を保持していると記述されています。これにより、あるストアが別のストアの更新を「waitFor
」する必要があるなどの問題が発生する可能性があります。Redux では、単一の reducer をより小さな reducer に分割することで、データドメイン間の分離がすでに実現されているため、これは必要ありません。
他のいくつかの質問と同様に、ページ内に複数の異なる Redux ストアを作成することは*可能*ですが、意図されたパターンは単一のストアのみを持つことです。単一のストアを持つことで、Redux DevTools の使用、データの永続化と再水和が簡単になり、サブスクリプションロジックが簡素化されます。
Redux で複数のストアを使用する正当な理由には、次のものがあります。
- アプリのプロファイリングで確認された、状態の一部の頻繁すぎる更新によって引き起こされるパフォーマンスの問題を解決する。
- より大きなアプリケーションのコンポーネントとして Redux アプリを分離する場合。この場合、ルートコンポーネントインスタンスごとにストアを作成したい場合があります。
ただし、特に Flux のバックグラウンドをお持ちの場合は、新しいストアを作成することを最初に考えるべきではありません。最初に reducer の合成を試し、それで問題が解決しない場合にのみ複数のストアを使用してください。
同様に、ストアインスタンスを直接インポートして参照することも*できます*が、これは Redux では推奨されるパターンではありません。ストアインスタンスを作成してモジュールからエクスポートすると、シングルトンになります。これは、Redux アプリをより大きなアプリのコンポーネントとして分離する場合、またはサーバーレンダリングを有効にする必要がある場合に、サーバーでリクエストごとに個別のストアインスタンスを作成する必要があるため、より困難になることを意味します。
React Redux では、connect()
関数によって生成されるラッパークラスは、実際には props.store
が存在する場合はそれを探しますが、ルートコンポーネントを <Provider store={store}>
でラップし、ストアの受け渡しについては React Redux に任せるのが最善です。これにより、コンポーネントはストアモジュールをインポートすることを気にする必要がなくなり、Redux アプリの分離やサーバーレンダリングの有効化を後で簡単に行うことができます。
詳細情報
ドキュメント
ディスカッション
- #1346: 'stores' ディレクトリのみを持つのは悪い慣習ですか?
- Stack Overflow: Redux の複数のストア、なぜだめなのですか?
- Stack Overflow: アクションクリエイターで Redux の状態にアクセスする
- Gist: Redux パラダイムから抜け出してアプリを分離する
ストアエンハンサーに複数のミドルウェアチェーンを持たせても大丈夫ですか?ミドルウェア関数における next
と dispatch
の違いは何ですか?
Redux ミドルウェアは、連結リストのように機能します。各ミドルウェア関数は、next(action)
を呼び出してアクションを次のミドルウェアに渡すか、dispatch(action)
を呼び出してリストの先頭から処理を再開するか、何もせずにアクションの処理をそれ以上停止することができます。
このミドルウェアのチェーンは、ストアの作成時に使用される applyMiddleware
関数に渡される引数によって定義されます。複数のチェーンを定義しても正しく機能しません。異なる dispatch
参照を持ち、異なるチェーンが事実上切断されるためです。
詳細情報
ドキュメント
ディスカッション
状態の一部のみをサブスクライブするにはどうすればよいですか?サブスクリプションの一部としてディスパッチされたアクションを取得できますか?
Redux は、ストアが更新されたことをリスナーに通知するための単一の store.subscribe
メソッドを提供します。リスナーコールバックは、現在の状態を引数として受け取りません。これは、*何か*が変更されたことを示す単なる指示です。サブスクライバーロジックは、getState()
を呼び出して現在の状態の値を取得できます。
この API は、依存関係や複雑さのない低レベルのプリミティブとして意図されており、より高度なサブスクリプションロジックを構築するために使用できます。React Redux などの UI バインディングは、接続された各コンポーネントのサブスクリプションを作成できます。古い状態と新しい状態をインテリジェントに比較し、特定の箇所が変更された場合にのみ追加のロジックを実行できる関数を作成することも可能です。例としては、redux-watch、redux-subscribe、redux-subscriber などがあり、サブスクリプションの指定と変更の処理に対して異なるアプローチを提供します。
新しい状態がリスナーに渡されないのは、Redux DevTools などのストアエンハンサーの実装を簡素化するためです。さらに、サブスクライバーはアクションではなく、状態値自体に反応することを意図しています。アクションが重要で、特に処理する必要がある場合は、ミドルウェアを使用できます。
詳細情報
ドキュメント
ディスカッション
- #303: 引数として状態を持つ subscribe API
- #580: store.subscribe でアクションと状態を取得することは可能ですか?
- #922: 提案: ミドルウェア API にサブスクライブを追加する
- #1057: subscribe リスナーはアクションパラメーターを取得できますか?
- #1300: Redux は素晴らしいが、主要な機能が欠落している
ライブラリ