# 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等等的编写才能实现整个流程。

,,,待完善