什么时候应该使用 Redux Saga 而不是 Redux Thunk，什么时候应该使用 Redux Thunk 而不是 Redux Saga？答案

【问题标题】：When should I use Redux Saga instead of Redux Thunk, and when should I use Redux Thunk instead of Redux Saga?什么时候应该使用 Redux Saga 而不是 Redux Thunk，什么时候应该使用 Redux Thunk 而不是 Redux Saga？
【发布时间】：2019-06-15 13:24:32
【问题描述】：

问题与过去不同，这就是为什么。这个问题是什么时候。由于两者本身都是很好的框架，所以问题是我什么时候应该使用 thunk 而不是 saga。因为我的一位朋友一直坚持让我在我们的应用程序中使用 saga，但没有明显的原因。先谢谢了

【问题讨论】：

标签： reactjs react-redux redux-saga redux-thunk redux-middleware

【解决方案1】：

更喜欢 saga 而不是 thunk 或相反的谎言取决于手头的任务。两者都有各自的权衡取舍。

Thunks 调度一个函数，该函数又调度一个动作。所以，

优点：维护简单的代码
缺点：必须在测试用例中模拟 thunk 的异步行为，这可能会变得非常笨拙
暗示：适用于应用程序的小型、直接的异步部分

Sagas 在下面使用生成器函数，因此该函数实际上会在异步操作处暂停并在解决时恢复

优点：测试用例变得公平和直接，无需模拟异步行为
缺点：增加了代码的复杂性
Implies：适用于需要复杂单元测试用例的应用程序的复杂异步部分

【讨论】：

【解决方案2】：

根据一些阅读资料和我的经验...

使用 Thunk 而不是 Saga 来完成简单而琐碎的任务，例如：

AJAX 调用
数据轮询并且仅当它们由用户交互直接启动时。

将 Saga 用于

相互交织的任务，文档的login example 非常完美
流程包含很多步骤并等待其他条件发生（“有限状态机”流程）
在后台工作并独立于用户交互（或背景/交互的混合）进行的任务

【讨论】：

【解决方案3】：

thunk are saga 都用作 redux 的中间件，通常用于 api hit。与 saga 相比，thunk 很容易使用，但是 saga 比 thunk 有很多好处，例如 saga 有效果takeLatest 如果用户重复按下按钮会有效，thunk 会在每次点击时使 api 命中但只使用 saga 效果将进行最新的（一个）api 命中。它也有其他效果和好处，但它有学习开销

【讨论】：