なぜReduxを使うのか

Transcript

1. なぜReduxを使うのか
   @kuy / Yuki Kodama
   2016.05.31 @ HTML5とか勉強会 #65
   

   View Slide

2. 自己紹介
   @kuy (カイ) / Yuki Kodama
   株式会社ジャパンベンチャーリサーチ
   entrepedia（アントレペディア）の開発・運用
   AWS, Ruby on Rails, JavaScript (React + Redux)
   ● redux-sagaで非同期処理と戦う
   ● Reduxでコンポーネントを再利用する
   ● Reduxのmiddlewareを積極的に使っていく
   ● ・・・など
   Qiita の記事
   

   View Slide

3. Redux、人気ですね
   去年の7月あたりから右肩上がり
   Google トレンド（2016.05.31 時点）
   キーワード：redux、カテゴリ：プログラミング
   ● 解説記事が増えてきた
   ● 周辺コミュニティが活発
   ● 関連ライブラリが充実している
   ● Server Side Rendering や ReactNative の事例もちらほら
   Redux 導入してみようかな！
   

   View Slide

4. ところが・・・
   ・・・Redux 大丈夫か？
   Twitter で見かける悲痛の声の数々
   「Redux つらい・・・」
   「Redux 難しい」
   「イマイチ Redux の良さがわからん」
   

   View Slide

5. Redux 作者、Dan氏のツイート
   「背景にあるアイデアを学んで、他所に適用しよう」
   

   View Slide

6. 順を追って理解してみる
   ● Flux はなにを解決したのか？
   ● Redux はなにがいいのか？
   ● Flux の歴史に興味があれば →
   @amagitakayosiさん
   http://amagitakayosi.hatenablog.com/entry/2015/12/02/172453
   

   View Slide

7. Flux
   

   View Slide

8. Flux の構成要素とデータフロー
   データの流れは常に一方通行
   Dispatcher を介して Action を Store に送ることでデータを変更する
   View は Store から受け取ったデータだけを使ってレンダリングする
   

   View Slide

9. Flux で解決したこと
   ● React コンポーネント階層が深くなったときのバケツリレーを回避
   ● コンポーネント間のデータの融通が不要になった
   ● デバッグが容易になった
   ○ redux-logger だけで原因を特定できることも多い
   ● テストが容易になった
   ○ React コンポーネントが与えられた props だけに基づいてレンダリングされる
   ようになる
   基本的には React 単体で構築したときに困ることの解決
   

   View Slide

10. Redux
    

    View Slide

11. Redux の構成要素とデータフロー #1
    1. View から Store に向けて Action が送り込まれる
    

    View Slide

12. Redux の構成要素とデータフロー #2
    2. Store の中で待ち受けているのはReducer
    受け取った Action と現在の状態から新しい State を作り出す
    

    View Slide

13. Redux の構成要素とデータフロー #3
    3. State が変更されたことを View に通知する
    

    View Slide

14. Redux の構成要素とデータフロー #4
    4. 新しい State にもとづいて View が更新される
    

    View Slide

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 の住人
    

    View Slide

16. Redux のどこがいいのか
    ● Single Store、Single State
    ○ １つの巨大な State ツリーを複数の Reducer で構築
    ● 状態管理に特化した
    ○ それ以外は開発者に丸投げ
    ○ 自分の目的に合ったスタックで開発できる、とも言える
    ● Store の役割を分割して名前を付けた
    ○ Reducer、Middleware など
    ○ 役割がはっきりすると効果的なテストが書きやすくなった
    

    View Slide

17. Multiple Stores、Multiple States
    By Fluxxor
    複数の Store があると Store 間のデータのやりとりに困る
    React で困っていたことが再び・・・！
    

    View Slide

18. Single Store、Single State
    By Fluxxor
    Redux は Store も State も１つにした
    どの Store の変更通知をどの View に購読させるか悩まなくなった
    その代わり、State から必要な部分だけ切り出す（react-redux）
    Store が１つになったので Store 間のやり取りは不要
    

    View Slide

