大纲预览

• 状态与组件的诞生
• 需要状态管理吗？
• 单一数据源
• 状态更新方式
• 异步更新？
• 状态模块化
• 模块化的槽点
• 下一步

状态与组件的诞生

自三大框架诞生起，它们共有的两个能力彻底暴击了 Jquery。这两个能力分别是：

1.数据驱动视图
2.组件化

数据驱动视图，使我们告别了只能依靠操作 DOM 更新页面的时代。我们不再需要每次更新页面时，通过层层 find 找到 DOM 然后修改它的属性和内容，可以通过操作数据来实现这些事情。

当然了在我们前端的眼里，数据基本可以理解为存储各种数据类型的 变量。在 数据驱动 这个概念出现之后，一部分变量也被赋予了特殊的含义。

首先是普通变量，和 JQ 时代没差，仅用来存储数据。除此之外还有一类变量，它们有响应式的作用，这些变量与视图绑定，当变量改变时，绑定了这些变量的视图也会触发对应的更新，这类变量我称之为状态变量。

所谓数据驱动视图，严格说就是状态变量在驱动视图。随着 Vue，React 的大力普及之下，前端开发们的工作重心逐渐从操作 DOM 转移到了操作数据，状态变量成为了核心。

状态变量，现在大家似乎更愿意称之为状态。我们经常词不离口的状态，状态管理，其实这个状态就是指状态变量。下文提到的状态同样也是指状态变量。

有了状态之后，组件也来了。

JQ 时代的前端一个页面就是一个 html，没有“组件”的概念，对于页面中的公共部分，想要优雅的实现复用简直不要太难。所幸三大框架带来了非常成熟的组件设计，可以很容易的抽取一个 DOM 片段作为组件，而且组件内部可以维护自己的状态，独立性更高。

组件的一个重要特性，就是内部的这些状态是对外隔离的。父组件无法访问到子组件内部的状态，但是子组件可以访问父组件显示传过来的状态（Props），并且根据变化自动响应。

这个特性可以理解为状态被模块化了。这样的好处是，不需要考虑当前设置的状态会影响到其他组件。当然了组件状态彻底隔离也是不现实的，必然会有多个组件共享状态的需求，这种情况的方案就是将状态提取到离这些组件最近的父组件，通过 Props 向下传递。

上述共享状态的方案，在通常情况下是没有问题的，也是一种官方建议的最佳实践。

但是如果你的页面复杂，你会发现还是有力不从心的地方。比如：

• 组件层级太深，需要共享状态，此时状态要层层传递。
• 子组件更新一个状态，可能有多个父组件，兄弟组件共用，实现困难。
  这种情况下继续使用 “提取状态到父组件” 的方法你会发现很复杂。而且随着组件增多，嵌套层级加深，这个复杂度也越来越高。因为关联的状态多，传递复杂，很容易出现像某个组件莫名其妙的更新，某个组件死活不更新这样的问题，异常排查也会困难重重。

鉴于此，我们需要一个更优雅到方案，专门去处理这种复杂状况下的状态。

需要状态管理吗？

上一节我们说到，随着页面的复杂，我们在跨组件共享状态的实现上遇到了棘手的问题。

那么有没有解决方案呢？当然有的，得益于社区大佬们的努力，方案还不止一个。但是这些方案都有一个共同的名字，就是我们在两年前讨论非常激烈的 ——— 状态管理。

状态管理，其实可以理解为全局状态管理，这里的状态不同于组件内部的状态，它是独立于组件单独维护的，然后再通过某种方式与需要该状态的组件关联起来。

状态管理各有各的实现方案。Vue 有 Vuex，React 有 Redux，Mobx，当然还有其他方案。但是它们解决的都是一个问题，就是跨组件状态共享的问题。

我记得前两年因为 “状态管理” 这个概念的火热，好像成了应用开发不可或缺的一部分。以 Vue 为例，创建一个项目必然会引入 Vuex 做状态管理。但是很多人不知道为什么用，什么时候用，怎么用状态管理，只是盲目跟风，于是后来出现了非常多滥用状态管理的例子。

看到这里，你应该知道状态管理不是必须的。它为什么出现，以及它要解决什么问题，上面基本都说明白了。如果你还没明白，请暂停，从开头再读一遍。不要觉得一个技术方案诞生的背景不重要，如果你不明白它的出现是为了解决什么问题，那么你就无法真正发挥它的作用。

Redux 作者有一句名言：如果你不知道是否需要 Redux（状态管理），那就是不需要它。

好了，如果你在用状态管理，或需要使用状态管理帮你解决问题，那我们继续往下看。

Vuex

Vue 在国内的应用非常广泛，尤其是中小团队，因此大多人接触到的第一个状态管理方案应该就是 Vuex。

那么 Vuex 是如何解决跨组件状态共享的问题的呢？我们一起来探索一下。

创建 store

