redux-thunk 和 redux-promise 有什么区别？

Question

据我所知，如果我错了，请纠正我， redux-thunk是一个中间件，它可以帮助我们在操作本身中调度异步函数和调试值，而当我使用redux-promise时，我无法在不实现自己的情况下创建异步函数作为 Action 的机制会引发仅调度普通对象的异常。

这两个包之间的主要区别是什么？ 在单个页面反应应用程序中使用这两个包或坚持使用 redux-thunk 有什么好处吗？

Answer 1

redux-thunk允许你的动作创建者返回一个函数：

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

redux-promise允许他们返回一个 promise ：

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

如果您需要异步或有条件地调度操作，这两个库都很有用。 redux-thunk还允许您在一个动作创建者中分派多次。 无论您选择一个，另一个或两者都完全取决于您的需求/风格。

Answer 2

您可能希望/需要在您的应用程序中同时使用两者。 从 redux-promise 开始，用于生成 promise 的常规异步任务，然后随着复杂性的增加扩大规模以添加 Thunks（或 Sagas 等） ：

• 当生活很简单，而你只是与返回一个承诺的创建者做基本的异步工作，那么redux-promise将改善你的生活并简化它，快速而简单。 （简而言之，当它们解决时，您不需要考虑“解包”您的承诺，然后编写/发送结果，redux-promise(-middleware) 会为您处理所有无聊的事情。）
• 但是，在以下情况下，生活会变得更加复杂：
• 也许您的动作创建者想要产生几个承诺，您希望将它们作为单独的动作分派给单独的减速器？
• 或者，在决定如何以及在何处分派结果之前，您需要管理一些复杂的预处理和条件逻辑？

在这些情况下， redux-thunk的好处是它允许您将复杂性封装在您的 action-creator中。

但请注意，如果您的 Thunk 生成并发送 Promise，那么您需要同时使用这两个库：

• Thunk 将组成原始动作并调度它们
• 然后redux-promise将在 reducer 处处理由 Thunk 生成的单个 promise 的展开，以避免需要的样板文件。 （你可以在 Thunks 中做所有事情，用promise.then(unwrapAndDispatchResult).catch(unwrapAndDispatchError) ...但你为什么要这样做？）

---

总结用例差异的另一种简单方法： Redux 操作周期的开始与结束：

• Thunks 用于 Redux 流程的开始：如果您需要创建一个复杂的操作，或者封装一些复杂的操作创建逻辑，请将其排除在您的组件之外，并且绝对排除在 reducer 之外。
• redux-promise用于结束您的流程，一旦一切都归结为简单的承诺，您只想解开它们并将它们的已解决/拒绝值存储在商店中

---

注释/参考：

• 我发现redux-promise-middleware是对原始redux-promise背后想法的更完整和更易于理解的实现。 它正在积极开发中，并且还得到了redux-promise-reducer良好补充。
• 还有其他类似的中间件可用于组合/排序您的复杂操作：一个非常流行的中间件是redux-saga ，它与redux-thunk非常相似，但基于生成器函数的语法。 同样，您可能会将它与redux-promise结合使用，因为 sagas 会产生您不想用大量样板文件手动解包和处理的承诺......
• 这是一篇很棒的文章，直接比较了各种异步组合选项，包括 thunk 和 redux-promise-middleware。 （TL;DR： “Redux Promise Middleware 与其他一些选项相比显着减少了样板文件” ...... “我认为我喜欢 Saga 用于更复杂的应用程序（阅读：“uses”），而 Redux Promise Middleware 用于其他一切。” )
• 请注意，有一个重要的情况，您可能认为您需要调度多个操作，但实际上您不需要，您可以让简单的事情保持简单。 这就是您只希望多个减速器对单个异步调用做出反应的地方，并且您倾向于将多个操作分派给这些多个减速器。 但是，根本没有理由为什么多个 reducer 不能监控单个动作类型。 您只需要确保您的团队知道您正在使用该约定，因此他们不会假设只有一个 reducer（具有相关名称）可以处理给定的操作。

Answer 3

全面披露：我对 Redux 开发相对较新，并且自己也在为这个问题而苦苦挣扎。 我将解释我找到的最简洁的答案：

ReduxPromise 在分派操作时返回一个 Promise 作为有效负载，然后 ReduxPromise 中间件解析该 Promise 并将结果传递给 reducer。

另一方面，ReduxThunk 强制动作创建者推迟将动作对象实际分派给减速器，直到调用分派。

这是我找到此信息的教程的链接： https ://blog.tighten.co/react-101-part-4-firebase。