Redux/Mobx/Akita/Vuex對比 - 選擇更適合低程式碼場景的狀態管理方案

JunpengZ發表於2021-06-09

近期準備開發一個資料分析 SDK,定位是作為資料中臺向外輸出資料分析能力的載體,前端的功能表現類似低程式碼平臺的各種拖拉拽。作為中颱能力的載體,SDK 未來很大概率會需要支援多種檢視層框架,比如Vue2/Vue3/React等。所以在技術架構上對檢視層框架的依賴性越輕,迭代的成本越低。基於這樣的目標,本文對前端狀態管理工具進行調研,在技術選型上應當儘量減輕與檢視框架的繫結程度,理想的目標是構建與檢視框架無關的資料/狀態管理層

調研物件包括以下:

調研物件 說明
Redux 最早的基於Flux架構改進的狀態管理工具,生態繁榮,有豐富的中介軟體和外掛滿足不同場景需求,較多搭配React
Vuex Vue專用的狀態管理工具,與 Redux 同屬 Flux 體系
Mobx 基於響應式程式設計思想,近兩年成長為React社群最流行的狀態管理工具之一
Akita 基於RxJS的響應式狀態管理工具
RxJS RxJS並不是狀態管理工具,但其響應式的設計有很大想象空間

RxJS 跟狀態管理沒有任何關係,不過它天生適合編寫非同步和基於事件的程式,有了這個前提,完全可以封裝一套基於 RxJS 的狀態管理架構,比如 Akita。同時RxJS 非常適合用來管理事件流,如果狀態管理工具能夠與 RxJS 比較好的搭配使用,能夠達到事半功倍的效果。本文的調研不涉及 RxJS,此處只列舉出它的作用,不做細節調研。

通過以下幾個維度進行對比(排名分先後):

對比維度 說明
業務場景覆蓋率 工具本身搭配社群解決方案是否能夠覆蓋業務場景所需的能力
資料流 瞭解每個工具的資料流模式是所有調研的基礎
與檢視框架的繫結程度和改造成本 大部分狀態管理工具都可以相容多種檢視框架,但一般需要適當的改造以提高開發便利性
風險和隱患 開源工具的選型都有一定隱患,主要考慮社群、生態以及開發團隊響應的及時性
效能 資料分析場景需要處理的資料量很大,對工具有一定效能要求,不過工具本身的效能遠未達到能夠成為應用的瓶頸的程度,所以此項僅作參考
學習曲線 結合當前研發人員的技術能力衡量上手成本和學習曲線,鑑於有一定的技術儲備時間,此維度的佔比可以適當放低

資料分析SDK是純端側的產品,所以本文調研的幾個工具對於SSR的支援不在調研範圍之內。

業務場景覆蓋率

在進入調研之前,首先把資料分析 SDK (下文簡稱分析 SDK)的定位以及業務場景講清楚。

分析 SDK 是資料分析功能的承擔者,但 SDK本身不是一個可用的完整產品,上層需要一個分析平臺作為宿主載體。以網易有數為例,網易有數是一個大資料平臺,它包含很多功能,比如看板、報告定製、取數、多維分析等等。分析 SDK 在其中的角色就是這些功能的載體,網易有數平臺將分析 SDK 整合進來,以視覺化的形式提供分析相關的功能。下圖展示的是網易有數報告定製的頁面:

圖片

資料分析是一種類似的低程式碼的業務場景,從技術角度上有以下特徵:

  • 資料量大且結構複雜;
  • 事件流複雜、高頻且時序敏感;
  • 元件結構複雜且互相之間存在大量的資料共享。

除此之外,之所以要做一個分析 SDK而不是分析平臺,是因為中颱的服務產出需要支援前臺業務的接入,分析 SDK 的目標使用者是前臺業務部門的各個分析平臺。在這個前提下,分析 SDK 對技術有另外一個額外要求:

  • 支援前臺分析平臺的技術棧。

