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的對比，請移步至這里。