什么时候考虑使用全局状态管理？vue获取全局状态变量一共有三种方法，你真的理解吗？

同学们可以私信我加入学习群！

---

---

前言

本文给大家做个参考，什么时候会考虑使用全局状态管理？以及帮助大家理解获取全局状态变量的三种方式。

在使用vue的全局状态管理工具pinia时，很多小伙伴可能都会有个疑问，那就是我们从全局状态管理中获取某个变量的值，一共有三个方法：

1.直接访问state中的变量

2.通过getters访问变量

3.通过actions中的方法访问

这三个方法有何区别，它们是不是有些冗余，究竟什么时候用哪个方式。本文通过简单的几分钟，教会大家这个基础知识点。

---

一、场景

最近的项目，我有一个组件（主要是jar包）管理的需求，如图：

参数配置功能需要对组件的配置文件（主要是.properties）进行修改、创建项、保存、导入导出等一些列操作：
每个配置页面布局是一样的，渲染逻辑也是一样的，所以肯定是写一个vue页面，给页面传递不同的数据，最终实现效果。

最初，通过props传递组件数据进来，已经很好地实现初步效果。但是当迭代后，配置功能变复杂，需要判断每个表单项的格式，需要把两个组件的配置文件合并到一个页面显示……

最终这个配置页面又被拆分，从一个单独的vue页面，变成不止一层的父子页面，再通过祖父级的props来传递参数，并且实现两个配置页面的数据合并到一个页面显示，两个页面间参数还会有联动，就会很麻烦。

最终需要改造成状态管理工具来管理父子间、兄弟间共享的数据。

二、设置state中的变量

这个状态管理的简易代码如下：

/**
 * 组件配置页*/

import {defineStore} from 'pinia'

export const useSettingItemStore = defineStore('settingItem', {
    state:()=>{
        tabItem:{}
    },
    getters:{
        getTabItem(){
            debugger
            return this.tabItem
        }
    },
    actions:{
        setTabItem(v){
            this.tabItem=v
        },
        getTabItemHandle(){
            debugger
            return this.tabItem
        }
    }
})

每次点击参数配置按钮，进入配置页时，我都会调用setTabItem方法，修改tabItem的数据，在配置页面渲染。

三、直接访问state中的变量

import {useSettingItemStore} from 'module-install/store/settingItem'
const {tabItem}=useSettingItemStore()
console.log(tabItem)

最终效果：tabItem是我们需要的数据。

四、通过getters访问变量

import {useSettingItemStore} from 'module-install/store/settingItem'
const {getTabItem}=useSettingItemStore()
console.log(getTabItem)

最终效果：tabItem不是我们需要的数据。

五、通过actions访问变量

import {useSettingItemStore} from 'module-install/store/settingItem'
const {getTabItemHandle}=useSettingItemStore()
console.log(getTabItemHandle())

最终效果：tabItem是我们需要的数据。

六、总结

1.对比最终效果，我们可以知道，通过getters方式访问的数据只有在第一次调用时会计算返回值，计算一次后，就会把getTabItem的值缓存起来，以后再改变tabItem变量，getTabItem的值也不会改变。

2.getters缓存结果的方式有利于性能，但不适用于每次都需要计算新值的场景。第一次调用指，第一次使用 const {getTabItem}=useSettingItemStore()获取getTabItem的时候。getters也有返回函数来应对重新计算的场景，但是非必要别用。那个函数不是用来解决缓存问题的。

3.使用getters和actions获取变量的好处是，因为有方法体的存在，可以根据维护的变量，定制输出值。

4.当每次都需要改变状态值，并重新计算输出，可以直接访问state中的变量或者通过actions访问，如果使用频率过高，推荐使用actions，因为在state变量和应用场景之间封装一层，有利于拓展性增强，也有利于webstorm跳转引用。

---

总结

获取资源，或者联系我，都可以通过下面入口：

https://lizetoolbox.top:8080/qrCode_contact