摘要：于是一個(gè)擁有版本控制和過(guò)期控制的本地內(nèi)容存儲(chǔ)功能模塊就算初步完成了。最后基于這個(gè)事情的考慮，于是順便寫了個(gè)本地存儲(chǔ)控制的庫(kù)，基本都在上面了

關(guān)于localStorage sessionStorage之類的api怎么用已經(jīng)無(wú)需我再贅述了，但是具體怎么落實(shí)到一個(gè)稍微復(fù)雜一些的業(yè)務(wù)中還是需要做一些前期的準(zhǔn)備

1.localStorage 與 sessionStorage具體適用于什么樣的業(yè)務(wù)場(chǎng)景？
2.如何維護(hù)本地儲(chǔ)存？
3.如何進(jìn)行版本控制?
4.碰到禁止本地緩存的情況下怎么解決這個(gè)問(wèn)題?

根據(jù)本身特性localStorage做長(zhǎng)期存儲(chǔ)， sessionStorage做臨時(shí)存儲(chǔ)大家都是清楚的也無(wú)需贅述，至于IndexedDB之類的暫時(shí)不做討論。
很多初級(jí)的前后端分離的項(xiàng)目習(xí)慣性誤區(qū)是把用戶token存到localStorage。
這時(shí)候碰到一個(gè)問(wèn)題：

如果需要在不同域名下做登陸信息共享該怎么辦？

常見(jiàn)做法是SSO，同一個(gè)域名下的小型項(xiàng)目用cookies的domain直接來(lái)做簡(jiǎn)單的跨域共享也是一個(gè)辦法，而這個(gè)時(shí)候localStorage和sessionStorage就出現(xiàn)業(yè)務(wù)盲點(diǎn)了。
不僅過(guò)不去，即使通過(guò)各種鬼畜的操作過(guò)去了后面擦屁股也麻煩的要死：

登陸了以后用戶信息怎么傳給別的域名？
退登的話怎么刪除所有頁(yè)面的登陸狀態(tài)？

當(dāng)然如果需要實(shí)現(xiàn)還是比較依賴后端的用戶登陸狀態(tài)判定，而這個(gè)時(shí)候某些分離得過(guò)分干凈的業(yè)務(wù)可能出現(xiàn)一些詭異的狀態(tài)判定，比如a.xxx.com站退登了b.xxx.com站還登著，你要真要前端來(lái)做這事代碼量也是相當(dāng)可觀的，甚至各個(gè)頁(yè)面緩存的token數(shù)據(jù)可能還都不一樣，顯然不夠合理也不適合這樣用，請(qǐng)把后端的事情還給后端，除非前端也寫一些node中間層。
而且某些瀏覽器的無(wú)痕功能禁用了localStorage和sessionStorage導(dǎo)致登陸狀態(tài)異常，所以localStorage存用戶token的事情就把它忘記吧，不然后面就等著哭吧。

存些不常變的東西？
比如圖片,把圖片轉(zhuǎn)成base64再存起來(lái)？
那么問(wèn)題來(lái)了，一般我們會(huì)存什么圖片？
比如一些背景圖？
那么為了這件事情我們首次載入的時(shí)候先要把圖片下載過(guò)來(lái)，然后費(fèi)盡心思存起來(lái)還要避免和別的同事重名，萬(wàn)一哪天要換個(gè)圖片還要想辦法把之前的內(nèi)容清理掉不然直接讀localStorage里的內(nèi)容，即使做好了本地存儲(chǔ)的版本控制還要專門寫一大堆代碼增刪改查，這明顯是嫌自己工作量不夠大，本來(lái)只要用cdn直接解決的東西被搞得這么費(fèi)勁，何必呢?
所以存文件的事情基本也可以忽略了。

還有一些神奇的做法是存js代碼，敢這樣做的人不是蠢就是壞了。

然后，一般localStorage常用于緩存一些內(nèi)容很多很固定的數(shù)據(jù)比如全國(guó)各地省市縣、區(qū)號(hào)之類的基本不會(huì)變但又會(huì)在各種ui組件里用到的簡(jiǎn)單數(shù)據(jù)，但是直接JSON.parse然后還去遍歷一個(gè)很大的數(shù)據(jù)做查詢篩選只會(huì)讓你的機(jī)器感到絕望發(fā)紅發(fā)燙瀕臨崩潰，而這個(gè)時(shí)候我還不如直接用cdn載入一個(gè)專門用于存放這類靜態(tài)數(shù)據(jù)的js文件來(lái)得快捷方便性能還好還能隨時(shí)改。

