如何評價mobx-state-tree？

https://github.com/mobxjs/mobx-state-tree

有一段時間的使用體驗了, 不過沒有往細了研究. 我因為主要心思都在 persistent data structure 的問題上, 對於 observable 沒有太多信任.

MobX 類庫本身實現的是 Observable Data, 數據可以被觀測, 隨後被 View 監聽用於界面更新. 而 MST 是作為 Global Store 設計的, 我們是用在組件外. 另一方面 MST 通過 Schema 定義了類型, 從網路拉取的數據被掛到 MST 的 Store 當中時, 會進行一次校驗, 保證數據的結構.

使用當中好處, MST 跟 TypeScript 的類型系統配合很好, 我本來擔心寫這類的應用會很累, 使用中再 VS Code 里自動補缺確實還可以. 確定了類型之後懟整體的可靠性確實有幫助. 基本上就是類型系統帶來的改進了.

不自然的地方也有一些, 也是因為類型系統, 比如沒有可以很方便使用的 Map 類型, 比如後端 API 頻繁改動的情況下, 前端需要大量添加 types.maybe 來兼容數據為 null 的情況, 同時如果格式出錯了, MST 當前列印的 error log 對於調試來說並不夠友好, 甚至密密麻麻的數據擠滿整個 Console 看起來很吃力.

還有一個坑就是跟很多基於 Observable 的庫一樣, 顯示在 Console 當中很難看. 我們 ClojureScript 當中數據也是封裝過的, 但是我們利用 Custom Formatter 對數據進行格式化了呀, 比這要好不少.

按照作者演講視頻里的描述, MST 底層還是基於 immutable data 設計的, 所有的修改實際上是被轉化為 Action 作用在不可變的樹上, 而且直接從外部不經過 Action 修改數據是不被允許的. 作為 ClojureScript 程序員, 我覺得這是很繞的.

我沒有深入用過 Redux, 作為對比的話, 我覺得 MST 至少目前風格上依據官方的寫法還算統一, 而且由於大家或多或少都有面向對象風格的一些習慣, 找到甜點應該還是可以的. FP 風格有時候會導致一些非常簡單粗暴的代碼, 用 MST 看上去相對正常一些.

另外 MST 作者在大會上演講挺拉風, 在 Twitter 和 Gitter 上卻不怎麼活躍, 不知道是怎樣一個人. 我好幾次去 Twitter 上評論吸引他注意都無功而返, 不開心. 一般在 GitHub 發問題隔天還是能回復的, 維護上說還是可以的.

剛踩完坑出來，MST相比Mobx，性能有問題，如果有超長列表&>1k項，不建議使用。

Orders of magnitude slower than mobx · Issue #440 · mobxjs/mobx-state-tree