私が疑問に思っていたのは、どの程度の状態が実際にはコンポーネントではなくストアに属しているのかということです。私はいくつかの場所で、実際にはすべての州が店舗内に住むべきだと読んだ.
入力値 (送信前)、入力検証、モーダルが開いているかどうか、何かがクリックされたかどうかなど、コンポーネント固有のものは本当に含まれますか?
ここでのベストプラクティスは何ですか?
私が疑問に思っていたのは、どの程度の状態が実際にはコンポーネントではなくストアに属しているのかということです。私はいくつかの場所で、実際にはすべての州が店舗内に住むべきだと読んだ.
入力値 (送信前)、入力検証、モーダルが開いているかどうか、何かがクリックされたかどうかなど、コンポーネント固有のものは本当に含まれますか?
ここでのベストプラクティスは何ですか?
明白な答え:
コンポーネント固有の状態 (入力値、モーダルのオープン/クローズ、クリックされたもの、レイアウト、フォーマット) を可能な限りコンポーネントの状態内に保持します。
そして、ストア内のアプリ固有の状態。これには、サーバーとの間でやり取りするものが含まれますが、これに限定されません。
とはいえ、ここには多くの灰色の領域があります。
私が使用するいくつかの経験則:
すべてをフラックス ストアに保持することは、一部のアプリにとって有益な場合があります。
したがって、まず、アプリがこのようなものかどうかを判断する必要があります。
しかしもちろん、コンポーネント内でいつ状態を保持し、いつ保持しないかを示す、ある種の特定のガイド、おそらく単に精神的なガイドがあると便利です。
私はこれらのガイドに行きます:
- この状態は純粋に UI 関連ですか? そうすれば、おそらく店に保管する必要はありません。
- この状態は、コンポーネント以外のどこかで共有されていますか? そうでない場合は、ストアに配置しないでください。コンポーネント内で問題ありません。
- この状態を URL に永続化できますか? もしそうなら、それを店に置かないでください。URLに貼ってください!入力または現在開いているタブの検索クエリである可能性があります。
これらすべてに例外があるかもしれませんが、一般的に、これはフラックス アプリの元のアイデアによく対応していると思います。
PSまた、すべてのUIを不変の状態ツリー内に保持する必要がある(保持してもよい)という話がたくさんあると言わなければなりません。それが多くの人にreduxが紹介される方法です。これは素晴らしいコンセプトであり、ユーザー インタラクションの保存/再生を可能にしますが、ほとんどの場合不要であり、Flux の主なアイデアではないことを理解しておく必要があります。また、redux 自体は優れたフラックス ツールであり、ストア内のすべての UI 状態を維持する必要はありません。
コンポーネント固有のビュー ステートは、そのコンポーネントに属します。多くのコンポーネントに関係するアプリの状態はストアに属します。