- 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
- ドメインを分割する
- ドメイン間のやり取りをメッセージパッシングのような疎結合な機構を用いて以下のように行う
- ユーザーの入力がビューに対して発生したことをロジック側に伝える
- ロジック処理の結果にデータが変更したことをビューに伝える
- 各ドメイン間のメッセージの送信方向は、組み合わせによって常に一つに決定される
Views ---> (actions) ----> Dispatcher ---> (registered callback) ---> Stores -------+
Ʌ |
| V
+-- (Controller-Views "change" event handlers) ---- (Stores emit "change" events) --+
- メッセージパッシングの採用により、同時にビューが何個存在しようとも、Storeから「データが更新された」というメッセージが発行されれば、そのメッセージを購読しているビューが勝手に更新される
- 煩わしい管理をする必要が無い
- ドメインの組み合わせに応じて、メッセージの流れる方向を制限することで、データフローが常に一つになる
- 処理の予測が可能になる
- メッセージパッシングによって引き起こされる、ドメイン間の依存性地獄の回避
- メッセージパッシングを使用しているので、ドメイン間の連携が強制的に非同期になる
- モデルがいくつのスレッドに分割されていようと、どれだけ時間がかかろうと、設計として全く問題なくなる
- StoreもDispatcherもシングルトンなサービスとして存在しているので(後述)、インスタンスの管理などの問題が軽減される
- 設計上、こうした方が良い、という点から、オブジェクトの生成が規定されることになる
- Storeに向けてメッセージを発行する場合は必ずココを介する
- シングルトンになる
facebook::Flux::Dispatcher
では、waitFor()
という機能を提供することにより、Store間の処理順序の依存性を解決している- これが無い場合、Store間の依存性解決用の細かいメッセージを大量に定義する必要が出てくる
- 無くても解決できるけど有った方が便利だわな
- データ処理の領域を取り扱う。
- が、"Nor are they the same as Backbone's collections"とのこと
- 内部は完全に隠蔽されている
- 独自にインスタンスを管理していようがシングルトンだろうが、ビューの状態も含めようが、それはロジックの問題である
- 状態を持つのであれば、状態の生成と破棄のためのメッセージを追加すれば良い
- 表向きにはシングルトンなオブジェクトがひとつ公開されており、それ経由でDispatcherからのメッセージ入力を受け取る
- ファサードって言っていいんだっけ?
- ユーザーからの入力とデータの出力(表示)を取り扱う
- Storeから発生するメッセージを購読する
- Storeからの入力に応じて(一意な)データの出力を行う
- Facebookの流儀では、ここでReactを用いて描画コストの問題を解消する
- 複数インスタンスを作ってよい
- 過剰なコンポーネント化は、複雑な状態の保持や、予期せぬActionの呼び出しを発生させるので、開発の複雑性を増加させることに注意
- Viewに対するユーザー入力やネットワーク経由の入力を待ち受ける
- やってきた入力を基にDispatcherのメッセージ発行処理を行い、入力されたデータをStoreに叩き込む.
- この入力とメッセージの発行処理をまとめてラップしてActionとして提供する.
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の定義を以下とする(面倒くさいのでwikipedia日本語版の該当項目とか『A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk -80』の図とか参考)
- Model: ドメインロジックの処理(およびデータの取り扱い)を受け持つ
- View: モデルの処理結果・データ類の表示(UI部分)を受け持つ
- Controller: ユーザの入力に応じてModelに向けて処理を開始するのを受け持つ
- これを踏まえた上で、observerパターンの上に、若干の条件を追加して、GUIアプリケーション向き実践にしたものだと認識しています
- (GUI)アプリケーションで頻出するドメインに名前を付けた
- ドメイン間でのメッセージ(データ)フローの方向性を規定
- 各ドメインを表すオブジェクトの作り方を細かく述べた
- 何も違いません。ただのobserverパターンです。
- __ベストプラクティス的なパターンに名前をつけて共通言語としたところ__です。
- 概念的に非常に革新的な何かがあるというわけではありません。
- たぶん「誰もが一度は似たような事をやったことがある」と思うが、従来は個々人がそれぞれ別の言葉で呼んでおり、意思疎通の上で面倒くさかった
React JS › Flux: Actions or ActionCreatorsにおける、Jing Chenの回答によると、ActionCreatorは
- Actionとして標準的な方法を提供する
- 日和見的なアクション(optimistic action)とサーバーのレスポンスの結果を調整し、複数のStoreに対するグローバルなロールバックなどをサポートする
のに使うのがよく、無限スクロールなどのようなケースにStoreがサーバーからデータを取得したい場合は、Store内で完結したところで問題はないということ.
Actionの所の解釈をずっと読み間違っていたので訂正した