Should I use redux-saga or not?

redux-sagaの解説、ReduxのMiddleware選定のお話、最近注目のMiddlewareの紹介をしました。デファクトは定まる気配がありません。

Transcript

1. Should I use redux-saga or not?
   @kuy / Yuki Kodama
   2016.09.27 @ React.js meetup #4
   

   View Slide

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

   View Slide

3. ✨ redux-saga ✨
   

   View Slide

4. ← ナルトの人
   ✨ redux-saga ✨
   Yassine Elouafi 氏
   github: @yelouafi
   twitter: @YassineElouafi2
   

   View Slide

5. redux-saga というのは
   ● Redux の Middleware
   ● React にも Redux にも書きたくないコードを置く場所を提供
   ● generator/yield によって非同期処理を同期処理として書ける
   ● あらゆる副作用をデータとして扱える
   ○ 強制されるわけではない
   ● ギリギリまでモックを使わないテストが可能
   ○ モック不要とは言ってない
   サンプルあるよ！ https://github.com/kuy/redux-saga-examples
   

   View Slide

6. redux-saga
   登場人物 Effect を使って処理を書く
   ● Saga: 実行したい処理をまとめたプロセ
   スのようなもの
   ● Effect: データとしての副作用
   ● Saga Runtime: 実行環境
   ● Effect を yield で返す Generator 関数
   ● Saga Runtime が Effect を実行
   ● 内部的には状態マシンになってる
   ● call: (非)同期関数呼び出し
   ● select: 状態の取得する
   ● put: Actionのdispatch
   ● take: Actionを待ち受ける
   ● fork: 別の Saga を起動する
   ● cancel: 起動した Saga を中止する
   ● ....などなど
   redux-saga が提供する実行環境で Saga を起動する
   実装
   

   View Slide

7. redux-saga の動作イメージ
   

   View Slide

8. redux-saga の挙動（ call ）
   var eff = mySaga.next(); var ret = yield call(hoge, 10);
   [1] ... = mySaga.next()
   [2] ... = yield call(hoge, 10)
   [3] var eff = ...
   hoge(10).then(ret => ...)
   mySaga.next(ret)
   [4] var ret = ...
   Saga Runtime Your Saga
   e.g. (pseudo) “call” effect object
   { fn: hoge, args: [10] }
   

   View Slide

9. redux-saga の挙動（ select ）
   var eff = mySaga.next(); var data = yield select(foo);
   [1] ... = mySaga.next()
   [2] ... = yield select(foo)
   [3] var eff = ...
   var data = foo(getState())
   mySaga.next(data)
   [4] var data = ...
   Saga Runtime Your Saga
   e.g. (pseudo) “select” effect object
   { fn: foo }
   

   View Slide

10. redux-saga と redux-thunk のコード比較
    ----- redux-saga ----- ----- redux-thunk -----
    呼び出しコード（共通）
    dispatch(fetchAPI());
    

    View Slide

11. redux-saga のコードが増えてきたら
    ● 適切に分割する
    ○ 単一責務を意識する
    ○ 例：あるActionを受け取ったら別のActionをdispatchして画面遷移する
    →ActionをチェインさせるsagaとActionを受け取ったら画面遷移するsagaを独
    立して動作させる
    ● 共通のsagaを切り出す
    ● 変化の少ないソリッドな処理はMiddlewareで書く
    ○ Socket.IO、Firebaseの連携など
    ● あくまでもsagaはロジックを書く場所にしておく
    ● 他で書けない/書きたくないものをsagaで書く
    ● ・・・詳しく知りたい部分があったら直接聞いて下さい！ → @kuy or リアル
    

    View Slide

12. redux-saga の問題点
    ● 基本的に初見殺し
    ● 学習・導入コストが小さくない
    ● generator/yield が必須
    ○ regeneratorRuntime によってスタックトレースが死ぬ
    ● 隠しきれないコード中の yield の存在感
    ● dispatch された Action を reject できない
    他の Middleware はどうなんだろう？
    

    View Slide

13. redux-saga
    redux-loop redux-machine
    redux-api-middleware
    redux-observable
    redux-thunk
    redux-promise
    redux-effects
    redux-task
    redux-logic
    Side Effect 関連の Middleware 多すぎ・・・
    全部見たい人→ https://github.com/markerikson/redux-ecosystem-links/blob/master/side-effects.md
    

    View Slide

14. Redux Middleware 戦争最前線！！
    @kuy / Yuki Kodama
    2016.09.27 @ React.js meetup #4
    

    View Slide

15. Middleware の選び方（テストの容易さ）
    ※ 個人の感想です
    

    View Slide

16. Middleware の選び方（プロジェクトの規模）
    ※ 個人の感想です
    

    View Slide

17. Middleware の選び方（プロジェクトの規模）
    ※ 個人の感想です
    ！？
    

    View Slide

