很久之前想写一篇对Redux的研究，但是网上写的很多，而MobX相比较Redux更小众，网上很多资料例如介绍api的都是官网的复刻节选，而我用MobX感觉真的很爽，所以写篇文章帮助初入MobX坑的玩家们，如果写的不对，也希望各位指正，更好发展。
适合用MobX的项目
我认为能用redux的项目就可以用mobx，除非需要redux-saga完成一些极其复杂的异步状态改变，都可以完美替代，一些如微博之类偏社交的整体异步状态并发改变可能很多，不太适合；像能分成各个小模块的，各模块互相联系不是很紧密的复杂项目用mobx体验很好。简言之，因地制宜，不要无脑使用redux，每个都有适合的环境。
基本知识储备
基本的api详细介绍
不使用严格模式的话，不会有Actions而是直接改observable的state，下面是占出现率99%的api
@observer：用在react的view层的组件上方，变成可观察的@observable：把一个变量变成可观察的@computed：类似于vue，收集observable的变化而变化autorun：包裹的函数先自动执行一次，里面检测到有依赖变动，自动执行toJS(value, options?)：把observable的对象变回原生js对象的函数（实际用的地方很少，但需要知道，如果是用4版本一下的还是要特别注意）
网上比较多，也可以移步MobX中文官网，安装MobX和mobx-react还有装饰器和对应的babel 官网资料也很清晰。
想更好的理解MobX可以找找网上的手写MobX教程，也有助于理解本篇文章（PS：很多api手写起来比想象的简单，简单说来就是把一个普通的深层对象通过递归层层绑定，变成observable的对象，实现最小细粒度的依赖收集）
另外，值得一提的就是MobX5使用的proxy，MobX4以下用的Object.defineProperty，还是有点区别的，不多说了
结合MVP思想使用
官网的图⬇
我们团队使用mvp思想，这里的mvp其实类似安卓的mvp思想，是mvc的兄弟，在MVC里，View是可以直接访问Model的，但MVP中的View并不能直接使用Model，而是通过为Presenter提供接口，让Presenter去更新Model，再通过观察者模式更新View。 与MVC相比，MVP模式通过解耦View和Model，完全分离视图和模型使职责划分更加清晰；由于View不依赖Model，可以将View抽离出来做成组件，它只需要提供一系列接口提供给上层操作。mvp优点是数据和视图分得很开，缺点是如果逻辑多的话，presenter可能会很重，但是采用MobX的话会好很多，大量受观察的数据可以少写些逻辑。MobX写起来很简单（代码比redux少太多），逻辑也比较清晰，可以在presenter里面很快找到数据变动的逻辑
下面用代码简单示意⤵️
View层GoodsPriceTrackHome.tsx代码如下：
@observer
export default class GoodsPriceTrackHome extends React.Component<any, any> {
private presenter: GoodsPriceTrackPresenter;
constructor(props: any, context: any) {
super(props, context);
this.presenter = new GoodsPriceTrackPresenter();
}
//简单示意
render() {
const {abc,changeAbc} = this.presenter;
return <div onClick={changeAbc}>
abc
</div>
}
//如果有子组件且需要传presenter的话
render() {
return <Children
presenter={this.presenter}
/>
}
控制器这一层GoodsPriceTrackPresenter.ts代码如下：
export default class GoodsPriceTrackPresenter {
@observable
public abc: number = 123;
public changeAbc(){
this.abc++;
}
}
是否及何时使用严格模式
结论：基本不用严格模式(像示例中直接改了this.abc)，如果是两三个人协作开发的小项目，开发过程中基本没有太多交集，自然不需要约定修改，大型项目的话，只有登录等账户全局的一些异步操作需要严格模式@action来约束，其他模块的话，最多一两个人来负责开发维护，所以如果基本上是自己负责一个模块或者一个小项目，就直接用普通模式
注意事项
所有的与服务器通信、数据变动操作都放在p（presenter）上，除了监控ui的变化（如一些自适应之类）才放在v（view）上
React Native下mobx相对更好
React Native编译后与h5或者web端这种浏览器是不同的，它对性能更敏感，每次刷新并不是操作dom而是原生组件，所以 在大型列表等情况下，MobX 可以更新特定单元格而无需重新呈现整个列表。通常这也可以通过 Redux 实现，但是需要重写 componentShouldUpdate() 方法并编写更多样板文件以避免不必要的重新渲染。在将其余变量复制到新状态时，redux的reducer 仍会执行一些不必要的工作
MobX体验的一些不足
1.开发插件
mobx由于是分布式的状态管理，所以几个开发插件体验不好，基本没怎么用，调试是打断点或者console，感觉这样更方便一些
2.内存泄漏
开发者水平不齐或者无意识的进行不规范的使用，可能会造成内存泄漏，用户长时间使用产品造成内存泄漏，影响用户体验（组件卸载之后，但是其他引用较乱，导致某些手观察对象或者闭包无法释放）
3.侵入性
面向对象的话，设计较为复杂，无关大量数据绑定太多，也会影响到性能
总结
1.基本不用严格模式约束，直接在Presenter组件里改状态（但怎么改一定要事先理清思路哈）
2.相比redux，MobX管理状态更简单有效率，写的代码更少，做项目效率更高（但要分项目适不适合）
3.如果不注意使用规范，大项目可能会有性能问题（一般是遇不到的）
这篇文章我还会经常去完善更新，因为状态库涉及太多，讲得比较草率，很多都点到即止了
欢迎评论区评论和拍砖，两开花啊两开花
