Upgrade to Pro — share decks privately, control downloads, hide ads and more …

なぜReduxを使うのか

 なぜReduxを使うのか

70ac3e9e67226ea693e90c7eb8605cd7?s=128

Yuki Kodama

May 31, 2016
Tweet

More Decks by Yuki Kodama

Other Decks in Programming

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 ◦ 1つの巨大な 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

    も1つにした どの Store の変更通知をどの View に購読させるか悩まなくなった その代わり、State から必要な部分だけ切り出す(react-redux) Store が1つになったので 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 の分割単位に問題がないか考えてみる ◦ 巨大な1つの 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コンポーネントとしての再利用性が低 くなる • もし間違って2箇所に配置したら2回読み込 まれる

    • 副作用のあるコードを仕込むのは避けた方 がいい • テストどうすんの?
  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!