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

状態管理の構成

非公式ベータ版翻訳

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

Redux FAQ: 状態管理の構成​

すべての状態をReduxに保存する必要がありますか？ Reactの useState や useReducer を使うべきですか？​

これに対する「正解」はありません。すべてのデータをReduxに保持し、常に完全にシリアライズ可能で制御されたアプリケーション状態を維持することを好むユーザーもいます。一方、ドロップダウンが現在開いているかどうかなどの重要度の低いUI状態は、コンポーネントの内部状態として保持することを好むユーザーもいます。

ローカルコンポーネント状態の使用は問題ありません。開発者として、アプリケーションを構成する状態の種類と各状態の配置場所を決定するのは_あなた_の仕事です。自分に合ったバランスを見つけて、それを採用してください。

Reduxに保存すべきデータの種類を判断するための一般的な経験則:

  • このデータはアプリケーションの他の部分に関係がありますか？

  • この元データからさらに派生データを作成する必要がありますか？

  • 同じデータが複数のコンポーネントで使用されていますか？

  • 特定の時点にこの状態を復元できること（例：タイムトラベルデバッグ）に価値がありますか？

  • データをキャッシュしたいですか（例：既に状態にあるデータを再リクエストせずに使用する）？

  • UIコンポーネントのホットリロード中にこのデータを一貫して保持したいですか（スワップ時に内部状態が失われる可能性があります）？

参考情報​

記事

ディスカッション

関数、Promise、その他の非シリアライズ可能なアイテムをストア状態に保存できますか？​

プレーンなシリアライズ可能なオブジェクト、配列、プリミティブのみをストアに保存することを強く推奨します。非シリアライズ可能なアイテムをストアに挿入することは_技術的には可能_ですが、そうするとストアの内容を永続化および再ハイドレートする機能が損なわれ、タイムトラベルデバッグにも干渉する可能性があります。

永続化やタイムトラベルデバッグが意図通りに機能しない可能性があっても問題ない場合は、非シリアライズ可能なアイテムをReduxストアに保存しても全く問題ありません。最終的には、それは_あなたの_アプリケーションであり、実装方法はあなた次第です。Reduxに関する他の多くのことと同様に、どんなトレードオフが伴うかを理解するようにしてください。

参考情報​

ディスカッション

状態内のネストされたデータや重複データをどのように整理すればよいですか？​

IDやネスト構造、関連性を持つデータは、一般的に「正規化」された形式で保存する必要があります。各オブジェクトはIDでキー付けされて一度だけ保存し、それを参照する他のオブジェクトはオブジェクト全体のコピーではなくIDのみを保持します。ストアの一部をデータベースのように考え、アイテムタイプごとに個別の「テーブル」があると捉えると理解しやすいでしょう。normalizrやredux-ormなどのライブラリは、正規化データの管理を支援する抽象化レイヤーを提供します。

参考情報​

ドキュメント

記事

ディスカッション

フォーム状態やその他のUI状態をストアに保存すべきですか？​

Reduxストアに保存すべき状態を判断する経験則は、この質問にも同様に適用されます。

これらの経験則に基づくと、ほとんどのフォーム状態はReduxに入れる必要がありません。コンポーネント間で共有される可能性が低いためです。ただし、この判断は常にケースバイケースです。元々ストアから取得したデータを編集する場合や、アプリケーションの他の部分で編集中の値を反映する必要がある場合は、フォーム状態をReduxに保持する選択もあり得ます。一方、フォーム状態をコンポーネント内にローカルに保持し、ユーザーが操作を完了した時点でストアにデータを保存するアクションをディスパッチする方がシンプルな解決策となる場合もあります。

この観点から、ほとんどのケースではReduxベースのフォーム管理ライブラリも不要でしょう。以下のアプローチをこの順序で試すことを推奨します：

  • データがReduxストアから取得される場合でも、まずは手動でフォームロジックを実装してください。それで十分なケースがほとんどです（Reactでのフォーム操作に関する優れたガイダンスについては、Gosha ArinichによるReactフォーム操作に関する記事を参照してください）。

  • フォームの手動作成が困難だと判断した場合は、FormikやReact-Final-FormなどのReactベースのフォームライブラリを試してください。

  • 他のアプローチでは不十分であるため_どうしても_Reduxベースのフォームライブラリを使用する必要があると確信している場合に限り、Redux-FormやReact-Redux-Formを検討してください。

フォーム状態をReduxで管理する場合は、パフォーマンス特性を考慮する時間を取ってください。テキスト入力のキーストロークごとにアクションをディスパッチすることはおそらく価値がなく、変更をディスパッチする前にローカルに保持するためにキーストロークをバッファリングする方法を検討する必要があるかもしれません。常に、アプリケーション全体のパフォーマンス要件を分析する時間を取ってください。

他の種類のUI状態も同様の経験則に従います。典型的な例はisDropdownOpenフラグの追跡です。ほとんどの状況では、アプリケーションの他の部分はこれを気にしないため、コンポーネントの内部状態に保持するべきです。ただし、アプリケーションによっては、Reduxを使用してダイアログやその他のポップアップ、タブ、展開パネルなどを管理することが理にかなっている場合があります。

参考情報​

記事