这个问题与过去不同，这就是为什么。这个问题是什么时候。由于两者本身都是很好的框架，问题是我什么时候应该使用 thunk 而不是 saga。因为我的一位朋友一直坚持让我在我们的应用程序中使用 saga，但没有明显的原因。提前谢谢
问问题
6907 次
3 回答
17
根据一些阅读和我的经验......
使用 Thunk 而不是 Saga 来完成简单而琐碎的任务，例如：
- AJAX 调用
- 数据轮询，并且仅当它们直接由用户交互启动时。
使用佐贺
- 相互交织的任务，文档的登录示例非常完美
- 有很多步骤的流程并等待其他条件发生（“有限状态机”流程）
- 在后台工作并独立于用户交互（或背景/交互的混合）进行的任务
于 2019-01-22T07:34:05.403 回答
9
喜欢 saga 而不是 thunk 或相反的谎言取决于手头的任务。两者都有其公平的权衡。
Thunks 分派一个函数，该函数又分派一个动作。所以，
- 优点：维护简单的代码
- 缺点：必须在测试用例中模拟 thunk 的异步行为，这可能会变得非常笨拙
- 暗示：适用于应用程序的小型、直接的异步部分
Sagas 在下面使用生成器函数，因此该函数实际上会在异步操作处暂停并在解决时恢复
- 优点：测试用例变得公平和直接，无需模拟异步行为
- 缺点：给代码带来了更多的复杂性
- 暗示：适用于需要复杂单元测试用例的应用程序的复杂异步部分
于 2019-01-22T14:42:42.100 回答
6
thunk are saga 都用作 redux 的中间件，通常用于 api hit。与 saga 相比，thunk 非常易于使用，但是 saga 比 thunk 有很多好处，例如 saga 有效果takeLatest，如果用户反复按下按钮会很有效，thunk 会在每次点击时使 api 命中，但只使用最新的 saga 效果（一个) api 命中。它也有其他效果和好处，但它有学习开销
于 2019-01-22T06:05:32.270 回答