When to use React’s built-in state management or a state management library

When writing data in React, state must be passed from the top downwards, with methods passed down if you need to change data above a component. This approach can become difficult when you need to pass data several components down, often through components that don’t need them. This post contains my thoughts on state management and state management libraries in React.

React’s built-in state management is often all you need

Before using a statement management library you should carefully consider whether you need one. Often the built-in state management React provides is enough for your application and you don’t need a state management library. Until you need features such as state change tracking, the ability to share data across the application to a deeply nested component, and more advanced state debugging tools, React’s built-in state management is usually enough for most small applications.

What is Redux?

What many React developers call Redux is actually Redux with React-Redux the official redux bindings for React. Redux is a predictable state container consisting of a single central application state and a set of predefined actions commonly referred to as the reducer. It is a complex approach to managing application state, and while it’s been made easier with the official Redux Toolkit the developers of Redux have the following to say on when you should use Redux: “In general, use Redux when you have reasonable amounts of data changing over time, you need a single source of truth, and you find that approaches like keeping everything in a top-level React component’s state are no longer sufficient.” (https://redux.js.org/faq/general#when-should-i-use-redux). Redux solves two problems for React developers: A lack of a global application state, and providing a way to track and debug state changes through the Redux Dev Tools and it’s time travel debugger a tool that lets you watch the application change a little at a time to track down bugs. However to solve one problem you must accept another. There is additional boilerplate code you have to add to your application, and Redux is hard to learn due to its many difficult to grasp concepts. As React continues to grow and mature, developers are given more options than React State and Redux. Wait to use Redux until you know you need it.

What is React Context?

React Context is another way to store state within React that needs to be passed across the component tree without using the prop drilling approach. Similar to Redux you have a provider element at the top of your component which passes data down to the rest of your application and is accessed by adding additional boilerplate code to your components. Many developers will find it is a simpler approach than Redux and opt for it when they need a global state. It does not require you to add additional NPM packages to your application and gives the developers the potential of greater performance. There are tradeoffs however, you cannot use the Redux Dev Tools with React Context, meaning you give up time travel debugging as well as libraries built to work with Redux. For example, Redux Persist lets you cache application state in local storage however this library would not work with React Context. That said a similar library could be written and may already exist.

Which should I use?

This depends on the needs of your application, and your needs as a developer. I’ve personally used Redux on smaller applications such as my Password Generator and had great success with it. The answer to this question is unique to the application that you are building and to you as a developer.