You probably have heard of local storage or session storage term but never got chance to explore it.. This article will clear all your concepts about it.

Local and Session storage comes under the category of HTML5 Web Storage.

It’s not the same as session storage that you might be familiar with, if you came from java background where session is stored on server side.

We will use the term Web Storage when we talk about Session and Local Storage together.

Web Storage is used for storing data on client side. So the data will be available across page refresh.

Previously before Web Storage came into play, the only way of storing the data on client side was using cookies.

Cookies are still used but there are some disadvantages of using cookies

1. Cookies are stored on client side and are transferred to server on every request sent to server. This makes cookies less secure
2. Cookies has storage limit. We can’t store more data into cookies after certain limit
3. Cookies can be disabled by using some browser extension tools
4. Storing data in cookies required some extra code

So Let’s explore about Web Storage Now

Session Storage :

1. Session Storage is for per browser tab. So data stored in one browser tab will not be accessible in other tab
2. Each browser tab has separate session storage data
3. Session Storage data gets cleared when we close the tab
4. It also gets cleared when we close the browser

Local Storage :

1. Local Storage is used for storing data across the entire application
2. Data stored in local storage will be accessible across all the tabs or pages only for that domain ( like www.google.com, www.medium.com etc)
3. Local Storage data stored for particular domain will be accessible even you open the another browser window (Control + n or Command + n (Mac)) on the same browser
4. Local Storage data stored on normal browsing session will not be available when you open browser in private browsing or in Incognito mode.
5. Local Storage data will not get cleared even if you close the browser. Because it’s stored on your browser cache in your machine.
6. Local Storage data will only be cleared when you clear the browser cache using Control + Shift + Delete or Command + Shift + Delete (Mac)
7. We can also clear the local storage data programmatically. We will see how to do that soon

Both Local and Session Storage has storage limit of 5MB.

All modern browsers support Web Storage. Regarding internet explorer, its supported from IE version 8 and above.

You can check your browser storage limit by visiting http://dev-test.nemikor.com/web-storage/support-test/ and running web storage test.

That’s enough for the details. Now lets dive into how to use it

Both Local and Session Storage has same syntax

Add data to Local Storage :

localStorage.setItem(key, value)

Remove data from Local Storage :

localStorage.removeItem(key)

Add data to Session Storage :

sessionStorage.setItem(key, value)

Remove data from Session Storage :

sessionStorage.removeItem(key)

Both the key and value has to be a string. But we can store JSON object also by using JSON.stringify method.

Local Storage :

Lets checkout a simple todo list application using react just to understand the web storage concepts.

Check out this live demo of todo list
https://codesandbox.io/s/github/myogeshchavan97/todo_list

Github Source Code: https://github.com/myogeshchavan97/todo_list

It’s not complete application with all todo list features. I just built it for this demo.
Try adding some todos in the application, you will see something like this

Now if you refresh the page, all the todos will be lost and you have to enter it again.

To fix it, we will add the localStorage functionality here to retain the todos even we access the application in any tab.
As you can see in TodoList.js inside components directory, todos is an array declared in state as

state = {
  todos: []
}

To save it to localStorage we need to convert it to string by using JSON.stringify because local and session storage allows storing only strings.

We will do that as shown below

const { todos } = this.state;
const json = JSON.stringify(todos);
localStorage.setItem("todos", json);

Now if we print the saved data, you will see the output as seen below

To read the data back, we need to parse it because its stored as JSON string

const todos = localStorage.getItem("todos");
if(todos) {
 const parsedJSON = JSON.parse(todos);
 this.setState({ todos: parsedJSON });
}

The complete code will look like

Lets understand the above code from componentDidMount and componentDidUpdate

1. Whenever we add item to todo, the state todos array changes so this is the perfect time to store the todos in local storage

2. We are doing that in componentDidUpdate method

This method gets called when state or props are changed. In this method, we are checking if the previous todos array and current todos array length is different and only then store in local storage

