A Peek Into The LocalStorage world

A front-end developer who has confusions on where the simple key-value data can be stored? Is your code muddled up to the extent, you are now having dilemmas on where it’s safe enough to stock the user information?

Our blog on local storage in front end can shine the light on the best practices to be implemented. Go on, read and let us know your valuable inputs in the comments section.

So, let’s start with just the basics.

In amateur terms, it refers to set the applications which provide the front-end web developers, access to a data storage. By doing this, the data will get stored in the client side which sequentially helps in the speeding of the web applications’ performance and reduces the complexities of compound database queries in the server.

Before the concept of LocalStorage came into inception, developers who wanted to stock up data on the client-end required browser cookies. Only downfall was, a cookie can only store 4,096 bytes of data. Adding to this, everytime a cookie was sent to the server, a HTTP request was made by the client. This meant, the size of the requests kept increasing exponentially and this resulted in higher usage of bandwidth and slower request times.

How do we store data in LocalStorage?

Storing Data in LocalStorage means, the user’s information can be captured and stored at his end. This data will have no expiration date and will persist even after the browser window is terminated.

A simple example where LocalStorage enhances the user performance would be the classic case of saving the data on user preferences ( theme colours on a website ) or saving the cart items in an e-commerce website and so on. The storage size is yet another icing on the cake. From just a storage space of 4KB using cookies, local storage will provide at least 5 MB of data storage across the various web browsers.

Representation of a loaded cart according to customer’s preferences

In practice, local storage is a large traditional JavaScript object where you can save or remove the data from.

Here’s an example of a JavaScript code we used in Pickyourtrail product that stores information in the local storage, echoes it back to us, and then subsequently removes it:

Step 1: We set the localStorage function initially

Step 2: Checking if the Key is mapped to the correct value we’ve set

Step 3: An alert displaying the set message

Step 4: Removing the localStorage in the same code

Step 5: Checking if the localStorage has been removed

Step 6: An alert message with the undefined values

Say you are building a static site (like a single page app — using React in our case), using something like local storage paves way for web pages to run independently on any web servers. The need for back-end language or logic to store data in the browser is not mandatory in this case.

An obvious reason for developers to go crazy over this concept right?

Pickyourtrail product captures user information right from their best interests to their passport details and gets the vacation booking done. However, we don’t use local storage for storing sensitive details of users or their session information. These are dropped and managed as HTTP-ONLY cookies from our web-server.

The local storage is used from our end to share information between pages/routes and also to retain the same information after every page load.

Sometimes there’s a need to store information which is publicly accessible in order to improve the user experience.

Interesting read: Solve your slow page loads!

*You need to keep backup of data constantly to prevent loss

*You are ultimately accountable for the protection of the data

*Sharing of data is tough — since you need to upload it on a hosted server and then share it with the designated user.

*Uses more storage space if you store locally

*Data storage is only of string type

*It is a synchronous process which means, every local storage operation you run will be one-at-a-time.

*It restricts the capacity of data you can save to approximately 5MB across all major browsers

Looking for alternatives? Yep, we’ve got you!

1. In order to save sensitive data, make use of the server-side session.

Listings under sensitive data:

• User IDs
• Session IDs
• JWTs
• Personal information
• Credit card information
• API keys and anything else you wouldn’t want to be accessible publicly.

Note:

A server-side session is another name for server-side cookies. The website stores a singular cookie on the browser holding a sole Session Identifier.

2. To store a non-string data

If there is a need from your end to store data in the browser and this data isn’t sensitive and is a partial string data, IndexedDB is your best option.

Brownie points for using IndexedDB

• Saving edits without having to sync every individual character change back to the server instantly
• Syncing the server when the user opens the browser the next time and posting the edits made in his previous session.
• To avoid the reloads of fonts or image resources every time the page is refreshed or reloaded.
• Can work with a database-esque object stored in the browser.
• You can avail the services of IndexedDB with Cache API if you are planning to run your application offline. Now, this Cache API will allow the network resources of the app to be cached and BAM! You have your required data with you!

With all that’s being said, are you using LocalStorage in any exciting ways in your project plans? Let us know in the comments below.

Planning for an international trip? Yep, hit us up right here!