DEV Community

Discussion on: React Beginner Question Thread ⚛

Collapse
 
varjmes profile image
james • Edited

When is it time to stop managing state at the component level and switch to something like Redux?

Collapse
 
kiraarghy profile image
Kara Stubbs

This is such a good question!

Collapse
 
dan_abramov profile image
Dan Abramov

This is a tough one; I think it really depends on whether you consider your app a React app or a Redux app. It’s also kind of fluid: you might still use Redux-like reducers for implementing local state, like at the end of this article.

I might use Redux for:

  • Data caches (note: there might be better solutions than Redux for this)
  • Things that are like “global variables” (e.g. authentication)
  • Things that have very complex update logic (e.g. a multimedia post editor)
  • Things that many distant components care about
  • In general, when the state tree shape is too different from the UI tree shape

Note that these use cases can be divided into:

  • Variables that are annoying to explicitly pass down the React tree
  • Update logic that is too complex to express with a bunch of setState()s
  • Data fetching and caching

The first use case really just means React doesn’t have a good way to do “global-ish” updates that directly update leaf nodes in the tree. So people use Redux to work around it, but it’s not really Redux per se that is useful to them, but the ability to broadcast updates. We plan to solve this with a new officially supported context API.

The second use case is also not as much about Redux, but about the setState() API. It is hard to keep a component with dozen setState()s readable. Redux gives you a paradigm to split that logic into independent parts (reducers), but it’s not obvious to most people that you can apply the exact same approach to the React state. I think we can solve this by making React state API slightly different, and it’s something we plan to look at in the future.

The third use case just means React doesn’t have a good solution for simple data fetching. You don’t usually want to keep it in the state because the data needs to be cached between mounting and unmounting components. So folks use Redux for this. We have some fun ideas about how to solve this with a first-class data fetching API in React, so watch that space.

Finally, when would I really prefer to use Redux? When its tradeoffs are useful. For example, for complex workflows where I want to reproduce bugs by “replaying” user actions. For distributed games that benefit from expressing everything as serializable actions. For extensible APIs where we want to let user hook into the update logic, like in Hyper. Etc. Where it really makes a difference.

The most important part is that the paradigm (actions and reducers) is not “bound” at all to Redux-the-library. You can take your reducers and use them to drive React local state in individual components, or vice versa.

Collapse
 
prasadpilla profile image
Prasad Pilla

Thanks for the honest recommendation Dan!!

Collapse
 
varjmes profile image
james

Thanks so much for your response Dan! Your community efforts are impressive and tireless :)

Collapse
 
mirmayne profile image
Daveyon Mayne 😻

Only when you share the same data with another component, Redux comes in.

Collapse
 
varjmes profile image
james

But isn't that just a case where you make the container of both hold the state and pass it down. I suppose when it gets more complex than that you'd use Redux.

Thread Thread
 
mirmayne profile image
Daveyon Mayne 😻

Personally, I'd say correct. When it feels wrong, that's when a state management comes in.