3. In componentDidMount we are reading from the localStorage and adding back to the state

So every time the component is rendered we are reading from localStorage.

This will make sure that, the todos are not lost even if we refresh the page.

Complete Demo Application with updated code : https://codesandbox.io/s/github/myogeshchavan97/todo_list_with_localstorage

Github Updated Source Code : https://github.com/myogeshchavan97/todo_list_with_localstorage

Another use case where Local Storage can be used is for storing shopping cart items.

Session Storage :
Goto any website like medium.com and in the console paste the following line and hit enter

sessionStorage.setItem("name", "Advanced User")

Now, a new entry will be added in sessionStorage for the medium.com domain.

Now, If you check the value using sessionStorage.getItem(“name”), you will see the text “Advanced User” which we set as shown below

Now open medium.com in another tab in the same browser window and check the value of sessionStorage.getItem(“name”)

You will see null printed instead of “Advanced User” as shown below

This is because each tab has separate Session Storage data even on the same domain but local storage data is available for same domain for each new tab.
You can see all the local and session storage data for each site under the Application tab in chrome developer tools as shown below

So the point to remember is that, you use session storage only when you want to persist data in a single tab and session storage data gets cleared when tab is closed or browser is closed

Now consider a following scenario.

Suppose, you have a modal on the page which displays some long form to enter details. Many times it happens that, user enters some data in the form and by mistake clicks outside the modal and modal gets closed. Because of which he looses all the entered data.

To fix this we can use sessionStorage so the stored data in modal will only be applicable to current tab.

Complete Demo Application with code : https://codepen.io/myogeshchavan97/pen/rNaBONm

Here we have a button for opening the modal. When we click on the close button inside the modal, I am saving all the entered data in sessionStorage and when user opens the modal again, We fill out the input fields with previously entered values.

Also note that, we are clearing the session data on page load so on initial load the form will be empty.

To put together,

Github Source Code for all applications we built :
1. https://github.com/myogeshchavan97/todo_list
2. https://github.com/myogeshchavan97/todo_list_with_localstorage

Codepen Source Code :
https://codepen.io/myogeshchavan97/pen/rNaBONm

That’s it for today. Hope you learned something new today.

Subscribe to get weekly updates directly in your inbox https://subscribe-user.herokuapp.com/

Everything you need to know about HTML5 local storage and session storage was originally published in JavaScript in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

Last year, Panorama’s engineering team set out to choose a front-end framework. Before this endeavor, our applications were purely Ruby on Rails, using JavaScript only when necessary. We decided to move towards a front-end framework for a few reasons:

• Robustness — We felt that our web applications, while usually consistent internally, felt fairly homegrown. We would prefer to build them in alignment with the broader javascript community’s practices.
• Performance — While server-side can be fast, we were increasingly needing to create UI’s over larger and larger datasets which limited our use of server-side html rendering.
• Reusability — We did achieve some reuse by our use of Rails view partials, but it still created a lot of boilerplate, especially for UI components and intricate JS logic.
• Hiring — We had some evidence from engineering interviews that very skilled front-end engineers found it a very bad sign if we were still without a dominant front-end stack.

The Plan

At Panorama, we have a pretty flat hierarchy and make decisions via influence, not authority. This means we didn’t have a chief architect to choose a front-end tech stack, and instead brought a group of interested engineers together to evaluate our options and make a proposal to the engineering department. Once we had that handful of engineers to push this initiative forward, we developed a plan to select a framework. Knowing that this was a major decision and expensive to change later, we wanted to be thorough in our evaluation. A group of engineers met and decided on the following plan:

• Compile a list of frameworks to research and develop rubrics to evaluate those frameworks against
• Do some preliminary research on rubrics to narrow down which ones seem promising
• Build prototypes of a complex front-end feature using each of the finalist frameworks
• Finally, present our findings and get feedback from the rest of engineering to make that final decision

Frameworks and rubrics

