我一直在阅读有关传奇故事、它们的意图和用法的内容。但是 - 我有两个问题我真的很想结束，然后更多的是一个意见问题。
- 当使用 Sagas 进行简单的 api 调用时，样板文件似乎非常过多。如果我有 20 个 api 调用，这比使用 thunk 更方便吗？另外，我一直听到“副作用”的想法 - 但我不确定它是如何发挥作用的。
我读过一些博客，它们使用了一种能够动态生成 Sagas 来减少样板文件的模式 - 但你不能也用 thunk 来做到这一点吗？另外，任何例子都会很棒。
- 在处理非常简单的 post 或 get 调用时，Sagas 仍然有用吗？
对 redux-sags 与 redux-observables 有什么看法吗？
谢谢!
最佳答案
免责声明:我是 redux-observable 的作者之一，因此我对 redux-saga 和 redux-observable 的看法都带有偏见
由于您使用了术语 Saga(而不是 Epic)，我假设您是在 redux-saga(而不是 redux-observable)的上下文中询问。
在 redux-saga 中，你所做的效果，例如AJAX 请求实际上并不在您的生成器传奇中直接处理。相反，您使用的帮助器正在创建普通的旧 JavaScript 对象，这些对象代表效果意图，您产生，然后是 redux-saga 中间件本身在内部执行效果，对您隐藏，将结果返回给您的 yield ，例如 yourSaga.next(response)。
有些人喜欢这样，因为你的传奇生成器是真正纯粹的。因为它使用生成器来支持多种效果，所以无需模拟即可轻松测试，因为您只需断言它产生的效果是预期的。就我个人而言，我发现在实践中这看起来比实际情况要酷得多:很多时候你最终会有效地重新创建传奇在测试中所做的一切。您现在正在测试传奇的实现是否正确，而不是测试传奇的行为。很多人并不关心(甚至注意到这一点)，但我关心。我想有些人甚至更喜欢它。这称为“效果即数据”。 FWIW，redux-observable 没有使用这种“效果即数据”模型，这是它与 redux-saga 之间最根本的区别。
将这与它们与 redux-thunk 的比较联系起来，最大的区别是:基于时间的操作(例如去抖动顺序操作)在没有重大黑客攻击的情况下单独使用 redux-thunk 是不切实际的。说到去抖动，它根本不附带任何实用程序，因此您需要处理去抖动和其他常见效果。测试要困难得多。
然而，这些大多是意见。当然，非常成功的应用程序可以(并且已经)使用 redux-thunk。 https://m.twitter.com我想到了。
我认为，对于简单的请求->响应 AJAX 调用，redux-thunk 明显更容易学习和使用，而不需要取消等，这不会有争议。事实上，我经常推荐不熟悉 RxJS 的用户使用redux-thunk 处理简单的事情，只依靠 redux-observable 处理更复杂的事情，这样他们就可以保持生产力并边学习边学习。学术上的“正确性”和漂亮的代码肯定有一席之地，但对于大多数人的工作来说，shipit™ 应该是第一要务。用户并不关心我们的代码有多正确，只关心它存在并且[大部分]有效。
关于 redux-saga 与 redux-observable 的观点，我有偏见，因为我是 redux-observable 的作者之一，但我在之前的 SO 帖子中总结了一些想法:Why use Redux-Observable over Redux-Saga? tl;dr 它们具有相似的整体模式，但 redux-saga 使用“效果作为数据”，而 redux-observable 使用 RxJS 的真实效果。两者都有优点和缺点，使用 RxJS 的主要优点是，它是一项对于 redux-observable 以外的事情非常有用的技能，并且几乎肯定会比 redux-observable/redux-saga 更长寿，因此该技能是高度可转移的。
关于Redux 传奇，rx-observable。对于普通的获取调用，为什么需要重击？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/41192264/