When to use redux state vs internal component state

There exists many other useful state management systems such as zustand or react context which may be more suited to your project, however this article is about redux versus the useState react hook.

There is an overhead in using redux to store your app state; the time it takes to create the actions, reducers, selectors, and dispatchers.

Therefore you might feel like just using useState or this.setState when building your component the first time, and use redux when the state requirements become more complex.

But you want to speed up your development process, so it makes sense to take a step back and make a decision early on in development of your component, on whether to store the component's state in redux, or internally to the component.

How do you determine this so you can quickly get started on building the component?

The first factor would be to ask yourself whether the state your component renders will need to be rendered elsewhere in your app, possibly in a completely different format. If this was the case, you would want this data to keep in sync between these components, so they render the shared data together and your app remains consistent and bug-free for the user.

An example of this would be 'dark mode/theme'. If your user has selected light or dark mode, in your <UserSettings/> component, that data will need to be visible by all of your UI components. You use a selector to get the theme from the redux state, instead of having to pass this as a prop down your entire component tree (plus your UserSettings component doesn't need to be at the top of that tree).

In other cases the choice is less obvious, let's take a component which allows a user to upload an image and render it on the screen.

In this case, whenever the user selects a file for upload by using an <input type="file"> element, you will want to store that file data URL in state, and then just render it with <img src={fileUrl}/>.

You can quickly implement internal state:

const [fileUrl, setFileUrl] = useState('');

in your component, and then render the UI which updates this state:

<input
  type="file"
  accept="image/*"
  onChange={e => setFileUrl(URL.createObjectURL(e.target.files[0])) }
/>
<img src={fileUrl}/>

Now you have a functional component in seconds that gets the job done.

However, what if for example that image is a user setting for their profile image, which is displayed in multiple places? In that case the obvious choice would be to store the image URL in redux state, so that it can easily be rendered anywhere in your app.

The simple use of useState allows you to quickly show a proof of concept that your code works, so that for more complex requirements you can introduce redux state, safe in the knowledge that your solution will work.

If however, for every single component you built, you automatically set up a redux structure, there would be an unnecessary overhead spent building each component. In addition to this, if there is a logic issue or bug, it may be much easier to resolve with the simpler internal state logic - so you don't need to contend with multiple redux files just for the issue with the one component.

useState is like a bicycle and redux like a car, you can beat the car in a race to a shop across town with a bicycle, but to get to a distant city, the car will always win. The bicycle is simple and effective in short range, and while the car is more clunky, it has a much larger range.

Key take aways:

• Ask yourself before you build a new component, does this data need to be rendered elsewhere in the app?
• If yes, ask yourself, would it be prudent to make a quick proof of concept with internal state first?