昨日ReactとReduxで悩んだが結局理解しきれなかった。でも悩むのが大事だと思う。今日会社に来てから頭をもうひと捻りしたら完全に理解した。
Reduxの存在意義がいまいちわからなかった。ReactComponent自信がレンダリングするために必要な情報を自分で持っていることの何が悪いのだろう、と思っていた。オブジェクト指向的で大変良いとすら思っていた。しかし、Reactはビューに特化したフレームワークなのである。DOMを組み立てることだけを責務にすべきであり、基本的にはステートレスであるべきだと悟った。jQuery時代、レンダリングするべき情報はDOMそれ自体が持つしか無かった。これを情報はjsonという形で切り出しDOMとは分離するという仕事をするのがReactなのだ。
で、Reduxは大きなjsonと思えば良い。DOMとは完全に切り離された綺麗な世界でアプリケーションの情報を持っている。ビューのフレームワークはReactでなくてもVue.jsでもいいし、いっそフレームワークを使わなくても扱うことのできる汎用的な形で情報を持つものだ。この情報はStateと呼ばれStoreという場所に保存される。Reducerという門番がActionを受け取り現在のStateと畳み込んで（Reduceして）新たなStateとしStoreに保存する。
ReactとReduxの世界を取り持つのがreact-reduxだ。Reactの世界の住人であるpropsにReduxの世界の住人を押し込んで、ReactからReduxの存在を隠蔽するための仕組みだ。これは多少複雑で本当に必要なのかおれには疑問に思えたが、一般的に流行っている形だというので利用することにする。
以上のような理解をしたので、フロントエンドを構築するとき、まず考えるべきはユースケースと状態遷移なのだと結論付けた。どういうActionが起こったときにStateはどういう状態になるのか、これをはっきりさせ、それをReducerという形で落とし込む。あとはReactからActionを発行するだけで良い。DOMの構築やらデザインやらはそのあとだ。というわけで仕事のススメ方がわかった。あとは設計だとおもっているが、一旦サンプルアプリケーションを作って考え方が正しいのか確認してみる。
