15

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

私のアプリケーションでは、アクション クリエーターはほとんどの場合、バックエンドAPI に対して async axios [ajax] 呼び出しを行います。Redux-Promise をミドルウェアとして注入すると、非同期データ フローの問題が解決されます。

スケーラブルなアプリを考えると、アクション クリエーターで複数の axios 呼び出しをチェーンする必要があるかもしれません。Redux-Promise をミドルウェアとして引き続き使用できると思います。これにより、アプリの非同期データ フローが処理されます。

一般的に、チームは Redux-Thunk を使用する傾向が強く、この問題の構文がより複雑に感じます。私のアクション作成者のほとんどが axios 呼び出し (約束) のみを行っていることを考慮して、これら 2 つのフレームワークを評価する際に提案が必要です。Redux-thunk hereに関する多くの議論を見てきました。thunk がいかに役立つかを理解しました。. しかし、Promises のみに使用する場合に Redux-Promise と Redux-Thunk を一緒に評価することについて、さらに明確にする必要があります。そのような状況でどのミドルウェアが優れているか、またその理由は? Redux-Promise よりも Redux-Thunk を使用すると、どのような利点がありますか? それともありませんか？

4

1 に答える 1

24

Redux Promise は、コードを手動で記述せずに 3 つのアクション (要求、成功、失敗) をディスパッチするのに便利です。

Redux Thunk は、あるアクション クリエーターが別のアクション クリエーターを待機していると表現する場合の非同期データ フローに便利です。また、条件付きディスパッチと早期救済の現在の状態を読み取ることもできます。

それらを一緒に使用することも、特定のいずれかを使用することもできます。Redux Thunk から始めることをお勧めします。Redux Thunk の方が制御性が高く、汎用性が高いからです。動作するようになったら、 Redux Promise を追加して、3 種類のアクションのディスパッチに関連するボイラープレート コードの一部を削除することを検討できます。あまり役に立たないことがわかった場合は、削除してください。一方、すべてのサンク アクション クリエーターが 1 つの promise をディスパッチするだけであることに気付いた場合は、代わりに Redux Thunk を削除できます。

それでも混乱する場合は、ミドルウェアの動作に慣れるまで Redux Thunk を使用することをお勧めします。

于 2016-05-01T15:42:14.877 に答える