思いつつままに書いてみたが、自分でもなんかしっくりこないので、WIP。同期縛りだからReduxのReducerがダメ、という自分の主張のコアの部分に自信がない。それを差し置いて呼んでほしい。
(1) https://togetter.com/li/911228 (2) http://qiita.com/mizchi/items/8cf4e0c868f5c49ebcbf
いろいろあって仕方なく覚えることにした。今度こそ好きになれるかと思って勉強したが、無理そうな気配を感じている。これで3度目ぐらいの挫折。挫折、というか理解はしたと思う。理解をした上で好きになれない。まだ真の理解に至ってないという可能性はあるが…
昔勉強した際の、生JSの癖に関数合成を多用して見づらい、というのは FlowやTypeScriptの表現力でカバーできるようになったことで、ある程度解決したと思う。というかボイラープレートを超えると、それらはさして問題ではなかった。そこから先。
今でも筋が悪いと思うのは、同期と非同期のAPIで設計がまるっと変わってしまうという点。チュートリアルとして、同期的なピュアなJS(ON)オブジェクトで TodoList 作ってみたんだが、バックエンドをサーバーに置いて非同期APIに書き直そうとした瞬間、まったく再利用できなくなった。
そもそも、ストレージ抽象を同期でAPIで書く、という発想が間違ってるのは認めるにしても、昔言ったように、アプリケーションドメインのフレームワークとしては、制御構造を任意に規定することで生まれるのは、秩序ではなく割れ窓ではないかと思う。結果として生まれるのは ActionCreator(あるいはActionCreatorCreator) 層が本当のビジネスロジックで、それがビューへ強く干渉することで、実質的にビューにビジネスロジックが埋め込まれていく未来だ。
言いたいのは、 reducer を同期縛りにして、ミドルウェアで解決しようとするのは方向性として間違っているのではないか。少なくともフレームワークは Agnostic であるべきで、redux は opinionated に過ぎる。自分はそういう結論になりつつある。
その辺の調査をする中で、redux-saga の必要性が多少わかった。
僕の理解ではアクションと更新を 1:1 の関係から 1:N にする過程をジェネレータでステップで記述するもの。しかし発火元からReducerにたどり着くまでが saga化 されるので、使った際に実際どのアクションが発火されていくか、すこぶる見通しは悪くなったと感じた。なんらかの命名規約なり、ビジュアライズの支援が必要になる。昔見た、アクション定義は多い割にどこで発火するか明示されない、死ぬほど辛い ActionScript3 のコードを思い出した。
https://gist.github.com/mizchi/6081622
sagaのAPIについては、最近 ES の generator の仕様を勉強しなおしたが、この小難しいAPIは「generator function を使うなら」 間違ってはいないと感じた。ただ、制御構造を generator の yield ベースで書きたいかというと、async/await がある今、好みの範疇であって、本質的な問題ではない。本質的な問題に注力してしまったので、やはり筋が悪いのではないか。
サーバーサイドJSでも express 対抗の koa にも同じことが言えるが、あれはパフォーマンスの問題ということなので、同じようには語れない、気がする。どうだろう。gulp 対抗の fly も同じ。
(結局async/await は Promise と Generator を使った polyfill という反論はわかる)
最近、Vue が流行っているのも、結局はシンプル化への揺り戻しだと思ってるので、Functional JavaScript を標榜して必要以上に物事を複雑化していくのは、まったく正しい姿勢ではないと思って、自分は意図的に rxjs や immutable-js を切り捨ててきたが、そういう趨勢が自分以外にも表に出てくると、一気にオワコンな空気が出る可能性がある。
僕がRedux嫌いというのは昔から一貫してる主張なんで、現時点で自分がこう主張したから趨勢が変わるというのはない。
https://github.com/mizchi/flumpt
非同期取れる flux というのを目指して作った flumpt, 僕自身使うタイミングなかったんだけど(かわりに内部APIを切り出した https://github.com/mizchi/react-dispatcher-decorator を使っていた)、思ったより使われてて、というか某社でめっちゃプロダクションに投入してます！って言われてびびったので、腐らないよう、APIをReduxを真似して、HOC版を作った。flux フレームワークの荒れてる時期に、HOCという言葉もない時代に作ったから、APIがダサいところがあった。
https://github.com/mizchi/flumpt#with-decorator
と、ここまで書いて思うと、やはり自分の意見は flumpt の作者としてのポジショントークにすぎないのではないか、という気持ちになったので、この話は終わり。はい解散、解散。