資訊專欄INFORMATION COLUMN
摘要：定時器時間到了就將中存的信息以及存的時間信息就是那個對象中的刪掉就行了。難道存了三條我就做三個定時器存的條我就做個定時器這也太了而且也并不符合實際。
一、酷酷的開頭
在潛水的時間長達一年之后，我終于鼓起勇氣開始寫我的第一篇文章了。前端小菜，只是想記錄一下自己的想法，望各位看到這文的大佬輕噴。
在現在前后端分離的開發模式下，存儲信息一般都不在使用以往使用的cookie了，就拿筆主我之前做過的項目來說。我們都是登錄成功了之后后端會返回給我一個token，一般情況下我會將這個token存到localStorage中，后續再每一次請求中都會將這個token攜帶在請求頭中。 至于為什么要存到localStorage中呢，相信做過單頁web應用的開發者們也知道，如果不存著，那用戶刷新了就啥都沒有了。
可以見得前端存儲在項目中是越來越重要了，瀏覽器給我們提供了兩個存儲方案，一個是localStorage，一個是sessionStorage。 存到localStorage中的信息是永久存儲,如果用戶不手動刪除或者代碼中沒有localStorage.removeItem(xxx)這樣的調用那這個信息將永遠不會消失; 在sessionStorage中存儲的信息則是一次性的，用戶關掉網頁了下一次在進入這個網頁信息就不會再存儲了。 但是在實際項目的運用中，這兩個方案的表現都不是那么令人滿意。就比如說，我想要實現用戶登錄之后七天之內不需要再次登錄這樣的功能，token生成了之后，后端設置了這個token的過期時間為7天，ok，傳到前端， 但是針對瀏覽器目前提供的存儲方案，我卻只能選擇永久存儲和一次性存儲。一次性存儲肯定是不能滿足需求的，永久存儲也違背了我的意愿。
二、之前在項目中的解決方式之前我在項目中的做法是，在用localStorage存儲了token值的同時， 我還存了一個過期時間（一個毫秒數），然后在項目初始化的時候我就會去檢查這個時間看看是不是已經小于當前時間了，如果是就將token刪掉。 這樣后續項目在使用到這個token的時候token就已經從localStorage中被刪掉了。但是這樣做也有一個問題，如果打開項目的時間剛好是還有10s token就過期的話，token也不會被刪掉了。于是我腦袋里就在構想一個可（垃）靠（圾）的解決方案，一不做，二不休，我把它封裝成了一個工具。
先厚臉皮的介紹一下我的項目， sweet-storage, 請無視這土的要死的名字。
github的地址為：https://github.com/Chechengyi/sweet-storage。 順便也正（卑）大（鄙）光（無）明（恥）的求一波star。
咳咳咳！ 廢話不多說了，講一下我的實現思路。
在遇到有過期時間的存儲需求時， 用我這個項目舉栗子， storage.save("name", "chechengyi", 10000) 這行代碼的意思是我想在localStorage中存一個鍵為name，值為chechengyi的信息，我希望這條信息只存10s，在將信息存入localStorage中的同時，我會把它的過期時間信息以
{
key: time
}
的形式也存到localStorage中。 key就是鍵， time就是這條信息到期的時間。 這里的時間的話應該存的是new Date().getTime()+我們設置的時間。這樣就得到了一個精確的毫秒數了。 這個過期時間信息在我的項目中以ISTORAGE_RECORD的字段存儲。 然后后面我們在根據這里面所提取出來的時間，即：new Date().getTime()-time這個時間去做一個定時器。定時器時間到了就將localStorage中存的信息以及存的時間信息就是那個對象中的key-time刪掉就行了。
但是這里也有一個問題，就是。可能我們需要有過期時間存儲的時間不只有一條啊。難道存了三條我就做三個定時器？存的100條我就做100個定時器？ 這也太low了而且也并不符合實際。于是我冥思苦想，發現我前幾天剛學習的優先隊列很適合用在這里。
我們可以這樣做，基于ISTORAGE_RECORD拿出來的對象里的time去做一個最小堆（我的這個優先隊列是基于最小堆的），最小堆嘛，根節點肯定就是最小的，time最小的那個不就是最先執行的定時器嗎？ 等這個定時器執行時就刪掉localStorage里存的信息和時間信息，然后優先隊列出列，下一個排隊等著出列的元素就是下一個時間最近，等著過期的信息了。這里涉及到了最小堆數據結構的操作就不多講了。有興趣的同學可以自己去看看實現。這就是我的項目實現的大概思路， 真正實現的話還要去考慮還沒過期就被用戶刪除了等等的情況。
到這里了我又在想，不行啊，這樣過期了也只是“悄悄”的過期了。 我想知道它什么時候過期的，也就是我希望它過期的時候能通知我一聲行不行啊？ 于是經過我又一輪的冥思苦想，我發現我去年學的發布-訂閱模式可以用到這里。然后就是代碼實現啦，無非就是做了一個observers對象。 以存儲的key名去訂閱了一個事件，在我的項目中就是storage.on("name", (key)=>{}) 然后再定時器執行的時候我會observers.trriger("name")去發布這個事件，并且將需要被刪除掉的信息的key傳入訂閱的函數當中。 這樣就做到了通知的功能。具體發布-訂閱模式怎么實現的也不在此多做贅述了。
四、無恥的總結sweet-storage 實現的大概思路就說完了，有興趣的同學可以去看看源碼實現，在此強調 github的地址為：https://github.com/Chechengyi/sweet-storage。 我的代碼寫的很通（垃）俗易（圾）懂。
我還將這個項目傳到了npm上面， npm install sweet-storage就可以安裝到本地。學以致用，這一年多來在各大論壇潛水每次看到別人分享心得心里都癢癢的，這次總算是下定了決心踏出第一步。在這個過程中也學習到了很多，希望自己能夠堅持下去。
如果有不對的地方希望朋友們指出，希望朋友們多給我提建議
最后在強調一波！！！
github的地址為：https://github.com/Chechengyi/sweet-storage。
求star 求fuck......
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/103649.html
摘要：保持狀態保存在瀏覽器端，保存在服務器端存儲的大小單個保存的數據不能超過大小沒有限制。的目的是克服由所帶來的一些限制，當數據需要被嚴格控制在客戶端時，不需要持續的將數據發回服務器。的生命周期是僅在當前會話下有效。 寫在前面 既然是淺談，就不會詳細從底層原理解釋這幾個的區別，就簡單地聊一下，這幾個的區別，優缺點，應用場景 cookie和session 瀏覽器的緩存機制提供了可以將用戶數據存...
摘要：理解進公園背景這個公園有一個總公園總公園里有許多小公園總公園是登錄頁面小公園是域名相同的頁面第一次進總公園第一次請求某個服務器工作人員檢查你的入園是否符合條件后端查看是否是注冊以后的用戶通過條件的話工作人員會給你一張票后端會給你一個響應頭這 Cookie, Session, LocalStorage, SessionStorage Cookie 理解 進公園 背景: 這個公園有一個總公...
摘要：路由之身份認證一身份認證簡介是目前最流行的跨域身份驗證解決方案，相較于機制，服務器就不需要保存任何數據了，也就是說，服務器變成無狀態了，從而比較容易實現擴展。 Vue路由之JWT身份認證 一、JWT身份認證簡介 JSON Web Token（JWT）是目前最流行的跨域身份驗證解決方案，相較于session機制，服務器就不需要保存任何 session 數據了，也就是說，服務器變成無狀態...
閱讀 3072·2021-11-25 09:43
閱讀 2251·2021-09-07 10:28
閱讀 3543·2021-08-11 11:14
閱讀 2777·2019-08-30 13:49
閱讀 3544·2019-08-29 18:41
閱讀 1163·2019-08-29 11:26
閱讀 1976·2019-08-26 13:23
閱讀 3372·2019-08-26 10:43
