源码深度解读: Vuex 的一些缺陷

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

链接: https://fly63.com/article/detial/10522

为什么使用Vuex

在学习Vuex之前,先了解一下“单向数据流”。Vuex核心就是它的store,其中,有三个重要的部分,State:通过它存取多个组件共享的数据。Mutations:可以改变State中的数据,Actions:提交mutation,可以包含任意异步操作这一步不是必要的。

Vue.js学习,关于Vuex源码解析

Vuex是一个专门为Vue.js框架设计的、用于对Vue.js应用程序进行状态管理的库,它借鉴了Flux、redux的基本思想,将共享的数据抽离到全局,以一个单例存放,同时利用Vue.js的响应式机制来进行高效的状态管理与更新。

vue + vuex + koa2交互实例

主要目的是学会使用koa框架搭建web服务,从而提供一些后端接口,供前端调用。搭建这个环境的目的是: 前端工程师在跟后台工程师商定了接口但还未联调之前,涉及到向后端请求数据的功能能够走前端工程师自己搭建的http路径

vuex 源码:深入 vuex 之 mutation

vuex 规定更改 state 的唯一方法是提交 mutation,主要是为了能用 devtools 追踪状态变化。那么,提交 mutation 除了最主要的更改 state,它还做了其它一些什么事情呢,让我们来一探究竟。

使用Vuex解决Vue中的身份验证

Vuex为Vue.js应用管理状态.。对于应用中所有的组件来说,它被当做中央存储,并用规则确保状态只能以可预见的方式改变。对于经常检查本地存储来说,听起来是个更好的选择?让我们一起来探索下吧。

关于Vuex的action传入多个参数的问题

已知Vuex中通过actions提交mutations要通过context.commit(mutations,object)的方式来完成,然而commit中只能传入两个参数,第一个就是mutations,第二个就是要传入的参数

Vuex 的异步数据更新

更改 Vuex 的 store 中的状态的唯一方法是提交 mutation。Vuex 中的 mutation 非常类似于事件:每个 mutation 都有一个字符串的 事件类型 (type) 和 一个 回调函数 (handler)。这个回调函数就是我们实际进行状态更改的地方,并且它会接受 state 作为第一个参数 mutation 是同步执行,不是异步执行。

vue单页面应用刷新网页后vuex的state数据丢失的解决方案

其实很简单,因为store里的数据是保存在运行内存中的,当页面刷新时,页面会重新加载vue实例,store里面的数据就会被重新赋值。一种是state里的数据全部是通过请求来触发action或mutation来改变

Vuex状态管理,state、getter

首先在 vue 2.0+ 你的vue-cli项目中安装 vuex :然后 在src文件目录下新建一个名为store的文件夹,为方便引入并在store文件夹里新建一个index.js,里面的内容如下:接下来,在 main.js里面引入store,然后再全局注入一下

Vuex新手的理解与使用

开始尝试学习使用vue,是因为此前总是遇到页面逻辑数据与视图的一致性问题.在使用vue之前,我们使用jQuery插件的时候,一桩麻烦事就是既要在每个数据变更后,写代码去改变视图,又要考虑html上各种输入

点击更多...

内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!