什么时候应该使用Redux Saga代替Redux Thunk，什么时候应该使用Redux Thunk代替Redux Saga？

Question

问题与过去不同，这就是为什么。这个问题是何时。由于两者本身都是好的框架，问题是我什么时候应该使用传奇而不是传奇。因为我的一位朋友一直坚持要求我在我们的应用中使用传奇，但没有明显的原因。谢谢你

Answer 1

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

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

• AJAX通话
• 数据轮询 并且只有在用户交互直接启动它们的情况下。

将Saga用于

• 任务交织，文档的login example很完美
• 具有很多步骤并等待其他条件发生的流（“有限状态机”流）
• 在后台运行并独立于用户交互（或后台/交互混合）进行的任务

Answer 2

两个thunk都是saga，它们用作redux的中间件，通常用于api命中。与saga相比，thunk易于使用，但是saga比thunk具有很多优点，例如saga具有效果takeLatest，如果用户反复按下按钮，thaga会很有效，thunk会在每次单击时使api命中，但使用saga仅会影响最新（一个）api命中。它也有其他作用，并且有好处，但是有学习开销

Answer 3

优先选择传奇而不是笨蛋取决于手头的任务。两者都有一定的取舍权衡。

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

• 优点：易于维护的代码
• 缺点：必须在测试用例中模拟thunk的异步行为，这可能会变得很笨拙
• 隐式：适用于应用程序的小型，直接异步部分

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

• 优点：测试用例变得公正而直接，而无需模拟异步行为
• 缺点：使代码更加复杂
• 简单：适合需要复杂单元测试用例的应用程序的复杂异步部分