Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

React-Redux: Should all component states be kept in Redux Store

Say I have a simple toggle:

When I click the button, the Color component changes between red and blue

I might achieve this result by doing something like this.

index.js

Button: onClick={()=>{dispatch(changeColor())}} Color: this.props.color ? blue : red 

container.js

connect(mapStateToProps)(indexPage) 

action_creator.js

function changeColor(){  return {type: 'CHANGE_COLOR'} } 

reducer.js

switch(){ case 'CHANGE_COLOR': return {color: true} 

but this is a hell of a lot of code to write for something that I could have achieved in 5 seconds with jQuery, some classes, and some css...

So I guess what I'm really asking is, what am I doing wrong here?

like image 481
l2silver Avatar asked Feb 10 '16 23:02

l2silver


People also ask

Should you keep all component states in the Redux store?

Some users prefer to keep every single piece of data in Redux, to maintain a fully serializable and controlled version of their application at all times. Others prefer to keep non-critical or UI state, such as “is this dropdown currently open”, inside a component's internal state. Using local component state is fine.

What should be in Redux store?

With redux, you would ideally store as little component state in your react components themselves and instead move that to the redux state tree. I believe a good point to start incorporating redux is when your app gets to a certain point where your components are no longer just "dumb" components that display data.

Where is the entire state kept in Redux?

The state in Redux is stored in memory, in the Redux store. This means that, if you refresh the page, that state gets wiped out. The state in redux is just a variable that persists in memory because it is referenced (via closure) by all redux functions.

Should I use React state with Redux?

It is totally fine to use a mix of React component state and Redux state. You might for example use non-critical UI state inside React components, like if a checkbox is checked or not. The official Redux FAQ has a good list of rules of thumb for determining what kind of data should put into Redux.


2 Answers

Redux is primarily intended for "application state." That is, anything related to your application logic. The view built on top of it is a reflection of that state, but does not have to exclusively use that state container for everything it does.

Simply ask these questions: Is this state important to the rest of the application? Will other parts of the application behave differently based on that state? In many minor cases, that will not be the case. Take a drop down menu: The fact that it's open or closed probably won't have an effect on other parts of the app. So, wiring it up to your store is probably overkill. It's certainly a valid option, but doesn't really net you any benefits. You're better off using this.state and calling it a day.

In your particular example, does the color that button is toggled to make any difference in other parts of the application? If it's some sort of global on/off toggle for a major part of your application, it definitely belongs in the store. But if you're just toggling a button color when you click the button, you can leave the color state locally-defined. The action of clicking the button might have other effects that require an action dispatch, but that is separate from the simple question of what color it should be.

In general, try to keep your application state as small as possible. You don't have to shove everything in there. Do it when you have to or it makes a lot of sense to keep something there. Or if it makes your life easier when using Dev Tools. But don't overload its importance too much.

like image 74
Tim Dorr Avatar answered Nov 02 '22 07:11

Tim Dorr


Redux FAQ: Organizing State
this part of redux official doc well answered your question.

Using local component state is fine. As a developer, it is your job to determine what kinds of state make up your application, and where each piece of state should live. Find a balance that works for you, and go with it.

Some common rules of thumb for determining what kind of data should be put into Redux:

  • Do other parts of the application care about this data?
  • Do you need to be able to create further derived data based on this original data?
  • Is the same data being used to drive multiple components?
  • Is there value to you in being able to restore this state to a given point in time (ie, time travel debugging)?
  • Do you want to cache the data (ie, use what's in state if it's already there instead of re-requesting it)?
like image 34
chuck911 Avatar answered Nov 02 '22 07:11

chuck911