很久之前想寫一篇對Redux的研究，但是網上寫的很多，而MobX相比較Redux更小眾，網上很多資料例如介紹api的都是官網的復刻節選，而我用MobX感覺真的很爽，所以寫篇文章幫助初入MobX坑的玩家們，如果寫的不對，也希望各位指正，更好發展。

適合用MobX的項目

我認為能用redux的項目就可以用mobx，除非需要redux-saga完成一些極其復雜的異步狀態改變，都可以完美替代，一些如微博之類偏社交的整體異步狀態并發改變可能很多，不太適合；像能分成各個小模塊的，各模塊互相聯系不是很緊密的復雜項目用mobx體驗很好。簡言之，因地制宜，不要無腦使用redux，每個都有適合的環境。

基本知識儲備

基本的api詳細介紹

不使用嚴格模式的話，不會有Actions而是直接改observable的state，下面是占出現率99%的api

• @observer：用在react的view層的組件上方，變成可觀察的
• @observable：把一個變量變成可觀察的
• @computed：類似于vue，收集observable的變化而變化
• autorun：包裹的函數先自動執行一次，里面檢測到有依賴變動，自動執行
• toJS(value, options?)：把observable的對象變回原生js對象的函數（實際用的地方很少，但需要知道，如果是用4版本一下的還是要特別注意）

網上比較多，也可以移步MobX中文官網，安裝MobX和mobx-react還有裝飾器和對應的babel 官網資料也很清晰。

想更好的理解MobX可以找找網上的手寫MobX教程，也有助于理解本篇文章（PS：很多api手寫起來比想象的簡單，簡單說來就是把一個普通的深層對象通過遞歸層層綁定，變成observable的對象，實現最小細粒度的依賴收集）

另外，值得一提的就是MobX5使用的proxy，MobX4以下用的Object.defineProperty，還是有點區別的，不多說了

結合MVP思想使用

官網的圖?

相比較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<any, any> {private presenter: GoodsPriceTrackPresenter;constructor(props: any, context: any) {super(props, context);this.presenter = new GoodsPriceTrackPresenter();}//簡單示意render() {const {abc,changeAbc} = this.presenter;return <div onClick={changeAbc}>abc</div>}//如果有子組件且需要傳presenter的話render() {return <Childrenpresenter={this.presenter}/>} 復制代碼

控制器這一層GoodsPriceTrackPresenter.ts代碼如下：

export default class GoodsPriceTrackPresenter {@observablepublic abc: number = 123;public changeAbc(){this.abc++;} } 復制代碼

是否及何時使用嚴格模式

結論：基本不用嚴格模式(像示例中直接改了this.abc)，如果是兩三個人協作開發的小項目，開發過程中基本沒有太多交集，自然不需要約定修改，大型項目的話，只有登錄等賬戶全局的一些異步操作需要嚴格模式@action來約束，其他模塊的話，最多一兩個人來負責開發維護，所以如果基本上是自己負責一個模塊或者一個小項目，就直接用普通模式

注意事項

所有的與服務器通信、數據變動操作都放在p（presenter）上，除了監控ui的變化（如一些自適應之類）才放在v（view）上

React Native下mobx相對更好

React Native編譯后與h5或者web端這種瀏覽器是不同的，它對性能更敏感，每次刷新并不是操作dom而是原生組件，所以 在大型列表等情況下，MobX 可以更新特定單元格而無需重新呈現整個列表。通常這也可以通過 Redux 實現，但是需要重寫 componentShouldUpdate() 方法并編寫更多樣板文件以避免不必要的重新渲染。在將其余變量復制到新狀態時，redux的reducer 仍會執行一些不必要的工作

MobX體驗的一些不足

1.開發插件

mobx由于是分布式的狀態管理，所以幾個開發插件體驗不好，基本沒怎么用，調試是打斷點或者console，感覺這樣更方便一些

2.內存泄漏

開發者水平不齊或者無意識的進行不規范的使用，可能會造成內存泄漏，用戶長時間使用產品造成內存泄漏，影響用戶體驗（組件卸載之后，但是其他引用較亂，導致某些手觀察對象或者閉包無法釋放）

3.侵入性

面向對象的話，設計較為復雜，無關大量數據綁定太多，也會影響到性能

總結

1.基本不用嚴格模式約束，直接在Presenter組件里改狀態（但怎么改一定要事先理清思路哈）

2.相比redux，MobX管理狀態更簡單有效率，寫的代碼更少，做項目效率更高（但要分項目適不適合）

3.如果不注意使用規范，大項目可能會有性能問題（一般是遇不到的）

這篇文章我還會經常去完善更新，因為狀態庫涉及太多，講得比較草率，很多都點到即止了

歡迎評論區評論和拍磚，兩開花啊兩開花

總結

以上是生活随笔為你收集整理的简洁的MobX与MVP思想—大型项目实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。