19. Reducer による State の分割
    State の階層はそのまま Reducer の階層になっている
    入れ子は可能だけど推奨されていない（必要なら normalizr などを使う）
    

    View Slide

20. 1. 必要な State を列挙して初期 State を決める
    2. 各 State を変更するのに必要そうな Action を書く
    3. 各 State に対応した Reducer を書く
    分割された Reducer による State の構築
    例えばブログアプリを考えると・・・
    app: ユーザ名、認証情報、設定情報、・・・
    posts: 記事データ、記事の順序、ページング情報、・・・
    categories: カテゴリデータ
    tags: タグデータ
    開発時の感覚としてはトップダウンではなくボトムアップ
    

    View Slide

21. 状態管理に特化した
    Redux を素の状態のまま使うのはおすすめできない（学習目的は除く）
    ● フォームを作りたいときは？ → redux-form, react-redux-form
    ● 通信処理のハンドリングはどうする？ → redux-api-middleware, redux-thunk
    ● 非同期処理はどこにどうやって書く？ → redux-saga, redux-thunk
    専用の Middleware ライブラリの導入を検討しよう
    本当に必要なら Middleware を書いてみよう
    無理して React、Action Creator、Reducer で実装すると後で大変です
    

    View Slide

22. Redux 再入門
    

    View Slide

23. State および Reducer の分割について
    combineReducers() ってどうなの？問題
    State と Reducer は対応関係にあり、Reducer は担当の State 以外は見えない。
    もし Reducer で他の Reducer が担当する State が欲しくなったらどうするの？
    ● State/Reducer の分割単位に問題がないか考えてみる
    ○ 巨大な１つの Reducer にするという手もなくはない（けど、おすすめしない）
    ● Middleware で情報を補完する
    ○ Action には View が持ってる最小限の情報を持たせる
    ○ Middleware でその Action をひろって改変 or 別 Action を投げて処理を継続する
    ● Yet Another combineReducers() を模索する
    

    View Slide

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
    

    View Slide

25. 非同期処理との戦い #1
    1. 起動時に初期データを読み込む悪い例（ダメ。ゼッタイ。）
    ● Reactコンポーネントとしての再利用性が低
    くなる
    ● もし間違って２箇所に配置したら２回読み込
    まれる
    ● 副作用のあるコードを仕込むのは避けた方
    がいい
    ● テストどうすんの？
    

    View Slide

26. 非同期処理との戦い #2
    2. redux-api-middleware を導入
    ● 副作用を View から Middleware に追い出すことに成功
    ● Symbol の CALL_API をキーにするという、ちょっと意味わからない仕様によって Middleware で Action
    を扱いにくい
    ● API呼び出しをチェーンさせたりするのどうしよう（ → Middleware 使うしか無い ）
    

    View Slide

27. 非同期処理との戦い #3
    3. redux-thunk に移行
    ● Promise を使えばチェーンもできる
    ● 変な CALL_API がなくなった
    ● 複雑な Promise の処理を Action Creator
    に押し込んでいいのか？
    ● redux-thunk はほぼ Middleware と同等の
    ことができるのにカジュアルに使えてしまう
    （乱用すると危険）
    ● テストどうすんの？
    ● 機能追加していくとひどいことになりそうな未
    来が見える
    

    View Slide

28. 非同期処理との戦い #4
    4. redux-saga に移行 ← イマココ
    ● 非同期処理が読みやすい
    ● 複雑な処理はどんどん分割する
    ● テストが容易、モックを使わないとテストでき
    ない部分が最小限になる
    ● やっていけそう
    

    View Slide

29. まとめ
    ● 背景にあるアイデアや何を解決しようとしているのかを理解して、ライブラ
    リの流行り廃りに振り回されないようにしよう
    ● Reducer の分割は一筋縄ではいかないのでしっかり悩もう
    ● Redux には適切な Middleware を導入しよう
    

    View Slide

30. Thank you!
    

    View Slide