在Redux里面，会有一个东西叫combineReducer，在state比较大的时候，用不同的reducer修改state的不同的分支，然后合并。如果使用RxJS，也可以很容易表达出来：
const meAction$ = new Subject() const meReducer = (state, payload) => {} const articleAction$ = new Subject() const articleReducer = (state, payload) => {} const me$ = meAction$.scan(meReducer).startWith({}) const article$ = articleAction$.scan(articleReducer).startWith({}) const state$ = Observable .zip( me$, article$, (me, article) => {me, article} )
借助这样的机制，我们实现了Redux类似的功能，社区里面也有基于RxJS实现的Redux-Observable这样的Redux中间件。
注意，我们这里的代码中，并未使用dispatch action这样的方式去严格模拟Redux。
再深入考虑，在比较复杂的场景下，reducer其实很复杂。比如说，视图上发起一个操作，会需要修改视图的好多地方，因此也就是要修改全局状态树的不同位置。
在这样的场景中，从视图发起的某个action，要么调用一个很复杂的reducer去到处改数据，要么再次发起多个action，让很多个reducer各自改自己的数据。
前者的问题是，代码耦合太严重；后者的问题是，整个流程太难追踪，比如说，某一块状态，想要追踪到自己是被从哪里发起的修改所改变的，是非常困难的事情。
如果我们能够把Observable上面的同步修改过程视为reducer，就可以从另外一些角度大幅简化代码，并且让联动逻辑清晰化。例如，如果我们想描述一篇文章的编辑权限：
const editable$ = Observable.combineLatest(article$, me$) .map(arr => { let [article, me] = arr return me.isAdmin || article.author === me.id })
这段代码的实质是什么？其实本质上还是reducer，表达的是数据的合并与转换过程，而且是同步的。我们可以把article和me的变更reduce到article$和me$里，由它们派发隐式的action去推动editable计算新值。
更详细探索的可以参见之前的这篇文章：复杂单页应用的数据层设计
小结
本篇通过一些简单例子介绍了RxJS的使用场景，可以用这么一句话来描述它：
其文简，其意博，其理奥，其趣深
RxJS提供大量的操作符，用于处理不同的业务需求。对于同一个场景来说，可能实现方式会有很多种，需要在写代码之前仔细斟酌。由于RxJS的抽象程度很高，所以，可以用很简短代码表达很复杂的含义，这对开发人员的要求也会比较高，需要有比较强的归纳能力。
本文是入职蚂蚁金服之后，第一次内部分享，科普为主，后面可能会逐步作一些深入的探讨。
蚂蚁的大部分业务系统前端不太适合用RxJS，大部分是中后台CRUD系统，因为两个原因：整体性、实时性的要求不高。
什么是整体性？这是一种系统设计的理念，系统中的很多业务模块不是孤立的，比如说，从展示上，GUI与命令行的差异在于什么？在于数据的冗余展示。我们可以把同一份业务数据以不同形态展示在不同视图上，甚至在PC端，由于屏幕大，可以允许同一份数据以不同形态同时展现，这时候，为了整体协调，对此数据的更新就会要产生很多分发和联动关系。
什么是实时性？这个其实有多个含义，一个比较重要的因素是服务端是否会主动向推送一些业务更新信息，如果用得比较多，也会产生不少的分发关系。
在分发和联动关系多的时候，RxJS才能更加体现出它比Generator、Promise的优势。