談談 Redux 與 Mobx 思想的適用場景

談談 Redux 與 Mobx 思想的適用場景

Redux 和 Mobx 都是當下比較火熱的數據流模型，一個背靠函數式，彷佛成爲了開源界標配，一個基於面向對象，低調的前行。

函數式 vs 面向對象

首先任何避開業務場景的技術選型都是耍流氓，我先耍一下流氓，首先函數式的優點，好比：

1. 無反作用，可時間回溯，適合併發。
2. 數據流變換處理很拿手，好比 rxjs。
3. 對於複雜數據邏輯、科學計算維的開發和維護效率更高。

固然，連原子都是由帶正電的原子核，與帶負電的電子組成的，幾乎任何事務都沒有絕對的好壞，面向對象也存在不少優點，好比：

1. javascript 的鴨子類型，代表它基於對象，不適合徹底函數式表達。
2. 數學思惟和數據處理適合用函數式，技術是爲業務服務的，而業務模型適合用面向對象。
3. 業務開發和作研究不一樣，邏輯嚴謹的函數式至關完美，但別期望每一個程序員都願意消耗大量腦細胞解決平常業務問題。

Redux vs Mobx

那麼具體到這兩種模型，又有一些特定的優缺點呈現出來，先談談 Redux 的優點：

1. 數據流流動很天然，由於任何 dispatch 都會致使廣播，須要依據對象引用是否變化來控制更新粒度。
2. 若是充分利用時間回溯的特徵，能夠加強業務的可預測性與錯誤定位能力。
3. 時間回溯代價很高，由於每次都要更新引用，除非增長代碼複雜度，或使用 immutable。
4. 時間回溯的另外一個代價是 action 與 reducer 徹底脫節，數據流過程須要自行腦補。緣由是可回溯必然不能保證引用關係。
5. 引入中間件，其實主要爲了解決異步帶來的反作用，業務邏輯或多或少參雜着 magic。
6. 可是靈活利用中間件，能夠經過約定完成許多複雜的工做。
7. 對 typescript 支持困難。

Mobx：

1. 數據流流動不天然，只有用到的數據纔會引起綁定，局部精確更新，但免去了粒度控制煩惱。
2. 沒有時間回溯能力，由於數據只有一份引用。
3. 自始至終一份引用，不須要 immutable，也沒有複製對象的額外開銷。
4. 沒有這樣的煩惱，數據流動由函數調用一鼓作氣，便於調試。
5. 業務開發不是腦力活，而是體力活，少一些 magic，多一些效率。
6. 因爲沒有 magic，因此沒有中間件機制，無法經過 magic 加快工做效率（這裏 magic 是指 action 分發到 reducer 的過程）。
7. 完美支持 typescript。

到底如何選擇

從目前經驗來看，我建議前端數據流不太複雜的狀況，使用 Mobx，由於更加清晰，也便於維護；若是前端數據流極度複雜，建議謹慎使用 Redux，經過中間件減緩巨大業務複雜度，但仍是要作到對開發人員儘可能透明，若是能夠建議使用 typescript 輔助。