简洁的MobX与MVP思想—大型项目实践

很久之前想写一篇对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思想使用

官网的图⬇

相比较redux状态管理库，这种单向流真的清晰容易理解，同时我们团队做了进一步简化，不用Actions触发，直接修改状态state，但对其做了一些约定，使得代码量进一步降低

我们团队使用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里面很快找到数据变动的逻辑

上图就是一个mvp思想下的模块，整个模块： Home这个tsx组件负责View，在constructor函数里面new实例化Presenter.ts这个控制器（最好是这样做，状态组件可以复用），presenter负责整个的数据处理逻辑，同时引入Home的子组件要把实例化后的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 <Childrenpresenter={this.presenter}/>}
复制代码

控制器这一层GoodsPriceTrackPresenter.ts代码如下：

export default class GoodsPriceTrackPresenter {@observablepublic 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.如果不注意使用规范，大项目可能会有性能问题（一般是遇不到的）

这篇文章我还会经常去完善更新，因为状态库涉及太多，讲得比较草率，很多都点到即止了

欢迎评论区评论和拍砖，两开花啊两开花