Presentation components and container components

Time:2021-9-27

Original address

I found that when you are writing react applications, it is a good model to divide components into container components and presentation components. If you useReact has been around for a while, you may have found out about it long ago. here you areAn articleIt is well explained, but I would like to add a few points.

If you divide components into these two categories, you will find that they become easier to reuse and understand. In this article, these two types are called presentation components and container components. But you can read other titles in other articles, such as fat and skinny, smart and dumb, stateful and pure, screens and components, etc. They are not exactly the same, but the core ideas are similar.

Features of display components:

  • Focus on UI rendering.

  • The interior can contain presentation components / container components, which usually contain DOM tags and have their own styles.

  • Can passthis.props.childrenContains other components.

  • It does not depend on the rest of the app, such as fluxactionorstore

  • It does not define how data is loaded and changed.

  • Only throughpropsReceive data and callback function.

  • Even if you have a state, it is only the state of the UI, not data.

  • If you do not need to have a state, the hook function or performance optimization of the life cycle is usually presented as a function component.

  • Examples: page, sidebar, story, userinfo, list

Characteristics of container components:

  • Focus on operation.

  • The interior can contain presentation components / container components, but usually there is no DOM label and any style (unless the outer layer needs to be wrapped with a DIV).

  • Provide data and behavior for presentation / container components.

  • Calling fluxactionAnd pass it to the presentation component as a callback function.

  • It is usually stateful because it is often used as a data source.

  • Usually byAdvanced componentsInstead of handwriting generation. Advanced components include Redux’s connect(), relay’s createcontainer(), or flux’s container. Create().

  • Examples: userpage, followerssidebar, storycontainer, followeduserlist

I put them under different project folders to better distinguish them.

The benefits of this process

  • Better separation of concerns. By writing components in this way, you can better understand your app and UI.

  • Better reusability. You can use the same presentation component with completely different data sources and put it into a separate container component.

  • The presentation component can be called the “palette” of the app. You can put it on a page and let the design toss around at will without changing the logic of the app. On the page, you can perform regression testing of page snapshots.

  • This forces you to separate “layout components” such as sidebar, page and ContextMenu and use themthis.props.children, instead of duplicating the same label in different container components.

Keep in mind that components do not have to build dom. They distinguish the boundaries between UIs and give a way to combine UIs. You need to make good use of this.

When are container components introduced?

My suggestion is to use only the presentation components to build the app first. Finally, you will find that you pass too much into the intermediate componentpropsYes. At this point, you will realize that some components do not need to use the information they receivepropsJust pass them down to the next level, and when the sub components need more data, you need to connect all these intermediate components again. This is the right time to introduce container components. In this way, subcomponents can obtain data and behaviorpropsWithout having to go through the irrelevant components in the middle. In short, it is to take out these states for unified management rather than transfer them layer by layer

This is a process of writing and changing, so don’t expect it to be done overnight. When you try this pattern, you can gradually develop an intuition about when to introduce container components, just as you know when to use functions.
This is freeGetting started with ReduxSeries may help you

Comparison of some nouns

It should be noted that there is no technical difference between display components and container components. The difference lies in the purpose of use.

In contrast, some relevant (but different) technical differences are listed below:

  • Stateful and stateless. Have you used reactsetState()Method, there are also components that do not use the method. Are container components often stateful while presentation components are stateless? This is not absolute. Container components can also be stateless. Conversely, presentation components can also be stateful.

  • Classes and functions. fromReact 0.14Since then, components can be declared in the form of classes or functions. Function component declarations are simpler, but lack some of the features that class components have. Some of these restrictions may disappear in the future, but they still exist at present. Function components are easier to understand, so I suggest you use them first, unless you need state, life cycle, hook functions or performance optimization. At present, only class components have these functions.

  • Pure and impure. For those components that give the same props and state every time to ensure the same output, we think it is pure. Pure components can be class components / function components, or stateful / stateless. Since pure components do not rely on deep changes in props or state, its rendering performance can be improved through the life cycleshouldComponentUpdateProps / state is optimized by shallow comparison in. Currently, only class components can be definedshouldComponentUpdateMethod, but it may change in the future.

The above is not a way to distinguish display components from container components. In my experience, presentation components are more stateless and non pure function components, while container components are often stateful and pure class components, which is not a rule, but only observed. I also see the opposite under specific conditions. There is no need for dogma to distinguish display components from container components. Sometimes it’s hard to draw a dividing line without leaves. If you are confused about whether a specific component should be a container component or a presentation component, it means that it is still early to distinguish at this time. Keep doing it.

example:
Michael ChanofThis articlepierce to the heart of the matter.

In depth reading:

footnote

In my early articles, you will find that I use the “smart” and “dumb” components to call them. But now it seems inappropriate. More importantly, it does not reflect the differences in their use purposes. I think it would be more appropriate to use presentation components and container components.
And in the previous article, I thought that the display component can only include other display components, which now seems unreasonable. It contains the implementation details of the presentation component / container component. You should be able to replace the presentation component with a container component without changing the call location. Therefore, the presentation component can include both container components and presentation components, and so can container components.