19

在RxJS - 目标我读到他们的目标是更好的可调试性：

目标

提供比以前版本的 RxJS 更多的可调试调用堆栈

我刚开始使用redux-observable它比较容易理解，redux-saga因为我已经习惯了使用lodashand的反应式风格ramda（好吧，也许是 fp 风格；）。我很惊讶还不能调试它。这是真的吗？如果是这样，那么我redux-saga可能要切换到 s 或坚持使用redux-thunk.

根据杰伊菲尔普斯的回答进行编辑

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

4

2 回答 2

16

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

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

一些用户使用更高级的技术，例如绘制依赖图或大理石图。André Staltz 最近写了这篇文章，所以这可能是一个有用的资源。

最终，任何类型的异步编程都将更难调试。这不是 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 内部超级超级超级简单，它实际上只是为您提供了一种使用 RxJS 的自然方式。因此，如果您了解 RxJS（或想了解），这是非常自然的选择。

目前我对大多数人的建议是，如果你必须问应该使用哪一个，你可能应该选择 redux-saga。

（免责声明：我是 redux-observable 和 RxJS v5 的维护者之一）

于 2016-07-26T18:39:15.647 回答
4 
import Rx, { Observable } from 'rxjs'

const arrStream$ = Observable.of(1,2,3)
                    .do(x=>console.log('Before',x))  // 1, 2, 3
                    .map(x=>x*2)
                    .do(x=>console.log('After',x))   // 2, 4, 6
                    .subscribe(value=>doThingsWith(value))
// real console output
// Before 1
// After  2
// doThingsWith(2)
// Before 2
// After  4
// doThingsWith(4)
// Before 3
// After  6
// doThingsWith(6)

.do(debugValue=> console.log(debugValue))

于 2017-01-10T09:48:09.957 回答