而前臺不止一個,不同業務線的技術棧也不統一,前端技術棧的契合度主要是元件要支援多種檢視層框架,比如React、Vue2、Vue3甚至Angular,所以分析 SDK的技術架構應當儘量減輕對檢視層框架的依賴程度,將核心業務邏輯從檢視層抽離出來。這樣的好處能夠降低支援不同檢視層框架時所投入的人力成本、時間成本和維護成本。這就是本文開頭所說的為什麼要構建與檢視框架無關的資料/狀態管理層的原因。「Smart Modeling,Dumb View」,即邏輯集中在資料層,檢視層儘量只做展示(類似 React 的 Pure Component)。

結合分析 SDK的定位和業務場景,可以提煉出對狀態管理工具的幾點具體需求:

  • 支援 state 按子模組劃分名稱空間,以便支援複雜資料模型;
  • 與檢視層框架沒有強繫結關係,以便支援多種檢視層框架;
  • 支援時間回溯,比如undo/redo,這是編輯器的基本操作。

資料流

目前絕大多數狀態管理工具都遵循單向資料流原則,這項原則最早是由 Flux 帶入到前端領域,所以在瞭解各個狀態管理工具的資料流之前,有必要先搞清楚 Flux 架構。

這部分只考慮正常互動場景下的資料流向,也就是隻考慮由view層觸發資料變動的情況,不考慮單元測試等非常規互動場景。

Flux

圖片

  • Action是描述一個行為的物件,每個 action 裡都包含兩部分資訊:actionType 和 payload,分別代表行為的型別和攜帶的資料;
  • Dispatcher是一個排程中心,它是 action 和 store 的連線中心。有兩個核心方法:
    • dispatch方法:觸發一個 action,一般由 view 層呼叫;
    • register方法:用於註冊 actionType 的回撥,在回撥中操作 store。
  • Store是資料倉儲以及資料操作的唯一場所,當資料發生變化時,向外廣播change事件;
  • View層監聽 store 的change事件,呼叫setState方法來更新相應的元件狀態。

Flux 並沒有規定如何進行非同步操作,比如介面的網路請求,這種場景在前端應用中非常高頻。為了解決這種問題,有人提出了Action Creators的概念並在開發者社群獲得了認同,加入 Action Creator 之後的 Flux 資料流如下:

圖片

Action Creators 顧名思義就是 action 的「製造者」,在“製造”action之前可以進行任何行為,包括非同步操作。比如以下程式碼:

async function updateUserInfoCreator(){
 // 第一步:非同步獲取使用者資訊
  const info = awaitfetch('...');
  //第二步:觸發action
  dispatch({
actionType: 'UPDATE_USERINFO',
    data: info
  });
}

在 view 層呼叫 updateUserInfoCreator 函式即可。

Flux 的價值更多的體現在理論而非實用意義上,它提出的單向資料流模式被後續很多優秀的狀態管理工具借鑑。Facebook 提供了一個 Flux 實現,不過目前很少有開發者直接使用它,而是使用一些在 Flux 架構模式基礎上的改進方案,最廣泛的就是 Redux。

Redux

Redux 遵循 Flux 的單向資料流思想,與 Flux 不同的是,Redux 沒有 Dispatcher 的概念,而是將本屬於 Dispatcher 的 dispatch 方法內聚到了 Store 物件上。

圖片

  • Redux 中 Action 的定位與 Flux 一致,都是描述一個具體行為的物件,包括 actionType 和 payload 兩部分資訊;
  • Redux 中的 Store 只有一個,也就是單一資料來源,並且所有 state 共同組成了一個樹形結構。這與 Flux 不同,Flux 並沒有規定 Store 的個數限制以及 state 的組合方式,可以一個 store 對應所有 view,也可以每個 view 分別對應一個 store;
  • Reducer 是 Redux 的專有概念,響應 action 並返回更新後的 state 傳送到 store 中。Reducer 並不會修改 state,而是在 action 和 old state 基礎上計算出新的 state 值併傳送給store,沒有任何副作用,更新 state 的行為是由 store 內部進行,對開發者不可見。

