1

私が疑問に思っていたのは、どの程度の状態が実際にはコンポーネントではなくストアに属しているのかということです。私はいくつかの場所で、実際にはすべての州が店舗内に住むべきだと読んだ.

入力値 (送信前)、入力検証、モーダルが開いているかどうか、何かがクリックされたかどうかなど、コンポーネント固有のものは本当に含まれますか?

ここでのベストプラクティスは何ですか?

4

4 に答える 4

2

明白な答え:
コンポーネント固有の状態 (入力値、モーダルのオープン/クローズ、クリックされたもの、レイアウト、フォーマット) を可能な限りコンポーネントの状態内に保持します。
そして、ストア内のアプリ固有の状態。これには、サーバーとの間でやり取りするものが含まれますが、これに限定されません。

とはいえ、ここには多くの灰色の領域があります。

  • フィルターは検索リスト コンポーネントの状態に適用されますか? またはアプリの状態 (同じページへの今後のアクセスのためにフィルターを保存する場合)?
  • 訪問したリンクは、グローバル ルート メニュー ルート コンポーネント状態またはアプリ状態ですか?
  • 楽観的な更新を使用している場合は、サーバーとの通信の前後に、ユーザー入力をストアに保存する必要がある場合があります。

私が使用するいくつかの経験則:

  • コンポーネントと同じライフサイクルを持つ場合、状態はコンポーネントに属します (したがって、コンポーネントがマウントされる前に状態が存在する必要がなく、コンポーネントがアンマウントされた後に忘れられる場合)
  • アプリを閉じて再度開くときに状態を記憶する必要がある場合は、おそらくストア内に配置するのが最適です(サーバーおよび/またはローカルストレージとの交換を行う場所)
  • 疑わしい場合は、コンポーネントのみの状態から始めてください。これにより、状態が (コンポーネントに対して) よりローカライズされ、コードがより管理しやすくなります。後の段階で、いつでも状態をストアに移動できます。
于 2016-04-28T19:37:35.790 に答える
0

すべてをフラックス ストアに保持することは、一部のアプリにとって有益な場合があります。

したがって、まず、アプリがこのようなものかどうかを判断する必要があります。

  1. 州の一部がフラックス ストアに属しているかどうかわからない場合は、属していない可能性が高くなります。
  2. フラックスが必要な時期がわかります。そして、そのようなアプリケーション アーキテクチャが自分に適しているかどうかについてそのレベルの理解に達すると、おそらく最初の質問に対する答えもわかるでしょう。

しかしもちろん、コンポーネント内でいつ状態を保持し、いつ保持しないかを示す、ある種の特定のガイド、おそらく単に精神的なガイドがあると便利です。

私はこれらのガイドに行きます:

  • この状態は純粋に UI 関連ですか? そうすれば、おそらく店に保管する必要はありません。
  • この状態は、コンポーネント以外のどこかで共有されていますか? そうでない場合は、ストアに配置しないでください。コンポーネント内で問題ありません。
  • この状態を URL に永続化できますか? もしそうなら、それを店に置かないでください。URLに貼ってください!入力または現在開いているタブの検索クエリである可能性があります。

これらすべてに例外があるかもしれませんが、一般的に、これはフラックス アプリの元のアイデアによく対応していると思います。


PSまた、すべてのUIを不変の状態ツリー内に保持する必要がある(保持してもよい)という話がたくさんあると言わなければなりません。それが多くの人にreduxが紹介される方法です。これは素晴らしいコンセプトであり、ユーザー インタラクションの保存/再生を可能にしますが、ほとんどの場合不要であり、Flux の主なアイデアではないことを理解しておく必要があります。また、redux 自体は優れたフラックス ツールであり、ストア内のすべての UI 状態を維持する必要はありません。

于 2016-05-04T11:53:56.867 に答える
0

コンポーネント固有のビュー ステートは、そのコンポーネントに属します。多くのコンポーネントに関係するアプリの状態はストアに属します。

于 2016-04-28T15:53:17.507 に答える