CODEWITHSUNDEEP
reactjsreduxreact-reduxreact-state-management
kla
kla

Reputation: 63

When we use Redux with React, do we put all states into Redux?

I may choose to put some states as component states, and I thought that's what useState() is for.

However, the book Learning React, O'Reilly, 1st Ed, 2nd Release, p. 185, said:

With Redux, we pull state management away from React entirely.

Also, in the official Redux website, the example "Real World" also even make isFetching a Redux state, instead of component state. (Its GitHub repo).

I also found that in some project in some company, coworkers seem to favor everything as Redux state even when it can be a component state.

For example, in that same book, p. 185, it said we even keep which messages is expanded or not into the Redux store. But which message is expanded, seems entirely local to this component and it has nothing whatsoever to do with other components at all. In the case of isFetching, as least I can understand it that what if the whole app wants to unite the isFetching of any component into a global spinner indicator.

This webpage also says:

The solution in idiomatic React – i.e., code that was written the way an experienced React developer would write it – is to have what's called a single source of truth, which is one master state for most if not all of your application, then send that state down as props to your child components.

be a pragmatic programmer: go for stateless components where possible

I don't quite understand it. How does it work? When a state can be a component state, would it be perfectly ok to put it as component state? Or in React / Redux, the rule is to make everything into a Redux state? (in such case, then what is useState() for?)

Update: I like @RemcoGerlich's answer, and I put two links as a comment under his answer. Those are official docs stating "Don't put all states into Redux".

Upvotes: 1

Views: 1037

Answers (2)

RemcoGerlich
RemcoGerlich

Reputation: 31250

It is an eternal discussion. There are several types of state that have their own best ways to solve them:

  • Navigation related state, to go to different "pages" or kinds of views in your application. For this, using the browser URL has many usability advantages, and using React Router is much more natural.

  • State retrieved from the backend through its API, this isn't really state of your frontend at all, you have a cache. For this a library like React Query is much more suited (it handles e.g. your "isFetching" state, as well as reloading things after a while).

  • Small bits of state that only have local significance, like whether a small control that hides some detail is now open or closed. I feel things that are used only locally should be stored only locally, like in useState.

Often the number of things left is quite small, and putting them in one or a few Contexts is fine, except if your application becomes quite complicated.

But, Redux comes with its own advantages -- a single way to make undo functionality, a way to serialize / rehydrate its entire state, and Redux dev tools that allow looking at the action history in case you find yourself debugging complicated effects to do with the order in which happened. If you use this heavily, then you would be inclined to store more state in Redux than you would if you only make a little use of these advantages.

So it's matter of degree, it's more art than exact science, there are no strict rules. "Put everything in Redux" certainly sounds suspect to me, but who knows about your team.

Upvotes: 2

shiponcs
shiponcs

Reputation: 1677

If your state and operations on that state are moderate in size then react Context API is really smart enough to support you. Even, @danAbrvmov writes:

React Redux uses context internally but it doesn’t expose this fact in the public API. So you should feel much safer using context via React Redux than directly because if it changes, the burden of updating the code will be on React Redux and not you.

You may like reading his article: You Might Not Need Redux

As for, you see some companies and projects using Redux, this is because Redux is out there for a long time and Context API is newer. Moreover, if you really need some features like redux-thunk, you can still use it.

I doubt you clearly understand how the state is handled in React.

In a typical React application, data is passed top-down (parent to child) via props. You may like my answer on another post to learn when we may need Context API or Redux at all: https://stackoverflow.com/a/62980048/9857078

Upvotes: 0

Related Questions