我们上面说到，对于一般的组件共享状态，官方建议“提取状态到最近的父组件”。Vuex 则是更高一步，将所有状态提取到了根组件，这样任何组件都能访问到。

也许你会问：这样做不是把状态暴露到全局了吗？不就彻底消除模块化的优势了吗？

其实不然。Vuex 这么做的主要目的是为了让所有组件都可以访问到这些状态，彻底避免子组件状态访问不了的情况。Vuex 把所有状态数据都放在一个对象上，遵循单一数据源的原则。但是这并不代表状态是堆砌的，Vuex 在这颗单一状态树上实现了自己的模块化方案。

别急，我们一步步来，先看看如何使用 Vuex。

Vuex 是作为 Vue 的插件存在的，首先 npm 安装：

 $ npm install --save vuex

安装之后，我们新建 src/store 文件夹，在这里放所有 Vuex 相关的代码。

新建 index.js 并写入如下代码。这段代码主要的作用就是用 Vue.use 方法加载 Vuex 这个插件，然后将配置好的 Vuex.Store 实例导出。

import Vue from 'vue'
import Vuex from 'vuex'
// 安装插件
Vue.use(Vuex)

export default new Vuex.Store({
 state: {},
 mutations: {},
 actions: {},
 modules: {}
})  

上面导出的实例我们通常称之为 store。一个 store 中包含了存储的状态（state）和修改状态的函数（mutation）等，所有状态和相关操作都在这里定义。

最后一步，在入口文件将上面导出的 store 实例挂载到 Vue 上：

import store from './store'
new Vue({
 el: '#app',
 store: store
})

注意：挂载这一步不是必须的。挂载这一步的作用只是为了方便在 .vue 组件中通过 this.$store 访问我们导出的 store 实例。如果不挂载，直接导入使用也是一样的。

单一数据源（state）

上一步我们用构造函数 Vuex.Store 创建了 store 实例，大家至少知道该怎么用 Vuex 了。这一步我们来看看 Vuex.Store 构造函数的具体配置。

首先是 state 配置，他的值是一个对象，用来存储状态。Vuex 使用 单一状态树 原则，将所有的状态都放在这个对象上，便于后续的状态定位和调试。

比如说我们有一个初始状态 app_version 表示版本，如下：

