我一直在读关于传奇，他们的意图和用法。但是 - 我有两个问题，我真的想要关闭，然后更多的意见问题。
我读了一些博客，这些博客使用的模式能够动态生成Sagas以减少样板量 - 但是你也不能用thunks做到这一点吗？此外，任何例子都会很棒。
有关redux-sags与redux-observables的任何意见？
谢谢！
答案 0 :(得分：4)
免责声明：我是redux-observable的作者之一，因此我对redux-saga和redux-observable的看法都受到偏见的影响
既然你使用了Saga这个术语（而不是Epic），我会假设你在redux-saga（不是redux-observable）的上下文中提问。
在redux-saga中，你所做的影响，例如：一个AJAX请求，实际上并没有在你的生成器传奇中直接处理。相反，您使用的帮助程序正在创建普通的旧JavaScript对象表示效果 intent ，您yield然后redux-saga中间件本身执行效果在内部，对您隐藏，将结果提供给您的收益，例如yourSaga.next(response)。
有些人喜欢这样，因为你的传奇发生器真的很纯净。因为它使用生成器来支持多种效果，所以它可以很容易地在没有模拟的情况下进行测试，因为你只是断言它所产生的效果是预期的。就我个人而言，我在实践中发现它看起来比实际情况要冷得多：很多时候你最终会有效地再现传奇在测试中所做的一切。您现在正在测试该传奇的实现是否正确，而不是测试该传奇的行为。许多人不关心（甚至不注意这一点），但我做到了。我想有些人甚至更喜欢它。这被称为“作为数据的效果”。 FWIW，redux-observable不使用这种“效果数据”模型，这是它与redux-saga之间最根本的区别。
将这一点与REDx-thunk相比较，最大的区别在于：基于时间的操作（例如，去除连续动作）对于单独使用redux-thunk而言并不重要。说到去抖，它根本没有任何实用工具，所以你正在处理你的处理去抖和其他常见效果。测试要困难得多。
然而，这些主要是意见。当然非常成功的应用程序可以（并且有）使用redux-thunk。想到https://m.twitter.com。
我认为说redux-thunk更容易学习和使用简单的请求 - ＆gt;响应AJAX调用，而不需要取消等等，这不会引起争议。事实上，我经常推荐不熟悉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更长，所以技能是高度可转移的。