Presentational versus container components

In the React bindings for Redux, there is a principle of separating presentational from container components (sometimes also called dumb and smart components). It is best practice to put them in different folders.

Presentational components are:

Concerned with how things look

Usually written as functional components, because they are very simple; they only render a certain part of the user interface

Not connected to the Redux store

Contain both presentational and container components

Container components are:

Concerned with how things work

Usually written as class components or using React bindings, such as the React-Redux bindings, because they are usually stateful

Data sources—they provide data and behavior to presentational or other container components

The idea behind separating components in such a way is separation of concerns. It is much easier to reason about presentational components, as they don't have complex state changes. Usually, they simply take properties as input, and render the output accordingly, without using React or Redux state.

It is also possible to re-use presentational components with different state sources. Furthermore, presentational components can be written and modified by designers, who just need to care about how the user interface elements look in different variations. They do not need to touch or look into the application logic, as it is contained in the container components. 

You can use React Storybook ( https://getstorybook.io/) to create a development environment for your React components. In Storybook, you can visualize different states of your UI components and develop them interactively.

Most of your components will be presentational. You should use container components to connect certain presentational components to the Redux store.

上一章目录下一章