源码解读： Vuex 的一些缺陷

众所周知，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 给我最大的感受是：便利，一样的功能有各类不一样语义的逻辑单元处理，职责分离方面作的很是好，若是严格遵循规范的话，确实能很是好的组织代码；接口也很简明易懂，对开发者很是友好。从用户数量、影响力等方面来看，无疑是一个很是伟大的框架。这里提出来的一些观点固然也是见仁见智的，目的不外乎抛砖引玉而已。