我在去年大量的使用了 Redux，但我最近都在使用 Mobx 来做状态（state）管理。似乎现在社区里关于该选什么来替代 Redux 很自然地成为了一件困惑的事。开发者不确定该选择哪种解决方案。这个问题并不只是出现在 Redux 与 Mobx 上。无论何时，只要存在选择，人们就会好奇最好的解决问题的方式是什么。我现在写的这些是为了解决 Redux 和 Mobx 这两个状态管理库之间的困惑。
大部分的文章都用 React 来介绍 Mobx 和 Redux 的用法。但是在大部分情况下你都可以将 React 替换成 Angular 、 Vue 或其他。
在 2016 年年初的时候我用 React + Redux 写了一个相当大的应用。在我发现可以使用 Mobx 替代 Redux 时，我花时间将应用从 Redux 重构成了 Mobx 。现在我可以非常自在的使用它俩并且解释它俩的用法。
这篇文章将要讲什么呢？如果你不打算看这么长的文章（TLDR：too long, didn't read（查看此链接请自备梯子）），你可以看下目录。但我想给你更多细节：第一，我想简单地回顾状态管理库为我们解决了什么问题。毕竟我们写 React 时只用 setState() 或写其他 SPA 框架时用 setState() 类似的方法一样也可以做的不错。第二，我会大致的说下它们之间的相同之处和不同之处。第三，我会给 React 生态初学者指明怎样学习 React 的状态管理。友情提醒：在你深入 Mobx 和 Redux 之前，请先使用 setState() 。最后，如果你已经有一个使用了 Mobx 或 Redux 的应用，我将会就如何从其中一个状态管理库重构到另一个给你更多我的理解。
目录
我们要解决的是什么问题？
Mobx 和 Redux 的不同？
React 状态管理的学习曲线
尝试另一个状态管理方案？
最后思考
我们要解决的是什么问题？
所有人都想在应用中使用状态管理。但它为我们解决了什么问题？很多人开始一个小应用时就已经引入一个状态管理库。所有人都在谈论 Mobx 和 Redux ，不是吗？但大部分应用在一开始的时候并不需要大型的状态管理。这甚至是危险的，因为这部分人将无法体验 Mobx 和 Redux 这些库所要解决的问题。
如今的现状是要用组件（components）来构建一个前端应用。组件有自己的内部状态。举个栗子，在 React 中上述的本地状态是用this.state和setState()来处理。但本地状态的状态管理在膨胀的应用中很快会变得混乱，因为：
一个组件需要和另一个组件共享状态
一个组件需要改变另一个组件的状态
到一定程度时，推算应用的状态将会变得越来越困难。它就会变成一个有很多状态对象并且在组件层级上互相修改状态的混乱应用。在大部分情况下，状态对象和状态的修改并没有必要绑定在一些组件上。当你把状态提升时，它们可以通过组件树得到。
所以，解决方案是引入状态管理库，比如：Mobx 或 Redux。它提供工具在某个地方保存状态、修改状态和更新状态。你可以从一个地方获得状态，一个地方修改它，一个地方得到它的更新。它遵循单一数据源的原则。这让我们更容易推断状态的值和状态的修改，因为它们与我们的组件是解耦的。
像 Redux 和 Mobx 这类状态管理库一般都有附带的工具，例如在 React 中使用的有 react-redux 和 mobx-react，它们使你的组件能够获得状态。一般情况下，这些组件被叫做容器组件（container components），或者说的更加确切的话，就是连接组件( connected components )。只要你将组件升级成连接组件，你就可以在组件层级的任何地方得到和更改状态。
Mobx 和 Redux 的不同？
在我们深入了解 Redux 和 Mobx 的不同之前，我想先谈谈它们之间的相同之处。
这两个库都是用来管理 JavaScript 应用的状态。它们并不一定要跟 React 绑定在一起，它们也可以在 AngularJs 和 VueJs 这些其他库里使用。但它们与 React 的理念结合得非常好。