User-Side Data Storage for JS Apps
localStorage object means that you won’t have to call on or persist data to your database since the data is stored specific to the protocol of the page. It’s not always appropriate but we’ll look at some use cases for this powerful tool.
Since the Web Storage API is not linked to your database, it’s different than a cookie. It also has a storage limit of 5MB which dramatically outperforms a cookie’s 4KB limit. You might consider using
localStorage for things like:
- Previous site activity (like shopping carts)
- Site preferences (like color scheme)
- Saving information for offline use
This probably won’t save you from needing to persist at least some data to your database, but it could save you from a lot of unnecessary calls to your database. The fewer calls you have to make the faster your program will run.
Let’s take a look at this works. To persist some data to
localStorage you simply use the
setItem method that takes in two arguments, a key and a value.
If you type that into your console and then call the
localStorage object, you’ll see something like this:
Check out that last key/value pair at the end of the object. COOL BEANS!
Whenever we want to retrieve information there’s a parallel method called
getItem that works just as simply as the
Alternatively, just like other JS objects, you can use the dot notation syntax to both create and retrieve data.
There are two other methods that can be called on the
localStorage object. One is the
clear method that takes in no arguments and clears all storage. The other is the
removeItem method that takes in one argument and deletes a key/value pair.
So, what does it look like to persist user input to the
localStorage object in a JS file? The example below illustrates what this would look like in a simple task app that allows users to create a list of personalized tasks.
As you can see, it’s only a few lines of code!
Are there any reasons not to use
localStorage? Why yes, yes there are. You should be aware of the drawbacks to this feature as using it inappropriately could run you into some real trouble.
- The data has no expiration date and is easily retrievable. Because of this it lacks security and should never be used to store important personal information. If this is the only caveat preventing you from using
localStorageobject, try using the
sessionStorageobject which works exactly the same but clears all data when the browser session is closed.
localStorageobject is a very simple Web Storage API and can only store string data. So, if your data is complex this is not a good solution. There are several libraries you can use in conjunction with your app to mitigate this problem. You can explore nine of those options HERE.
- It’s synchronous so integrating it with a dynamic site will likely not work.
Are there better options out there? The world of user-side storage is ever-evolving and there are certainly other options. One of the most intriguing options for storing more complex, user-side data asynchronously is IndexedDB. You can read more about it HERE.