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