Fluxとは何か MVC, MVVMとの違いも含めて
動機
仕事で, React + Redux + TypeScirpt + WebPackを使うことになりそうなので学んでいく.
そもそもjsに疎いので探り探りやっていく.
間違えもあるかもしれないが, 徐々にやっていこう.
TL;DR
- Fluxとは, アプリケーションのデータフロー管理のためのアーキテクチャパターン
- イベント駆動であり, 一方向のデータフロー制御を行う
- Fluxの特徴は,
Viewで独立したデータを持つ,データ状態を一方向のフローで制御,Event駆動である. - Fluxは
Action,Dispatcher,Store,Viewの4要素で構成される.
Reduxとは
Reduxとは, Facebookが提唱, 開発しているJsApp.
jsにおいて, データの状態(データの流れ)を管理するためのツールである.
ReduxはFluxの実装と聞いたことがあるので, Reduxの前にFluxについて学んでいこう.
FluxもFacebookが提唱しているアーキテクチャである.
Fluxとは
FB公式から抜粋
Flux is a pattern for managing data flow in your application. The most important concept is that data flows in one direction. Fluxとは, アプリケーションのデータフロー管理のためのアーキテクチャパターンである. もっとも重要なコンセプトは`データフローが一方向にしか流れないこと`である.
JavaScriptでWebページのデータを制御する際に, データの状態制御が複雑になりやすい.
Fluxはデータの流れを一方向に限定することで状態遷移を単純にし, データ状態の複雑さを軽減させようとする考え方である.
あくまでも考え方なので, 実装は伴わない.
RESTの実装がHTTPのように, Fluxの実装がReduxという関係性なのかなと想像している.
Reduxの源流なので, Fluxから追っていこうと思う.
Fluxのアーキテクチャ
図をみると, 4つのパーツから構成されていることがわかる.
- Dispatcher
- Store
- Action
- View
データは必ず以下の動作で変更されていく.
- 何らかの
Actionがあり(Apiからのレスポンス, ViewEvent),Dispatcherがその全てを受ける. DispatcherがStoreにActionを伝搬.Storeは,Dispatcherから受けたActionによってデータの状態を変更.change eventを発火する.Storeのデータ状態がViewに渡される.change eventでトリガーされる.ViewがStoreから受けたデータを表示.Viewで何らかのActionが発生. 1に戻る.
storeは必ずしも1つではなく複数個持てる.
todoアプリであれば, 未消化タスク, 消化済みタスク でstoreを分けることが可能である.
Fluxとはなんなのか より引用
Fluxのなにがいいのか
Fluxとはなんなのかより引用するが,
Fluxを導入すると以下のメリットがあると言える
- ViewにEvent(Action)の発行元だけ持たせ, App全体をEventDrivenにした
- Storeに状態や副作用を集約したことで, そこ以外では参照等価になった.
- これにより, App全体の見通しがよくなった
個人的にまだよくわかっていないこと
MVC, MVVCとの違い
正直, MVC(Model/View/Controller)との違いがそれほど大きくわかってない. MVVC(Model/View/ViewModel/Contoller)もそうだが, Viewの中の話でほぼ終始しているような気がする.
一回整理してみよう
MVC
MVCについて振り返る. at-grandpa.hatenablog.jp より図を引用.
ViewはModelの状態を参照しているだけ.
ViewはあくまでもModelの状態を表示しているだけで, ユーザの入力はControllerを伝ってModelで処理されデータの状態が変化する.
サーバサイドレンダリングで作ったページを思い浮かべると良さそう.
Viewの中でデータの状態そのものは気にせず, ユーザの明示的な操作(formのPOSTなど)としてフォームの値が渡ってくるイメージ.
(Viewの中でformデータなどの状態はあるがDOMで閉じる)
MVVM
qiita.com より図を引用.
MVC の場合は, ViewがModelを直接参照していた.
MVVM では, ViewとModelの間にViewModelという中間層を置く.
ViewはViewModelの状態を参照し,ViewModelは常にViewの入力を監視する.Viewに対する入力(Event)があれば, 即座に検知してViewModelの状態が変わる.- 逆に
ViewModelの状態が変わればViewの表示が変更される.
これを, Two-way data Bindingと呼ぶ.
Modelの状態変更は, ユーザの明示的な操作(formのPOSTなど)によって行われる.
このとき, ViewModelの状態がModelに反映される.
この図には, Controller が存在しないが ModelとViewModelの間にControllerがある.
言い換えれば, MVVMCとなる.
Flux
Fluxの場合は, 上のような図になる. MVCと比較するためあえてMCを書いている.
Fluxは Fluxのアーキテクチャ で述べた通り, データフローが一方向に制御されるコンセプトを持っている.
こうやって見てみると, MCとVで明確な境界線がある.
View側で独立のデータを持ち, データ状態の制御だけに関心をあてているのがFluxである.
Viewで独立のデータ構造をもつアプリケーション, と考えてしまえばMVVMとそう変わらない
MVVMと比較すると, ViewModelがStoreとなり, データの方向制御のためにDispatcherが登場したという形になる.
Fluxでは, EventをActionと呼ぶためここは同義として見て良いだろう.
MVC, MVVM, Fluxの違い まとめ
こうやってMVC, MVVM, Fluxを同じ構成で見てみると,
実はどれもMVCの延長線上にあることがわかる.
というか, そもそもVIewのデータフローアーキテクチャなのでMCとは関係ないものである.
そもそも関心ごとが違うので比較するまでもなかった.
MVCとMVVM, Fluxで大きく異なるのは, View側にサーバ(Model, Controller)とは独立したアプリケーションがあり, Viewで独立したデータ状態を持つ/制御することであろう.
ここさえ理解すれば, MVVM, Fluxはあくまでもデータフローが双方向か一方向かの違いしかないことに気づける.
