Summary of redux-react best practices
Please raise an issue or a PR when you see anything inappropriate (with valid arguments).
Compared to storing everything in redux's store, letting Component to handle their own has the benefit of
- more direct,
setState -> render -> shouldComponentUpdateinstead ofaction -> store -> render -> shouldComponentUpdate - more readable as you can know what happen to the state just by looking at the Component's code, without digging into the action and reducer.
an example of local UI state would be whether a checkbox is checked or not, {checked: true}
This is being repeated in quite a lot of places, one reason being impure reducer will break the time travel functionality of redux-dev-tools, as you cannot revert side effect. More details
All side effects should be in actions, actions should be the only way Component interact with outside world (store, ajax or websocket call). This will simplify the component, and provide a simpler, less buggy architecture.
Separate components into two categories,
- Smart - Components that have direct access to store and actions
- Dumb - Components that have no direct access to store and actions This allow Dumb components to be highly composable and seldom need to be change There are a few more rules to be consider, kindly check link below. More details
Actions being the bridge of your application to the outside world should in charge in reshaping data shape if necessary, for example if external api return an array ['Female', '178cm', '55kg'] , what you want to store is {gender: 'F', height: '178', weight: '55'}, this conversion should happen in ActionCreators.
Selectors should only have 1 reason to be triggered, if selectors have more than 1 reason to be triggered, some of the computation would be meaningless, it will not affect program correctness if things are pure, but it would means unnecesary computations.