源码解读： Vuex 的一些缺陷

怼烎@ 2022-10-05 07:52 345阅读 0赞

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

◆ ◆ ◆  ◆

关注小生，每日都有新收获！

你的在看我当成喜欢