web-dev-qa-db-ja.com

redux-thunkとredux-promiseの違いは何ですか?

私の知る限り、間違っている場合は修正します redux-thunk は、 redux-promise Actionはプレーンオブジェクトのみをディスパッチする例外をスローするため、独自のメカニズムを実装しないと非同期関数を作成できませんでした。

これら2つのパッケージの主な違いは何ですか?単一ページのリアクションアプリで両方のパッケージを使用すること、またはredux-thunkに固執することで十分なメリットはありますか?

81
rash.tay

redux-thunkを使用すると、アクション作成者は関数を返すことができます。

function myAction(payload){
    return function(dispatch){
        // use dispatch as you please
    }
}

redux-promiseを使用すると、約束を返すことができます。

function myAction(payload){
    return new Promise(function(resolve, reject){
        resolve(someData); // redux-promise will dispatch someData
    });
}

両方のライブラリは、非同期または条件付きでアクションをディスパッチする必要がある場合に役立ちます。 redux-thunkを使用すると、1人のアクション作成者内で複数回ディスパッチすることもできます。どちらを選択するか、もう一方を選択するか、両方を選択するかは、ニーズ/スタイルに完全に依存します。

104
VonD

アプリで両方を一緒に使用する必要があります。 ルーチンのプロデュース非同期タスクのredux-promiseから開始し、複雑さが増すにつれてサンク(またはSagasなど)を追加するためにスケールアップします

  • 人生が単純で、単一の約束を返すクリエーターと基本的な非同期作業をしているだけなら、redux-promiseは人生を改善し、それを迅速かつ簡単に単純化します。 (一言で言えば、約束が解決するときに約束を「アンラップ」することを考える必要はなく、結果を記述/ディスパッチするのではなく、redux-promise(-middleware)がすべての退屈なものを処理してくれます。)
  • しかし、人生は次の場合により複雑になります。
    • アクション作成者が複数のプロミスを作成したい場合、それらを個別のアクションとして個別のレデューサーにディスパッチしたい場合がありますか?
    • または、結果をディスパッチする方法と場所を決定する前に、管理する複雑な前処理と条件付きロジックがありますか?

これらの場合、redux-thunkの利点は、action-creator内に複雑さをカプセル化できることです。

ただし、Thunkがpromiseを生成およびディスパッチする場合、両方のライブラリを一緒に使用する必要があることに注意してください

  • サンクは元のアクションを作成してディスパッチします
  • redux-promiseは、Thunkによって生成された個々のプロミスのリデューサーでのアンラップを処理し、それに伴うボイラープレートを回避します。 (あなたはcould代わりにpromise.then(unwrapAndDispatchResult).catch(unwrapAndDispatchError)...でサンクのすべてを行うことができますが、なぜですか?)

ユースケースの違いを要約する別の簡単な方法:Reduxアクションサイクルの開始と終了

  • サンクはReduxフローのbeginningのためのものです:複雑なアクションを作成する必要がある場合、またはいくつかの厄介なアクション作成ロジックをカプセル化して、コンポーネントから除外し、間違いなく除外する場合減速機の。
  • redux-promiseは、フローのendに対応します。すべてが単純な約束まで煮詰められたら、それらをアンラップして、解決/拒否された値を保存するだけです。店舗

注/参照:

  • redux-promise-middlewareは、元のredux-promiseの背後にあるアイデアのより完全で理解しやすい実装であると思います。それは活発に開発中であり、redux-promise-reducerによってうまく補完されています。
  • 複雑なアクションを構成/シーケンスするために利用可能な追加の類似ミドルウェアがあります。非常に人気のあるものはredux-sagaです。これはredux-thunkに非常に似ていますが、ジェネレーター関数の構文に基づいています。繰り返しますが、redux-promiseと組み合わせて使用​​することになるでしょう。
  • 素晴らしい記事 は、サンクやredux-promise-middlewareなどのさまざまな非同期構成オプションを直接比較しています。 (TL; DR: "Redux Promiseミドルウェアは、ボイラープレートを他のオプションのいくつかに対してかなり劇的に削減します。"... "複雑なアプリケーション(読み取り:「使用」)、、およびその他すべてのRedux Promiseミドルウェア。
  • 複数のアクションをディスパッチする必要があると思うかもしれないが、実際にはそうしないという重要なケースがあることに注意してください。シンプルなことをシンプルに保つことができます。そこで、複数のレデューサーが非同期呼び出しに反応するようにします。ただし、複数のレデューサーが単一のアクションタイプを監視できない理由はまったくありません。単に、その規則を使用していることをチームに認識させたいだけです。そのため、特定のアクションを処理できるのは(関連する名前を持つ)単一のレデューサーだけだと想定していません。
73
XML

完全な開示:私はReduxの開発に比較的慣れていないため、この質問に苦労しました。私が見つけた最も簡潔な答えを言い換えます:

ReduxPromiseは、アクションがディスパッチされると「ペイロード」としてプロミスを返します。その後、「ReduxPromise」ミドルウェアはそのプロミスを解決し、結果をリデューサーに渡します。

一方、ReduxThunkは、「ディスパッチ」が呼び出されるまで、実際にアクションオブジェクトをリデューサーにディスパッチすることをアクションクリエーターに保留させます。

この情報を見つけたチュートリアルへのリンクは次のとおりです。 https://blog.tighten.co/react-101-part-4-firebase

21
lgants