で前の質問私は、フラックスのアプリでサーバーに更新を送信するための責任者を尋ねました。人々は、アクションがこれを行うべきだと私に言いました。したがって、サーバーからデータをフェッチする場合も同じことが言えると思います。FetchDataアクションがあります。このアクションは、データをフェッチし、ストアが保持するデータをディスパッチします。しかし、そのような場合、キャッシングロジックはどのように機能しますか？
リストが最後に要求された時刻を保存する必要があると思います。StreamsStore内のリストのTTLとfetchStreamsアクションは、サーバーに問い合わせる必要があるかどうかを判断するためにTTLと最後のフェッチ時刻を取得します。
これは正しい方法ですか？ストアとアクションの間にキャッシュロジックを分散させるのは奇妙に思えますが、それを行うためのより良い方法は考えられません。
これは素晴らしい質問であり、私も以前に遭遇した質問です。
Fluxで最も重要なことは、データが常に一方向に流れることです。あなたはすでにこれを知っています—その1つのステートメントには多くの明確な力があり、Fluxについてのほとんどすべての質問に対する答えを保持しているので、私はそれを取り上げます。
アクションはストアにデータを送信するため、ストア内の何かの値をチェックするロジックをアクションに追加すると、フローに対して間違った方向にデータが送信されます。
では、Fluxアプリのどの部分が店舗からデータを受け取るのでしょうか？景色。あなたの答えがあります。
キャッシュロジックを保持するビューの考え方は奇妙に感じるかもしれませんが、キャッシュとは何かを考えてください。
ビューハンドル＃1。それは非常に簡単です。そして＃3は明らかにあなたの行動によって処理されます。しかし、少なくともFluxアプリでは、＃2は、ビュー、より具体的にはコントローラービューでも処理する必要があることがわかりました。コントローラービューは、Fluxの見過ごされがちな部分です。おそらく、コントローラーの概念がMVCと非常に密接に関連しているためです。しかし、フラックスにもそれらがあります！FluxのWebサイトから：
コントローラはFluxアプリケーションに存在しますが、コントローラビューです。これは、ストアからデータを取得し、このデータを子に渡す階層の最上位によく見られるビューです。
Reactを使用していると仮定すると、このアイデアはおなじみのように聞こえるはずです。高レベルのReactコンポーネントはコントローラーyですが、低レベルのコンポーネントはより「純粋」です。
これについての別の考え方は、アクションは単なるディスパッチャヘルパーであることに注意することです。（私の記憶が正しければ、Facebookが最初にフラックスを導入したとき、彼らも行動を言及しなかった）あなたは、アクションと呼ばれてきた時点で、あなたはすでに発送には決定を行った。唯一の問題はあるものを、ない場合。
これを読み返してみると、これはすべて違いのない区別のように見えるかもしれませんが、主なポイントは、いいえ、アクションでは店舗の状態を検査できないということです。彼らはディスパッチャを介してのみ彼らと通信することができます。それを実際に機能させる方法を見つけるかもしれませんが（これは割り引かれるべきではありません！）、それは慣用的なフラックスではありません。
これが理にかなっていることを願っています！
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加