简洁的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 <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.若是不注意使用规范，大项目可能会有性能问题（通常是遇不到的）

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

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