哈尔滨松北区建设局网站,唐山企业网站模板建站,河北住房和城乡建设厅,校友网站建设我看了vuex3和vuex4的源码也输出了文章#xff0c;看到这篇时#xff0c;vuex还有缺陷#xff1f;看了看确实是好文#xff0c;不愧是大佬写的。文章不算长#xff0c;推荐给大家看看。点击下方卡片关注我、加个星标学习源码整体架构系列、年度总结、JS基础系列众所周知看到这篇时vuex还有缺陷看了看确实是好文不愧是大佬写的。文章不算长推荐给大家看看。点击下方卡片关注我、加个星标学习源码整体架构系列、年度总结、JS基础系列众所周知Vuex 是 Flux 架构的一种实现。Flux 清晰确立了数据管理场景下各种职能单位其主要准则有中心化状态管理状态只能通过专门 突变 单元进行变更应用层通过发送信号(一般称 action)触发变更Vuex 也是紧紧围绕这些准则开发的通过 store 类提供 Flux 模式的核心功能。在满足架构的基本要求之外则进一步设计了许多便利的措施通过“模块化”设计隔离数据单元提供 getter 机制提高代码复用性使用 Vue.$watch 方法实现数据流零配置天然整合进 Vue 环境网上已经有很多解析的文章没必要赘述。本文仅就 中心化、信号机制、数据流 三个点的实现上展开讨论一下 Vuex 实现上的缺陷。中心化在Vuex中store 整合了所有功能是对外提供的主要接口也是Flux模式下的数据管理中心。通过它Vuex 主要对外提供了信号相关的 dispatch、commit侦听器接口 subscribestate 值变更接口(替换state值不应调用) replaceStatestate 模型变更接口(建议仅在按需引用场景下使用)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 的核心整份代码只有两个逻辑通过_state属性实现中心化、自包含数据中心层。通过 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)}...
}
两者之间的不同在于dispatch 触发的是 action 回调commit 触发的 mutation 回调。dispatch 返回 Promisecommit 无返回值。这样的设计意图主要还是职责分离action 单元用于描述 发生了什么mutation用于修改数据层状态state。Vuex 用相似的接口将两者放置在相同的地位上这一层接口设计其实存在弊病action、mutation 各自需要一套type体系允许应用层绕过action直接 commit mutationstate 并非 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 到 getterVuex 的 getter属性 与 Vue 的computed属性在各方面的特性都非常相似实际上getter 正是基于 computed 实现的。其核心逻辑有function resetStoreVM(store, state, hot) {...store.getters {}const wrappedGetters store._wrappedGettersconst 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 属性实现的这种实现方式不可谓不精妙。问题则是Vuex 与 Vue 深度耦合致使不能迁移到其他环境下使用Vue 的watch机制是基于属性读写函数实现的如果直接替换根节点会导致各种子属性回调失效即不可能实现immutable特性后语Vuex 给我最大的感觉是便利同样的功能有各种不同语义的逻辑单元处理职责分离方面做的非常好如果严格遵循规范的话确实能非常好的组织代码接口也很简明易懂对开发者非常友好。从用户数量、影响力等方面来看无疑是一个非常伟大的框架。这里提出来的一些观点当然也是见仁见智的目的不外乎抛砖引玉而已。最近组建了一个湖南人的前端交流群如果你是湖南人可以加我微信 ruochuan12 拉你进群。今日话题湖南长沙互联网据说发展还可以所以建一个湖南人的前端交流群欢迎湖南人进群。欢迎分享、收藏、点赞、在看我的公众号文章~一个愿景是帮助5年内前端人走向前列的公众号可加我个人微信 ruochuan12长期交流学习推荐阅读我在阿里招前端我该怎么帮你可进模拟面试群2年前端经验做的项目没技术含量怎么办点击上方卡片关注我、加个星标················· 若川简介 ·················你好我是若川毕业于江西高校。现在是一名前端开发“工程师”。写有《学习源码整体架构系列》多篇在知乎、掘金收获超百万阅读。从2014年起每年都会写一篇年度总结已经写了7篇点击查看年度总结。同时活跃在知乎若川掘金若川。致力于分享前端开发经验愿景帮助5年内前端人走向前列。
