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

Question 1

redux-thunkは、間違っている場合は私が知り、修正する限り、非同期関数をディスパッチし、アクション自体の値をデバッグするのに役立つミドルウェアですが、redux-promiseを使用すると、独自の関数を実装しないと非同期関数を作成できませんでしたアクションとしてのメカニズムは、プレーンオブジェクトのみをディスパッチするという例外をスローします。

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

Question 2

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つのアクション作成者内で数回ディスパッチすることもできます。1つを選択するか、もう1つを選択するか、または両方を選択するかは、完全にニーズ/スタイルに依存します。

Question 3

あなたはおそらくあなたのアプリで両方を一緒にしたい/必要とするでしょう。まずは、promiseを生成するルーチンの非同期タスクのredux-promiseから始め、次に、スケールアップしてサンク（またはSagasなど）を追加します。

人生がシンプルで、単一の約束を返すクリエイターとの基本的な非同期作業を行っているだけでredux-promise、人生を改善し、それを簡単にすばやく行うことができます。（簡単に言えば、約束が解決されたときに約束を「アンラップ」することを考える必要がなく、結果を書き込み/ディスパッチする代わりに、redux-promise（-middleware）がすべての退屈なことを処理します。）
しかし、次のような場合、人生はより複雑になります。
- アクションの作成者が複数のプロミスを作成したいと思うかもしれませんが、それらは別々のアクションとしてレデューサーを分離するためにディスパッチしたいですか？
- または、結果をディスパッチする方法と場所を決定する前に、管理する複雑な前処理と条件付きロジックがありますか？

このような場合の利点はredux-thunk、アクション作成者の内部に複雑さをカプセル化できることです。

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

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

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

サンクはReduxフローの最初の部分です。複雑なアクションを作成する必要がある場合、または危険なアクション作成ロジックをカプセル化してコンポーネントから除外し、レデューサーから除外する必要がある場合。
redux-promiseすべてが単純なプロミスにまとめられ、それらをアンラップして、解決済み/拒否された値をストアに格納したい場合、フローの終わりです

注/ REFS：

私が見つけredux-promise-middleware、オリジナルの背後にある考え方をより完全に理解し、実施しますredux-promise。これは活発に開発されており、によってもうまく補完されていredux-promise-reducerます。
複雑なアクションの構成/シーケンスに使用できる同様のミドルウェアが他にもあります。非常に人気のあるミドルウェアはですredux-saga。これはに非常に似てredux-thunkいますが、ジェネレーター関数の構文に基づいています。繰り返しになりますが、と組み合わせて使用する可能性がありますredux-promise。
サンクやredux-promise-middlewareなど、さまざまな非同期構成オプションを直接比較する優れた記事を次に示します。（TL; DR：「Redux Promiseミドルウェアは、他のいくつかのオプションと比べて、定型文を大幅に削減します」 ... 「より複雑なアプリケーション（読み取り：「用途」）についてはSagaが好きで、それ以外のものについてはRedux Promiseミドルウェアが好きです。」）
複数のアクションをディスパッチする必要があると思うかもしれないが実際にはそうしない重要なケースがあることに注意してください、そしてあなたは単純なものを単純に保つことができます。ここで、複数のレデューサーが非同期呼び出しに反応するようにします。ただし、複数のレデューサーが1つのアクションタイプを監視できない理由はまったくありません。チームがその規則を使用していることをチームに確実に知らせたいので、特定のアクションを処理できるのは1つのレデューサー（関連する名前を持つ）だけではないと想定しません。

Question 4

完全な開示：私はReduxの開発に比較的慣れていないため、この質問に自分自身で取り組んでいます。私が見つけた最も簡潔な答えを言い換えます：

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

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

これが私がこの情報を見つけたチュートリアルへのリンクです：https : //blog.tighten.co/react-101-part-4-firebase。