談談 Redux 與 Mobx 思想的適用場景
Redux 和 Mobx 都是當下比較火熱的數據流模型，一個背靠函數式，似乎成為了開源界標配，一個基於面向對象，低調的前行。
函數式 vs 面向對象
首先任何避開業務場景的技術選型都是耍流氓，我先耍一下流氓，首先函數式的優勢，比如：
- 無副作用，可時間回溯，適合並發。
- 數據流變換處理很拿手，比如 rxjs。
- 對於復雜數據邏輯、科學計算維的開發和維護效率更高。
當然，連原子都是由帶正電的原子核，與帶負電的電子組成的，幾乎任何事務都沒有絕對的好壞，面向對象也存在很多優勢，比如：
- javascript 的鴨子類型，表明它基於對象，不適合完全函數式表達。
- 數學思維和數據處理適合用函數式，技術是為業務服務的，而業務模型適合用面向對象。
- 業務開發和做研究不同，邏輯嚴謹的函數式相當完美，但別指望每個程序員都願意消耗大量腦細胞解決日常業務問題。
Redux vs Mobx
那么具體到這兩種模型，又有一些特定的優缺點呈現出來，先談談 Redux 的優勢：
- 數據流流動很自然，因為任何 dispatch 都會導致廣播，需要依據對象引用是否變化來控制更新粒度。
- 如果充分利用時間回溯的特征，可以增強業務的可預測性與錯誤定位能力。
- 時間回溯代價很高，因為每次都要更新引用，除非增加代碼復雜度，或使用 immutable。
- 時間回溯的另一個代價是 action 與 reducer 完全脫節，數據流過程需要自行腦補。原因是可回溯必然不能保證引用關系。
- 引入中間件，其實主要為了解決異步帶來的副作用，業務邏輯或多或少參雜着 magic。
- 但是靈活利用中間件，可以通過約定完成許多復雜的工作。
- 對 typescript 支持困難。
Mobx：
- 數據流流動不自然，只有用到的數據才會引發綁定，局部精確更新，但免去了粒度控制煩惱。
- 沒有時間回溯能力，因為數據只有一份引用。
- 自始至終一份引用，不需要 immutable，也沒有復制對象的額外開銷。
- 沒有這樣的煩惱，數據流動由函數調用一氣呵成，便於調試。
- 業務開發不是腦力活，而是體力活，少一些 magic，多一些效率。
- 由於沒有 magic，所以沒有中間件機制，沒法通過 magic 加快工作效率（這里 magic 是指 action 分發到 reducer 的過程）。
- 完美支持 typescript。
到底如何選擇
從目前經驗來看，我建議前端數據流不太復雜的情況，使用 Mobx，因為更加清晰，也便於維護；如果前端數據流極度復雜，建議謹慎使用 Redux，通過中間件減緩巨大業務復雜度，但還是要做到對開發人員盡量透明，如果可以建議使用 typescript 輔助。