未加星标

简洁的MobX与MVP思想

字体大小 | |
[前端(javascript) 所属分类 前端(javascript) | 发布者 店小二05 | 时间 2019 | 作者 红领巾 ] 0人收藏点击收藏

我认为能用redux的项目就可以用mobx,除非需要 redux-saga 完成一些极其复杂的异步状态改变,都可以完美替代,一些如微博之类偏社交的整体异步状态并发改变可能很多,不太适合;像能分成各个小模块的,各模块互相联系不是很紧密的复杂项目用mobx体验很好。简言之,因地制宜,不要无脑使用redux,每个都有适合的环境。

基本知识储备

基本的api等详细介绍就略过了,网上还比较多,也可以移步MobX中文官网,安装MobX和mobx-react还有装饰器和对应的babel网上资料也很清晰。

想更好的理解MobX可以找找网上的 手写MobX教程 ,也有助于理解本篇文章(PS:很多api手写起来比想象的简单,简单说来就是把一个普通的深层对象通过递归层层绑定,变成observable的对象,实现最小细粒度的依赖收集)

另外,值得一提的就是MobX5使用的proxy,MobX4以下用的Object.defineProperty,还是有点区别的,不多说了

结合MVP思想使用

官网的图


简洁的MobX与MVP思想
简洁的MobX与MVP思想

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

我们团队使用mvp思想,这里的mvp其实类似安卓的mvp思想,是mvc的兄弟,mvp优点是数据和视图分得很开,缺点是如果逻辑多的话,presenter可能会很重,但是采用MobX的话会好很多,大量受观察的数据可以少写些逻辑。MobX写起来很简单(代码比redux少太多),逻辑也比较清晰,可以在presenter里面很快找到数据变动的逻辑


简洁的MobX与MVP思想

上图就是一个mvp思想下的模块,整个模块: Home这个tsx组件负责View,在constructor函数里面new实例化Presenter.ts这个控制器(最好是这样做,状态组件可以复用),presenter负责整个的数据处理逻辑,同时引入Home的子组件要把实例化后的presenter传入,大体就是这些

不使用严格模式的话,不会有Actions而是直接改observable的state,下面是占出现率99%的api

@observer :用在react的view层的组件上方,变成可观察的 @observable :把一个变量变成可观察的 @computed :类似于vue,收集observable的变化而变化 autorun :包裹的函数先自动执行一次,里面检测到有依赖变动,自动执行 toJS(value, options?) :把observable的对象变回原生js对象的函数(实际用的地方很少,但需要知道,如果是用4版本一下的还是要特别注意)

下面用代码简单示意:arrow_heading_down:

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)上

MobX体验的一些不足 1.开发插件

mobx由于是分布式的状态管理,所以几个开发插件体验不好,基本没怎么用,调试是打断点或者console,感觉这样更方便一些

2.内存泄漏

开发者水平不齐或者无意识的进行不规范的使用,可能会造成内存泄漏,用户长时间使用产品造成内存泄漏,影响用户体验(组件卸载之后,但是其他引用较乱,导致某些手观察对象或者闭包无法释放)

3.侵入性

面向对象的话,设计较为复杂,无关大量数据绑定太多,也会影响到性能

总结

1.基本不用严格模式约束,直接在Presenter组件里改状态(但怎么改一定要事先理清思路哈)

2.相比redux,MobX管理状态更简单有效率,写的代码更少,做项目效率更高(但要分项目适不适合)

3.如果不注意使用规范,大项目可能会有性能问题(一般是遇不到的)

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

本文前端(javascript)相关术语:javascript是什么意思 javascript下载 javascript权威指南 javascript基础教程 javascript 正则表达式 javascript设计模式 javascript高级程序设计 精通javascript javascript教程

代码区博客精选文章
分页:12
转载请注明
本文标题:简洁的MobX与MVP思想
本站链接:https://www.codesec.net/view/628432.html


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 前端(javascript) | 评论(0) | 阅读(204)