什么时候应该使用 Redux Saga 而不是 Redux Thunk，什么时候应该使用 Redux Thunk 而不是 Redux Saga？
Posted
技术标签:
【中文标题】什么时候应该使用 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? 【发布时间】：2019-06-15 13:24:32 【问题描述】：问题与过去不同，这就是为什么。这个问题是什么时候。由于两者本身都是很好的框架，所以问题是我什么时候应该使用 thunk 而不是 saga。因为我的一位朋友一直坚持让我在我们的应用程序中使用 saga，但没有明显的原因。先谢谢了
【问题讨论】：
【参考方案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 命中。它也有其他效果和好处，但它有学习开销
【讨论】：
以上是关于什么时候应该使用 Redux Saga 而不是 Redux Thunk，什么时候应该使用 Redux Thunk 而不是 Redux Saga？的主要内容，如果未能解决你的问题，请参考以下文章
为啥 redux-saga 使用 put 方法而不是 dispatch？
为啥使用 redux-thunk 或 redux-saga 进行 fetches？