关于React状态管理的一些想法
我最开始使用React的时候，那个时候版本还比较低（16版本以前），所以状态管理都是靠React自身API去进行管理，但当时最大的问题就是跨组件通信以及状态同步和状态共享的问题，因为React是自上而下的数据流处理方式，仅仅通过提取到公共父组件内的方式还是比较麻烦，而且当时Context的API无法透传组件的问题也导致React自身很难去解决这些问题，于是我就引入了Redux。
Redux最大的优势是在于它的状态可回溯，整个流程比较清晰且无副作用，而且对于一个多人合作的大型项目来说，它的强规约性起到了很好的作用，配合React-redux解决了刚刚提到的几个问题。
但是随着业务代码不断增多，Redux的模板代码也越来越多，特别是action和reducer这些文件夹也越来越多，一个项目几十个actionType，确实后期会比较头疼，而且改一处动全身，开发工作量增加很多。Redux本身内部是无脑的发布订阅的模式，每次dispatch一个action都会遍历所有的reducer，因此订阅多了之后计算浪费等性能问题也随之而来，尽管我使用了reselect、immutable等优化方案，但还是会有少量的页面卡顿现象，因此最终还是只能考虑别的状态管理方案。
mobx是我们选的第二个方案，这个也是Redux的作者Dan abramov的推荐，它的内部实现有点类似于Vue，最新的Mobx 5也是利用proxy来追踪属性，之前的版本都是Object.defineProperty，通过隐式订阅自动追踪被监听的对象的变化，然后触发组件更新，这种数据劫持的方式在状态管理上自然会方便很多，比起Redux的一套纯净而复杂的流程，直接修改数据要简单很多。
（
PS: 为什么mobx要从 Object.defineProperty 升级到 proxy？包括Vue 3.0也是
首先要清楚如何利用Object.defineProperty进行数据双向绑定的。
劫持getter和setter，在getter中做数据依赖收集处理，在setter中监听数据的变化，并通知订阅当前数据的地方，从而进行UI的绘制。
因为原先 Object.defineProperty 最大的问题是：
1，无法检测到新的属性添加和删除（在初始化之后添加的）；
2，无法监控到数组下标的变化，导致直接通过数组下标给数组设置值无法实时响应；
3，当data数据较深时会有性能问题；
而proxy可以解决上述问题，原因是proxy是对对象进行拦截，无论新增还是删除对象的属性，都必须先走这层拦截。
但是Proxy有个问题是兼容性的问题，IE浏览器不支持，所以在IE浏览器上会自动降级为Object.defineProperty
）
mobx最大的优势就是代码量少，而且更新粒度精准，实现局部更新。但是使用一段时间后也发现了一些缺点，比如对于一些复杂且数据结构层比较深的时候，UI更新会出问题，而且当多个组件共享某个状态的时候，由于是直接修改的状态，因此当状态更新出错时，回溯能力就比较弱了，来源不清晰，无法定位问题组件，还有就是mobx没有中间件，对于异步数据流的处理也比较弱，而redux这点就比较优势，因为它提供了中间件。
我后来还尝试使用了rxjs来进行状态管理，因为有mobx的实践经验，对于这种函数响应式开发并不陌生。rxjs最大的优势在于处理数据流有着一套强大的工具库，类似于lodash，但是后来发现仅仅利用这个来帮助react管理状态，确实有点大材小用了。不过有一个redux-observable的中间件，可以搭配redux去处理一些异步数据流，这个还是比较好的。