なぜReduxを使うのか

Transcript

1. なぜReduxを使うのか @kuy / Yuki Kodama 2016.05.31 @ HTML5とか勉強会 #65
2. 自己紹介 @kuy (カイ) / Yuki Kodama 株式会社ジャパンベンチャーリサーチ entrepedia（アントレペディア）の開発・運用 AWS, Ruby on Rails, JavaScript (React + Redux) • redux-sagaで非同期処理と戦う • Reduxでコンポーネントを再利用する • Reduxのmiddlewareを積極的に使っていく • ・・・など Qiita の記事
3. Redux、人気ですね 去年の7月あたりから右肩上がり Google トレンド（2016.05.31 時点） キーワード：redux、カテゴリ：プログラミング • 解説記事が増えてきた • 周辺コミュニティが活発 • 関連ライブラリが充実している • Server Side Rendering や ReactNative の事例もちらほら Redux 導入してみようかな！
4. ところが・・・ ・・・Redux 大丈夫か？ Twitter で見かける悲痛の声の数々 「Redux つらい・・・」 「Redux 難しい」 「イマイチ Redux の良さがわからん」
5. Redux 作者、Dan氏のツイート 「背景にあるアイデアを学んで、他所に適用しよう」
6. 順を追って理解してみる • Flux はなにを解決したのか？ • Redux はなにがいいのか？ • Flux の歴史に興味があれば → @amagitakayosiさん http://amagitakayosi.hatenablog.com/entry/2015/12/02/172453
7. Flux
8. Flux の構成要素とデータフロー データの流れは常に一方通行 Dispatcher を介して Action を Store に送ることでデータを変更する View は Store から受け取ったデータだけを使ってレンダリングする
9. Flux で解決したこと • React コンポーネント階層が深くなったときのバケツリレーを回避 • コンポーネント間のデータの融通が不要になった • デバッグが容易になった ◦ redux-logger だけで原因を特定できることも多い • テストが容易になった ◦ React コンポーネントが与えられた props だけに基づいてレンダリングされる ようになる 基本的には React 単体で構築したときに困ることの解決
10. Redux
11. Redux の構成要素とデータフロー #1 1. View から Store に向けて Action が送り込まれる
12. Redux の構成要素とデータフロー #2 2. Store の中で待ち受けているのはReducer 受け取った Action と現在の状態から新しい State を作り出す
13. Redux の構成要素とデータフロー #3 3. State が変更されたことを View に通知する
14. Redux の構成要素とデータフロー #4 4. 新しい State にもとづいて View が更新される
15. Redux と Flux の構成要素の違い Flux Redux View View Action Creator, Action Action Creator, Action Dispatcher (Store) Store Store (State) Store Reducer Store Middleware Store Store Enhancer 登場人物が増えたように見えるけど、もともと Store の住人
16. Redux のどこがいいのか • Single Store、Single State ◦ １つの巨大な State ツリーを複数の Reducer で構築 • 状態管理に特化した ◦ それ以外は開発者に丸投げ ◦ 自分の目的に合ったスタックで開発できる、とも言える • Store の役割を分割して名前を付けた ◦ Reducer、Middleware など ◦ 役割がはっきりすると効果的なテストが書きやすくなった
17. Multiple Stores、Multiple States By Fluxxor 複数の Store があると Store 間のデータのやりとりに困る React で困っていたことが再び・・・！
18. Single Store、Single State By Fluxxor Redux は Store も State も１つにした どの Store の変更通知をどの View に購読させるか悩まなくなった その代わり、State から必要な部分だけ切り出す（react-redux） Store が１つになったので Store 間のやり取りは不要
19. Reducer による State の分割 State の階層はそのまま Reducer の階層になっている 入れ子は可能だけど推奨されていない（必要なら normalizr などを使う）
20. 1. 必要な State を列挙して初期 State を決める 2. 各 State を変更するのに必要そうな Action を書く 3. 各 State に対応した Reducer を書く 分割された Reducer による State の構築 例えばブログアプリを考えると・・・ app: ユーザ名、認証情報、設定情報、・・・ posts: 記事データ、記事の順序、ページング情報、・・・ categories: カテゴリデータ tags: タグデータ 開発時の感覚としてはトップダウンではなくボトムアップ
21. 状態管理に特化した Redux を素の状態のまま使うのはおすすめできない（学習目的は除く） • フォームを作りたいときは？ → redux-form, react-redux-form • 通信処理のハンドリングはどうする？ → redux-api-middleware, redux-thunk • 非同期処理はどこにどうやって書く？ → redux-saga, redux-thunk 専用の Middleware ライブラリの導入を検討しよう 本当に必要なら Middleware を書いてみよう 無理して React、Action Creator、Reducer で実装すると後で大変です
22. Redux 再入門
23. State および Reducer の分割について combineReducers() ってどうなの？問題 State と Reducer は対応関係にあり、Reducer は担当の State 以外は見えない。 もし Reducer で他の Reducer が担当する State が欲しくなったらどうするの？ • State/Reducer の分割単位に問題がないか考えてみる ◦ 巨大な１つの Reducer にするという手もなくはない（けど、おすすめしない） • Middleware で情報を補完する ◦ Action には View が持ってる最小限の情報を持たせる ◦ Middleware でその Action をひろって改変 or 別 Action を投げて処理を継続する • Yet Another combineReducers() を模索する
24. State および Reducer の分割について http://bouzuya.hatenablog.com/entry/2016/05/25/235959 https://github.com/ryo33/combine-section-reducers combine-section-reducers: State 全体にも触れる combineReducers Thanks! @bouzuya, @bokuweb17
25. 非同期処理との戦い #1 1. 起動時に初期データを読み込む悪い例（ダメ。ゼッタイ。） • Reactコンポーネントとしての再利用性が低 くなる • もし間違って２箇所に配置したら２回読み込 まれる • 副作用のあるコードを仕込むのは避けた方 がいい • テストどうすんの？
26. 非同期処理との戦い #2 2. redux-api-middleware を導入 • 副作用を View から Middleware に追い出すことに成功 • Symbol の CALL_API をキーにするという、ちょっと意味わからない仕様によって Middleware で Action を扱いにくい • API呼び出しをチェーンさせたりするのどうしよう（ → Middleware 使うしか無い ）
27. 非同期処理との戦い #3 3. redux-thunk に移行 • Promise を使えばチェーンもできる • 変な CALL_API がなくなった • 複雑な Promise の処理を Action Creator に押し込んでいいのか？ • redux-thunk はほぼ Middleware と同等の ことができるのにカジュアルに使えてしまう （乱用すると危険） • テストどうすんの？ • 機能追加していくとひどいことになりそうな未 来が見える
28. 非同期処理との戦い #4 4. redux-saga に移行 ← イマココ • 非同期処理が読みやすい • 複雑な処理はどんどん分割する • テストが容易、モックを使わないとテストでき ない部分が最小限になる • やっていけそう
29. まとめ • 背景にあるアイデアや何を解決しようとしているのかを理解して、ライブラ リの流行り廃りに振り回されないようにしよう • Reducer の分割は一筋縄ではいかないのでしっかり悩もう • Redux には適切な Middleware を導入しよう
30. Thank you!