2017年对于Vue注定是不平凡的一年。凭借着自身简介、轻量、快速等特点,Vue俨然成为最火的前端MVVM开发框架。随着Vue2.0的release,越来越多的项目开始采用Vue作为他们的前端框架。而作为Vue生态中最重要的一环,Vuex渐渐进入大家的视野。
数据管理模式
在正式开始介绍Vuex之前,有必要介绍一下数据管理模式的前世今生。
当你在开发应用程序时,你一定会分解出很多组件进行开发,而各个组件之间想必在逻辑上多少是有关系的。那么组件之间的“通信”,就成了待解决问题。以前我们试图用事件广播来做,但随之而来的问题是,在应用不断的扩展、变化中,事件变得越来越复杂,越来越不可预料,以至于越来越难调试,越来越难追踪错误。这当然不是我们想要的,我们希望应用的各个部分都易维护、可扩展、好调试、能预测。于是数据管理模式应运而生。
图1是最简单的组件关系,b是a的子组件,而c是b的子组件。在我们不引入任何数据管理模式之前,c组件要拿到a组件的数据只能由a先传给b,在由b传给c。如果组件树变得复杂,可想而知这将是一场灾难。看似严谨的父子结构其实严格限制了数据的流动方式。
图2是最简单的数据管理模式,所有数据将统一交给全局store来管理。a和c组件现在直接修改store里的数据,并且通过mapState从store中抓取自己感兴趣的数据到自己的组件中。而b组件,如果它对a、c组件的数据毫无兴趣,则可以做到完全解耦。
随着数据管理的进一步发展和演变,有一种叫单向数据流的东西冒了出来。图3就是一个表示“单向数据流”理念的极简示意。单向数据流要求各组件间的数据走向永远是单向的,可预期的。你不能直接改变 store 中的状态。改变 store 中的状态的唯一途径就是显式地提交Actions。这样使得我们可以方便地跟踪每一个状态的变化,从而让我们能够更好地了解我们的应用。
这次我们的主人公Vuex可以说是单向数据流的最佳实践者。
Vuex是什么?
Vuex 是一个专为 Vue.js 应用程序开发的状态管理模式。Vuex背后的基本思想,就是前面所说的单向数据流。图4就是Vuex实现单向数据流的示意图。
接下来,我们将会更深入地探讨一些核心概念。让我们先从Store概念开始。
Store
每一个 Vuex 应用的核心就是 store(仓库)。“store”基本上就是一个容器,它包含着你的应用中大部分的状态 (state) 。
安装 Vuex 之后,让我们来创建一个最简单的 store。创建过程直截了当——仅需要提供一个初始 state 对象和一些 mutation:
现在,你可以通过 store.state 来获取状态对象,以及通过 store.commit 方法触发状态变更:
由于 store 中的状态是响应式的,在组件中调用 store 中的状态简单到仅需要在计算属性中返回即可。触发变化也仅仅是在组件的 methods 中提交 mutation。
State
Vuex 使用单一状态树——是的,用一个对象就包含了全部的应用层级状态。至此它便作为一个“唯一数据源 (SSOT)”而存在。单一状态树让我们能够直接地定位任一特定的状态片段,在调试的过程中也能轻易地取得整个当前应用状态的快照。
那么我们如何在 Vue 组件中展示状态呢?由于 Vuex 的状态存储是响应式的,从 store 实例中读取状态最简单的方法就是在计算属性中返回某个状态:
Getter
有时候我们需要从 store 中的 state 中派生出一些状态,例如对列表进行过滤并计数:
如果有多个组件需要用到此属性,我们要么复制这个函数,或者抽取到一个共享函数然后在多处导入它——无论哪种方式都不是很理想。
Vuex 允许我们在 store 中定义“getter”(可以认为是 store 的计算属性)。就像计算属性一样,getter 的返回值会根据它的依赖被缓存起来,且只有当它的依赖值发生了改变才会被重新计算。
Getter 会暴露为 store.getters 对象:
Mutation
Vuex 的 store 中的状态的唯一方法是提交 mutation。Vuex 中的 mutation 非常类似于事件:每个 mutation 都有一个字符串的 事件类型 (type) 和 一个 回调函数(handler)。这个回调函数就是我们实际进行状态更改的地方,并且它会接受 state 作为第一个参数,payload作为第二个参数(额外的参数):
一条重要的原则就是要记住 mutation 必须是同步函数。
Action
Action 类似于 mutation,不同在于:
1.Action 提交的是 mutation,而不是直接变更状态。
2.Action 可以包含任意异步操作。
让我们来注册一个简单的 action:
Action 函数接受一个与 store 实例具有相同方法和属性的 context 对象,因此你可以调用 context.commit 提交一个 mutation,或者通过 context.state 和 context.getters 来获取 state 和 getters。
我们可以在 action 内部执行异步操作:
今天的目标
这是一个记忆小游戏,来自leftstick的vue-memory-game,github地址:https://github.com/leftstick/vue-memory-game。今天我们就这个小游戏来详细讲解下vuex的实现。
组件分解
我们根据分解图,先把要实现的组件挨个儿列出来:
目录结构
让我们聚焦红框中关于Vuex的这一部分。接下来我们将结合Card.vue和Chessboard.vue这两个核心组件进行。
store/index.js
store的创建并没有什么复杂的逻辑,而state就是这个项目需要维护的整个数据。初始化cards的结构我简要的整合了一下:
你可以选择初始化store的时候直接带进去,也可以像作者一样从入口处reset一遍数据,这里就不详细展开了。
Chessboard.vue
Card.vue
我在源码上增加了一些注释,方便大家理解。
mapGetter和mapActions只是一些辅助函数,可以减少一些this.$store和dispatch action之类比较重复的代码,这些辅助函数可以帮助vuex应用的更加简便。
相比与这些可有可无的噱头,我们更关心卡片被点击的时候发生了什么?this.flipCard()后数据流向了哪里?
数据流动
当卡片被点击时,vue component 实则 dispatch出了一个action,而我们的数据,作为载荷(参数),也只能随波逐流了。
他首先来到了第一站:actions,然而actions却说你不需要什么异步处理,可以去下一站了。(如果没有异步操作,其实可以少走一站)
actions处理函数
数据没有灰心,很快他就来到了mutaions。
mutaions欣喜若狂:你在这等着,待我处理好了你再上路。
mutations处理函数
不一会,数据就改头换面了,但如何告诉vue components我发生变化了呢?迷茫的数据找到了getter。getter哈哈大笑:你在我这的状态存储是响应式的,只要vue components在计算属性中应用了你,他们就能第一时间知道你的状态变更哦。
getter生成计算属性(如果没有派生出其他状态,可以不用getter)
components状态更新
结尾
通过这个记忆小游戏,希望大家对Vuex有一个基本的理解。如果你熟悉Redux的话,掌握Vuex应该不难,因为Vuex和Redux基本思想是一致的,实现方式也是大同小异。但Vuex只适用于Vue,没有Redux那么泛用罢了。
网易云大礼包:https://www.163yun.com/gift
本文来自网易实践者社区,经作者刘凌阳授权发布