與 Flux 一樣,Redux 同樣沒有規定如何處理非同步資料流。最原始的方案是上文提到的 Action Creators。不過 Redux提供了更優雅的解決方案:中介軟體

關於 Redux 中介軟體的詳細使用方案就不介紹了,熟悉 Node.js 的開發者更容易理解中介軟體的概念,Express、Koa都實現了這種模式。

Redux 中介軟體同時也擴充了 dispatch 的行為,只要保證經過多箇中介軟體的一系列連續行為的最後 dispatch 返回一個規範的 action物件即可,中間過程中可以 dispatch 一個 action creator 函式,這個函式內部還可以再次 dispatch 另一個 action。

中介軟體極大的豐富了 Redux 的可擴充套件性,孵化出很多優秀的非同步資料流解決方案,比如 redux-thunk、redux-saga 等等。

綜合以上,Redux 的優勢有以下幾點:

  • 單向資料流;
  • 單一資料來源,state聚合方便支援時間回溯;
  • 引入資料不可變性理念( Reducer 本質是一個純函式),state 寫行為收斂;
  • 可擴充套件性高。

Redux 同時也有一些被人詬病的缺點,主要有兩個:

  • 繁瑣。各個角色分配的很精細,這樣的優點是行為單一邏輯嚴謹,缺點是樣板程式碼(boilerplate code)數量大,尤其是 reducer,在複雜場景中需要寫大量的switch,可讀性差維護難度大,要理解一個狀態機往往需要配合好幾個程式碼檔案才能讀懂;

    樣板程式碼指的是為了完成一個功能所需的所有程式碼。

  • 複雜。Redux 預設只支援同步資料流,提供中介軟體機制讓開發者自己定製非同步資料流,社群中的解決方案複雜度不一,複雜業務場景下的解決方案比如 redux-saga 的複雜度更是高出幾個量級,導致開發者在做技術選型和寫程式碼時很頭疼。

    在複雜度方面,Redux 跟前端這個行業很像,看上去非常簡單,稍一深入就臥了個槽。

另外,Redux 是函數語言程式設計的推崇者,架構和API 設計對喜歡函數語言程式設計的開發者非常友好。

Vuex

Vuex 是針對 Vue 的一種特異化的 Flux,保留了單向資料流的核心概念,同時吸取了部分 Redux 的理念。跟 Flux/Redux相比,Vuex 是更加全面的狀態管理解決方案,提供了非同步操作支援,見下圖:

圖片

由於 Vuex只能搭配 Vue 使用,不具備適配多種檢視框架的能力,所以詳細的解析就不寫了,只簡單提一下它的優缺點。

Vuex的優點在於:

  • 全面。Vuex 天然支援非同步資料流,開發者不必操心選型問題。當然這個也有兩面性,如果存在 Vuex 覆蓋不了的業務場景(雖然概率很小),那麼很大可能造成包括檢視層技術棧的整體遷移;
  • 易用。包括兩方面,一是 API足夠簡單,$store 物件直接掛載到 Vue 例項物件上;二是各角色劃分清晰且職責單一( action 相對複雜一些),容易理解;
  • 響應式。與 Vue 的響應式特性天然結合,配合簡單易用的 API,Vue + Vuex 的組合在寫程式碼時非常舒服。

這裡額外說一點,Vue 與 React實現響應式的方式不一樣,React 是通過事件 push 機制實現,Vue 是藉助 Proxy 進行 IO 劫持實現。

Vuex 的缺點,僅個人理解,有以下幾點:

  • 適用面窄。與 Vue 強繫結,不適用於其他檢視框架。當然這也是跟它自身的定位有關,Vuex 本來就是針對 Vue 的解決方案,並沒有想成為一種通用方案。這算不上缺點,但在資料分析 SDK這個需求背景下確實不合適;
  • 繁瑣。與 Redux 一樣,樣板程式碼過多造成閱讀程式碼的難度加強。

