Redux - 複数のストア、なぜダメなのか? 質問する

注記: 私は Redux (Baobab も) のドキュメントを読み、Google 検索とテストをかなり行いました。

Redux アプリにストアを 1 つだけ持つことが強く推奨されるのはなぜですか?

単一ストア設定と複数ストア設定の長所と短所を理解しています (この件については SO に多くの Q&A があります)。

私の意見では、このアーキテクチャ上の決定は、プロジェクトのニーズに基づいてアプリ開発者が行うものです。では、なぜ Redux ではこれが必須であるかのように強く推奨されているのでしょうか (複数のストアを作成することを妨げるものは何もありませんが)?

編集: 単一店舗への変換後のフィードバック

多くの人が複雑な SPA と考えるものに redux を使用して数か月間取り組んだ結果、単一ストア構造で作業するのは本当に楽しかったと言えます。

単一のストアと複数のストアのどちらが、非常に多くのユースケースで意味のない問題であるかを他の人が理解するのに役立つかもしれないいくつかのポイント:

• 信頼性が高い: セレクターを使用してアプリの状態を調べ、コンテキストに関連する情報を取得します。必要なデータはすべて単一のストアにあることがわかっています。状態の問題がどこにあるのかという疑問をすべて回避できます。
• 高速です。現在、当社のストアには 100 個近くのリデューサーがあります。その数でも、特定のディスパッチでデータを処理するのは少数のリデューサーのみで、他のリデューサーは以前の状態を返すだけです。巨大/複雑なストア (リデューサーの数が多い) は遅いという議論は、ほとんど意味がありません。少なくとも、そこからパフォーマンスの問題は発生していません。
• デバッグしやすい: これは redux を全体的に使用するための最も説得力のある議論ですが、単一ストアと複数ストアにも当てはまります。アプリを構築すると、プロセス中に状態エラー (プログラマーのミス) が発生することは当然ですが、これは正常なことです。PITA は、それらのエラーのデバッグに何時間もかかる場合です。単一ストア (および redux-logger ) のおかげで、特定の状態の問題に数分以上費やすことはありません。

いくつかのヒント

Redux ストアを構築する際の本当の課題は、その構造を決定することです。まず、後で構造を変更すると非常に面倒だからです。次に、プロセスでアプリ データをどのように使用し、クエリするかが主に決まるからです。ストアの構造化方法については多くの提案があります。私たちの場合、次の方法が理想的であることがわかりました。

{
  apis: {     // data from various services
    api1: {},
    api2: {},
    ...
  }, 
  components: {} // UI state data for each widget, component, you name it 
  session: {} // session-specific information
}