使用mobx項目開發總結（再也不更新）

 

mobx的優勢

1，使用@observer的組件真正實現按需更新，只有監聽的數據發生變化，它纔會re-render，儘管父組件發生更新，可是子組件只要有@observer，則不會觸發更新，相似於實現了shouldComponentUpdate的效果，而一樣的場景，若是是redux，子組件經過connect綁定了store裏部分數據，可是若是父組件發生更新，子組件綁定的數據源並未發生變化，所以子組件不該該更新，然而卻強制更新。

 

mobx耦合性更低。

 

mobx的缺點

1，store過多致使沒法統一數據源，在多人開發的狀況下會比較混亂，若是須要公用某個store，惟有在特定組件注入該store，那若是有多個store裏有多個數據源須要公用呢，那就要同時注入多個store，項目複雜了，store的管理又是一個問題。

 

2，mobx對於數組的處理，會將它轉換成observableArray，它不是一個數組類型，須要進行數組轉換（如slice）。

 

3，mobx在forceupdate時，並無像setState那樣處理多個更新合併的操做，這就帶來個問題就是，在同一個event loop中，若是屢次經過action去引發同一個觀察者的更新，那麼它就會連續更新屢次，可是若是是setState，它會進行一次合併，不會有這種負擔。（這裏的解決方案就是人爲的去控制，避免這種屢次同時更新，能夠將多個action手動合併爲1個action）；

 

4，對於某個公共組件，可能多個頁面須要用到，可是組件內狀態較多，而且不一樣頁面，狀態差別較多，此時若是用mobx的store來管理，會存在一個問題，組件雖然unmount了，可是store並未消失，致使須要手動reset store裏全部的狀態，不然會混亂

 

 

 

mobx的思想

將響應式編程和部分函數式編程相結合，取締傳統React的命令式編程，分而治之，將組件都變成可響應的，React提供了渲染的最優方式，經過對比虛擬DOM的diff算法來減小沒必要要的渲染耗費，而mobx則給React提供了響應式的狀態管理。

 

 

關於mobx細粒度拆分

是否全部的state我都交給mobx來管理，其實相似於redux，只有當某個狀態須要多個組件（這裏默認爲2個及以上）公用，則將該狀態放到store裏去監聽，而後須要引用該狀態的組件經過mobx-react的inject來進行監聽。

 

關於mobx的優化

這裏我參考redux的優化，將容器組件經過mobx-react來鏈接須要監聽的store，而後展現組件就仍是經過PureComponent來進行優化，避免重複re-render。這裏其實有一點考慮是，咱們能夠利用@observer來對展現組件須要更新的狀態進行一個監聽，免去shouldComponentUpdate的步驟，可是若是多掛一層監聽，性能未必更優，至關於要多處理一個監聽器，因此仍是減小監聽的個數會好些。

 

 

爲何選擇mobx而不是redux

這個標題不是爲了貶低redux，而是解釋爲何在某些項目環境中，我不使用redux，而是使用mobx，可否使用redux？能夠，只不過mobx會更讓開發者舒服一些。

 

項目場景分析：

 

（待續）

 

===============

2019.3.7更新

這篇隨筆不會再更新了，有一篇更詳細的講解mobx以及和redux還有rxjs的對比，請移步至這裏。