参考
- Read Me | Redux
- "Redux evolves the ideas of Flux"
- Flux | Application Architecture for Building User Interfaces
- Example: Todo List | Redux
- Redux入門【ダイジェスト版】10分で理解するReduxの基礎 - Qiita
- Redux入門 1日目 Reduxとは(公式ドキュメント和訳) - Qiita
- "state(状態)の管理は開発者に委ねられたままなので、Reduxはそこを解決するためにある。"
- Redux入門 1日目 Reduxとは(公式ドキュメント和訳) - Qiita
- Reduxとは? – PAYFORWARD
- "MVCの亜種にオブザーバパターンを乗せてデータの一方向性のルールを適用させたものだ。"
- ReactとFluxのこと // Speaker Deck
- "「fluxをインストールすればレールに乗れる」「fluxは完全に新しい概念、最高」これは嘘"
- "ただのobserverパターン"
- "データのフローは常に絶対必ず一方向"
- "どういったフローでデータが降ってきて、どういった結果が出たか、問題の切り分けがとても楽"
経験談
- Reactで気持ち複雑なチャットサービスをつくったんだけど、
- 複数の子コンポーネントが変更しうるデータは、各々stateとして扱っちゃお互いに反映されないし、
- だから大元データをstoreとして持ってる親コンポーネントからsetterのようなものをpropsとして渡すことになるんだけど、
- 子コンポーネントでいらないsetterを孫コンポーネントに伝えるためだけにpropsとして渡すとか変なことになってるので、
- 大親コンポーネントに渡すデータを一か所で管理するサブスクライバみたいなのがいて、子コンポーネントはそこへイベントをパブリッシュする みたいにすればいいのかなと思っていたんだけど
- fluxがやりたいobserverパターンってそういうことなのかなという理解をした ←ｲﾏｺｺ
やってみる
なんか、複数の子コンポーネントが、あるひとつのデータをお互いに変えれるようなモデルがいいなと思ったので、こういう感じでつくりました
http://otiai10.github.io/react-examples/ufo-catcher/
雑感
- Redux、なんか意識高そうだし、個人開発だとするとオーバーキル感否めないので敬遠してた
- やってみたら、単にpub/subモデルというか、Observerパターンというか、なんのことはない
- かつて自分が感じた不満をダイレクトに解決していたので、良さが分かりやすかった
大親コンポーネントから子コンポーネントへのpropsの受け渡しは、やっぱりだらだらやらなきゃいけないんだろうか- そんなことはなかった。さすが。下記追記を参照
- ReducerやActionCreaterをちゃんとつくって、combineReducersとか使い始めたらもっと意識高い
- Thanks to プロフェッサー subuta
DRY
ベルリンに引っ越しました。ご支援いただけるとマジでうれしいです！ ほしいものリスト（ベルリンに引っ越した）（わりと必需品）
追記: 2016/04/19
そんなことはなくて、子コンポーネントだろうが孫コンポーネントだろうが、勝手にconnectして、そのときのconnectの第1引数であるmapStateToPropsでちゃんと処理すれば、その末端コンポーネントのthis.propsとして扱える。だから、必要なComponentで必要なpropsにアクセスできるので、よいね、っていう話。
そのコミット と、そのときつまずいた問題。
Don't Repeat Yourself
