ナカザンドットネット

それって私の感想ですよね

FluxにはModelがないのではないかと思った覚書

Fluxを使い始めると「おっ、MV＊に比べて頭が悪くても状態が壊れないぞ？」という感想になる人が多いと思うんだけど、その理由がふたつあるような気がしてきた。

ModelやViewModelについてはコンテキストが違う人から「それ違くない？」と言われそうな書き方になるかもだけど、思いつきを書きなぐってるだけなので勘弁してください。

1. 単方向データフローが分かりやすく、コードの複雑さの低下に寄与している

これは全くポジティブな要因。

2. FluxはMV＊のModel相当の要素が図に含まれていないので考えることが減った

MV＊は「Modelって書いてあるからには何かをModelと呼んでデータを突っ込まなきゃいけない」という意識が生まれやすかった（その責務分割が適切だったかは別として）と思う。

でも、FluxにはStoreとかいうViewModel*1みたいなものしかない*2と私は思っていて、MV＊でModelと呼ばれていたものを定義させようとする意図は感じられません。

結果的に、Modelについて書いてないので考えるきっかけがなくなって、必要な脳内メモリの量が減った結果、「頭が悪くても〜」という感想になるのではと思いました。

文脈

文脈としてはこの辺の話から来ています。

まとめ

MV＊はModel内の設計について定義していませんでしたが、FluxはModelの存在自体を私たちに押し付けてこない子なのでは、と思い始めました。Model相当のものがなくていいわけがないのですが、単方向データフローが強力すぎて、Model相当の部分があやふやでも、みんな何とかなっちゃってるんじゃないかな・・・*3

Model相当の部分を設計したFlux、業務で色々と試してみているので、どこかのタイミングで布教していきたいです。

補足をいただきました

この記事の本質を言語化し直してくれました。

nekogata.hatenablog.com

うん、StoreとVMの話は余計だったなという気持ちはあります。

おまけ

DroidKaigi 2018でベノワさんが紹介していたModel-View-Intentは限定的ながらModel相当の部分（Repositoryとか）にも言及している単方向データフローで、Fluxの単方向データフローしか見たことがなかった私にとってはかなり学びがあったので、興味があれば見てみてください。

speakerdeck.com

www.youtube.com

*1:VMを持ち出すと文脈がぼやけてしまいますが、Presentation Domain SeperationにおけるPresentationの中にいるということだけ伝わればOKです。

*2:StoreがViewModelに見えているのは僕の主観です。Modelだと主張したい方の思想を否定するものではありませんので、異論反論はご自身の主張を自分のブログか何かで展開してください。それはそれで僕も読みたい。

*3:Fat Controller相当のものがAction CreatorやReducerの中に増殖して見通しが死ぬほど悪くなったコードをたまに見かけるし書いたこともあります。