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