Vuex 和 Redux 本質上都是基於 Flux 的改進方案,核心思想同屬於 Flux 體系。接下來幾個是另外一套體系:響應式

Mobx

Mobx 是一個基於函式式響應式程式設計(Functional Reactive Programming,簡稱 FRP)的狀態管理解決方案,同樣遵循單向資料流原則。

圖片

理解 Mobx 之前,必須先搞清楚兩個核心概念:observableobserver。從名字上很好理解,observable 是可被觀察的物件,observer 是觀察者。這兩個概念被廣泛地使用在釋出訂閱模式(Pub/Sub Pattern)、觀察者模式(Observer Pattern)以及響應式程式設計中。observable 物件的變化會“自動觸發” observer 物件執行對應的響應邏輯,而自動觸發的實現方式在不同的工具中存在差異,進而造成程式碼正規化、擴充套件性、效能等方面的差異。

在此背景之下,再去理解Mobx中的三個核心概念:

  • State - 狀態,顧名思義就是應用程式使用的狀態資料,在 Mobx 中,state 是一種 Observable 物件

  • Actions - 動作,是任何一段可以改變 state 的程式碼。Mobx中的 action 與 Redux 和 Vuex 中的 action 都不同,Redux 的action 是行為的描述物件,並不會改變 state;Vuex 中的 action 是可選的,一般是用來執行非同步操作,而改變 state 的執行者是 mutation。Mobx 中 action 其實是一個抽象概念,action 的目的是修改 state,至於如何修改完全交給開發者自由發揮,也就是說 action 中可以包含任意邏輯的程式碼,包括非同步操作(action.bound/runInAction/flow);

  • Derivations - 衍生。Mobx 官方對 derivation 的定義如下:
    圖片

    有些不好理解,其實可以簡單粗暴的把 derivation 理解成 Observer 物件,它對 state 的改變做出響應,但是有一個條件,derivation只能消費 state,不能對 state 進行再次操作。

    Derivation 分成兩種:

    • Computed values - 計算值,類似 Vue 中的 computed value,基於 state 使用一個純函式計算出另外一個值;
    • Reactions -反應,根據 state 改變自動觸發的一些副作用,比如渲染 UI。

    至於什麼時候用 Computed 什麼時候用 Reaction 其實並沒有絕對的邊界,Reaction 可以解決絕大多數問題只不過需要自己寫程式碼模擬 Computed(這一點也跟 Vue 中的 watch 和 computed 類似),如果應用中需要一個基於 state 的派生值同時這個值有一定的複用性,可以考慮使用 Computed。

Mobx的優點是,它沒有 Redux 和 Vuex 中那麼多概念,樣板程式碼的數量很小,程式碼可讀性和可維護性高。基於這一點,Mobx 的上手也非常容易,開發者需要理解的概念越少越容易上手。此外,雖然 Mobx 是基於 FRP,但它的 API設計非常適合物件導向程式設計,比如 decorator 裝飾詞、class 是一等公民等等。而且有 Reactions 作為響應式程式設計和指令式程式設計的橋樑,開發者可以用更舒服的正規化寫程式碼。

decorator 還沒有成為 JavaScript 語言標準(ES)的一部分,Mobx 6中移除了 decorator 裝飾器語法,不過核心思想沒有改變。之所以移除 decorator,一方面是為了向 JavaScript 語言標準靠攏,另一方面是由於 decorator本身的程式碼量很大,增大了打包後的 js 檔案體積。

Mobx 雖然不是 Flux 系列,但有一點與 Flux 的設計理念相同:沒有規範 store 的組織模式。Redux 和 Vuex 中的 store 都是樹形結構,單一資料來源並且方便快照(snapshot),這個優點讓兩者非常便於除錯,並且支援時間回溯的場景上游刃有餘。而 Mobx 並沒有這些優點,所以社群中湧現了一批補充方案,比如mobx-state-tree(簡稱MST)和mobx-keystone,核心思想就是將 store 的組織結構聚攏為樹狀,以便支援更友好的除錯和時間回溯。

