[解決済み] Fluxアーキテクチャでは、Storeのライフサイクルをどのように管理するのですか？

質問

について読んでいます。 フラックス を読んでいますが Todo アプリの例 は単純すぎて、いくつかの重要なポイントを理解することができません。

Facebookのようなシングルページのアプリを想像してください。 ユーザープロファイルページ . 各ユーザープロファイルページでは、いくつかのユーザ情報とその最新の投稿を、無限スクロールで表示したいと思います。我々は、1つのユーザプロファイルから別のものにナビゲートすることができます。

Fluxアーキテクチャでは、これはStoresとDispatchersにどのように対応するのでしょうか？

私たちは1つの PostStore を使うのか、それとも何らかのグローバルストアを持つのでしょうか? ディスパッチャについては、各「ユーザーページ」に対して新しいディスパッチャを作成するのでしょうか、それともシングルトンを使用するのでしょうか？最後に、ルートの変更に対応する「ページ固有の」ストアのライフサイクルを管理するのは、アーキテクチャのどの部分でしょうか？

さらに、1つの疑似ページが、同じタイプのデータの複数のリストを持つことがあります。たとえば、プロフィールページで、両方の フォロワー と フォロー . どのようにして、シングルトン UserStore はこの場合どのように機能するのでしょうか？そうすると UserPageStore を管理する followedBy: UserStore そして follows: UserStore ?

どのように解決するのですか？

Fluxアプリでは、Dispatcherは1つだけであるべきです。 すべてのデータはこの中心的なハブを介して流れます。 シングルトンのDispatcherを持つことで、すべてのStoreを管理することができます。 これは、Store #1が自身を更新し、Store #2がActionとStore #1の状態の両方を基に自身を更新する必要がある場合に重要になります。 Fluxは、このような状況が大規模なアプリケーションで起こりうることを想定しています。 理想を言えば、このような状況は発生する必要がなく、開発者は可能であればこのような複雑な状況を避けるように努力すべきです。 しかし、シングルトンDispatcherは、いざというときに対処できるようになっています。

ストアも同様にシングルトンです。 コントローラビューからクエリ可能な自己充足された宇宙です。 ストアに入る唯一の道は、ディスパッチャに登録されたコールバックを通ることです。 Storeに入るには、Dispatcherに登録したコールバックを経由し、出るにはゲッター関数を経由します。 ストアはまた、状態が変化したときにイベントを発行するので、Controller-Viewはゲッターを使用して新しい状態のためにクエリを実行するタイミングを知ることができます。

この例のアプリでは、1つの PostStore . この同じストアで、FBのニュースフィードのような、異なるユーザーからの投稿が表示されるページ（疑似ページ）の投稿を管理することができます。 その論理的な領域は投稿のリストであり、どんな投稿のリストでも扱うことができる。 擬似ページから擬似ページに移行する際には、新しい状態を反映させるために、ストアの状態を再初期化したいと思います。 また、擬似ページ間を行き来する際の最適化として、以前の状態をlocalStorageにキャッシュしておきたい場合もありますが、私の考えとしては、擬似ページ間の移動のために PageStore を設定し、他のすべてのストアを待ち、擬似ページ上のすべてのストアについて localStorage との関係を管理し、それから自身の状態を更新します。 なお、この PageStore は投稿について何も保存しないことに注意してください。 PostStore . それは単に、特定の疑似ページがキャッシュされたかどうかを知っているだけです。なぜなら、疑似ページはそのドメインだからです。

は PostStore があれば initialize() メソッドがあります。 このメソッドは、たとえこれが最初の初期化であっても、常に古い状態をクリアし、その後、Actionを通じて受け取ったデータに基づいて、Dispatcherを通じて状態を作成します。 ある疑似ページから別の疑似ページへの移動には、おそらく PAGE_UPDATE アクションを含んでおり、これは initialize() . ローカル キャッシュからのデータの取得、サーバーからのデータの取得、最適化レンダリング、XHR エラー ステートなどの詳細な作業が必要ですが、これは一般的なアイデアです。

特定の疑似ページがアプリケーション内のすべてのストアを必要としない場合、メモリの制約以外に、未使用のストアを破棄する理由があるかどうかは完全にわかりません。 しかし、ストアは通常、大量のメモリを消費するわけではありません。 ただ、破棄するController-Viewsのイベントリスナーを削除しておく必要があります。 これは、Reactの componentWillUnmount() メソッドを使用します。