In old days we see that websites were not that much evolved. I would say Web Applications are just an evolved website, which uses somewhat more JS for making Websites more & more Interactive.

And as providing users a better User Experience, there is need of managing data at clients browser. I would like to take example of React, but somewhat same thing applies to other Front-end frameworks, like Angular or Vue.

When I started using React, things started making a little bit more sense, and I realized some rules there like,

  1. React Applications uses components to make application more Reusable
  2. We can pass data from one component to another component using props

But still some leaf components, we cant pass data to main root component directly.

This was somewhat confusing to me so, where should I hold my data in application, should it be distributed or central ?

I just want to explain this stuff from my beginner experience, on building some logical decisions on where should we store it.

The Prop Drilling Approach

In this we just pass data from parent component to child component, like if there is a component A , it can pass its state to its child components. So, if there are multiple components which are depending on single parent component and there should 1 level of hierarchy.

But as number of levels increases and there are multiple components dependent on multiple components for data. This Prop drilling approach will might be a disaster.

Pros

  • When working with small applications, it will be a simple & will serve purpose in easy way
  • Data passed as props can be easily changed if needed

Cons

  • As Codebase increases, prop drilling will make over complicate things
  • Props passing to end component, will increase unnecessary increase in codebase if level of hierarchy is large

To Solve this issue, we can make a central store which can pass data directly to those components only, which require them, this will reduce the extra code, and make easy for components to share data with Central store.

There are multiple solutions which uses central store, like Redux or Context APIs or etc. But I’ll be going through with above 2 only, as I have used above 2 only.

Redux

Redux provides a state container for Web Apps, specifically JS Apps. It provides a centralized state solution, which enables component to exchange data with other components at any level of hierarchy.

Redux uses the concept of Reducers, Actions & dispatch events which follows a set of rules to make changes to central store.

My main aim is to tell you about the approaches, so I’ll not be writing here about Redux Working, things are well documented in documentation & that are super easy and beginner friendly.

Pros

  • Central Store, any component can access any state from store.
  • No need to pass data through props, so no prop drilling
  • Reduces number of rerenders, which reduces shallow copying
  • Testing is easier as, Data & UI States are separated

Cons

  • For simpler applications, the boiler plate code is too much to handle
  • No state safety, any state can read data from any state, so it makes state somewhat vulnerable
  • Redux state is Immutable, so whenever state gets updated, this uses more & more memory

Context APIs

Context APIs are the feature of React Hooks, so it’s the feature of React itself, so no need to install any 3rd party library. Using Context APIs, we can create different number of context APIs, like so maintaining UI State, User State, Browser state, Auth state etc. which enables Encapsulation, which ensures safety.

It makes codebase much more cleaner in comparison to Redux.

Pros

  • Easy to understand & It is part of React Hooks
  • Can create multiple contexts for maintaining different types of states

Cons

  • Context APIs are not designed for multiple Refresh
  • Decreases maintainability, even if we have made custom helpers
  • Reusing Components, becomes somewhat difficult, because data not always comes from Contexts and Props.

Summary

There are multiple approaches for state management, it just depends on the use case in which we are building our application. Is it small scale or big scale or Some toy Application? But when going with some big scale projects, we should opt for Redux, as it is widely used, and can handle high frequency updates, while Context APIs can’t handle high frequency updates.

In the end, “which one is better”, should be interpreted as “what is better for our product & team”. It depends on both Developers experience & the use case in project.

Extra Material

Check out - Redux & Flux Architecture