難道localStorage真的這么廢？

其實(shí)也不是啦，首先要確定一點(diǎn)，不去存過(guò)大的JSON數(shù)據(jù),那就存?zhèn)€小的：

用戶搜索歷史的緩存。
文本編輯器內(nèi)輸入的內(nèi)容。

然后是sessionStorage，其實(shí)我最喜歡用這個(gè)了，關(guān)掉就清除毫無(wú)后顧之憂，那一般我會(huì)用于什么業(yè)務(wù)場(chǎng)景呢：

存網(wǎng)頁(yè)的歷史記錄，操作過(guò)histroyAPI的朋友一定知道為了避免安全性問(wèn)題histroy只會(huì)給你當(dāng)前頁(yè)面前面打開(kāi)過(guò)幾個(gè)頁(yè)面的數(shù)量。所以完全可以在這里做個(gè)histroy的詳細(xì)記錄，甚至結(jié)合spa項(xiàng)目的router插件來(lái)滿足各類奇怪的需求，比如跳了好幾次頁(yè)面填了一堆表格后點(diǎn)擊支付然后支付完成后即使點(diǎn)擊瀏覽器頂部的后退按鈕也能直接一腳跨回首頁(yè)。
或者存那堆臨時(shí)表格的內(nèi)容（2B業(yè)務(wù)經(jīng)常碰到那種填一大堆又臭又長(zhǎng)的申請(qǐng)表還要經(jīng)過(guò)各種審批的功能）
存用戶個(gè)人信息，比如用戶昵稱之類的，不用每次刷新都去服務(wù)器拖一遍（當(dāng)然這種事情其實(shí)還是有一定風(fēng)險(xiǎn)的，萬(wàn)一用戶在別的地方改昵稱了，你還得想辦法同步，具體解決辦法后面說(shuō)）

很多人第一反應(yīng)可能是直接使用 localStorage.setItem之類的api
一旦你真的只這樣做了...我可能無(wú)法保證你不被同事揍

每個(gè)業(yè)務(wù)線本身應(yīng)該有個(gè)狀態(tài)的管理區(qū)域，而這些業(yè)務(wù)線的本地?cái)?shù)據(jù)存儲(chǔ)業(yè)務(wù)應(yīng)該匯總?cè)氲揭粋€(gè)公共的入口做類型判定以及進(jìn)行增刪改查。
一般比如Vue的應(yīng)用，我們會(huì)把數(shù)據(jù)存到Vuex的state內(nèi)，每個(gè)業(yè)務(wù)線分支都會(huì)有多帶帶的模塊引入并進(jìn)行獨(dú)立維護(hù)。

你必須確定一個(gè)習(xí)慣一致，名字唯一的命名協(xié)議。
自?shī)首詷?lè)的項(xiàng)目也就罷了，萬(wàn)一是個(gè)超過(guò)四個(gè)人的前端小隊(duì)每年可能都有不同的人會(huì)離職不同的人會(huì)入職不同的業(yè)務(wù)要迭代不同的功能要修改，增刪改查的事情如果沒(méi)有一個(gè)確定的標(biāo)準(zhǔn)后果不堪設(shè)想。
一般常見(jiàn)命名方式會(huì)在前面帶入業(yè)務(wù)模塊名稱
比如 USER_INFORMATION_NICKNAME 之類的，當(dāng)然有的信息可能不方便透露只寫個(gè)索引名稱也是有的，主要還是看公司里決定這個(gè)規(guī)則的人怎么考慮。

還是以Vuex做為例子（以下內(nèi)容僅供參考，請(qǐng)勿直接用于業(yè)務(wù)代碼中）

在State中聲明對(duì)象用于獲取本地存儲(chǔ)內(nèi)容的元數(shù)據(jù)

state:{
  NICKNAME: window.localStorage.getItem("USER_INFORMATION_NICKNAME")
}

創(chuàng)建一個(gè)Getter用于內(nèi)容讀取

getters: {
  USER_INFORMATION_NICKNAME: state => {
    try {
      return JSON.parse(state.NICKNAME)
    } catch (e) {
      localStorage.removeItem("USER_INFORMATION_NICKNAME")
      return  null
    }
 }
}

