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?

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.

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)?

For the purpose of highlighting the great link provided by @AR7, and because that link moved a while back:

>Use React for ephemeral state that doesn't matter to the app globally and doesn't mutate in complex ways. For example, a toggle in some UI element, a form input state. Use Redux for state that matters globally or is mutated in complex ways. For example, cached users, or a post draft. > >Sometimes you'll want to move from Redux state to React state (when storing something in Redux gets awkward) or the other way around (when more components need to have access to some state that used to be local). > >The rule of thumb is: do whatever is less awkward. > >Dan Abramov: https://github.com/reactjs/redux/issues/1287#issuecomment-175351978

This is the problem with Redux, developers overengineer state designs, which always turn applications that could be fairly simply into complex structures.

Redux to me, is a react architecture that should be well planned and designed before implementing.

https://kentcdodds.com/blog/application-state-management-with-react/ ”One of the reasons redux was so successful was the fact that react-redux solved the Prop-Drilling problem. The fact that you could share data across different parts of your tree by simply passing your component into some magical connect function was wonderful. Its use of reducers/action creators/etc. is great too, but I'm convinced that the ubiquity of redux is because it solved the Prop-Drilling pain point for developers.

This is the reason that I only ever used redux on one project: I consistently see developers putting all of their state into redux. Not just global application state, but local state as well. This leads to a lot of problems, not the least of which is that when you're maintaining any state interaction, it involves interacting with reducers, action creators/types, and dispatch calls, which ultimately results in having to open many files and trace through the code in your head to figure out what's happening and what impact it has on the rest of the codebase. “”

Yes, it's worth striving to store all component state in Redux. If you do, you will benefit from many features of Redux like time travel debugging and replayable bug reports. If you don't, those features could be completely unusable.

Any time you do not store a component state change in Redux, that change is completely lost from the stack of Redux changes and your application UI will be out of sync with the store. If this is not important to you then ask yourself why use Redux at all? Your application will be less complex without it!

For performance reasons, you may wish to fall back to this.setState() for anything that would dispatch many actions repeatedly. For example: storing the state of an input field in Redux each time the user types a key may result in poor performance. You can solve this by treating it like a transaction: once the user action is "committed," save the final state in Redux.

Your original post mentions how the Redux way is a "hell of a lot of code to write." Yes but you can use abstractions for common patterns such as local component state.