Fluxアーキテクチャのメモ

Laravel

最近は Flux + React を使っています。Secure Code Tipsでも部分的に採用しました。今回は Fluxアーキテクチャについて、現時点で自分の理解している内容をメモしておきます。

Flux: Actions and the Dispatcher | React というページでは以下の図が使用されています。よく見る図です。

現在の自分の認識を基にしてこの図をもう少し詳しくすると、以下になります（だいたいこんな感じという程度の図です）。

* Web API と Web API Utils は省略しています。

何かしら新しい値が発生した場合に、それらの値を包むのが Action(object literal)です。つまり Action とはデータです。Actionと聞くとメソッドをイメージしてしまうかもしれませんが違います。
Actionには “actionType”プロパティを持たせて、区別できるようにします。

Action Creator は、主に画面上の操作に対して実行する処理を保持するオブジェクトです。
- 基本的には actionType毎に対応するメソッドを Action Creator 内に作成します。
- 上の図では1つのメソッドに1つのActionを対応させていますが、そう決まっているわけではないと思います。
このメソッドでは、基本的に (1) Actionを生成し、(2) Dispatcherのdispatch(Action)を実行します。
- dispatch()を実行する前にAjaxでデータを取得することもありえますし、別のActionCreatorのメソッドを呼ぶこともありえます。
処理の種類毎に Action Creator を作成して使用します。

アプリケーションにただ1つだけ存在し、全てのデータの流れを管理します。
各StoreはあらかじめDispatcherにコールバックを登録しておきます。そのコールバック内では、自分自身(Store)を更新する必要のある actionType が呼ばれた場合の処理を記述しておきます。
- 基本的には、Store毎にコールバックを登録します。
- 基本的には、まず Store内のデータを操作する処理を行い、その後で関連するViewのステータスを更新する処理を実行(イベントの発火)します。
1つの actionType に対して、複数のStoreがそれぞれの処理を登録する可能性があります。
- この場合、どの Storeの処理から実行するかが問題となりますが、Dispatcherの層がこの順序を解決する責任を持ちます。
  - 各Storeのコールバック処理の中で waitFor()メソッドを使い、依存する他のStoreの処理を先に実行させることができます。

Domainのstate(状態)を管理します。
- いわゆるMVCのModelに似ていますが、別物であるようです。
- Domain毎にStoreを作成します。
Dispatcherにコールバックを登録します。
- 各Storeは、自分に関連のあるデータのかたまり(actionTypeで判別する)が発生した時に実行する処理をDispatcherに登録します。
これは EventEmitter そのものです。
- 関連するViewのステータス更新処理を保持して、必要な時に実行します。

最終更新日: 2015-05-28