我一直在阅读有关 sagas、它们的意图和用法的信息。但是 - 我有两个问题我真的很想结束，然后是更多的意见问题。
我阅读了一些博客，它们使用了一种能够动态生成 Sagas 以减少样板代码的模式 - 但您不能也使用 thunk 来做到这一点吗？此外，任何示例都会很棒。
对 redux-sags 与 redux-observables 有何看法？
谢谢！
【问题讨论】：
标签： redux redux-saga redux-observable
免责声明：我是 redux-observable 的作者之一，所以我对 redux-saga 和 redux-observable 的看法都带有偏见
由于您使用术语 Saga（而不是 Epic），我假设您是在 redux-saga（不是 redux-observable）的上下文中询问的。
在 redux-saga 中，你所做的效果，例如AJAX 请求，实际上并没有在您的生成器 sagas 中直接处理。相反，您使用的助手正在创建普通的旧 JavaScript 对象，它表示效果 intent，您 yield 然后 redux-saga 中间件本身在内部执行效果，对您隐藏，将结果提供给您的收益，例如 yourSaga.next(response)。
有些人喜欢这样，因为您的 saga 生成器是真正纯粹的。因为它使用生成器来支持多种效果，所以无需模拟就可以轻松进行测试，因为您只需断言它产生的效果是预期的。就个人而言，我在实践中发现这似乎比实际要酷得多：很多时候，你最终有效地重新创建了 saga 在测试中所做的一切。您现在正在测试 saga 的 实现 是正确的，而不是测试 saga 的 行为。许多人不在乎（甚至注意到这一点），但我做到了。我想有些人甚至更喜欢它。这被称为“作为数据的效果”。 FWIW，redux-observable 没有使用这种“效果即数据”的模型，这是它和 redux-saga 最根本的区别。
将这与它们与 redux-thunk 的比较联系起来，最大的区别是：基于时间的操作（例如，去抖动顺序操作）在没有重大 hack 的情况下单独使用 redux-thunk 是不切实际的。说到去抖动，它根本不附带任何实用程序，因此您正在处理去抖动和其他常见效果。测试要困难得多。
但是，这些主要是意见。当然，非常成功的应用程序可以（并且已经）使用 redux-thunk。 https://m.twitter.com 浮现在脑海中。
我认为对于简单的 request->response 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 寿命更长，因此该技能是高度可转移的。
【讨论】：