2

我一直在阅读有关 sagas、它们的意图和用法的信息。但是 - 我有两个问题我真的很想结束，然后是更多的意见问题。

  1. 当使用 Sagas 进行简单的 api 调用时，样板文件似乎非常多。如果我有 20 个 api 调用，那怎么比使用 thunk 少？另外，我一直听到“副作用”的想法——但我不确定它是如何发挥作用的。

我读过一些博客，它们使用了一种能够动态生成 Sagas 以减少样板文件的模式——但你不能用 thunk 来做到这一点吗？此外，任何例子都会很棒。

  1. 在处理非常简单的帖子或接听电话时，Sagas 是否仍然有用？

关于 redux-sags 与 redux-observables 的任何意见？

谢谢！

4

1 回答 1

4

免责声明：我是 redux-observable 的作者之一，所以我对 redux-saga 和 redux-observable 的看法都带有偏见

由于您使用了 Saga 一词（而不是 Epic），我假设您是在 redux-saga（不是 redux-observable）的上下文中询问的。

在 redux-saga 中，您所做的效果，例如 AJAX 请求，实际上并没有在您的生成器 sagas 中直接处理。相反，您使用的助手正在创建表示效果意图的普通旧 JavaScript 对象，您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 vs. redux-observable 的看法，我是有偏见的，因为我是 redux-observable 的作者之一，但我在之前的 SO 帖子中总结了一些想法：Why use Redux-Observable over Redux-佐贺？tl;dr 他们有一个相似的整体模式，但是 redux-saga 使用“效果作为数据”，而 redux-observable 使用 RxJS 的真实效果。两者的优点和缺点，使用 RxJS 的主要优点是它是一种技能，对于 redux-observable 以外的东西来说是一项非常有用的技能，并且几乎肯定会比 redux-observable/redux-saga 寿命更长，因此该技能是高度可转移的。

于 2016-12-17T21:35:46.773 回答