已关闭。此问题需要更多的focused。当前不接受答案。
**想要改进此问题吗？**更新问题，使其仅关注editing this post的一个问题。
13天前关闭。
Improve this question
看起来thunk和 Saga 是Redux Toolkit中允许副作用和异步操作的两种类型的中间件。基于一些基本的谷歌搜索，看起来thunk和saga基本上服务于相同的目的。在不了解这两种类型的中间件之间的关键区别的情况下，基于一些基本的谷歌搜索，我得到的印象是，从历史上看，形实转换（thunk）通常优选用于小到中等大小的应用程序，而传奇（ Saga ）通常优选用于较大的应用程序。
然而，在一些情况下，Redux Toolkit已经包含了thunk作为其切片实现的默认中间件。所以看起来Redux Toolkit开发团队已经决定thunk是比 Saga 更好的选择。我的推理正确吗？您能想到一个场景，在Redux Toolkit实现中saga是比thunk更好的选择吗（特别是在基于开发人员对sagas的经验水平的偏见之外）？或者，将thunk作为默认值是否表明Redux Toolkit开发团队在这两种中间件技术中选择了thunk？
看起来createAsyncThunk是thunk使用的主要函数，它通常用于支持api集成。退一步说，thunk的一般用途是“允许副作用和异步操作”，但实际上，生产应用中的绝大多数thunk实现都是专门用于支持api集成的吗？例如，如果我在一次采访中说我只在API集成中使用过thunk，那么如果这是90%以上的thunk使用案例，这是一个合理的说法吗？或者有没有什么特定的场景可以让你“我在过去使用过thunk，它不是专门用于api集成的，而是代表了一个您认为开发人员应该理解的重要用例场景。
最后，看起来Redux Toolkit开发团队现在推荐RTK Query用于API集成，而不是thunk。那么，您认为在新的Redux Toolkit实现中，使用thunk是推荐的方法的主要场景是什么？
1条答案
按热度按时间z5btuh9x1#
我是Redux的维护者和Redux工具包的创建者。
对以上所有问题的简短回答是“是的！"。
Thunk一直是Redux应用的默认/最常见的副作用中间件，很大程度上是因为它们的简单性。这就是为什么RTK包含了对Thunk的开箱即用支持。同样值得注意的是，虽然“获取数据并基于结果调度操作”可能是最常见的Thunk用例，但Thunk可能包含 * 任何 * 逻辑，同步或异步。
也就是说，大多数应用程序中的大多数“异步逻辑”实际上是“从API中获取数据”。这就是为什么我们创建了RTK Query，它完全取代了编写 * 任何 * thunk、reducer、effect或hook来管理数据获取的需要。
多年来，我们一直普遍反对在大多数情况下使用传奇。传奇是一个很好的动力工具，但它们有点像电锯。有几个非常特殊的场合，当你真正需要这个工具时，你需要所有的动力。但它不是你每天都需要的东西。并且我们特别建议不要将saga用于数据获取用例。
此外，新的RTK“监听器”中间件解决了与sagas相同的“React式逻辑”用例，但具有更简单的API、更小的捆绑包大小和更好的TS支持。
鉴于此，今天几乎没有理由使用传奇。
我将粘贴“异步逻辑的演变”演讲的最后一张幻灯片：
您尝试解决的使用情形是什么？
数据提取
*使用RTK查询作为数据提取和缓存的默认方法
createAsyncThunk响应操作/状态更改，异步工作流
*使用RTK侦听器作为响应存储更新和编写长时间运行的异步工作流的默认值
带状态访问的逻辑
*将thunk用于复杂同步和中等异步逻辑，包括访问
getState和调度多个操作我建议阅读我写的这些附加文章、演讲和文档页面：