redux & mobx

记得我刚开始学习 react 时非常困惑，并不明白为什么要用 mobx ，要用 redux ？react component 不是自带了 state 么，谁要用传给它不就好了。当时看官方文档做了下棋的小游戏，又做了一个 todo list，虽然有尝试用 mobx ，可依然说不太清它的用法和好处在哪里。更不要说 redux 了，action，reducer，store，多个概念弄得我一头雾水，但是随着参与大型项目的开发，我渐渐体会到这两个库的好处。

(当你的应用非常小的时候，并不需要急着引入状态管理库，this.state 完全可以满足你的需求)

状态管理库的好处

1. 状态和组件解耦合
   react component 给我们提供了一个 state 变量，当我们修改它的时候，react 会延时执行检查，统一处理（减少操作次数），重新渲染引用了相关 state 的地方。对于开发者而言，我们只需要调用 setState 这个接口就可以了，非常简单就能写出部分更新页面的应用。所有需要更新的部分，都由 react 的 virtul dom & dom diff 帮我们进行了高效的处理。
   当应用非常简单时，可能只有一个页面，只有两三个组件，如果这两三个组件需要共享状态时，直接把最顶层组件的 state 传给他们就可以了，并没有什么问题。但当应用变大后，问题就会显现。
   比如说一个网站的 N 个页面，都需要获取已登陆用户的某个状态，那么这个状态应该放在哪里呢？
   假设还是放在最顶层，我们可以把 state 层层传递到特定的组件，没有问题，这当然是可以工作的，只是这不仅要写大量无聊的代码，而且增加了组件之间的耦合程度。其次，如果有多个底层组件可以改变 state，麻烦就来了，你有多个地方可以改变，你就难以分清是谁执行的更改，当 bug 出现的时候，非常难定位。
   而引入 mobx / redux 的 store 就可以解决这个问题。store 把状态从应用中解放出来，存放在一个地方，当你需要的时候引入就可以了。这样组件之间不会因为需要状态而耦合在一起。但 state 也并不一无是处，特定业务组件的状态依然可以放在 state 中，如果放入 store 反而是多余的，并且更复杂。

2. 更改行为可追踪
   mobx 和 redux 都有类似的 action 概念，redux 强制要求开发者调用 action 来更新 store 里的状态，而 mobx 是无主张的，你可以直接修改，也可以调用 action 来修改。但如果要想追踪更改行为，我建议用 mobx 时也采取 action。

简单比较 redux 和 mobx

根据我目前的理解，我觉得 redux 把状态管理这件事分得更细，更教条一些，而 mobx 就如上面所说，它是无主张的，它不限制你怎么去管理状态，怎么用它。最近的一个发现是，你完全可以采取类似 redux 的用法来用 mobx ——基于 mobx 的面向对象特点，写出相对简化的状态管理，基于 redux(flux) 思想，相对规范地管理状态，两者互补。

redux 是 flux 思想的具体实现，它是面向过程的，过程中有多个模块，给定输入得到相应的输出，然后各个模块组合成一个流程。
mobx 的特点是面向对象，如果你之前有面向对象编程经验，上手会非常容易。store 即是一个对象，store 有属于自己的 observable variable，有改变 variable 的 action。完全是面向对象的编程模式。

redux 只有一个 store，可以根据 reducer 分出不同 app 的状态。
mobx 有多个 store，没有 reducer 这个概念，一个 app 可以有自己的一个或者多个 store 。我觉得 mobx 的 store 和 redux 的 reducer 很像，当你采取 flux 思想来用 mobx 时，它们就更像了。

未完待续 ...