To choose the frameworks to look into, we came up with ideas based on what seemed to be industry standards, and what engineers were generally interested in working on. We decided to investigate React, Vue.js, Stimulus, Polymer Project, and native web components.

In building our rubric, we first had a few themes of measurements, including philosophical balance, compatibility with our other technologies, features and functionality, and external resources available. In each theme we drilled down into a few specific items, like incremental adoptability, rails integration ability, perceived learning curve, and a strong community supporting the framework.

Initial investigation

We found some commonalities across all frameworks in our initial investigation. For example, every framework we evaluated allowed for incremental adoption and use outside of single-page applications. Though some had smaller learning curves than others, they all seemed compatible with other technology we use like Rails, and they all seemed to have enough information available that we could overcome the learning curve.

In some areas, the results were starkly different. Vue.js and React both have strong ecosystems behind them, like using Vuex and Redux for state, and Jest for unit tests. They are both fairly mature, so we wouldn’t expect major changes where an upgrade would feel like using a totally new framework. Finally, they both have large communities, including popular local meetups and even conferences. Thus, we decided to prototype both of those frameworks towards making our final decision.

Prototype

Now that we were down to two frameworks to prototype, we also had to decide what to actually prototype. In this case, we wanted to prototype something already built in our application, so that we could put the frameworks’ incremental adoptability to the test. Ideally, we’d all be working in an area of our applications that we were familiar with. This turned out to be pretty difficult as many of us were new engineers.

We settled on prototyping our user management tool. We realized that multiple squads had done work on the tool, so we had two engineers familiar with the tool. Each of us paired with another engineer and each pair picked one of the two frameworks.

Struggles and successes

We discovered that prototyping was a lot more complex than researching the tools. Research wasn’t too hard to fit between meetings. To prototype, we had to ensure our dev environments were set up (for some of us, in a different application than we usually worked in) and then we had to build the features while learning the new tools. It was also harder to shift away from writing code for normal squad work to writing code for a side project.

Over the next few weeks, we gradually shifted our tactics to make progress on the prototype. Each group realized it would be better to set aside time for pair programming, which had a few benefits:

• The time was blocked off, making it easier to step away from normal squad work.
• Only one person on each given day needed to have everything set up and working.
• It was easier to work while one person drove the code, and another could research how the framework works.

While this helped, after a few weeks we were still disappointed at the progress we hadn’t made. An hour is not much time to get into the groove of coding, especially with an unfamiliar technology. We decided we needed larger blocks of time, so we scheduled some large blocks of time we could all use to make progress. These afternoons led to great progress on the prototypes, helping us decide as a group that both frameworks felt like feasible options. It was time to call the prototypes done.

Then what?

On realizing that either framework would meet our needs, we surveyed engineering to find their preferences and if there was anything more to consider in our decision. We asked engineers whether they preferred Vue.js or React, how strong that preference was, and if others had experiences to share. With 21 responses, the survey results didn’t lead to a clear favorite.

With those results, the working group went back to discuss the options. Knowing that either would meet our needs, we went back to our initial investigations and prototypes to deeply understand which framework would be better. We noted that Vue.js had a slightly easier learning curve. We also appreciated that the tech stack to go along with it was fairly standardized in the industry, so we didn’t expect more difficult decisions on how to unit test or bundle the code. Additionally, we anticipated another difficult task to begin rolling out a new framework. Since Vue.js had a slight edge in our survey, we were excited to propose the framework with more engineers passionately supporting it.

Since engineering decisions are made collectively, we had one last step to finalize Vue.js as our framework of choice — agreement from the rest of the engineering team. Thankfully, our research, prototypes, and final decision making were easily understood by engineers and the whole team agreed to move forwards with Vue.js.

Are you interested in seeing where our Vue.js journey has taken us, and being part of future technology decisions? We’re hiring!

Choosing a Front-End Framework was originally published in Building Panorama Education on Medium, where people are continuing the conversation by highlighting and responding to this story.

Very good breakdown of what’s going on between both frameworks