还没有开始使用 RxJS 的人想要知道它在使用中的优缺点和项目适用性

[iugo]

有人向我推荐, 可我觉得这东西我用不着, Promise 足以.

看了 <amp-youtube data-videoid="AslncyG8whg" layout="responsive" width="480" height="270"></amp-youtube> 推荐 RxJS, 说了 Promise 的两个问题, 不可中断与单值传递.

我目前还没觉得这是 Promise 的问题.

我目前对 RxJS 有些抵触的原因是, 我觉得只有当我遇到痛点时才会想办法解决, 如果提前引入一些东西我也不会深刻理解为什么要这样做, 然后也用不好反而拖累项目.

请带着原因批评我, 谢谢.

[momocraft]

我自己的体会是需要 push 数据时特别方便。可以代替 EventEmitter 。

可以先开个小项目试用一下再决定。也许你真的不需要。

[Lxxyx]

前些天一直在学 Rx ，想引入项目后面还是放弃了。
目前看来 Rx 适合复杂的异步时间和数据流等，简单的小场景用 Rx 只是自己给自己找麻烦。而且 Rx 的侵入性特别强，基本上用了之后都是 Rx 那一套东西了。

最后贴一句前两天自己看到的一句话：不要为了 Rx 而 Rx 。

[iugo]

视频中也说到了 RxJS 是有一点学习曲线的.

Ben Lesh 谈 redux-observable, 说受到了 redux-thunk 的启发 (is inspired by redux-thunk).
https://medium.com/@benlesh/redux-observable-ec0b00d2eb52

https://www.reddit.com/r/reactjs/comments/4l06gm/which_one_you_use_to_do_async_ops_reduxthunk_vs/

redux-saga 在 npm 目前的下载量五倍于 redux-observable

[ChefIsAwesome]

你有好几个异步数据流吗？你需要对这好几个数据流进行合并等高级操作吗？
没有就别上 rx

[vghdjgh]

可以看看 rxjs 内的 Subject 对象（继承自 Observable ）， new 出一个 Subject 对象后，多个源可以向这个 subject 发消息，也可以有多个源来订阅消息，这是轻量的订阅发布模式（虽然自定义事件也可以做到）， subject 支持大量的操作（ filter 、 map 、 buffer 、延迟等）来方便处理复杂业务，简单业务确实不太需要 rxjs 。

[codelegant]

个人看法，框架与库是解决问题，不是预防问题。当项目里的一些东西复杂到无法靠人力维护的时候，应该考虑引入相应的框架与库了。

[crashX]

Rx 不是看两天就看明白的，学习曲线比跨语言还陡。

[zhuangzhuang1988]

https://github.com/jayphelps/nofux
试试这个人的另外一个库, kill redux

[arzusyume]

这视频有人做了个内容介绍... https://zhuanlan.zhihu.com/p/24263212
最近 reactive 热度很高, rxjs 作为学习方向挺好的, 目前 react 项目暂时不打算用... 或许以后 node server 会考虑
另外我第一眼看 mobx 时, 觉得这货和 rxjs 蛮像的(作者还写了篇 issue 介绍二者区别)

[wobuhuicode]

技术选型要看项目……

[JamesRuan]

单值传递不是问题，传 Array 就好了。
不可中断不是问题，造个可中断的轮子代替 Promise 用就好了，比如我模仿 golang 写一个 https://github.com/coffee-toolbox/context 。

[ChefIsAwesome]

我之前有个用 node 写的爬虫项目，里头用的 rx 。项目需要对 4 个网站的某个资源前 5 页的结果进行抓取。我用 rx 实现每次对一个网站的 5 页做平行请求，每个请求如果失败就重试，重试 3 次之后再放弃。完成一个网站 5 页抓取之后再进行下一个网站 5 页内容的抓取，最后收集结果保存。
这种需要对流进行复杂操作的场景，自己写就太困难了，靠 rx 就非常容易。
如果是做前端 ui 的话，需要 rx 的场景实在太少。硬上 rx 只是增加一层抽象，给自己添乱。

[uxstone]

Angular 中默认使用 RxJS 了,但觉的还是得看具体项目,
杀鸡焉用牛刀...