Fluxを使い始めると「おっ、MV*に比べて頭が悪くても状態が壊れないぞ?」という感想になる人が多いと思うんだけど、その理由がふたつあるような気がしてきた。
ModelやViewModelについてはコンテキストが違う人から「それ違くない?」と言われそうな書き方になるかもだけど、思いつきを書きなぐってるだけなので勘弁してください。
1. 単方向データフローが分かりやすく、コードの複雑さの低下に寄与している
これは全くポジティブな要因。
2. FluxはMV*のModel相当の要素が図に含まれていないので考えることが減った
MV*は「Modelって書いてあるからには何かをModelと呼んでデータを突っ込まなきゃいけない」という意識が生まれやすかった(その責務分割が適切だったかは別として)と思う。
でも、FluxにはStoreとかいうViewModel*1みたいなものしかない*2と私は思っていて、MV*でModelと呼ばれていたものを定義させようとする意図は感じられません。
結果的に、Modelについて書いてないので考えるきっかけがなくなって、必要な脳内メモリの量が減った結果、「頭が悪くても〜」という感想になるのではと思いました。
文脈
文脈としてはこの辺の話から来ています。
ReduxやFluxの中にアーキテクチャを構築するんじゃない。自分が信じたアーキテクチャの中にReduxやFluxを配置するんだ。
— なかざん (@Nkzn) May 15, 2018
Fluxは所詮MVWと同じレベルで状態管理の責務の依存関係や処理の順番を定義しているだけだから、FluxベースだとやっぱりModel相当の場所の設計はサポートされてないんだぞと思ってる。MiddlewareはMW間の通信方法を工夫してるだけなのでやっぱり違う。MVWの問題についてはこれ↓https://t.co/NVpXyEYPhY
— なかざん (@Nkzn) 2018年5月15日
細かいことを言うと僕はFluxはMVVMだと思っていて、FluxのStoreはVMの状態で、ReduxのMiddlewareはM⇔VM間の通信をごにょっとするためのものという認識でいる。だからなおさら、Mについて何もしていないという意識が強い。
— なかざん (@Nkzn) 2018年5月15日
単方向データフロー方面に行くトレンドはもう崩れなさそうだからいいけど
— なかざん (@Nkzn) 2018年5月15日
プレゼンテーション層のアーキテクチャですよね、Flux。
— Keita Kagurazaka (@kkagurazaka) 2018年5月15日
モデル側はこれまで散々議論されてきた設計を利用できますし。
まとめ
MV*という呪いをFluxという呪いに移し替えたときに、Fluxの単方向データフローという価値にMV*が釣り合わなくて、等価交換でModelを持っていかれた、という嘘ストーリーをどこかのカンファレンスで喋りたい
— なかざん (@Nkzn) 2018年5月15日
MV*はModel内の設計について定義していませんでしたが、FluxはModelの存在自体を私たちに押し付けてこない子なのでは、と思い始めました。Model相当のものがなくていいわけがないのですが、単方向データフローが強力すぎて、Model相当の部分があやふやでも、みんな何とかなっちゃってるんじゃないかな・・・*3
Model相当の部分を設計したFlux、業務で色々と試してみているので、どこかのタイミングで布教していきたいです。
補足をいただきました
この記事の本質を言語化し直してくれました。
うん、StoreとVMの話は余計だったなという気持ちはあります。
おまけ
DroidKaigi 2018でベノワさんが紹介していたModel-View-Intentは限定的ながらModel相当の部分(Repositoryとか)にも言及している単方向データフローで、Fluxの単方向データフローしか見たことがなかった私にとってはかなり学びがあったので、興味があれば見てみてください。