フラックスパターンを理解する

私は実際にフラックスのパターンを研究していますが、ストアに関して理解できないことがあります。

彼らは正確に何ですか？

私は多くの記事を読みましたが、それはドメインに関係しているようです。

これは、API呼び出しまたはバックエンド呼び出しに関連する「抽象的な」部分であることを意味しますか？

私にはあまりはっきりしていません。

編集：それは角度の工場と同じものでしたか？リモートデータの取得、ビジネスタスクの作成、アプリの状態の保存（現在のユーザーの接続など）

では、ステップバイステップから説明させてください

1 Fluxとは何ですか？

• パターン
• 集中ディスパッチャ
• 単方向データフロー
• リストアイテム

彼らもそれをフラックスと呼んでいます。

フラックス実装

• Facebookのフラックス
• Alt
• 還流
• Flummox
• NuclearJS
• 融通性

Fluxとのチャット

反応：ちょっとアクション、誰かがこの「コースを保存」ボタンをクリックしました。

アクション：ありがとう、React！アクションクリエーターをディスパッチャーに登録したので、ディスパッチャーは気にするすべてのストアに通知する必要があります。

ディスパッチャー：コースの保存を気にする人を見てみましょう。あ！ストアがコールバックを登録しているように見えるので、彼女に知らせます。

ストア：こんにちはディスパッチャ！更新していただきありがとうございます！送信したペイロードでデータを更新します。次に、気にするReactコンポーネントのイベントを発行します。

React：おお！ストアからの光沢のある新しいデータ！これを反映するためにUIを更新します！

フラックスAPI

register（function callback） –「ちょっとディスパッチャ、アクションが発生したら実行してください。-お店"

unregister（string id） –「ちょっとディスパッチャ、このアクションについて心配するのを止めてください。-お店"

waitFor（array ids） –「最初にこのストアを更新します。-お店"

dispatch（object payload） -「ディスパッチャよ、このアクションについてストアに伝えてください。-アクション"

isDispatching（） –「現在、コールバックのディスパッチに忙しい」

だから私たちの心に浮かぶ質問は

Fluxはパブリッシュ/サブスクライブモデルですか？

そうでもない。

次の2つの点で異なります。

1.すべてのペイロードは、登録されているすべてのコールバックにディスパッチされます。

2.コールバックは他のコールバックを待つことができます

概要

Fluxは単方向データフローのパターンですアクションはイベントをカプセル化しますDispatcherはコールバックを保持する中央ハブですストアはアプリの状態を保持します多くの実装

単純な例（https://github.com/facebook/flux/tree/master/examples/flux-todomvc/）を検索すると、「ストアはアプリケーション内の特定のドメインのアプリケーション状態を管理します。」つまり、アプリケーションの状態の状態に関するデータと、それを変更するすべてのコード。Dispatcherからの新しい更新があるたびに、すべてのストアがそれを確認し、それに応じてデータを更新する方法を決定し、データが変更されたことをビューに通知します。例では、ストアには「見えないスレッドリスト」（ディスパッチャが新しいメッセージの到着または古いメッセージが読み取られたことを通知し、ビューはメッセージスレッドをユーザーに表示する）や「現在の再生時間と状態。"

より技術的には、コールバックをDispatcherに登録して更新を受信し、データの状態が変化したときにビューに通知するフレームワークの中間層です。（その後、ビューはアクションをDispatcherに送り返す可能性があります。）それらが実装する抽象インターフェースがあり、各ストアはコールバックをDispatcherに登録し、イベントをビューにブロードキャストしますが、各ストアは具体的な方法で特定のドメインを表すようです。（反例はありますか？）

ストアは、アプリケーションの状態と複雑なロジックを格納するコードの領域です。それらの理由は、複数のビューが同じデータを使用する可能性がありますが、それらを異なる方法で表示したり、特定のドメインのすべてではなく一部のデータを表示したりすることです。たとえば、ユーザーがログインすると、名、姓、電子メール、写真、町、住所番号、電話番号などを受け取ります。この情報は別のビューに表示されます。ビュー間でデータを複製するのではなく、ユーザーのデータを保存するUserStoreという1つのストアを使用できます。これにより、格納されているロジックまたはデータを変更する必要がある場合に、「変更する場所を1つ」にすることでシステムが簡素化されます。ストアを使用する理由は他にもたくさんありますが、それは私が考える最も明白な理由です。