綜合以上,總結 Mobx的優點是:

  • 簡單易學習;
  • 程式碼可讀性和可維護性高;
  • OOP編碼正規化,易於上手。

缺點有以下:

  • 除錯困難(與Redux/Vuex相比);
  • 不支援時間回溯。

搭配使用一些社群解決方案,Mobx的以上缺點可以得到一定程度上的彌補。

有很多開發者認為 Redux更適合複雜的大型應用,Mobx 適合資料流相對簡單的應用。這其實並不絕對。Redux 嚴謹的程式碼組織確實對複雜場景有加分,但 Mobx 也並不是不適用,而且市場中已經有很多 Mobx 解決複雜場景的實踐經驗,比如低程式碼開發平臺Mendix,而且 Mendix 的業務場景與資料分析有很高的相似度,這也從側面證明了 Mobx 與此類低程式碼場景的契合度。

Akita

Akita是來自 Datorama 公司研發團隊的前端狀態管理方案,跟其他幾個競品相比,Akita 的資歷是最淺的。不過 Akita有一個優勢:與 Mobx一樣,Akita 經過了與資料分析類似業務場景的實踐驗證。Datorama 是一家提供資料解決方案的公司,它的業務場景與資料分析有很大的重合度,Akita 已經在 Datorama 的一些產品中得到了實踐和驗證。

Datorama 是 Angular 技術棧,Akita 最初就是為了解決Angular的狀態管理,後期開源後已經從 Angular 技術棧中剝離,對檢視層框架沒有強依賴關係。不過仍然保留了最核心的一點:基於 RxJS。在前端三大框架中,Angular 與 RxJS 的關係最緊密,Akita 最早作為 Angular 的狀態管理方案也對 RxJS 有強依賴,包括資料的封裝也是遵循 RxJS的“萬物皆流”的理念。

下圖是 Akita 的資料流:

圖片

同樣是單向資料流,Akita 有以下幾個角色:

  • Store - 倉庫。Akita 中 Store 分為兩種:Basic Store 和 Entity Store。Basic Store 指的是常規的狀態資料,一般是一個純 JavaScript 物件,沒有額外附加的 API;Entity Store即實體 Store,Akita 將 Entity Store 類比為關係型資料庫的表(table),有一系列配套的 CURD API;
  • Query - 查詢。Akita 限制 Store 中的資料不能被直接讀取,必須藉助一個 Query 物件做橋接(類似 Vuex的 Getter )。與 Store 一樣,Query 也分為 Basic Query 和 Entity Query,兩者的主要區別是 API 的豐富程度,Basic Query 只有基本的條件查詢和全量查詢 API,Entity Query 搭配 Entity Store 使用,有更豐富的 API。另外,如圖中所示,Query 可以巢狀;
  • Component - 元件,即檢視層;
  • Service - 服務。Akita 中的 Service 與 Mobx 的 Action 有些類似,都是為了封裝更新 Store的邏輯,包括非同步操作。

很明顯可以看出 Akita 的設計與關係型資料庫非常接近,說不定設計者是個關係型資料庫死忠粉。

Akita 與 Mobx/Flux 有一個相同的設計:沒有規範 Store 的組織模式。而且由於比較年輕,生態不繁榮,社群並沒有類似 MST 的解決方案,這造成在面對複雜資料場景下沒有既定的正規化可遵循,程式碼的健壯性非常依賴開發者的能力。Akita 的 Entity Store 是一個 class,可以將其他 Store 作為一個 property,以此來實現Store 的巢狀。但 JavaScript 物件之間複雜的引用關係很容易造成 memory leak,這同樣是對開發者自身能力的高要求。

