很久之前想寫一篇對redux的研究，但是網上寫的很多，而mobx相比較redux更小眾，網上很多資料例如介紹api的都是官網的復刻節選，而我用mobx感覺真的很爽，所以寫篇文章幫助初入mobx坑的玩家們，如果寫的不對，也希望各位指正，更好發展。我認為能用redux的專案就可以用mobx，除非需要
redux-saga完成一些極其複雜的非同步狀態改變，都可以完美替代，一些如微博之類偏社交的整體非同步狀態併發改變可能很多，不太適合；像能分成各個小模組的，各模組互相聯絡不是很緊密的複雜專案用mobx體驗很好。簡言之，因地制宜，不要無腦使用redux，每個都有適合的環境。
基本的api詳細介紹
不使用嚴格模式的話，不會有actions而是直接改observable的state，下面是佔出現率99%的api
網上比較多，也可以移步mobx中文官網，安裝mobx和mobx-react還有裝飾器和對應的babel 官網資料也很清晰。
想更好的理解mobx可以找找網上的手寫mobx教程，也有助於理解本篇文章（ps：很多api手寫起來比想象的簡單，簡單說來就是把乙個普通的深層物件通過遞迴層層繫結，變成observable的物件，實現最小細粒度的依賴收集）
另外，值得一提的就是mobx5使用的proxy，mobx4以下用的object.defineproperty，還是有點區別的，不多說了
官網的圖⬇
相比較redux狀態管理庫，這種單向流真的清晰容易理解，同時我們團隊做了進一步簡化，不用actions觸發，直接修改狀態state，但對其做了一些約定，使得**量進一步降低
我們團隊使用mvp思想，這裡的mvp其實類似安卓的mvp思想，是mvc的兄弟，在mvc裡，view是可以直接訪問model的，但mvp中的view並不能直接使用model，而是通過為presenter提供介面，讓presenter去更新model，再通過觀察者模式更新view。 與mvc相比，mvp模式通過解耦view和model，完全分離檢視和模型使職責劃分更加清晰；由於view不依賴model，可以將view抽離出來做成元件，它只需要提供一系列介面提供給上層操作。mvp優點是資料和檢視分得很開，缺點是如果邏輯多的話，presenter可能會很重，但是採用mobx的話會好很多，大量受觀察的資料可以少寫些邏輯。mobx寫起來很簡單（**比redux少太多），邏輯也比較清晰，可以在presenter裡面很快找到資料變動的邏輯
上圖就是乙個mvp思想下的模組，整個模組： home這個tsx元件負責view，在constructor函式裡面new例項化presenter.ts這個控制器（最好是這樣做，狀態元件可以復用），presenter負責整個的資料處理邏輯，同時引入home的子元件要把例項化後的presenter傳入，大體就是這些
下面用**簡單示意⤵️
view層goodspricetrackhome.tsx**如下：
@observer
export
default
class
goodspricetrackhome
extends
react.component
//簡單示意
render() = this.presenter;
return
onclick=>
abcdiv>
}//如果有子元件且需要傳presenter的話
render()
/>
}複製**
export default class goodspricetrackpresenter
}複製**
this.abc)，如果是兩三個人協作開發的小專案，開發過程中基本沒有太多交集，自然不需要約定修改，大型專案的話，只有登入等賬戶全域性的一些非同步操作需要嚴格模式@action來約束，其他模組的話，最多一兩個人來負責開發維護，所以如果基本上是自己負責乙個模組或者乙個小專案，就直接用普通模式
所有的與伺服器通訊、資料變動操作都放在p（presenter）上，除了監控ui的變化（如一些自適應之類）才放在v（view）上
react native編譯後與h5或者web端這種瀏覽器是不同的，它對效能更敏感，每次重新整理並不是操作dom而是原生元件，所以 在大型列表等情況下，mobx 可以更新特定單元格而無需重新呈現整個列表。通常這也可以通過 redux 實現，但是需要重寫 componentshouldupdate() 方法並編寫更多樣板檔案以避免不必要的重新渲染。在將其餘變數複製到新狀態時，redux的reducer 仍會執行一些不必要的工作
1.開發外掛程式
mobx由於是分布式的狀態管理，所以幾個開發外掛程式體驗不好，基本沒怎麼用，除錯是打斷點或者console，感覺這樣更方便一些
2.記憶體洩漏
開發者水平不齊或者無意識的進行不規範的使用，可能會造成記憶體洩漏，使用者長時間使用產品造成記憶體洩漏，影響使用者體驗（元件解除安裝之後，但是其他引用較亂，導致某些手觀察物件或者閉包無法釋放）
3.侵入性
物件導向的話，設計較為複雜，無關大量資料繫結太多，也會影響到效能
1.基本不用嚴格模式約束，直接在presenter元件裡改狀態（但怎麼改一定要事先理清思路哈）
2.相比redux，mobx管理狀態更簡單有效率，寫的**更少，做專案效率更高（但要分專案適不適合）
3.如果不注意使用規範，大專案可能會有效能問題（一般是遇不到的）
這篇文章我還會經常去完善更新，因為狀態庫涉及太多，講得比較草率，很多都點到即止了
MVC與MVP的區別
1.mvp是針對於高階開發工程師和架構師使用，mvp主要目的是 1 為了提高系統應用的擴充套件性，後期在修改以及維護 增加功能模組時，修改的地方越少越好 2 為了把m和v的耦合性降低,即解決邏輯和檢視之間的鬆散耦合性問題，減輕了view的工作壓力，在安卓的view指的是activity 3 在mvp...
MVC與MVP的區別
mvc全名是model view controller，是模型 model 檢視 view 控制器 controller 的縮寫。1 模型 用於儲存資料以及處理 使用者請求的業務邏輯。2 檢視 向控制器提交資料，顯示模型中的資料。3 控制器 根據檢視提出的請求，判斷將請求和資料提交交給哪個模型來處理...
MVC與MVP的區別
1 presenter與controller都扮演了邏輯層的角色，但是presenter層的功能相對更複雜，因為他負責和view的雙向互動，controller只是單向的中介。因為presenter是從view層抽離出來的，通常和view是一對一的關係，而controller是面向業務的，往往是單例...