Läsa och skriva localStorage i React

localStorage är ett inbyggt lagringsutrymme i webbläsaren med fyra centrala metoder: setItem(key, value), getItem(key), removeItem(key) och clear(). Data finns kvar efter omladdningar av sidan och omstarter av webbläsaren.

Det finns på objektet window och är avgränsat per origin, vilket innebär att varje domän har sitt eget separata lagringsutrymme.

Varje anrop till localStorage körs synkront på huvudtråden. Läsning eller skrivning av stora datamängder kan blockera rendering och få gränssnittet att kännas ryckigt.

Håll därför lagrade värden små och undvik att skriva vid varje tangenttryckning eller rullningshändelse.

localStorage kan endast lagra strängar. För att lagra ett objekt eller en array måste Ni först serialisera det med JSON.stringify(value) innan Ni anropar setItem.

Om Ni lagrar något som inte är en sträng direkt omvandlas det automatiskt, så ett objekt blir den oanvändbara strängen [object Object].

Vid läsning anropar Ni JSON.parse(localStorage.getItem(key)), men parsningen kan kasta ett undantag om den lagrade strängen är skadad eller har skrivits av en annan källa.

Omslut parsningen i en try/catch och använd ett standardvärde om parsningen misslyckas, så att en felaktig post inte kraschar komponenten.

localStorage kan inte alltid användas: vid serverrendering finns inte window, och vissa lägen för privat surfning kastar ett undantag vid skrivning. Skydda åtkomsten med en funktionskontroll.

Ett säkert test är en try/catch som lägger till och tar bort en dummy-nyckel och returnerar false om ett undantag kastas.

De flesta webbläsare begränsar localStorage till ungefär fem megabyte per origin. Om gränsen överskrids kastas ett QuotaExceededError vid skrivning.

Det gör localStorage lämpligt för små datamängder, men till ett dåligt val för bilder, stora datamängder eller cachade API-svar.

Bra kandidater är små, icke-känsliga delar av UI och användarens state: temainställning, om sidofältet är hopfällt, senast använda filter, stängda banners och osparade formulärutkast.

Detta är värden som ska överleva en omladdning, men som inte behöver en serverförfrågan.

Undvik att lagra hemligheter som tokens eller lösenord, eftersom alla skript på sidan kan läsa localStorage, vilket gör det sårbart för XSS. Undvik också stora objekt och auktoritativ serverdata.

Känsliga autentiseringsdata hör hemma i httpOnly-cookies, och kanoniska data hör hemma på servern.

Båda har samma API, men sessionStorage rensas när fliken stängs och delas inte mellan flikar. localStorage finns kvar permanent och delas mellan alla flikar med samma origin.

Välj sessionStorage för kortlivade data som är specifika för en flik och localStorage för bestående inställningar.

Cookies är små och skickas med varje HTTP-begäran, vilket passar för autentisering men slösar bandbredd för allmänna data. IndexedDB är en asynkron databas för stora, strukturerade datamängder som vida överskrider gränsen på 5 MB.

Välj cookies för autentisering som läses av servern, localStorage för små klientinställningar och IndexedDB för stora eller komplexa data.

En minimal hjälpfunktion skriver med localStorage.setItem(key, JSON.stringify(value)) och läser med en skyddad try/catch runt JSON.parse(localStorage.getItem(key)), och returnerar ett standardvärde vid fel.

Den här lilla wrappern samlar serialisering och felhantering på ett ställe.

Du har lärt dig localStorage-API:t, att det är synkront, endast lagrar strängar och har en gräns på nära 5 MB, samt hur du parsar säkert och kontrollerar tillgängligheten för SSR och privat läge.

Du har också jämfört det med sessionStorage, cookies och IndexedDB för att kunna välja rätt lagringsplats.