new Vuex.Store({
 state: {
   app_version: '0.1.1'
 }
}

现在要在组件中获取，可以这样：

this.$store.state.app_version

但这并不是唯一的获取方式，也可以这样：

import store from '@/store' // @ 表示 src 目录
store.state.app_version

为什么要强调这一点呢？因为很多小伙伴以为 Vuex 只能通过 this.$store 操作。到了非组件内，比如在请求函数中要设置某一个 Vuex 的状态，就不知道该怎么办了。

事实上组件中获取状态还有更优雅的方法，比如 mapState 函数，它让获取多状态变得更简单。

import { mapState } from 'vuex'
export default {
computed: {
... // 其他计算属性
...mapState({
  version: state => state.app_version
  })
}
}

状态更新方式（mutation）

Vuex 中的状态与组件中的状态不同，不能直接用 state.app_version='xx' 这种方式修改。Vuex 规定修改状态的唯一方法是提交 mutation。

Mutation 是一个函数，第一个参数为 state，它的作用就是更改 state 的状态。

下面定义一个名叫 increment 的 mutation，在函数内更新 count 这个状态：

new Vuex.Store({
 state: {
   count: 1
 },
 mutations: {
 increment(state, count) {
  // 变更状态
  state.count += count
 }
 }
})

然后在 .vue 组件中触发 increment：

 this.$store.commit('increment', 2)

这样绑定了 count 的视图就会自动更新。

同步更新

虽然 mutation 是更新状态的唯一方式，但实际上它还有一个限制：必须是同步更新。

为什么必须是同步更新？因为在开发过程中，我们常常会追踪状态的变化。常用的手段就是在浏览器控制台中调试。而在 mutation 中使用异步更新状态，虽然也会使状态正常更新，但是会导致开发者工具有时无法追踪到状态的变化，调试起来就会很困难。

再有 Vuex 给 mutation 的定位就是更改状态，只是更改状态，别的不要参与。所谓专人干专事儿，这样也帮助我们避免把更改状态和自己的业务逻辑混起来，同时也规范了函数功能。

那如果确实需要异步更新，该怎么办呢？

异步更新

异步更新状态是一个非常常见的场景，比如接口请求回来的数据要存储，那就是异步更新。

Vuex 提供了 action 用于异步更新状态。与 mutation 不同的是，action 不直接更新状态，而是通过触发 mutation 间接更新状态。因此即便使用 action 也不违背 “修改状态的唯一方法是提交 mutation” 的原则。

Action 允许在实际更新状态前做一些副作用的操作，比如上面说的异步，还有数据处理，按条件提交不同的 mutation 等等。看一个例子：

 new Vuex.Store({
 state: {
  count: 1
 },
 mutations: {
add(state) {
  state.count++
},
reduce(state) {
  state.count--
   }
 },
 actions: {
increment(context, data) {
  axios.get('**').then(res => {
    if (data.iscan) {
      context.commit('add')
    } else {
      context.commit('reduce')
    }
  })
  }
 }
})

在组件中触发 action：

 this.$store.dispatch('increment', { iscan: true })

这些就是 action 的使用方法。其实 action 最主要的作用就是请求接口，拿到需要的数据，然后触发 mutation 修改状态。

其实这一步在组件中也可以实现。我看过一些方案，常见的是在组件内写一个请求方法，当请求成功，直接通过 this.$store.commit 方法触发 mutation 来更新状态，完全用不到 action。

难道 action 可有可无吗？

也不是，在特定场景下确实需要 action 的，这个会在下一篇说。

状态模块化（module）

前面讲过，Vuex 是单一状态树，所有状态存放在一个对象上。同时 Vuex 有自己的模块化方案 ，可以避免状态堆砌到一起，变的臃肿。

Vuex 允许我们将 store 分割成模块（module），每个模块拥有自己的 state、mutation、action。虽然状态注册在根组件，但是支持模块分割，相当于做到了与页面组件平级的“状态组件”。

为了区分，我们将被分割的模块称为子模块，暴露在全局的称为全局模块。

我们来看基础用法：

new Vuex.Store({
 modules: {
user: {
  state: {
    uname: 'ruims'
  },
  mutation: {
    setName(state, name) {
      state.name = name
    }
  }
  }
 }
})

上面定义了 user 模块，包含了一个 state 和一个 mutation。在组件中使用方法如下：

// 访问状态
 this.$store.state.user.uname
// 更新状态
 this.$store.commit('setName')

大家发现了，访问子模块的 state 要通过 this.$store.state.[模块名称] 这种方式去访问，触发 mutation 则与全局模块一样，没有区别。

action 与 mutation 原理一致，不细说。

命名空间

上面说到，子模块触发 mutation 和 action 与全局模块一致，那么假设全局模块和子模块中都有一个名为 setName 的 mutation。在组件中触发，哪个 mutation 会执行呢？

经过试验，都会执行。官方的说法是：为了多个模块能够对同一 mutation 或 action 作出响应。

其实官方做的这个兼容，我一直没遇到实际的应用场景，反而因为同名 mutation 导致误触发带来了不少的麻烦。可能官方也意识到了这个问题，索引后来也为 mutation 和 action 做了模块处理方案。

这个方案，就是命名空间。

命名空间也很简单，在子模块中加一个 namespaced: true 的配置即可开启，如：

new Vuex.Store({
 modules: {
 user: {
   namespaced: true,
   state: {}
  }
 }
})

开启命名空间后，触发 mutation 就变成了：

 this.$store.commit('user/setName')

可见提交参数由 '[mutation]' 变成了 '[模块名称]/[mutation]'。

模块化的槽点

上面我们介绍了 Vuex 的模块化方案，将单一状态树 store 分割成多个 module，各自负责本模块状态的存储和更新。

模块化是必要的，但是这个模块的方案，用起来总觉得有点别扭。

比如，总体的设计是将 store 先分模块，模块下在包含 state，mutation，action。

那么按照正常理解，访问 user 模块下 state 应该是这样的：

 this.$store.user.state.uname

但是实际 API 却是这样的：

this.$store.state.user.uname

这个 API 仿佛是在 state 中又各自分了模块。我没看过源码，但从使用体验上来说，这是别扭一。

除 state 外，mutation，action 默认注册在全局的设计，也很别扭。

首先，官方说的多个模块对同一 mutation 或 action 作出响应，这个功能暂无找到应用场景。并且未配 namespace 时还要保证命名唯一，否则会导致误触发。

其次，用 namespace 后，触发 mutation 是这样的：

  this.$store.commit('user/setName')

这个明显是将参数单独处理了，为什么不是这样：

this.$store.user.commit('setName')

总体感受就是 Vuex 模块化做的还不够彻底。

为什么吐槽

上面说的槽点，并不是为了吐槽而吐槽。主要是感觉还有优化空间。

比如 this.$store.commit 函数可以触发任何 mutation 来更改状态。如果一个组件复杂，需要操作多个子模块的状态，那么就很难快速的找出当前组件操作了哪些子模块，当然也不好做权限规定。

我希望的是，比如在 A 组件要用到 b, c 两个子模块的状态，不允许操作其他子模块，那么就可以先将要用到模块导入，比如这样写：

import { a, b } from this.$store
export default {
 methods: {
  test() {
  alert(a.state.uname) // 访问状态
   a.commit('setName')// 修改状态
  }
 }
}

这样按照模块导入，查询和使用都比较清晰。