debugging - 如何调试rxjs5？

Question

关于RxJS - Goals我读到他们的目标是更好的可调试性:

Goals

Provide more debuggable call stacks than preceding versions of RxJS

我刚刚开始使用 redux-observable ，与 redux-saga 相比，它对我来说更容易理解，因为我已经习惯了响应式风格lodash 和 ramda (好吧，也许是 fp 风格；)。我很惊讶现在还无法调试它。这是真的吗？如果是这样，那么我可能需要切换到 redux-saga 或坚持使用 redux-thunk。

根据 Jay Phelps 的回答进行编辑

通过调试，我的意思是:“如何在浏览器中的 observable.map(...) 上设置断点？”使用 lodash，我可以在浏览器中设置断点，它就停在 _.map(...) 上。如何使用redux-observable(或rxjs)来做到这一点？我不想依赖大理石图和console.log()的绘制。

Answer 1

当然可以调试 RxJS 代码。我认为可以肯定地说，如果不是这种情况，几乎没有人会使用它——Angular2 也是建立在它的基础上的。

人们最常用的方式与调试其他 JavaScript、断点(例如调试器)和 console.log() 的方式相同

一些用户使用更高级的技术，例如绘制依赖图或弹珠图。 André Staltz wrote about this最近，所以这可能是一个有用的资源。

最终，任何类型的异步编程都将变得更难调试。这并不是 redux-observable/RxJS 独有的；快速搜索也会发现 redux-saga 的大量调试问题。

事实证明，redux-thunk 是绝大多数应用程序构建的最佳解决方案，因为它们中的大多数没有复杂的副作用问题，无法证明 redux-observable 或 redux-saga 等东西的合理性。不过，如果您已经精通 RxJS，那么使用 redux-observable 并没有什么问题。

redux-saga 作为一个项目比 redux-observable 存在的时间更长，因此这无疑是一个主要卖点。您会发现更多文档、示例，并且可能有更好的社区可以获得支持。

相反的是，你在 redux-saga 中学习的运算符和 API 并不像学习 RxJS 那样可移植，而 RxJS 到处都在使用。 redux-observable 内部 super super super 简单，它实际上只是为您提供了一种使用 RxJS 的自然方式。因此，如果您了解 RxJS(或想要了解)，那么它是非常合适的。

目前我对大多数人的建议是，如果您不得不问应该使用哪一个，那么您可能应该选择 redux-saga。

(免责声明:我是 redux-observable 和 RxJS v5 的维护者之一)