簡潔的MobX與MVP思想—大型專案實踐

mguy_1發表於2019-01-03
MVP

很久之前想寫一篇對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思想使用

官網的圖⬇

簡潔的MobX與MVP思想—大型專案實踐
簡潔的MobX與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裡面很快找到資料變動的邏輯

簡潔的MobX與MVP思想—大型專案實踐
上圖就是一個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 <Children
                   presenter={this.presenter}
               />
    }
複製程式碼

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

export default class GoodsPriceTrackPresenter {
    @observable
    public 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.如果不注意使用規範，大專案可能會有效能問題（一般是遇不到的）

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

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

相關文章