Akita的優點主要有三個:

  1. 足夠簡單,核心概念比 Mobx 和 Flux 還少,對開發者來說,有足夠的定製空間。同時如上文所述,這是一把雙刃劍,對開發者的能力要求很高;
  2. 與關係型資料庫搭配順暢。Akita 的概念設計與關係型資料庫非常相似,這可能也是結合 Darorama 的業務特色,資料分析場景中的資料模型一般是一張二維表,Akita 的實體概念與 table 的搭配非常自然;
  3. 與 RxJS 無縫銜接。資料分析業務場景的事件流操作非常適合用 RxJS,Akita 底層基於 RxJS,這一點是其他競品沒有的優勢。

Akita 的缺點,如上文所述,有以下幾個:

  1. 對開發者的編碼能力要求很高;
  2. 社群不繁榮,生態不夠健全,沒有在市場中得到大範圍實踐驗證;
  3. 比較小眾,遇到問題可交流和參考的空間很小。

小結

綜合以上,各工具的基本情況如下:

是否支援劃分名稱空間 是否支援時間回溯
Redux
Vuex
Mobx 需搭配社群解決方案 需搭配社群解決方案
Akita 無規範無限制,開發者需自行組織程式碼 外掛支援

與檢視框架的繫結程度和改造成本

除了 Vuex 之外,其他幾個工具都沒有限制檢視層框架,只不過 Vue + Vuex 生態比較健全,使用其他狀態管理工具的情況比較少。Redux/Mobx/Akita 目前對 React的支援都很好,要配合 Vue 框架,為了提高編碼效率和維護成本,一般需要一定的改造成本。

是否繫結檢視框架 改造成本 其他
Redux
Vuex - 不適用
Mobx 需搭配社群解決方案
Akita

由於 Vuex 不具備相容多種檢視層框架的能力,所以下文的各維度對比不再統計 Vuex。

當然理論上 Vuex 搭配 React 也不是不可能,但這種操作就太騷了,純粹為了用而用。

效能

資料分析業務場景需要處理的資料量遠大於常規 Web 應用,不過以這種資料的量級還遠未達到需要對工具效能要求非常苛刻的程度,所以對於效能的對比僅做參考。

這裡的意思並不是說工具效能不重要,而是還沒有成為應用程式的效能瓶頸。本文調研的幾個工具都是很成熟的開源產品,已經經受了大量的業務驗證,雖然在效能上存在些許差距,但對應用效能表現的影響非常有限。

除非是涉及海量資料渲染的 web 應用,比如複雜的圖形應用(WebGL/Canvas/SVG),否則工具的效能大概率不會成為應用的效能瓶頸,尤其是比較成熟的、經過大量業務驗證的開源工具。

效能對比

以下參考自社群的兩份效能對比資料,一份是對比 Redux 和 Mobx,一份是對比 Redux 和 Akita。兩份資料都是配合 React 完成。

Redux vs Mobx

圖片

這張表格來自 Mobx 作者 Michel Weststrate 的實驗資料,場景是在包含不同數量級 items 的 todolist 應用上進行增/改操作,分別統計 Redux 和 Mobx 的耗時情況。從表格裡可以看出 Mobx 有明顯的效能優勢。

這份資料僅作參考,一是因為這個實驗是2016年進行的,當時的 Redux和 Mobx 版本比較老舊。另外由於資料來自 Mobx 的作者,有些王婆賣瓜的嫌疑哈哈。不過實驗原始碼是公開的,社群也比較認可。

Redux vs Akita

圖片

這份資料來自Performance Comparison of State Management Solutions in React,場景是生成一個 grid,每次生成100行,每行10列,然後隨機更新1000列的資料。測試進行10次,統計總耗時(單位s)。從上圖中可以明顯看出 Akita 的耗時遠大於 Redux,更新行為的耗時對比尤其明顯。Akita 畢竟比較“年輕”,很多方面趕不上老大哥 Redux 也很正常。

綜合上面的兩份實驗資料,可以得出結論:效能方面 Mobx > Redux > Akita

之所以上述實驗僅做參考,一方面是因為實驗的場景與真實的業務場景差距很大,現實業務中不可能只用 Redux 或 Mobx,往往還需要配合其他解決方案,比如 redux-thunk 或 MST;另一方面是實驗本身並不絕對嚴謹,而且由於是搭配 React 進行,React 本身在不同邏輯場景下的效能表現也會直接影響實驗結果。

