前端项目，看我在这里管理全局后台初始化的数据，就问你飒不飒？

Posted 2022-08-01 webmote

• 📢博客主页： https://blog.csdn.net/codeex
• 📢欢迎点赞 ：👍 收藏 ⭐留言 📝 如有错误敬请指正，赐人玫瑰，手留余香！
• 📢本文作者：由webmote 原创，首发于 CSDN🙉
• 📢作者格言： 生活在于折腾，当你不折腾生活时，生活就开始折腾你，让我们一起加油！💪💪💪

🎏 1. 大道起源

俗话说：一生二、二生三、三生万物。

在一个混沌初开的世界，总需要预留一个初始过程，就如女娲娘娘需要🔥冶炼石头一样🎎。搭建一个前端项目， 我们也需要初始化一些类库，组织组织脚手架，配置配置webpack等等。

当然，在这里，我们关心的是后台的某些数据，需要初始化🍀🍀🍀🍀。

有哪些花花草草🌼，需要初始化施肥呢？

🍄 系统全局配置，全局配置一般来自于后台数据库
🍄 系统词典列表，一般也来自后台数据库
🍄 某些国际化词典资源，大部分国际化直接来自前台，但总有某些例外的家伙~~

🎏 2. 初始化的优点

从第1小节，我们可以看到，需要初始化的资源，在每个模块被使用的几率，还是很高的。

如果没有初始化的帮忙，每次模块的created ，都需要调用后台api，获取数据。

因此从这能看出来，其优点🌷如下：

• 入口统一
• 数据保持
• 全局使用
• 减少api调用次数
• 减轻后台压力
• 降低使用复杂度

🎏 3. 初始化的缺点

话⚡说，天下大势，分久必合，合久必分，历史的事情都是在循环往复中曲折前进。

既然没有必然的事情，那我们就来看看引入了初始化，会带来哪些麻烦🥀？

• 数据需要持久化，初始化后的数据需要存储在vue属性、vuex、cookie、localStorage等任一前端存储内
• 数据不一致性，持久化数据后，必然会带来数据的不一致；例如，✍用户修改了词典

针对这些缺点，我们需要为引入的初始化做额外多余的工作🏃🏃🏃。

1. 持久化是前端的老本行了，可选择余地很大；
2. 不一致性可以使用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中路由到一个公共组件，然后根据路径中是否存在文件动态加载组件
👉解放前端工程师——手把手教你开发自己的自定义列表和自定义表单系列之一缘起
👉解放前端工程师——手把手教你开发自己的自定义列表和自定义表单系列之二接口
👉解放前端工程师——手把手教你开发自己的自定义列表和自定义表单系列之三表格