Reduxで非同期処理をしたい場合、Middlewareを使ったほうがいいというのはなんとなく理解したが、どのMiddlewareを使えばいいのか迷ったのでまとめてみる。
参考：Reduxで非同期処理をしたいときに、なぜMiddlewareを使わないといけないのか
いろいろと検索してみた所、「redux-thunk」「redux-saga」「redux-promise」というのが人気らしいと判断し、それぞれのメリットデメリットを調べてみた。
#redux-thunk
ActionCreatorではActionしか返すことができなかった。
それを、redux-thunkを使うことによって関数も返すことができるようになる。
今までのようなActionを返す関数と、非同期処理をしてその結果を使って上記関数を実行する関数を返す関数。
この２種類の関数をActionCreatorに書くことで非同期処理を動かす仕組みになっている。
##所感
新たに覚えることがほとんどなく、わかりやすいと思った。
ただ、「処理が完了した後に～」と続けていくとコールバックが大量にネストされていき見づらくなりそう。
#redux-saga
- １つのGenerator関数を実行する。
- 初めのActionがdispatchされるまで処理をストップさせる。
- dispatchされたら返り値を受け取って先に進む。
- HTTPリクエストを実行し、Promiseが完了されるまで処理をストップさせる。
- 完了したら返り値を受け取って先に進む。
- 受け取った返り値をつかって別のActionをdispatchする。
- 全ての処理が終わったら、また初めに戻りActionのdispatchを待つ。
上記例のように、Reduxの標準機能と関係ないところで同期的に処理をさせるGenerator関数（タスクと言う）を作成することによって、アプリケーションとして非同期処理を行う。
redux-sagaで非同期処理と戦う
詳しく知りたい場合は、この記事がわかりやすい。
##所感
redux-saga独自の書き方が結構な数ある。
学習コストは高くなるが、ActionCreatorを汚さない、要件追加に対応しやすいなど
理解できれば一番見やすいコードになると思った。
#redux-promise
redux-actionsと同じ作者。
Promiseがresolve(成功)、またはreject(失敗)したらdispatchが実行される
ActionCreatorにresolve処理とreject処理を書いてあげれば、勝手に非同期で実行してくれる。
##所感
ググっても情報が少なすぎて、わからないところもあるが、
HTTPリクエスト処理をaxiosやfetchなどのPromiseに対応したパッケージを使えば、綺麗なコードになるのではと思った。
#まとめ
| Middleware | メリット | デメリット |
|---|---|---|
| redux-thunk | 覚えることがほとんどない | コールバック地獄になる |
| redux-saga | ActionCreatorを汚さない 要件追加に対応しやすい |
学習コストが高い |
| promise | redux-actionsとの相性がいい | 情報が少ない |