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

Redux FAQ: 状態の構成

目次​

状態の構成​

すべての状態をReduxに配置する必要がありますか？ ReactのuseStateまたはuseReducerを使用する必要がある場合はありますか？​

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

ローカルコンポーネント状態を使用しても問題ありません。 開発者として、アプリケーションを構成する状態の種類と、各状態がどこに存在する必要があるかを決定するのはあなたの仕事です。 自分にとってうまくいくバランスを見つけて、それを使用してください。

Reduxに配置する必要があるデータの種類を決定するための一般的な経験則

  • アプリケーションの他の部分がこのデータを気にしますか？
  • この元のデータに基づいて、さらに派生データを 생성する必要がありますか？
  • 同じデータが複数のコンポーネントを駆動するために使用されていますか？
  • この状態を特定の時点に復元できること（つまり、タイムトラベルデバッグ）に価値がありますか？
  • データをキャッシュしますか（つまり、すでに存在する場合は状態の内容を使用して、再リクエストする代わりに使用しますか）？
  • UIコンポーネントのホットリロード中にこのデータの整合性を維持しますか（スワップ時に内部状態が失われる可能性があります）？

詳細情報​

記事

ディスカッション

関数、Promise、またはその他のシリアライズ不可能なアイテムをストアの状態に配置できますか？​

プレーンなシリアライズ可能なオブジェクト、配列、およびプリミティブのみをストアに配置することを強くお勧めします。 シリアライズ不可能なアイテムをストアに挿入することは技術的に可能ですが、そうすると、ストアの内容を永続化および再水和する機能が損なわれ、タイムトラベルデバッグが妨げられる可能性があります。

永続性やタイムトラベルデバッグなどが意図したとおりに機能しない可能性があっても問題ない場合は、シリアライズ不可能なアイテムをReduxストアに配置しても構いません。 結局のところ、それはあなたのアプリケーションであり、それをどのように実装するかはあなた次第です。 Reduxに関する他の多くのことと同様に、どのようなトレードオフが伴うかを理解していることを確認してください。

詳細情報​

ディスカッション

状態のネストされたデータまたは重複するデータをどのように構成しますか？​

ID、ネスト、または関係を持つデータは、一般に「正規化」された方法で格納する必要があります。各オブジェクトはIDによってキー設定されて1回格納する必要があり、それを参照する他のオブジェクトは、オブジェクト全体のコピーではなくIDのみを格納する必要があります。 ストアの一部をデータベースと見なし、アイテムタイプごとに個別の「テーブル」があると考えるのに役立つ場合があります。 normalizrやredux-ormなどのライブラリは、正規化されたデータの管理に役立つ抽象化を提供できます。

詳細情報​

ドキュメント

記事

ディスカッション

フォームの状態またはその他のUIの状態をストアに配置する必要がありますか？​

Reduxストアに何を配置するかを決定するための同じ経験則がこの質問にも当てはまります。

これらの経験則に基づくと、ほとんどのフォームの状態はReduxに配置する必要はありません。これは、コンポーネント間で共有されていない可能性が高いためです。 ただし、その決定は常にあなたとあなたのアプリケーションに固有のものになります。 ストアから最初に取得したデータを編集しているため、またはアプリケーションの他の場所にある他のコンポーネントに作業中の値を反映させる必要があるため、Reduxに一部のフォーム状態を保持することを選択する場合があります。 一方、フォームの状態をコンポーネントに対してローカルに保ち、ユーザーがフォームを使い終わったらデータをストアに配置するためのアクションをディスパッチする方がはるかに簡単な場合があります。

これに基づいて、ほとんどの場合、Reduxベースのフォーム管理ライブラリも必要ありません。 次のアプローチをこの順序で試してみることをお勧めします

  • データがReduxストアから取得されている場合でも、最初にフォームロジックを手書きで記述することから始めます。 これが必要なすべてである可能性があります。 （これについては、Reactでのフォームの操作に関するGosha Arinichの投稿をご覧ください。）
  • フォームを手動で記述するのが難しいと判断した場合は、FormikやReact-Final-FormなどのReactベースのフォームライブラリを試してください。
  • 他のアプローチでは不十分なため、Reduxベースのフォームライブラリを必ず使用する必要があると確信している場合は、Redux-FormとReact-Redux-Formを確認することをお勧めします。

Reduxにフォーム状態を保持している場合は、パフォーマンス特性を検討する時間を取る必要があります。 テキスト入力のすべてのキーストロークでアクションをディスパッチすることはおそらく価値がなく、ディスパッチする前にキーストロークをバッファリングして変更をローカルに保つ方法を検討することをお勧めします。 いつものように、独自のアプリケーションの全体的なパフォーマンスニーズを分析するために時間をかけてください。

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

詳細情報​

記事