Flux まとめ
Flux は、コールバック関数やプロパティを延々と引き継がなくてはならない pure な React 構造を補助するフレームワークで、利用することで記述量を減らしたり、モジュールの役割を分散できる。ここでは、Fluxに登場するそれぞれの役目についての概説と、実装した時の覚書をメモしておく。
Action
ディスパッチャは、ストアに対するデータ更新のトリガーを引くための関数を公開している。アクションは、意味的なまとまりで構成されたヘルパー関数によってラップされディスパッチャに送信される。このヘルパー関数は、ビューに公開される。
ActionCreator と呼ばれるヘルパー関数を利用することで、ユーザインタラクションを発生させるビューに対して、props
を伝搬する必要がなくなる。
ビューが直接ストアの状態を操作することはなく、アクションのみがそれを許されている(single-direction)。
Store
ストアは、MVC のモデルに相当するが、単一のテーブルにとどまらず、意味のあるデータのかたまりを丸ごと取り扱う。
またオブザーバパターンのSubject
として、特定のイベントを発火する。状態を保つビュー(コントロール・ビュー)は、ストアのCHANGE_EVENT
を Listen することで、イベントに合わせて状態を更新することができる。ビューコンポーネントがマウントされた時点でのstate
の初期値も、このストアから取得することができる。
Dispatcher
アクションは、特定の情報を含んだペイロード。ユーザによるインタラクションや、システムによるイベントで アクション が発生する。この アクション は、 ディスパッチャ を経由して、 目的の ストア に対してデータを更新するように通知する。
なお、ディスパッチャ は、すべての ストア に対して、UI またはシステムからの アクション を通知する。ストア は、actionType
属性から、それが自分に関係するアクションかどうかを判定して処理を決める。
actionType属性に設定する値は、定数として外部に定義しておくと良い。その際、
keyMirror
というモジュールが便利。
ディスパッチャ は、ストア間の依存関係を管理できる。 waitFor()
関数を用いて、それを行う。
実装上の勘所
次のような基本原則を用いて、コーディングしていく。まず pure な React を作ってからリファクタリングしても良いし、いきなり Flux を適用しても良い。後者の場合は設計作業を少々丁寧に行うと良い。
- ユーザインタラクションが発生するビューは、アクションに依存する
- コントロール・ビューは、ストアに依存する
- ストアは、それが管理する情報を必要とするビュー向けにAPIを公開する
- ストアは、通知されるペイロードを正しく処理するために
actionType
を使って制御した関するをディスパッチャに渡す - アクション(ヘルパー関数)は、ディスパッチャにペイロード(
actionType
と値)を渡す