Axios apisで使用するRedux-ThunkとRedux-Promiseの違いは何ですか？

Question

私はReact、Reduxを数ヶ月から使っています。エコシステムの最も混乱しやすい部分の1つは、非同期データフローです。利用可能な多くの優れたソリューションがあり、問題に適したソリューションを選択するのは難しい作業です。

私のアプリケーションでは、アクション作成者のほとんどが非同期axios [ajax]がバックエンドapiを呼び出しています。ミドルウェアとしてRedux-Promiseをインジェクトすると、非同期データフローの問題が解決されます。

スケーラブルなアプリケーションを考えると、私はアクション作成者に複数のアクシオコールを連鎖させる必要があるかもしれません。私はまだミドルウェアとしてRedux-Promiseを使用できると思うし、これは私のアプリで非同期のデータフローを処理するだろう。

一般的に、チームはRedux-Thunkを使用する傾向が強く、この問題の構文がより複雑に感じられます。私のアクションクリエイターの大部分がアクシオスコール（約束）だけをしていると考えて、これらの2つのフレームワークを評価する際の提案が必要です。私はRedux-thunk hereについて多くの議論を見ました。私はサンクがどのように役立つのか理解しました。 。しかし、私は、約束のためだけにRedux-PromiseとRedux-Thunkを一緒に評価すると、もっと明確にする必要があります。どのミドルウェアがそのような状況で優れているのですか？ Redux-Thunk over Redux-Promiseを使用して得られる利点は何ですか？それとも何もないのですか？

Answer 1

Redux Promiseは、コードを手動で記述することなく、3つのアクション（リクエスト、成功、失敗）をディスパッチするのに便利です。

Redux Thunkは、あるアクション作成者を別のアクション作成者を待って表現するとき、非同期データフローに便利です。また、条件付きの派遣と早期救済措置の現状を読むことができます。

これらを一緒に使用することも、特にいずれかを使用することができます。 Redux Thunkで始めることをお勧めします。なぜなら、より多くの制御を提供し、より汎用性が高いからです。それを有効にしたら、を追加して Redux Promiseを実行して、3種類のアクションをディスパッチするための定型コードを削除することができます。あなたがそれほどあなたを買わないことが分かったら、それを取り除いてください。一方、あなたがアクションクリエイターのすべてがただ一つの約束を送るだけであれば、代わりにRedux Thunkを削除することができます。

これはまだ混乱している場合は、ミドルウェアの仕組みに慣れるまでRedux Thunkを使用することをお勧めします。