Thinking in React lays out how to structure components in React. When using Redux it's even more important to know how to structure your components. Therefore a small reminder in form of an article. :D
"Plans are only good intentions unless they immediately degenerate into hard work." - Peter Drucker
Planning your application and components before you start writing code will help you save a lot of time later on. With all the possible features React components can have, they clutter very fast and become soon not manageable. Dividing the purpose and functionality of your components will significantly improve your workflow when your app starts to grow.
- presentational components (how things look)
- container components (how things work)
Make sure to read the article from Dan Abramov, where he explains the key ideas between those components in detail.
| Presentational Components | Container Components | |
|---|---|---|
| Purpose | How things look (markup, styles) | How things work (data fetching, state updates) |
| Aware of Redux | No | Yes |
| To read data | Read data from props | Subscribe to Redux state |
| To change data | Invoke callbacks from props | Dispatch Redux actions |
| Are written | By hand | Usually generated by React Redux |
Source: https://github.com/reactjs/redux/blob/master/docs/basics/UsageWithReact.md
- React Component
- Manage own State
- May take place in React Lifecycle
- Stateless
- Rely on Props
- Pure functions
- Don't take place in React Lifecycle
"I call components encapsulated React components that are driven solely by props and don't talk to Redux. Same as “dumb components”. They should stay the same regardless of your router, data fetching library, etc." - Dan Abramov
See this article for a great example.
"I call containers React components that are aware of Redux, Router, etc. They are more coupled to the app. Same as “smart components”." - Dan Abramov
If you gained something from this article let me know with a comment or heart. Make sure to follow for more :)