我在去年大量的使用了 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()來處理。但本地狀態的狀態管理在膨脹的應用中很快會變得混亂，因為：

一個組件需要和另一個組件共享狀態

一個組件需要改變另一個組件的狀態

到一定程度時，推算應用的狀態將會變得越來越困難。它就會變成一個有很多狀態對象并且在組件層級上互相修改狀態的混亂應用。在大部分情況下，狀態對象和狀態的修改并沒有必要綁定在一些組件上。當你把狀態提升時，它們可以通過組件樹得到。