I've built a relatively large React app using Redux for state management. Etheryte's point is valid -- if state is only used within a single component (or maybe

I've built a relatively large React app using Redux for state management. Etheryte's point is valid -- if state is only used within a single component (or maybe shared with its immediate children), you're probably better off leaving it local to that component. And if it turns out you're wrong later and actually do need it somewhere else you can refactor and pull it into Redux at that time. If you have more than a few bits of state to manage, use multiple reducers and split your state into logical groups. Within each reducer, I use immutable.js `Record`s as the main state container. I also use Flow to strongly-type these reducers and get autocomplete and type checking of my state, but the benefits of that are mostly orthogonal to the benefits of using Redux. You should almost never try to "denormalize" data (store the same thing in multiple places) or eg. use Redux state to initialize a component's local state. Trying to keep these in sync will kill your mental model. Instead, use selectors to keep components in sync, and if a particular view is costly to compute as a function of your state you can memoize it (I use https://github.com/reactjs/reselect https://github.com/reactjs/reselect for that). But that's extra complexity that should only be added in the few cases that warrant it. I found that by organizing my code this way I was able to keep the parts of the app that I needed to make any particular change in my head easily, which did incredible things for developer velocity and happiness. :)