この記事はSwiftベースで話を進めています。
iOSを普段書いている方には記事を呼んで頂きたいですが、
それ以外が主戦場の方は別の記事でFluxについての理解を深めることを推奨します。
Fluxとは
Facebookが作成したアーキテクチャパターンでJSの文化から輸入してきた物です。
(そもそもClientの設計パターンはほとんどJSの文化で生まれた物ばかりです)
下の画像からわかることとして
Action -> Dispatcher -> Store -> **View**のフローがあって、
その後、
View -> Action -> **Dispatcher**のフローが存在します。
これによって一つのライフサイクルが作成されていることがわかります。
Fluxの設計パターンの最大の特徴はこの**Action** -> Dispatcher -> Store -> **View**の単一方法のデータの受け渡しが行われていることにあります。逆に言えばこのパターンが逸脱したいと思った時はFluxを採用することをやめるべきとも言えます。(そのときはMVC,MVVM,Redux等を利用することを検討することになると思います)
他の設計パターンと比較する
すべてのアーキテクチャとの比較をすることはめんどくさい 時間がかかってしまうので今回はいくつかある設計パターンのうち、その中でも似ているMVVM(Model,View,ViewModel)と比較することにしましょう。
このとき、最大の違いはViewModelをDispatcher/Storeに書き換えてみるとわかります。
図をみてわかる通り、FluxとMVVMの最大の違いは
Viewが一つ前の層であるViewModelをみることで変更をみることができるのがMVVM
Viewがみることができるのは2つ前のDispatcher(StoreとActionの中継役)をみるのがFlux
です。なのでFluxでは値をもらう**Storeが中で何をしているのか全く知らない状態になるという意味です。これはMVVMに比べてFluxの方が制約が厳しいという意味に直結**します。
各役割の説明
なんとなく雰囲気でわかったものの、各役職がどんなことを実際に説明していなかったので説明します。
-
Action
最終的にViewに渡したいdataを保持している場所。 -
Dispatcher
ActionとStoreの中継場所。
Viewで入力された値とかはここが受け取ることで再度Storeに渡して
Viewに反映したりする。 -
Store
値の状態を管理する場所。 -
View
UIViewControllerやUIViewがこれにあたる。UIViewControllerの場合、ViewControllerとしてではなく、なるべくControllerとしての役割を剥いで、Viewとして利用する。
メリット・デメリット
メリット
- 単一方向であることを制約に掲げているのでデータフローが役割ごとに分けられることで理解しやすくなる。
- MVCの設計よりも
UIViewControllerから状態管理のためのコードが減ってViewControllerとしてではなく、Viewとしての役割に近い状態になる
デメリット
- そもそもFluxを採用するほどの規模のアプリは少ない。（小中規模でこれほどの制約は返って開発コストが高くつきそう）
今回はこれで以上です。サンプルコードを追加した上での説明は今回は省きます（追加する予定はあります）