I recently learned Redux and I'm wondering how to combine thinking in Redux with the guidelines of the Reacts docs for thinking in React? facebook.github.io/react/docs/thinking-in-react.h…
My initial instinct is that you'd have to think through step 4 differently since some state would be in the Redux store rather than say placing components higher up the component chain.
The thing I'm having trouble with is how to plan container vs presentational components. (medium.com/@dan_abramov/smart-and-dumb-components…) Would you have to wait to plan your container components until step 5 since you don't know where your state would lie until then?
Is this how you've incorporated Redux into thinking in React? I'd also be curious if anyone uses a different template from the one in the docs to think in React / Redux that they've found works for them and could explain why.
Not a rock star
This should help you get started redux.js.org/docs/introduction
Brad Pearson
I think the dirty secret of Redux is that you don't *really* need it. You can choose to use it, and there are some good reasons to use it, but there's no reason everything in React can't just be props, children and state. Unless there is a compelling reason for me to use Redux, I don't.
What Redux gives you is the ability to inject state into any component, anywhere. It can make it easy to get lazy with how you construct your application and nest your components unless you are diligent and keep some kind of structure in your state object that maps well to your set of components.
If I were new starting out in React, I'd just do state and props and try to keep components in charge of their own data. When you work out this separation, it will make your app more structured and easier to manage.
If you have the use case of saving an entire huge object at once, then maybe Redux is a better choice, but it adds overhead and complexity that can be heavy.