寫入Mutation用于增刪改

mutations: {
  DELETE_USER_INFORMATION_NICKNAME (state) {
    window.localStorage.removeItem("USER_INFORMATION_NICKNAME")
    state.USER_INFORMATION_NICKNAME = value
  }，
  UPDATE_USER_INFORMATION_NICKNAME (state, value) {
    window.localStorage.setItem("USER_INFORMATION_NICKNAME", value)
    state.USER_INFORMATION_NICKNAME = null
  }
}

寫入Action用于信息同步

actions: {
  GET_USER_INFORMATION_NICKNAME：context => {
    $http
    .get("xxx")
    .then(res=> {
      context.commit("UPDATE_INFORMATION_NICKNAME", res)
    })
    .catch(e => xxx...)
 }
}

這樣一個(gè)最最最基本的讀取策略已經(jīng)完成了。
但問(wèn)題又來(lái)了

畢竟是永久緩存，版本控制非常重要，不然就是給自己挖坑
首先要明確刪除數(shù)據(jù)的具體場(chǎng)景

可能是只存一小段時(shí)間后就失效的內(nèi)容

可能是下個(gè)大版本會(huì)被迭代掉的內(nèi)容

可能會(huì)發(fā)起部分用戶要升級(jí)部分用戶維持現(xiàn)狀甚至因?yàn)樾掳姹緲I(yè)務(wù)不夠完善可能需要回滾的灰度更新。

一般情況下我們需要在getter內(nèi)先確定一個(gè)數(shù)據(jù)讀取的依賴項(xiàng)，讀取的內(nèi)容可能是跟著依賴項(xiàng)數(shù)據(jù)走也可能不跟著依賴項(xiàng)數(shù)據(jù)走，這個(gè)看具體業(yè)務(wù)需求，如果不跟著依賴項(xiàng)走或者本身就是被依賴的項(xiàng)目的話就需要確定幾件事情

版本

過(guò)期時(shí)間

可能該內(nèi)容依賴于父級(jí)項(xiàng) 0.0.1版本的內(nèi)容，超過(guò)或者低于這個(gè)版本都可能出現(xiàn)問(wèn)題需要及時(shí)刪除并重新獲取
可能當(dāng)前載入的頁(yè)面中的配置項(xiàng)的版本與自身版本不一致所以需要移除并更新數(shù)據(jù)
于是導(dǎo)致的結(jié)果是我們需要再去聲明一個(gè)不保存在本地的配置JSON

{
  "USER_INFORMATION": {
    "NICKNAME": "1.1.1",
    "AGE": "1.1.2"
    ...
  }
}

如果要進(jìn)行灰度更新的話，這個(gè)配置就需要寫入到接口里面了。
還有個(gè)情況就是設(shè)置過(guò)期時(shí)間，超出這個(gè)限定的時(shí)間就清空數(shù)據(jù)。
于是我們就需要在UPDATE方法內(nèi)多寫入些東西

UPDATE_USER_INFORMATION_NICKNAME (state, value) {

  const new_value = {
    expires: Date.now() + 24 * 1000 * 30 * 3600,
    version: state.config.USER_INFORMATION.NICKNAME,
    value: value
  }

  window.localStorage.setItem("USER_INFORMATION_NICKNAME", JSON.stringify(new_value))
  state.USER_INFORMATION_NICKNAME = new_value
}

再調(diào)整下讀取的邏輯,
其他的代碼也跟著做一遍調(diào)整，依照自己能力水平能封裝的封裝，能復(fù)用的復(fù)用。
于是一個(gè)擁有版本控制和過(guò)期控制的本地內(nèi)容存儲(chǔ)功能模塊就算初步完成了。
做完這一切雖然感覺(jué)好像是像那么回事了

后面的問(wèn)題也只是封裝業(yè)務(wù)中的判斷邏輯罷了...
所以，有一個(gè)健壯的前端數(shù)據(jù)流才是核心，其他的只不過(guò)是幫助頁(yè)面達(dá)到更好的體驗(yàn)的輔助功能罷了，東西再好也不能濫用。

基于這個(gè)事情的考慮，于是順便寫了個(gè)本地存儲(chǔ)控制的庫(kù)，api基本都在上面了
GITHUB:steerable-storrage