RxJS/Cycle.js 与 React/Vue 相比更适用于什么样的应用场景?
先说观点,React/Vue 和 Cycle 一起用是不太合理的,因为 Cycle 本身定位是框架,定义了整个应用的代码组织方式和开发范式,那就是无论是用户事件处理还是服务端数据同步,统统用 Rx 来做,Cycle 自己也提供了偏好的 view layer(基于 virtual-dom 的 DOM driver)。总的来说 Cycle 的范式侵入性很强,属于要么不用要用就得全盘接受 Rx for everything 的理念。我本身对于这个理念持保留态度,同时目前还没有看到过大型 Cycle 应用的例子,那么自然对于 Cycle 到底好不好用,也是持保留态度。
另一方面,在 React/Vue 应用中部分使用 Rx 是完全没有问题的。思路上来说就是把 React/Vue 组件的 local state 当做一个『中介』,在一个 Rx Observable 的 subscribe 回调里面更新组件状态。通过简单的绑定库支持,可以完全把 component state 作为一个实现细节封装掉,实现 Observable -> view 的声明式绑定。参考:
- Vue + Rx: https://github.com/vuejs/vue-rx/
- React + Rx: GitHub - belfz/fully-reactive-react-example
我个人倾向于在适合 Rx 的地方用 Rx,但是不强求 Rx for everything。比较合适的例子就是比如多个服务端实时消息流,通过 Rx 进行高阶处理,最后到 view 层就是很清晰的一个 Observable,但是 view 层本身处理用户事件依然可以沿用现有的范式。
---
题外话,
的答案拿 Vue 说事,然后说不可避免会遇到『性能墙』问题,而 Virtual DOM 是 React 对『性能墙』的解决方案,我只能说这个看法基本属于对 Virtual DOM 理解停留在宣传层面的水平。详见 网上都说操作真实 DOM 慢,但测试结果却比 React 更快,为什么? - 尤雨溪的回答。而关于『复杂度墙』,则要么是对『单向数据流』的理解停留在宣传层面,要么是对 Vue 的了解有限(不了解您可以少说两句)。React 如果没有 Flux,其实也是依赖 component local state。React + Redux 做的事情说到底就是把应用状态从组件本身隔离出去统一管理,这种思路 并不是只有 React 能做到,只要有个声明式的视图层就行了。这也是为什么 Redux 是 view-layer agnostic,Vue,Angular 2 都有配合 Redux 使用的例子,Vue 自己也有专属的状态管理方案 Vuex。(这些话我其实在知乎重复过好几遍了,只是太多人被 FB 的宣传洗了脑,说 React 必提 virtual dom 性能好 + 单向数据流应对复杂度,对其本质却不知其所以然...)
我们厂(小厂)在iOS(Native)、Android(ReactNative)和Web上都选择了Data Flow驱动的设定思路,使用RxJS(RxSwift)来作为Data Flow驱动的核心组件,架构基本类似,把全局状态和组件局部状态分开,结构很清楚,因为Data Flow会让你比较容易追踪到数据变化的原因,最终导致UI变化的原因。其实只要把全局状态和局部状态有效管理,使用Redux也很好,不过使用RxJS是因为我们可以很轻松的把全局状态Stream和组件局部状态的Stream通过Rx运算子共同运算,代码会更加清晰,同时大大减少对全局状态的污染,有效控制数据状态变化传播的范围。
Reactive programming is oriented around data flows and the propagation of change. Erik Meijer gave us Rx because he was induced by push-based systems. When you want to stay up to date about the state of the world, it is much better to push instead of to pull.
Observable Stream + FRP围绕数据流驱动设计App架构,会大大减少UI上的复杂度,非常看好的结构方向。
而React本身定义了数据流向的要求,但是没有定义如何解决这个问题,所以,React和RxJS解决的不是一个问题……They have not solved the problem of how to achieve explicit data-flow graphs
https://medium.com/@fkrautwald/plug-and-play-all-your-observable-streams-with-cycle-js-e543fc287872#.zcbj1db3x
部分引入Rx只会获得部分收益,总要从Observable这个monad容器出来进去,导致编码本身大量冗余,丢掉大部分FP的好处。
用用Cycle你就能发现比React大量的手动绑定简洁多了,这样重构也方便。Cycle效率真心远超React Redux,这取决于React onClick绑定,导致要做到类似Reactive Programming的效果(Flux / Redux 对React来说是标配),需要做大量重复工作,Flux只是模式,导致不能真的抽象成库。这是React为数不多的硬伤。
缺点就是Rx4测试困难,如果你们不要求覆盖率,调试Rx其实并不是很麻烦的事情。
Vue 的年龄轻,但是 Vue 却是最传统的基于 observer 的MVC,但是做到了尽量简单。但是不可避免的,当你的 Web App 越来越复杂,自然也会撞到两堵墙,"性能墙"和"复杂度墙"(否则也就不会有React, Cycle.js..., Angular早就一统江湖了)。
React 针对"性能墙"的方案就是 VirtualDOM,对于"复杂度墙"的方案就是单向数据流,希望用一些"函数式"的概念来规避过于复杂的状态维护(对于稍微复杂一些的应用,这是一定会出现的问题)。但是由于 React 自身不是"函数式"的,又有大量的工程妥协,因此真的是充满了 boilerplate。
Cycle.js 其实是 FRP 在 Web App 领域的一种"模式"(Source/Driver, MVI),是天生用来对付"复杂度墙"的。而且,得益于 React 的思路, Cycle.js 也老大不客气地把 VirtualDOM 拿来缓解"性能墙"问题。
但是,由于 Cycle.js 尚没有被大量的开发者使用,缺少工程验证,尤其是性能评估方面;而且也没有大厂持续地投资,所以还是在探索阶段。不过以我个人体验来看,Cycle.js 是一种“对”的开发方式。