为什么会有 rxjs 这种库？

[yhvictor]

别人推荐我看一下 reactiveX，于是看了下，一看 operator 真是不知道多少个： https://www.learnrxjs.io/operators/

相比较之下，guava concurrency 的 operator 就少得多了（一半以上还是因为重载）： https://google.github.io/guava/releases/21.0/api/docs/com/google/common/util/concurrent/Futures.html

所以，rxjs 这东西有什么好处呢？为什么能火呢？ 以及 javascript 有没有类似 listenable future 的类或者库呢？

[JesseHeisenberg]

当你用起来就能感受到丝滑般的流畅，事件流在管理着各种跨模块的状态，给每个单独的模块解耦合，想想就激动。

[lrz0lrz]

1、rxjs 不火
2、有 rxjs 是因为有 rxjava 等其他语言的 ReactiveX 库
3、listenable future 是啥？不过 rxjs 的竞品有不少，或许有楼主想要的

[jera]

1. rxjs 不火。
2. rx 好像起源于 linq 的扩展。
3. operator 多是因为官方帮你实现了他认为有必要实现的，实质上任何人都可以自己实现 operator 用 Observable#lift 方法挂上去。
4. 不懂 java，你说的 listenable future 应该是 Observable 或者 Observable 的订阅。

[jera]

对了，你应该对比 RxJAVA 而不是 RxJS。

[jimrok]

学习曲线其实挺高的，使用异步事件模式来组织业务逻辑是非常难的，代码也非常难维护。因为业务逻辑非常依赖一个上下文状态，但在流的方式下，上下文的状态数据会随着流在处理环节中流动，你只需面对流中的上下文信息就好了。而且单向数据流避免了并发引起的状态混乱。

[akatquas]

时间流的思想高的不知道哪里去了

[Yiki]

用过一点，懂了一点，觉得学起来蛮吃力是真的
但好像是挺好用的……

[wly19960911]

@jimrok #5 那我们能不能把数据 copy 一份，然后接受流的处理，之后 return 赋值给 this 的变量，这样的话避免掉使用 this，其实我一直很忌讳使用 this 的变量，或者说直接修改所需要的业务数据。我好奇这种情况适用性广不广？

[zjsxwc]

等价于有了微积分 我们为什么要学傅立叶变换

[jimrok]

@wly19960911 你说的对，reactive 就是要求数据不变性，函数不能产生副作用，而且要求数据单向流动。你可以想像成在汽车流水线上工作，不是一哄而上的进行修改。

[kutata]

歪个楼，有人能告诉我 graphQL 是什么吗…？😹😹😹

[youxiachai]

rxjs 什么是火了....

[drydiy]

@kutata 别问，学就对了。

[66beta]

@kutata 前端不需要后端系列

[PALELESS]

xstream 了解一下 与 cyclejs 配套使用无敌 不过说实话流式编程感觉也就是开拓思维吧 暂时正式项目很少见到 会的人不是很多

[zhwithsweet]

1.rxjs 本身是基于可观测，维护一个稳定的数据流，dom 操作，网络 I/O 等等都归结为副作用，有专门的订阅者执行。数据可观测，可控。
2.rxjs 不火。
3.有，比如 cycle.js 的底层依赖 xsteam.js 。（本人用过，用来解耦 jsbridge 和 webview 的交互

[mafeifan]

很多人使用 rxjs 因为用的 angular。在 angular 里很多地方要用到。处理起来也是挺方便的。

[azh7138m]

@PALELESS 石墨文档好像用的很多

看上去很好，就是不知道实际使用成本大不大

[grewer]

其实我感觉不是太需要 如果只是为了使用而去使用 那还是罢了
先了解一下使用场景 碰到了特殊问题再去考虑吧

[bluzz]

我从 rxjava 开始用的，后来搞 ios 就用 rxswift,重要是思想是一致的，上手就很快

[Perry]

rxjs 主要靠 Angular 壮大起来的，目前来说还不算火吧。。。

[ljzxloaf]

rxjs 不知道,rxjava 就是一种开发范式.由事件和数据驱动业务逻辑,将业务解耦得比较彻底,适合复杂多变的业务场景,当业务发生变化时,改动比较小-------以上是官话.

我没用过只看过别人的例子,我的理解是简单项目尤其是现在大家都是微服务了,真的用不上这个,如果要用的话也不会直接用,应该结合各自的业务场景再封装一遍,否则开发效率可能要大打折扣.东西是好东西,但是没必要全盘接收.缺点是代码的可读性变差,当然整体上来说更易于理解,逻辑也更清晰了,但是局部代码因为变成了通用逻辑,读起来没那么直观.还有个重要的缺点是调试起来更麻烦了,如果不熟悉的人可能搞不懂它的执行流程.还有涉及到并发 /异步 io/流控什么的时候容易用错. 如果没有接触过这些概念的话有一定的学习成本.

另外,用不用是一回事,了解一下思想还是有好处的.我就是了解了一下,这不是就装了个 X(

[ChefIsAwesome]

假设你需要抓 100 个页面，考虑到性能，你的策略是这样的：
每 5 个页面为一组，因为异步的特性，5 个请求可以同时进行。这 5 个请求完成的时间未知（第 5 个可能在第一个之前完成），你希望收集到数据仍然是按顺序排列的。
一组请求全部完成之后才进行下一组，直到全部完成。

这已经是个相当复杂的过程了。实际场景可能更复杂：
一个请求失败时，自动重试，最多可以试 3 次。
一组操作完成之后，等 3 秒钟才进行下一组。

用 rx 的话，上面描述的问题就非常容易解决。
简单讲，observable 是高级的 promise。当你把异步操作封装成一个可以组合，可以被函数返回的值的时候，很多问题都可以迎刃而解了。
前端应该碰不到这么复杂的异步问题，好多人看的云里雾里，所以没那么火。

[gzf6]

就是异步的一种处理方式，也可以用别的方式，不必拘泥于一种

[sagaxu]

@ChefIsAwesome 这个例子用 Future 组合写起来也不复杂，用协程就更简单了吧，直接写循环，跟同步阻塞代码一样写。

[lhx2008]

好像还有 reactorjs，也是 rxjava 那班人写的

[ooeyunarika]

reactiveX 这套异步处理思路现在主流语言都有对应的类库,在处理异步问题上得到相同的体验,学会一套就到处受用了,多少会降低一些跨语言异步处理的心智负担

相比于其他语言尤其是 java,js 的异步处理工具和类库要丰富和成熟很多,所以 rxjs 确实在这当中不算突出,但如楼上大佬们所说,rx 这套工具衍生自 linq,是大量地开发实践后催生出来的更为成熟的异步处理思路.

至于可读性降低那只是因为异步本身就需要考虑那么多复杂的场景,只是之前大部分都被忽略了.尤其是前端,以前大部分用 promise 都只考虑 success 而忽视了 failure 的处理,在前端最多控制台报个错用户刷新一下就恢复了,放在后端就可能是非常致命的 bug.

[asAnotherJack]

rxjava 挺火的

[xzk715]

说 rx 主要是位了解决异步问题的 一看就不是真了解 rx

[Sapp]

rx 其实我是用来做一些数据处理，如果真的数据非常多，非常乱，需要几路并流，然后经过转换输出结果，还是好用的，其他业务没什么必要，不过我还是经常用 xstream，比 rxjs 小，更简单，偶尔用用也够用了