為啥我放棄用 Pinia 和 Vuex 去做字典狀態管理呢?
大家好,我是林三心,用最通俗易懂的話講最難的知識點是我的座右銘,基礎是進階的前提是我的初心~
最近需要需要封裝一套字典數據,給團隊中的所有項目使用,因為畢竟字典這東西,是很通用的,所以封裝一套公用的字典數據,也是很有必要的~
一、字典封裝
在項目開發中,字典是不可或缺的一部分,字典一般就是一個不會頻繁修改的集合,字典的作用一般是用來做:
- 下拉框選擇
- 表格數據的回顯
- 其他用處
1.下拉框選擇
這個相信是用的最多的,項目中會有許許多多的下拉框,這些下拉框其實基本都是不變的,且可能很多個頁面的下拉框都會共用同一個字典
2.表格回顯
比如你在添加表格數據的時候,你傳的是字典值去后端,那么到時查詢表格數據回顯時,后端也是給你返回字典值的話,那么這時你需要通過字典值去匹配出字典文本顯示在表格上~
3.其他用處
當然字典也有其他用處,比如你需要拿這個字典列表去展示到頁面上,或者其他不同的用戶。
4.思考
當我們明白字典的用處之后,思考一下,我們需要從字典上獲取什么東西,才能實現上面三個功能呢?回顧總結一下三個要求:
- 下拉框列表展示:項目統一格式是{ label: string; value: string }[]
- 字典值匹配字典文本:怎么去匹配呢?其實使用map去匹配性能比較好
- 其他用處:其實我們也不敢保證哪里會用到,所以需要保留字典原始數據
所以其實封裝字典,最重要的是封裝三個數據:
- 字典原始數據
- 字典option格式數據
- 字典map
并且,每個項目中所需要用到的字典也是不同的,比如 A 項目只需要用到 5 個字典,而 B 項目需要用到 10 個字典,所以也需要提供一個開關,讓項目自己去選擇需要哪些字典,而不是全量去請求字典
二、存在哪呢?
咱們的字典是需要狀態管理的,并響應渲染到對應的頁面上。
在現在的 Vue3 項目中,很多項目都會使用Pinia來進行狀態管理,小部分 Vue2 遷移 Vue3 的項目還是會繼續使用Vuex來進行狀態管理。
這兩個都是不錯的狀態管理工具,字典存在里面,其實都能達到我們想要的效果。
但是我們想一個問題,如果我們的字典數據封裝是基于Pinia或Vuex去封裝的,那就耦合在一起了,萬一以后項目用了其他的狀態管理工具呢?那是不是我又得基于這個狀態管理工具去封裝一套?而且就算是只有Pinia和Vuex,我也得封裝兩套,但是我覺得我只想封裝一套就夠了,兩套的話維護起來成本高。
所以啊,可以選擇另外的東西來進行狀態管理~我們不要去基于Pinia或Vuex去封裝,我們要基于Vue3去封裝,那么就只需要封裝一套了。
三、effectScope
effectScope是Vue3提供的一個 API ,effectScope 可以有兩個作用:
- 收集副作用
- 全局狀態管理
第一個作用不是我們本文章的重點,重點是第二個作用。
現在 Vue3 最火的全局狀態管理工具肯定是 Pinia 了,那么你們知道 Pinia 的原理是什么嗎?原理就是依賴了 effectScope:
所以我們完全可以自己使用 effectScope 來實現自己的局部狀態管理,比如我們封裝一個通用組件,這個組件層級比較多,并且需要共享一些數據,那么這個時候肯定不會用 Pinia 這種全局狀態管理,而是會自己寫一個局部的狀態管理,這個時候 effectScope 就可以排上用場了。
vueuse 中的 createGlobalState 就是為了這個而生:
四、回到字典封裝
回到字典封裝,現在我們可以使用 effectScope來進行狀態管理存儲了,首先我們自己封裝一個useGlobalState
接著需要用這個函數,來創建咱們的字典狀態管理,具體代碼如下,其實重點就在于,獲取某一個字典的時候,需要獲取這三個東西:
- 原始數據
- options
- 映射對象map
接著,我只需要在適當的時機,去請求字典就行了,一般都是放在初始化的時候去獲取的:
可以看出我們獲取到了我們想要的字典,并且具備響應式渲染的效果: