React has two main types of components, namely, “State Components” and “Stateless Components”. State components are broken down into “Class Components” and “Functional Components”. For more complex purposes such as API integrations, React State Components are recommended. In State Components, developers have to manage states as global variables in a specific component. With React 16.12.0 (Current stable release -14/11/2019), there are three main techniques to handle states.
React Context API
React Context API
Context API in React is a method to share data between the component tree structure without using Props. This way, developers will be able to share data without having to explicitly pass Props through every level of component.
Local Storage is a front-end storage (up to 10MB) provided by a web browser to store data. The main goal of using local storage over Redux and Context API is to retain data, even through multiple sessions or even after restarting the web browser or the computer. In this way, developers are able to store and restore data between two session breakdowns and continue the UI, allowing an optimised user experience in an application.
Front-End Data Caching
Caching is a technique of storing data near to the place of processing, in order to reduce the data transmission time through memory or servers. Since React applications are working with states and state is volatile, a caching technique is required to store states globally to keep them through a session interruption. A session interruption can occur due to many reasons such as a network failure, an API exception, browser timeout, accidental browser reloads or tab closes etc. After having a session interruption, to continue the application user journey with previous states, it is required to have a cache memory inside the application front-end.
Let’s assume that a user fills a form in a React application which is handled by states inside the source code. A session interruption can occur as mentioned above while filling the form, after filling the form or after submitting the form. In order to resubmit the form due to the session interruption, having to refill the form kills the usability of the application. To fix this, developers can integrate a caching mechanism in the front-end.
The application first checks for existing states in local storage and finds it’s empty. It will then create a cache entry. First, when the user is filling data, each state related to the data is appended to a predefined object which follows a set of JSON rules. For every state change, this object is updated and for every update, it is stored in the local storage. For every session restart, the program will first look for existing states in local storage and those values are fetched into the program and all the relevant states are updated. Then the user is able to continue the form without refilling it.
Sample state handling code fragment:
When the local storage is compared to the other web storage APIs, we have the following conclusions.
The session storage API is the same as the local storage but the data is destroyed during session interruptions. When it comes to Cookies, local storage has more capacity (Cookies have about 4KB allowed capacity), more security, and is more stable than Cookies. With IndexedDB, you can store data as tables with indexes but it is a more complex method than using local storage with objects. After this comparison, for front-end cache memory, the local storage is the most suitable storage type.