I'm referring to the two types of react components - presentation component and container component. In a more platform-agnostic description, is the container component just an adapter for a presentation component and the rest of the system? Or is it an instance of some other pattern?

  • 2
    Could you perhaps edit your question to explain what a “container component” is, for those of us that don't know React very well?
    – amon
    Feb 9 '17 at 22:25
  • 1
    but this question is meant to be answered by people who do know react
    – Andy
    Feb 10 '17 at 4:53

When you look at the adapter-pattern which is something like a translation- or glue- pattern, the answer is: no.

From Wikipedia:

Converts one interface to another so that it matches what the client is expecting


I find it hard to categorize this structure - or other "modern" javascript structurs - in "classical" pattern terminology. What comes perhaps closest is a mixture of delegation and mediator pattern. But with sprinkles of the M and C of MVC. The same goes for the frameworks, which describe themselves as MV* or so.

As far as I understand the distinction between container and presentation component, the first one is the computational part which organizes the data (whatever is necessary to do so) and hands the data to the presentation component whose job it is to "display" the computed results. They have a parent-child relationship.

  • It's more of a "mapping parts of the state object to props" situation, not a "computational" or "organizes data" situation, so it does smell like a "glue" or "translation" thing.
    – Andy
    Jun 25 '17 at 3:17

Is a react container component an instance of the adapter pattern?

No, it isn't. It's something that in the React world is called the container component pattern. As a general pattern though it kinda fits under "delegation", as Thomas Junk already mentioned in his answer.

But more than a patterns, the "container component" builds on top of a principle: The Single Responsibility Principle.

Instead of having one component perform two functions - presentation (1), and data fetching and business logic interactions (2) - you separate the two. The container component manages the data, actions, business interactions with the rest of the app, while the presentation component only handles presentation with props it receives from its container and any user interactions are passed to the container component instead of itself interacting with the rest of the application.

This has some advantages as well put by Dan Abramov, the creator of Redux:

  • Better separation of concerns. You understand your app and your UI better by writing components this way.

  • Better reusability. You can use the same presentational component with completely different state sources, and turn those into separate container components that can be further reused.

  • Presentational components are essentially your app’s “palette”. You can put them on a single page and let the designer tweak all their variations without touching the app’s logic. You can run screenshot regression tests on that page.

  • This forces you to extract “layout components” such as Sidebar, Page, ContextMenu and use this.props.children instead of duplicating the same markup and layout in several container components.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.