前端项目,看我在这里管理全局后台初始化的数据,就问你飒不飒?
Posted webmote
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了前端项目,看我在这里管理全局后台初始化的数据,就问你飒不飒?相关的知识,希望对你有一定的参考价值。
- 📢博客主页: https://blog.csdn.net/codeex
- 📢欢迎点赞 :👍 收藏 ⭐留言 📝 如有错误敬请指正,赐人玫瑰,手留余香!
- 📢本文作者:由webmote 原创,首发于 CSDN🙉
- 📢作者格言: 生活在于折腾,当你不折腾生活时,生活就开始折腾你,让我们一起加油!💪💪💪
🎏 1. 大道起源
俗话说:一生二、二生三、三生万物。
在一个混沌初开的世界,总需要预留一个初始过程,就如女娲娘娘需要🔥冶炼石头一样🎎。搭建一个前端项目, 我们也需要初始化一些类库,组织组织脚手架,配置配置webpack等等。
当然,在这里,我们关心的是后台的某些数据,需要初始化🍀🍀🍀🍀。
有哪些花花草草🌼,需要初始化施肥呢?
🍄 系统全局配置,全局配置一般来自于后台数据库
🍄 系统词典列表,一般也来自后台数据库
🍄 某些国际化词典资源,大部分国际化直接来自前台,但总有某些例外的家伙~~
🎏 2. 初始化的优点
从第1小节,我们可以看到,需要初始化的资源,在每个模块被使用的几率,还是很高的。
如果没有初始化的帮忙,每次模块的created
,都需要调用后台api,获取数据。
因此从这能看出来,其优点🌷如下:
- 入口统一
- 数据保持
- 全局使用
- 减少api调用次数
- 减轻后台压力
- 降低使用复杂度
🎏 3. 初始化的缺点
话⚡说,天下大势,分久必合,合久必分,历史的事情都是在循环往复中曲折前进。
既然没有必然的事情,那我们就来看看引入了初始化,会带来哪些麻烦🥀?
- 数据需要持久化,初始化后的数据需要存储在vue属性、vuex、cookie、localStorage等任一前端存储内
- 数据不一致性,持久化数据后,必然会带来数据的不一致;例如,✍用户修改了词典
针对这些缺点,我们需要为引入的初始化做额外多余的工作🏃🏃🏃。
- 持久化是前端的老本行了,可选择余地很大;
- 不一致性可以使用2个思路进行。
👉不管它,用户修改了自己刷新整体页面重新初始化后生效;
👉找到时机,哪里修改,哪里负责重新激发数据的初始化;
🎏 4. 三分钟体验区
下面是三分钟体验区,欢迎进入! 👬👬👬手拉手,往前走,一步一步过小坑~~
🚧 场景:某后台管理程序,有1个词典
和1个配置
接口很符合我们的初始化场景,请求改造。
⛱ 改造三分钟,请看下面步骤。
🏒4.1 定义存储Vuex
因为是后台管理程序,其大概率需要存储其他数据,因此,我们选择了稍微重量级的VueX作为存储的方案。
我们采用Vuex作为初始化数据的持久化存储区,并利用Cookie缓存数据,以便获取不到后台Api是,暂时用来撑场子。
import Cookies from 'js-cookie'
# 定义 dict 和 appConfig 作为 存储路径
const state = {
dict: Cookies.get('dict') || [],
appConfig: Cookies.get('config') || {},
}
增加mutations 和 actions,以下是常规操作。
const mutations = {
SET_DICT: (state, dict) => {
if (dict) {
state.dict = dict
Cookies.set('dict', dict)
}
},
SET_APP_CONFIG: (state, appConfig) => {
if (appConfig) {
state.appConfig = appConfig
Cookies.set('config', appConfig)
}
},
}
const actions = {
setDict({ commit }, dict) {
commit('SET_DICT', dict)
},
setAppConfig({ commit }, config) {
commit('SET_APP_CONFIG', config)
},
}
export default {
namespaced: true,
state,
mutations,
actions,
}
🏒4.2 定义Api调用类
集中力量办大事,是我国的特色! 做人处事,当学我党的优秀作风! 🌌🌌🌌 我们的目标是,星辰大海~~
/**
* @file 基础数据读取:【挂在vue上,其他组件直接使用】
* @author webmote
* @date 2021.06
*/
import store from '@/store'
const GetDictCategory = function(vm) {
vm.$http.fetch({
url: '/tools/GetDictCategory',
method: 'get',
}).then(data => {
// 使用store存储数据
store.dispatch('app/setDict', data)
})
}
const GetConfig = function(vm) {
vm.$http.fetch({
url: '/cfg/GetCfgList',
method: 'get',
}).then(data => {
//这里,需要你根据自己的后台api进行适当调整了~~~
const dict = {}
if (data) {
for (let i = 0; i < data.length; i++) {
const item = data[i]
dict[item.cfgName] = item.cfgValue
}
}
console.log(dict)
store.dispatch('app/setAppConfig', dict)
})
}
const getData = function(vm) {
GetDictCategory(vm)
GetConfig(vm)
}
export default {
getData,
}
🏒4.3 初始化时机
那我们应该在啥时候初始化呢? 🤔🤔🤔思考1分钟,再往下看。
你一犹豫、一担忧,机会稍纵即逝,就是Loser;当机立断者,就成李奇威、巴顿、马云。
机遇稍纵即逝,可遇而不可求。所以当机遇到来时,要果断地抓住机遇;如果犹豫不决,当机会失去时便懊悔莫及。
春天在哪里呀春天在哪里?🌺🌺🌺🌺🌺🌺
春天在那青翠的山林里! 🌳🌳🌳🌲🌲🌲
这里有红花呀这里有绿草,🌷🌷🌷🍀🍀🍀
还有那会唱歌的小黄鹂。 🐦🐦🐦🐥🐥🐥
打开App.Vue
。 对,你没看错! 就是它,我们在它 created
时构建请求。
<script>
export default {
name: 'App',
created() {
console.log('the App is startup........')
this.$baseData.getData(this)
},
}
</script>
哎,大哥 $baseData
又是啥东东?玩我呢?
奥,奥,忘了说了。
🏒4.4 全局定义
这个定义在main.js
内,定义在main里.😍😍😍
主要考虑是为了解决缺点二,如果你需要在其他地方调用,可以方便的引用之。
import BaseData from '@/utils/baseData'
Vue.baseData = Vue.prototype.$baseData = BaseData
🏒4.4 使用
词典和配置都在VueX内定义,因此使用的时候,就不要考虑后台Api的事情了。仅仅需要:
dict: this.$store.state.app.dict,
cfg: this.$store.state.app.appConfig,
词典是数组套数组,因此如果需要访问指定类型的词典,可以写个简单函数
getDict(category) {
if (!this.dict) return []
const item = this.dict.find(item => item.category == category)
if (!item) return []
return item.dictValues
},
🎏 5. 小结
时机的确是我最纠结的,这个时机的选择来自一位多年前的前端大牛,向他致敬!
年少不识前端香,🕺🕺🕺 错把后端当个宝!
例行小结,理性看待!
结的是啥啊,结的是我想你而不可得的寂寞。😳😳😳
👓都看到这了,还在乎点个赞吗?
👓都点赞了,还在乎一个收藏吗?
👓都收藏了,还在乎一个评论吗?
还有系列前端文章,客官,你不瞧瞧?
👉Vue中路由到一个公共组件,然后根据路径中是否存在文件动态加载组件
👉解放前端工程师——手把手教你开发自己的自定义列表和自定义表单系列之一缘起
👉解放前端工程师——手把手教你开发自己的自定义列表和自定义表单系列之二接口
👉解放前端工程师——手把手教你开发自己的自定义列表和自定义表单系列之三表格
以上是关于前端项目,看我在这里管理全局后台初始化的数据,就问你飒不飒?的主要内容,如果未能解决你的问题,请参考以下文章
Java 之SpringBoot+SpringSecurity+Vue实现后台管理系统的开发一前端
Java 之SpringBoot+Vue实现后台管理系统的开发一前端