18. Side Effect Middleware に求めているもの
    ● Scalability + Composability
    ○ 適切にコードを分割できる、共通化しやすい
    ○ 全体を知らなくても、部分的な理解でメンテ可能
    ● Testability
    ○ 本当にテストしたい部分だけテストコードを書ける
    ● Background/Long-Running Process
    ○ UIコードと完全分離したい
    

    View Slide

19. redux-thunk redux-saga
    ⚔
    

    View Slide

20. Beyond redux-saga…?
    

    View Slide

21. ⚙ redux-logic ⚙
    

    View Slide

22. redux-logic（まだ実戦投入してない ）
    ✅ 第一印象：Middleware を構造化してくれる Middleware、内部はRxJS
    ✅ 副作用コードを validate, transform, process の3つに分ける
    redux-sagaで不可能だったActionの reject が可能！
    ✅ 好みの方法でロジックを書ける
    vanilla, RxJS, async/await
    処理によって得意分野が違うから、書き分けするのもあり？
    ✅ サービスがDIされるので比較的テストしやすい（はず）
    けど、モックは避けられない・・・？
    ❌ 副作用をデータとして扱っているわけではない
    要調査： async/awaitを使った場合のテストは？
    "I wrote the rxjs code so you won't have to." by @jeffbski
    

    View Slide

23. さらに続く期待の新人たち・・・
    ● clarus/redux-ship (redux-sagaの正統進化系になりえる？)
    ○ Composable, typable and testable Redux middleware
    ● exponentjs/redux-effex
    ○ Spin off async functions to perform side effects
    どちらも副作用をデータとして扱っている
    

    View Slide

24. まとまらない
    Middleware 戦争、収束の見込み無し。
    本当に必要なものを見極めて使っていこうね。
    

    View Slide

25. yield call(say, “Thank you!”);
    

    View Slide

26. View Slide

27. 参考資料
    [GitHub] “Redux Ecosystem Links > Side Effects”
    markerikson/redux-ecosystem-links
    

    View Slide

28. redux-thunk redux-saga
    ⚔
    

    View Slide

29. redux-thunk v.s. redux-saga
    ● 導入、学習コスト：小さい、大きい
    ● スケール：しない、する
    ○ ここで言うスケールってのは機能追加するときに、できるだけ既
    存のコードをいじらずに拡張していけるという意味です
    ● テスト：面倒、簡単
    

    View Slide

30. 学習コスト
    ● redux-thunkはAction CreatorからActionの代わりに関数投げれば
    いいだけなので簡単
    ● redux-sagaは考え方を学んだ上でGenerator関数の知識も必要
    だったりしてサクサク書くまでには慣れが必要
    

    View Slide

31. 導入コスト
    ● redux-thunkはMiddlewareとして追加して、Action Creatorに処理
    を書けば終わり
    ● redux-sagaはGenerator関数が必須なのでビルド設定の変更が必
    要なのと、以前と比べるとcreateStore周りの書き方が若干面倒に
    なった
    

    View Slide

32. スケール
    ● redux-thunkはAction Creatorの中に処理を書くため、が切り出しの
    単位になるが、基本的にただの関数なので処理を分割しにくい。共
    通化するとしたらAction Creator単位。
    ● redux-sagaはそれぞれのsagaがプロセスのように動いてくれるの
    で他のsagaが何やってるのか気にならないし、責務ごとに分割しや
    すい。共通化はあらゆるレベルで可能。
    

    View Slide

33. React.js
    React.js
    View State
    Side Effect
    

    View Slide

34. React.js + Redux
    React.js
    Redux
    View State
    Side Effect
    状態管理を Redux に任せた
    

    View Slide

35. React.js + Redux
    React.js
    Redux
    View State
    Side Effect
    これどうしよう？
    

    View Slide

36. React.js + Redux + redux-saga
    React.js
    Redux
    View State
    Side Effect
    redux-saga
    Middleware
    理想的な Side Effect Middleware とは？
    

    View Slide

37. redux-observable
    ● Netflixが開発、RxJS 5.x
    ● Epicの導入によってアクの強さが軽減された
    ● 副作用をデータとして扱ってない
    ○ → テストのしやすさの観点ではイマイチ
    ● RxJS知らないのにわざわざ勉強してまで使うメリットは感じられなかった
    ● RxJSをすでに知っているか、RxJSが大活躍するロジックをたくさん書く
    なら選択肢に含める、くらいの感じ
    

    View Slide

38. redux-saga 以外の選択肢
    ● redux-thunk
    ● redux-promise
    ● redux-observable
    ● redux-loop
    ● ...etc
    @shuheikagawa
    https://speakerdeck.com/shuhei/redux-middleware-wars-japanese
    

    View Slide

39. Middlewareの配置からざっくりつかむ
    ● 後置 → 基本的に監視＋追加のAction（安全）
    ● 前置 → Actionの改変の可能性（注意）
    ● Store Enhancer → 何するかわからん（要注意）
    

    View Slide