不過第二個實驗中涉及的一個點對本次調研工作非常有價值:狀態管理工具的批量(batch)更新能力

批量更新

資料分析是重互動、重通訊的事件密集型業務場景,很大可能在非常短的時間內發生多個事件,如果每個事件都觸發一次渲染流程(包括計算邏輯和渲染行為)的話,不僅會產生非常嚴重且無價值的效能損耗,而且如果涉及網路請求的話還可能產生行為時序混亂進而造成結果的不正確,對業務產生無法預估的負面影響。

所謂批量更新是一個籠統的說法,在不同的工具中有不同的術語表達,不過核心目的是統一的,都是將一定時間內的 store 更新行為進行歸攏,消除中間態只產生最終結果。這種技術手段在前端還有另外一個叫法:防抖(debounce)。

Redux 本身並不具備批量更新能力,需要搭配社群解決方案,比如 redux-batched-subscriberedux-batched-actions

Mobx 有一個底層 API:transaction。這是個函式,作用是將一段時間內的所有更新行為按時序進行批量處理,所有行為處理完成之後才會通知 observer 執行回撥,中間過程中不會產生任何回撥。很明顯 transaction 是借鑑的資料庫中的事務概念。

Akita 與 Redux 一樣,本身同樣不具備批量更新的能力,但是由於它的底層基於 RxJS,可以使用 RxJS 的所有能力,在處理防抖場景下常用sampleTimedebounceTime兩個方法。

學習曲線

學習曲線/5分制 說明
Redux 5 Redux本身的學習難度不高,但Redux自身無法滿足複雜需求,需要額外的社群解決方案,增加了學習成本
Mobx 4 同Redux一樣,需要學習額外的社群解決方案,但成本總量比Redux低
Akita 4 由於Akita是基於RxJS構建,所以除了Akita本身,還需要理解RxJS的一些基本概念

風險與隱患

對於開源工具的選擇需要考慮的風險與隱患主要考慮其社群、生態以及背後團隊的響應及時性

從這三個角度上對比,Redux 作為資歷最老的一個,各方面也是最好的,雖然目前有大量開發者對 Redux 的吐槽,但總的來說 Redux 的位置仍然很穩固,尤其是在 React社群。

Mobx 是近兩三年才逐漸佔據主流,社群和生態也相對比較完善,開發團隊的響應速度也不錯。

Akita 跟前兩者比起來,最大的優勢就是開發團隊響應速度很快,目前處於上升期,開發團隊也比較活躍。但相對來說還是比較小眾,Akita 最早是面向 Angular 的,Angular 的開發者群體規模本身就比 React 和 Vue 小。 Akita 底層的 RxJS 更加小眾(雖然很好用)。目前圍繞 Akita 的複雜業務場景除了 Darorama 公司自己的業務之外,還沒有其他比較好的實踐驗證。

結論

綜合以上所有的調研維度,可以得出以下結論:

Redux Mobx Akita
自身是否完全覆蓋業務需求
是否有成熟的補足方案
支援Vue的改造成本
是否支援批量更新
學習曲線(5分制) 5 4 4
風險與隱患
效能(僅參考)

綜合對比,在 Redux/Mobx/Akita 三者當中,資料分析 SDK 的狀態管理技術選型是:Mobx

參考資料

  1. Flux架構的工作原理
  2. 為 MobX 開啟 Time-Travelling 引擎
  3. Build A View-Framework-Free Data Layer Based on MobX — Integration With Vue
  4. 用mobx構建大型專案的最佳實踐
  5. Becoming fully reactive: an in-depth explanation of MobX;
  6. 現代前端框架響應模型對比: Vue, Mobx, React, Redux
  7. Mobx vs Reactive Stream Libraries
  8. Defining data stores with Mobx;
  9. OOP and RxJS: Managing State in React with Akita

相關文章