大纲预览
- 状态与组件的诞生
- 需要状态管理吗？
- 单一数据源
- 状态更新方式
- 异步更新？
- 状态模块化
- 模块化的槽点
- 下一步
状态与组件的诞生
自三大框架诞生起，它们共有的两个能力彻底暴击了 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')// 修改状态
}
}
}
这样按照模块导入，查询和使用都比较清晰。
网友评论