Redux VS Mobox

Mobx和Redux都是JavaScript應用狀態管理庫，都適用於React，Angular，VueJs等框架或庫，而不是侷限於某一特定UI庫。

Redux

要介紹Redux，咱們就不得不談到Flux了:

Flux是Facebook用來開發客戶端-服務端web應用程序的應用架構，它更可能是一種架構模式，而非一個特定框架。

而Redux更多的是遵循Flux模式的一種實現，是一個JavaScript庫，它關注點主要是如下幾方面：

1. Action：一個JavaScript對象，描述動做相關信息，主要包含type屬性和payload屬性：

1. type：action 類型；

2. payload：負載數據；

2. Reducer：定義應用狀態如何響應不一樣動做（action），如何更新狀態；

3. Store：管理action和reducer及其關係的對象，主要提供如下功能：

1. 維護應用狀態並支持訪問狀態（getState()）；

2. 支持監聽action的分發，更新狀態（dispatch(action)）；

3. 支持訂閱store的變動（subscribe(listener)）；

4. 異步流：因爲Redux全部對store狀態的變動，都應該經過action觸發，異步任務（一般都是業務或獲取數據任務）也不例外，而爲了避免將業務或數據相關的任務混入React組件中，就須要使用其餘框架配合管理異步任務流程，如redux-thunk，redux-saga等；

Mobx

Mobx是一個透明函數響應式編程（Transparently Functional Reactive Programming，TFRP）的狀態管理庫，它使得狀態管理簡單可伸縮：

1. Action：定義改變狀態的動做函數，包括如何變動狀態；

2. Store：集中管理模塊狀態（State）和動做（action）；

3. Derivation（衍生）：從應用狀態中派生而出，且沒有任何其餘影響的數據，咱們稱爲derivation（衍生），衍生在如下狀況下存在：

1. 用戶界面；

2. 衍生數據；衍生主要有兩種：

1. Computed Values（計算值）：計算值老是可使用純函數（pure function）從當前可觀察狀態中獲取；

2. Reactions（反應）：反應指狀態變動時須要自動發生的反作用，這種狀況下，咱們須要實現其讀寫操做；

單一store和多store

store是應用管理數據的地方，在Redux應用中，咱們老是將全部共享的應用數據集中在一個大的store中，而Mobx則一般按模塊將應用狀態劃分，在多個獨立的store中管理。

JavaScript對象和可觀察對象

Redux默認以JavaScript原生對象形式存儲數據，而Mobx使用可觀察對象：

1. Redux須要手動追蹤全部狀態對象的變動；

2. Mobx中能夠監聽可觀察對象，當其變動時將自動觸發監聽；

選擇Mobx的緣由

1. 學習成本少：Mobx基礎知識很簡單，學習了半小時官方文檔和示例代碼就搭建了新項目實例；而Redux確較繁瑣，流程較多，須要配置，建立store，編寫reducer，action，若是涉及異步任務，還須要引入redux-thunk或redux-saga編寫額外代碼，Mobx流程相比就簡單不少，而且不須要額外異步處理庫；

2. 面向對象編程：Mobx支持面向對象編程，咱們可使用@observable and @observer，以面向對象編程方式使得JavaScript對象具備響應式能力；而Redux最推薦遵循函數式編程，固然Mobx也支持函數式編程；

3. 模版代碼少：相對於Redux的各類模版代碼，如，actionCreater，reducer，saga／thunk等，Mobx則不須要編寫這類模板代碼；

不選擇Mobx的可能緣由

1. 過於自由：Mobx提供的約定及模版代碼不多，這致使開發代碼編寫很自由，若是不作一些約定，比較容易致使團隊代碼風格不統一，因此當團隊成員較多時，確實須要添加一些約定；

2. 可拓展，可維護性：也許你會擔憂Mobx能不能適應後期項目發展壯大呢？確實Mobx更適合用在中小型項目中，但這並不表示其不能支撐大型項目，關鍵在於大型項目一般須要特別注意可拓展性，可維護性，相比而言，規範的Redux更有優點，而Mobx更自由，須要咱們本身制定一些規則來確保項目後期拓展，維護難易程度；

不管前端仍是後端，遇到問題，大多數時候也許你們老是習慣於推薦已經廣泛推廣使用的，習慣，熟悉就很容易變成瓜熟蒂落的，咱們應該更進一步去思考，合適的纔是更好的。

固然對於「Redux更規範，更靠譜，應該使用Redux」或」Redux模版太多，太複雜了，應該選擇Mobx」這類推斷，咱們也應該避免，這些都是相對而言，每一個框架都有各自的實現，特點，及其適用場景，正好比Redux流程更復雜，但熟悉流程後就更能把握它的一些基礎／核心理念，使用起來可能更有心得及感悟；而Mobx簡單化，把大部分東西隱藏起來，若是不去特別研究就不能接觸到它的核心／基本思想，也許使得開發者一直停留在使用層次。

因此不管是技術棧仍是框架。類庫，並無絕對的比較咱們就應該選擇什麼，拋棄什麼，咱們應該更關注它們解決什麼問題，它們解決問題的關注點，或者說實現方式是什麼，它們的優缺點還有什麼，哪個更適合當前項目，以及項目將來發展。