原始碼解讀： Vuex 的一些缺陷

Tec發表於2018-04-07
原始碼Vue

眾所周知，Vuex 是 Flux 架構的一種實現。Flux 清晰確立了資料管理場景下各種職能單位，其主要準則有：

  1. 中心化狀態管理
  2. 狀態只能通過專門 突變 單元進行變更
  3. 應用層通過傳送訊號(一般稱 action)，觸發變更

Vuex 也是緊緊圍繞這些準則開發的，通過 store 類提供 Flux 模式的核心功能。在滿足架構的基本要求之外，則進一步設計了許多便利的措施：

  1. 通過“模組化”設計，隔離資料單元
  2. 提供 getter 機制，提高程式碼複用性
  3. 使用 Vue.$watch 方法，實現資料流
  4. 零配置，天然整合進 Vue 環境

網上已經有很多解析的文章，沒必要贅述。本文僅就 中心化、訊號機制、資料流 三個點的實現上展開，討論一下 Vuex 實現上的缺陷。

中心化

在Vuex中，store 整合了所有功能，是對外提供的主要介面，也是Flux模式下的資料管理中心。通過它，Vuex 主要對外提供了：

  • 訊號相關的： dispatch、commit
  • 偵聽器介面： subscribe
  • state 值變更介面(替換state值，不應呼叫)： replaceState
  • state 模型變更介面(建議僅在按需引用場景下使用)：registerModule、unregisterModule
  • 熱更新介面(HMR邏輯，不關注)：hotUpdate

官方實現的 store 非常複雜，耦合了許多邏輯。簡便起見，我們刨除各種旁路邏輯，只關注Flux架構的中心化、訊號控制機制，可以總結出一份非常簡單的實現：

export default class Store {
  constructor(options) {
    this._state = options.state;
    this._mutations = options.mutations;
  }

  get state() {
    return this._state;
  }

  commit(type, payload) {
    this._mutations[type].apply(this, [this.state].concat([...payload]));
  }
}
複製程式碼

這是理解 Vuex 的核心，整份程式碼只有兩個邏輯：

  1. 通過_state屬性實現中心化、自包含資料中心層。
  2. 通過 dispatch 方法，回撥觸發事先註冊的_mutations方法。

這份程式碼有很多問題，舉例來說：

  • 使用簡單物件作為 state
  • 狀態的突變僅僅通過修改state物件屬性值實現
  • 沒有任何有效的機制，防止 state 物件被誤修改

這些設計問題，在Vuex中同樣存在，這與Vue.$watch機制有非常密切的關係(見下文)，個人認為這是極其不嚴謹的。

訊號機制

Vuex 提供了兩個與訊號有關的介面，其原始碼可簡略為：

export default class Store {
  ...
  commit (_type, _payload, _options) {
    ...
    const entry = this._mutations[type]
    this._withCommit(() => {
      entry.forEach(function commitIterator (handler) {
        handler(payload)
      })
    })
    this._subscribers.forEach(sub => sub(mutation, this.state))
    ...
  }

  dispatch (_type, _payload) {
    ...
    const entry = this._actions[type]
    return entry.length > 1
      ? Promise.all(entry.map(handler => handler(payload)))
      : entry[0](payload)
  }
  ...
}
複製程式碼

兩者之間的不同在於：

  1. dispatch 觸發的是 action 回撥；commit 觸發的 mutation 回撥。
  2. dispatch 返回 Promise；commit 無返回值。

這樣的設計意圖，主要還是職責分離，action 單元用於描述 發生了什麼；mutation用於修改資料層狀態state。Vuex 用相似的介面，將兩者放置在相同的地位上，這一層介面設計其實存在弊病：

  1. action、mutation 各自需要一套type體系
  2. 允許應用層繞過action，直接 commit mutation
  3. state 並非 immutable 的，而且在 action 中允許修改 state

雖然確實提升了便利性，但對初學者而言，可能導致如下反模式：

  • 設計了兩套無法正交的type體系
  • 造成“直接提交mutation即可”的假象，破壞了Flux的訊號機制
  • 在 action 中手誤修改了 state ，而沒有友好的跟蹤機制（這一點在getter中特別嚴重）

由於沒有確切有效的機制防止錯誤，在使用Vuex的過程中，需要非常非常警惕；需要嚴謹正確地使用各種職能單元；或者以規範填補設計上的缺陷。

單向資料流

這裡的資料流是指從 Vuex 的 state 到 Vue 元件的props/computed/data 等狀態單元的對映，即如何在元件中獲取state。Vuex 官方推薦使用 mapGetter、mapState 介面實現資料繫結。

mapState

該函式非常簡單，程式碼邏輯可梳理為：

export const mapState = normalizeNamespace((namespace, states) => {
  const res = {}
  ...
  normalizeMap(states).forEach(({ key, val }) => {
    res[key] = function mappedState() {
      ...
      return typeof val === 'function' ?
        val.call(this, state, getters) :
        state[val]
    }
  })
  ...
  return res
})
複製程式碼

mapState 直接讀取 state 物件的屬性。值得注意的一點是，res[key]一般作為函式掛載在外部物件，此時函式的this指向掛載的 Vue 元件。

mapGetter

該函式同樣非常簡單，其程式碼邏輯為：

export const mapGetters = normalizeNamespace((namespace, getters) => {
  const res = {}
  normalizeMap(getters).forEach(({ key, val }) => {

    res[key] = function mappedGetter() {
        ...
        return this.$store.getters[val]
      }
      ...
  })
  return res
})
複製程式碼

mapGetter 訪問的則是元件掛載是 $store 例項的 getters 屬性。

從 state 到 getter

Vuex 的 getter屬性 與 Vue 的computed屬性在各方面的特性都非常相似，實際上，getter 正是基於 computed 實現的。其核心邏輯有：

function resetStoreVM(store, state, hot) {
  ...
  store.getters = {}
  const wrappedGetters = store._wrappedGetters
  const computed = {}
    // 遍歷 getter 配置，生成 computed 屬性
  forEachValue(wrappedGetters, (fn, key) => {
    computed[key] = () => fn(store)
    Object.defineProperty(store.getters, key, {
      // 獲取 vue 例項屬性
      get: () => store._vm[key],
      enumerable: true // for local getters
    })
  })

  // 新建 Vue 例項，專門用於監聽屬性變更
  store._vm = new Vue({
      data: {
        $$state: state
      },
      computed
    })
    ...
}
複製程式碼

從程式碼可以看出，Vuex 將整個 state 物件託管到vue例項的data屬性中，以此換取Vue的整個 watch 機制。而getter屬性正是通過返回例項的 computed 屬性實現的，這種實現方式，不可謂不精妙。問題則是：

  1. Vuex 與 Vue 深度耦合，致使不能遷移到其他環境下使用
  2. Vue 的watch機制是基於屬性讀寫函式實現的，如果直接替換根節點，會導致各種子屬性回撥失效，即不可能實現immutable特性

後語

Vuex 給我最大的感覺是：便利，同樣的功能有各種不同語義的邏輯單元處理，職責分離方面做的非常好，如果嚴格遵循規範的話，確實能非常好的組織程式碼；介面也很簡明易懂，對開發者非常友好。從使用者數量、影響力等方面來看，無疑是一個非常偉大的框架。這裡提出來的一些觀點當然也是見仁見智的，目的不外乎拋磚引玉而已。

相關文章