Facebook提唱のFluxのメモ：http://facebook.github.io/flux/docs/overview.html

flux-architecture-memo.md

Fluxアーキテクチャ覚え書き

参考資料

• Flux Application Architecture | React
• javascript - In Flux architecture, how do you manage Store lifecycle? - Stack Overflow
• Flux Chat Example
• React JS › Flux: Actions or ActionCreators
• Stores and form validation? · Issue #2 · facebook/flux

アーキテクチャ本質

1. ドメインを分割する
2. ドメイン間のやり取りをメッセージパッシングのような疎結合な機構を用いて以下のように行う

• ユーザーの入力がビューに対して発生したことをロジック側に伝える
• ロジック処理の結果にデータが変更したことをビューに伝える

3. 各ドメイン間のメッセージの送信方向は、組み合わせによって常に一つに決定される

Views ---> (actions) ----> Dispatcher ---> (registered callback) ---> Stores -------+
Ʌ                                                                                   |
|                                                                                   V
+-- (Controller-Views "change" event handlers) ---- (Stores emit "change" events) --+

設計によって得られるメリット

• メッセージパッシングの採用により、同時にビューが何個存在しようとも、Storeから「データが更新された」というメッセージが発行されれば、そのメッセージを購読しているビューが勝手に更新される
  • 煩わしい管理をする必要が無い
• ドメインの組み合わせに応じて、メッセージの流れる方向を制限することで、データフローが常に一つになる
  • 処理の予測が可能になる
  • メッセージパッシングによって引き起こされる、ドメイン間の依存性地獄の回避
• メッセージパッシングを使用しているので、ドメイン間の連携が強制的に非同期になる
  • モデルがいくつのスレッドに分割されていようと、どれだけ時間がかかろうと、設計として全く問題なくなる
• StoreもDispatcherもシングルトンなサービスとして存在しているので（後述）、インスタンスの管理などの問題が軽減される

各ドメイン

• 設計上、こうした方が良い、という点から、オブジェクトの生成が規定されることになる

Dispatcher

• Storeに向けてメッセージを発行する場合は必ずココを介する
• シングルトンになる
• facebook::Flux::Dispatcherでは、waitFor()という機能を提供することにより、Store間の処理順序の依存性を解決している
  • これが無い場合、Store間の依存性解決用の細かいメッセージを大量に定義する必要が出てくる
  • 無くても解決できるけど有った方が便利だわな

Store

• データ処理の領域を取り扱う。
  • が、"Nor are they the same as Backbone's collections"とのこと
• 内部は完全に隠蔽されている
  • 独自にインスタンスを管理していようがシングルトンだろうが、ビューの状態も含めようが、それはロジックの問題である
  • 状態を持つのであれば、状態の生成と破棄のためのメッセージを追加すれば良い
• 表向きにはシングルトンなオブジェクトがひとつ公開されており、それ経由でDispatcherからのメッセージ入力を受け取る
  • ファサードって言っていいんだっけ？

View (Controller-View)

• ユーザーからの入力とデータの出力（表示）を取り扱う
• Storeから発生するメッセージを購読する
• Storeからの入力に応じて（一意な）データの出力を行う
  • Facebookの流儀では、ここでReactを用いて描画コストの問題を解消する
• 複数インスタンスを作ってよい
• 過剰なコンポーネント化は、複雑な状態の保持や、予期せぬActionの呼び出しを発生させるので、開発の複雑性を増加させることに注意

ActionCreators

1. Viewに対するユーザー入力やネットワーク経由の入力を待ち受ける
2. やってきた入力を基にDispatcherのメッセージ発行処理を行い、入力されたデータをStoreに叩き込む.
3. この入力とメッセージの発行処理をまとめてラップしてActionとして提供する.

なぜ通常のMVCでは駄目だったか

http://facebook.github.io/flux/docs/overview.html:

We originally set out to deal correctly with derived data: for example, we wanted to show an unread count for message threads while another view showed a list of threads, with the unread ones highlighted. This was difficult to handle with MVC — marking a single thread as read would update the thread model, and then also need to update the unread count model. These dependencies and cascading updates often occur in a large MVC application, leading to a tangled weave of data flow and unpredictable results.

MVCと何が違うの

• 宗教論争をするつもりは無いので、MVCの定義を以下とする（面倒くさいのでwikipedia日本語版の該当項目とか『A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk -80』の図とか参考）
  • Model: ドメインロジックの処理（およびデータの取り扱い）を受け持つ
  • View: モデルの処理結果・データ類の表示（UI部分）を受け持つ
  • Controller: ユーザの入力に応じてModelに向けて処理を開始するのを受け持つ
• これを踏まえた上で、observerパターンの上に、若干の条件を追加して、GUIアプリケーション向き実践にしたものだと認識しています
  • （GUI）アプリケーションで頻出するドメインに名前を付けた
  • ドメイン間でのメッセージ（データ）フローの方向性を規定
  • 各ドメインを表すオブジェクトの作り方を細かく述べた

observerパターンと何が違うの？

• 何も違いません。ただのobserverパターンです。

何がすごいの？

• __ベストプラクティス的なパターンに名前をつけて共通言語としたところ__です。
• 概念的に非常に革新的な何かがあるというわけではありません。
• たぶん「誰もが一度は似たような事をやったことがある」と思うが、従来は個々人がそれぞれ別の言葉で呼んでおり、意思疎通の上で面倒くさかった

外部（サーバー）との入出力はActionに入れるべきかStoreに入れるべきか

React JS › Flux: Actions or ActionCreatorsにおける、Jing Chenの回答によると、ActionCreatorは

• Actionとして標準的な方法を提供する
• 日和見的なアクション（optimistic action）とサーバーのレスポンスの結果を調整し、複数のStoreに対するグローバルなロールバックなどをサポートする

のに使うのがよく、無限スクロールなどのようなケースにStoreがサーバーからデータを取得したい場合は、Store内で完結したところで問題はないということ.

Actionの所の解釈をずっと読み間違っていたので訂正した

過去の更新の際に間違えて一カ所消してしまっていた；