Mbox

Mobx专注于解决数据级别的响应,它不关系数据的来源方式,只要一个对象中的属性、一个基本类型变量发生了变化,对这些数据的订阅就会自动执行。使用Mobx管理状态时,当我们更新观察对象的状态后,由观察对象的改变带来的界面重渲染、数据序列化等一系列副作用,Mobx会自动帮我们完成。

Mobx的主要概念

Actions: 改变state的操作。

ObservableState:应用的可被观察的数据状态。

Computed: 从state中通过纯函数的操作衍生出的值,state变化它也会跟着变化。

Reactions:需要对state变化动态作出反应的东西,它包含不同的概念,基于被观察数据的更新导致某个计算值,或者是发送网络请求以及更新视图等,都属于响应的范畴,这也是响应式编程在 JavaScript 中的一个应用。

Autorun: 依赖收集,监听触发,autorun 背后由 reaction 实现。由于 autorun 与 view 的 render 函数很像,我们在 render 函数初始化执行时,使其包裹在 autorun 环境中,第 2 次 render 开始遍剥离外层的 autorun,保证只绑定一遍数据。这样 view 层在原本 props 更新机制的基础上,增加了 autorun 的功能,实现修改任何数据自动更新对应 view 的效果。(ps:使用autoRun实现Mobx-react非常简单,核心思想是将组件外面包上autoRun,这样代码中用到的所有属性都会像上面Demo一样,与当前组件绑定,一旦任何值发生了修改,就直接forceUpdate,而且精确命中,效率最高。)

Mobx流程

Mobx的优缺点

优点:

1.使用起来十分顺手,降低开发难度。十分“智能”,当我们更新观察对象的状态后,由观察对象的改变带来的界面重渲染、数据序列化等一系列副作用,Mobx会自动帮我们完成。

2.面向对象的使用方法,较为符合我们平时开发的逻辑。

缺点:

1.无副作用隔离,非严格模式下可以对observable直接修改,这样容易造成 store 被随意修改。在项目规模比较大的时候,像 Vuex 和 Redux 一样对修改数据的入口进行限制可以提高安全性。因此如果不规范Mobx使用的话将会导致数据流变化混乱问题。

2.在收集依赖时,Mobx会把autorun执行一遍来触发里面observable的getter从而收集依赖。但是万一你写出了以下的代码,Mobx是收集不到你想要收集的依赖的

3.observable跟普通的plainObject傻傻分不清楚,observable跟plainObject外貌上一摸一样,有时可能会误会了observable的本质

Mobx与Redux的区别

1.从数据管理模式的差别上看,Mobx是基于双向绑定的响应式的实现,而redux是基于flux的单向数据流的实现。 2.从开发上来看是和面向对象和函数式编程的区别。但是前端开发需要经常与副作用打交道,所以前端开发很难与完美的函数式编程相结合。 3.redux的state是只读的,产生新的state的过程是pure的;Mobx的state可读可写,并且action并不是必须的,可以直接赋值改变,这也看出了Mobx改变数据的impure。 4.在可预测性、可维护性上看,redux得益于它的清晰的单向数据流和纯函数的实现,在这方面优于Mobx。 5.redux是单一数据源;而Mobx是多个store。 6.redux中的store是普通的js对象结构,而Mobx中的会对其进行observable化,从而实现响应式。 7.从代码量上看,Mobx能少写很多代码,而redux要通过action,reducer等等的编写才能实现整个流程。

,,,待完善

最后更新时间: 10/8/2019, 7:41:17 PM