挑战全网最幽默的Vuex系列教程:第一讲 Vuex到底是什么鬼
先说两句
官方已经有教程了,为什么还要写这个教程呢?说实话,还真不是我闲着蛋疼,官方的教程真的是太官方了,对于刚入门 vuex 的童鞋来说,想必看官方的教程,很多地方就如同看圣经一样,比如「欧玛尼玛尼牙」,所有的字都认识,就是不知道说些什么玩意,不信,你可以。
当然,对于大神级别一看就懂的,那就不用说了,肯定是看官方的更权威。还有,如果对 flux、redux、the elm architecture 比较熟悉的话,也可以移步官方,因为官方也说了,vuex 的套路基本上都是从那边吸取整合后,过渡而来的,只不过,vuex 只钟情于 vue.js 罢了。
我之所以写这个教程,主要是因为自己刚刚开始和 vuex 打交道的时候,痛过了、苦过了、伤过了,所以痛定思痛,为了能让自己更好的驾驭 vuex,也为了不让新来的童鞋们被 vuex 调戏过后无处诉苦,所以方才决定把官方的这些抽象的文字和概念,用连你身后的鼓励师小姐姐都能看懂的语言,分享出来,助你在前端的道路上越走越顺,顺利的找到一份有鼓励师陪伴的工作。
再说一句
vuex 是 vue.js 的座驾,所以,如果还不懂vue.js 的话,那还是先把 vue.js 勾搭上了再带过来一起坐坐吧。当然,既然能够溜达到这里,想必跟 vue.js 起码也已经是朋友了吧。
有点啰嗦,不要嫌弃,写教程也需要有点前戏,毕竟是第一次。
安装
关于 vuex 的具体安装,就不在这里说了,这个官方还是比较清晰的,。但是需要注意两点:
-
在一个模块化的打包系统中,您必须显式地通过 vue.use() 来安装 vuex,比如:
import vue from 'vue' import vuex from 'vuex' vue.use(vuex) // 必须调用此函数来注入 vuex
-
当使用全局 script 标签引用 vuex 时,就不用那么麻烦了,直接引用进来就好,但要注意引用的先后顺序,如下:
// 在 vue 之后引入 vuex 会进行自动安装 <script src="/path/to/vue.js"></script> <script src="/path/to/vuex.js"></script>
虽然 script 的方式看起来比较自动化,但是接触得多了,你就会明白模块化其实才是我们的最佳姿势。
揭开 vuex 的神秘面纱
拿到一个工具,我们第一时间需要弄明白的,就是这个工具到底能够帮助我们解决什么问题。比如锤子,砸得了鸡蛋打得了电话,比如苹果,不但能吃还能玩。那么 vuex 呢,如果把 vue.js 比喻成路人(走路的人)的话,那么 vuex 就是他的桑塔纳,如果他想去隔壁买包烟,那走过去就行了,开个车过去反而是一种负担,但是如果他想去几十公里的学校采花,那桑塔纳就得派上用场了,不然等他走过去,可能花儿都谢了。
当然,类比只是为了告诉我们 vuex 的价值所在,那么在具体在实际的应用中,它能干什么?什么时候才需要翻它的牌呢?
我们先来看一段官方代码:
new vue({ // state 数据源 data () { return { count: 0 } }, // view 视图 template: ` <div>{{ count }}</div> `, // actions 事件 methods: { increment () { this.count++ } } })
这是一个很简单的增长型计数功能页面,和 vue.js 有一腿的,应该秒懂。通过事件 increment
,实现 count
增长,然后渲染到界面上去。
这种方式其实就跟走路买烟一样,属于短途效应,官方称作为「单向数据流」,很好理解。
但是,情况变了,现在有两个页面 a 和 b,还有以下两个要求:
- 要求它们都能对 count 进行操控。
- 要求 a 修改了 count 后,b 要第一时间知道,b 修改后,a 也要第一时间知道。
怎么办?稍微有点开发经验的,就能够很容易的想到,把数据源 count 剥离开来,用一个全局变量或者全局单例的模式进行管理,这样不就在任何页面都可以很容易的取到这个状态了。
是啊,这尼玛就是 vuex 背后的思想啊,它干的就是这个事情。是不是有一种被 vuex 这个高大上的名号所坑害的感觉,不就是全局模型吗,不用它也同样可能搞定嘛。
是的,也可以搞定,就像没有桑塔纳,你也可以去学校看花一样,只是经历的过程不一样了。
vuex 的目的是为了管理共享状态,为了达到这个目的,它制定了一系列的规则,比如修改数据源 state、触发 actions 等等,都需要遵循它的规则,以此来达到让项目结构更加清晰且易于维护的目的。
那么我们再来看看官方的描述:
vuex 是一个专为 vue.js 应用程序开发的状态管理模式。它采用集中式存储管理应用的所有组件的状态,并以相应的规则保证状态以一种可预测的方式发生变化。
有没有瞬间清晰多了。
什么时候翻 vuex 的牌
其实了解了 vuex 要干的活以后,什么时候翻牌,那就容易选择得多了。就像前面的类比一样,去隔壁买包烟,你还开个桑塔纳,找停车位的时间,烟都抽完了。
所以,我们要根据项目的需要,来衡量短期和长期的效益,如果不打算开发大型的单页应用,那 vuex 可能还是你的一个负担。对于一些不大不小的项目,自己又懒得走,开车又觉得麻烦,那你骑个共享单车过去也行嘛。
这里的共享单车指代的是官方中的一个简单的 store 模式,其实就是一个单纯的全局对象。
关于全局对象和 vuex 之间的区别,官方写得还是比较通俗易懂的:
vuex 和单纯的全局对象有以下两点不同:
- vuex 的状态存储是响应式的。当 vue 组件从 store 中读取状态的时候,若 store 中的状态发生变化,那么相应的组件也会相应地得到高效更新。
- 你不能直接改变 store 中的状态。改变 store 中状态的唯一途径就是显式地提交 (commit) mutation。这样使得我们可以方便地跟踪每一个状态的变化,从而让我们能够实现一些工具帮助我们更好地了解我们的应用。
简单示例
// 如果在模块化构建系统中,请确保在开头调用了 vue.use(vuex) const store = new vuex.store({ state: { count: 0 }, mutations: { increment (state) { state.count++ } } })
每一个 vuex 应用的核心就是 store(仓库)。store 基本上就是一个容器,它包含着你的应用中大部分的状态 (state)。
注意:如果 mutations 不知道是什么,没关系,后面会专门讲解到,可以单纯的理解为只能用它里面的方法来修改 state 中的数据。
store.commit('increment') // 调用 mutations 中的方法 console.log(store.state.count) // -> 1
为什么要这样设计的,官方也给出了具体的原因:
我们通过提交 mutation 的方式,而非直接改变 store.state.count,是因为我们想要更明确地追踪到状态的变化。这个简单的约定能够让你的意图更加明显,这样你在阅读代码的时候能更容易地解读应用内部的状态改变。此外,这样也让我们有机会去实现一些能记录每次状态改变,保存状态快照的调试工具。有了它,我们甚至可以实现如时间穿梭般的调试体验。
由于 store 中的状态是响应式的,在组件中调用 store 中的状态简单到仅需要在计算属性中返回即可。触发变化也仅仅是在组件的 methods 中提交 mutation。
如果最后一句话没看懂,没关系,下一章马上就会讲到。
ps
来点正经的,到这里,第一篇其实就已经写完了,当然,这里的内容都是我看了官方的教程后,自己的一个理解,如果有理解不到位的地方,欢迎拍砖。
转载声明:
作者:大宏说
原文链接:
后记
以上就是胡哥今天给大家分享的内容,喜欢的小伙伴记得点赞
、收藏
呦,关注胡哥有话说,学习前端不迷路,欢迎多多留言交流...
胡哥有话说,一个有技术,有情怀的胡哥!现任京东前端攻城狮一枚。
胡哥有话说,专注于大前端技术领域,分享前端系统架构,框架实现原理,最新最高效的技术实践!