Fluxの設計を考えてみる
なぜこの設計になっているのか
なぜAction Creatorsがあるのか
- MVCでいうCにあたる（dispatcherも含めて）（Model = Store, V = Component）のだろうが、その役割そのもの
- つまり、Viewとロジックの 疎結合 を保つために必要。容易に取り替えられるような Interface となる。
- 依存関係を図に書いてみると分かりやすいかも。Actionsがない場合、Component - Store間の依存性が凄いことになる。
なぜConstantsがあるのか
- イベント駆動で書いていると、イベント名（string）がグローバルっぽい感じになって管理しづらい。
- それを一箇所にまとめるために必要だった。（個人的解釈）
Action Creatorsから、イベントdispatchするのはなぜ
- dispatcherがあるおかげで、Store間の依存関係を管理できる。
- 例）AStoreのfooCallbackが終了してから、BStoreのbarCallbackを起動する
- fluxの肝である「単方向データフロー」を実現（強制）するために不可欠な存在である。
- ActionsがどのStoreを使うか、知らなくて済むようになる。
Storeがイベントemitするのはなぜ
- ここも疎結合のため。大量のView, Storeが存在したとしても、ひとつだけView, Storeが存在するものとみなせる。（dispatcherも似たような役割がある）
Storeとはなにか
Store は、アプリケーションの状態とロジックを含んでいます。Store の 役割は、古典的な MVC における Model の役割に少し似ていますが、しか し多数のオブジェクトの状態を管理していて、一個のオブジェクトのイン スタンスではないという点が異なっています。また、Backboneフレームワー クのコレクションと同じものでもありません。ORM形式のオブジェクトの集 合を管理するよりももっと単純に、Storeはそのアプリケーション内のある 特定の ドメイン について、アプリケーションの状態を管理します。
