函式式 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 輔助。
打賞支援我寫出更多好文章，謝謝！
打賞作者
打賞支援我寫出更多好文章，謝謝！
任選一種支付方式
