Before going into any kind of explanation, we need to understand the difference between server side storage and client side storage when it comes to websites and applications. Server side means that we store our data on a server, using a database, client side consists of JavaScript APIs that allow you to store data on the client (in the browser).
WHAT IS LOCAL STORAGE?
In simple terms, the local storage can be compared to a data base, except it's found in a browser and not on a server. It's basically a huge Javascript object inside which we are able to store data in the form of key-value pairs. Not only we can store data, we can also delete it or retrieve it (a complete list of browsers which have a localStorage cant be found here). The data you store in the localStorage never leaves you machine (doesn't get sent back to the server, unlike with cookies, which will discuss in a future article), and depending on the browser, you can store up to 5MB of data.
In technical terms,
the localStorage read-only property of the
windowinterface allows you to access aStorageobject for theDocument'sorigin;
the stored data is saved across browser sessions.
WHY USE IT?
Local storage lets us cache (store) some application data in the browser, for later usage. Therefore, it is very useful if we want to speed applications up (since the data is stored totally on the client, it does not travel between the client and server on each request or response). This way we can allow an user, for example, to continue a game where they left off or serve them relevant content based on their previous visit of our website.
I'm mostly using it when I'm building static websites. Since I don’t need any backend language or logic to store data in the browser, my web pages can run independently of any web server.
There are two types of storages, local and session, but for now the only difference you should remember is that the local storage has no expiration date (meaning that the data will stay in there until we remove it manually), whereas the session one gets cleared once we close the browser (session).
I will be using Chrome browser for this article, but generally, accessing the localStorage of any browser is pretty similar. We open the console (F12), navigate to the Application tab and in the menu on the left we'll see Local storage under the Storage tab. Something like this:
If we expand the Local storage dropdown, we'll get to this view:
We have two columns, Key and Value, and usually they're filled with data, which I just removed before taking the screen shot.
The way we can access this storage object and populate the two columns is by making use of some specific methods. Remember, local storage is read-only, meaning we can add, read and delete data from it but we can't modify it (at most, we can overwrite the previous value of a key, by re-adding to the storage, using the same key and the new value we want to store). For access we should use the following syntax:
window.localStorage
//or
localStorage
If we want to add something, we can do it like this:
localStorage.setItem("key", "value");
To access a value, we write this:
localStorage.getItem("key");
And lastly, we can delete one specific value:
localStorage.removeItem("key");
Or we can clear the whole local storage:
localStorage.clear();
Now, let's try to actually write some code. I will use my console, for simplicity's sake. Let's add an item:
window.localStorage.setItem("city", "Toronto");
Now, local storage looks like this:
One important thing to remember is that the localStorage can store only strings. To store objects, we must first convert them to strings using the JSON. stringify() method. And we convert the strings back into objects, after we retrieve them from the localStorage, using the JSON.parse().
Let's add some more values, using different types of data as keys and values:
localStorage.setItem(0, "number");
const person = {name: "Alan", age: 32};
JSON.stringify(person); // returns "{\"name\":\"Alan\",\"age\":32}"
localStorage.setItem("person","{\"name\":\"Alan\",\"age\":32}");
Now the local storage will look like this:
We can add as many key-value pairs as we want as long as the data doesn't exceed 5MB. Now let's retrieve the value of the person key, convert it to an object and print it to the console:
const result = localStorage.getItem("person");
console.log(result); // returns {"name":"Alan","age":32}
const objectResult = JSON.parse(result);
console.log(objectResult);// returns {name: "Alan", age: 32}
Finally, let's delete one item only, followed by clearing the whole localStorage:
localStorage.removeItem("0");
localStorage.clear();
THINGS TO REMEMBER ABOUT THE LOCAL STORAGE
- it is tab specific, meaning each browser tab we open will have different data in the
localStorage(this doesn't apply if the tabs have the same origin (share the same domain)) - some browsers, when used in
incognito modedon't allow for setting data in thelocalStorage - it is synchronous, meaning each operation will execute one after the other (this might work for small projects, but it will impact the runtime of the more complex ones)
- it can only store data string data (this is fine for small projects, but it can be cumbersome to
serializedata in complex ones)
SUPER IMPORTANT THING TO REMEMBER
Local storage should under no circumstances be used to store sensitive information (e.g. passwords or personal details), since the data inside it can be accessed from anywhere on the page (it has no real protection and it's susceptible to cross-site scripting).
Image source: ThisIsEngineering/ @thisisengineering on Pexels
Top comments (21)
It seems like you have deleted the previous post and then re-created it.
Tnx for the post :)
Yes, true. To answer your question, I believe your usage of localStorage is safe, for development purposes. Unrelated to localStorge, what I would pay attention to would be not to expose your API key if the API you're using has provided you with a private key (that if tou chose to upload your project using Gihub Pages, Netlify etc).
I agree. For that reason, I use .env to protect api key
Even if you store your keys in an .env file, they will be exposed once the React project is built. For more details you can read this article
Indeed. A file with credentials should not be read by the client / frontend by JS because it means a user can access the value too.
An appropriate use for .env file credentials is if your frontend did not care about this details at all. But you have a server side REST API or Lambda which internally loads the .env file and obscures the values and then your frontend requests that service.
Also remember that a .env on GitHub can be read by other users. So typically you would use secret environment variables set in your CI so that only you and admin users can see the values and they get used in the app at build time, and when the app starts.
Do you have some resources on how to achieve this exactly? I've been dealing with this issue myself but I nevet got into details on how to obscure my API keys. Thank you!
If you have a simple app that does one thing then consider Netlify Functions, similar to Lambda but letting you run server side Node code and the frontend interfaces through API requests. And it is serveless so you don't need to set up a Node server! Add a file in the right directory and Netlify will deploy your serverless code. In your Function file, you would reference process.env.
And the value would be set in the env variables in your Netlify admin view.
For example if you want to search the Twitter API using your secret keys but allow users to input their own search terms and not have to do any auth themselves.
Here is an article I found
dev.to/irohitgaur/how-to-access-ap...
I have an example of a file and site for reference. I use frontend JS to query the Function and return the result on the frontend.
github.com/MichaelCurrin/netflix-a...
It doesn't use an API key because the external API doesn't need one. But for Twitter where you do need one, I would have set and used env variables as in my previous comment. Note I would not use a .env file because it would be stored in version control and maybe accidentally deployed as a public file on the site. Keep your secrets out of version control and in your CI tool env variables. Or say AWS secrets manager.
Drifting from the web app flow, here is how to use secret environment variables on GitHub Actions to post a tweet.
github.com/MichaelCurrin/tweet-gh-...
If you are making complex app handling say user profiles and photos then instead of Function you probably need to make a REST API with Express JS or Flask (Python) and maybe a database. And host that on Vercel or AWS. And your app would read the env variables on
process.envoros.envwhen the app starts but only send and receive precise info to the user so they cannot see the API key used behind the scenes.Thank you so much for all the resources, sounds very interesting (and tricky :D)!
Nie!!!
Sorry nice!!!
Not if the tabs share the same origin. It's only true if you use
sessionStorageTrue, I forgot to mention that. Thx!
Very useful... Thank you
Thanks for sharing!
Thx for pointing out the typos (bad copy paste :D). I mentioned you can access the storage both ways (with or without
window), but yes, I might as well remove thewindowkeyword in the examples.Thanks for this wonderful post :)
Thx for reading, I hope it was useful.
Nice post. Thanks for sharing.