The Container-Presenter design pattern was initially coined by Dan Abramov and has been highly adopted due to the rather clean implementation of the Separation of Concerns principle, as well as the elegant way it deals with complex ‘stateful’ logic and the consistency it maintains throughout an application.

Container-Presenter Pattern Philosophy

The philosophy behind the Container-Presenter design pattern is rather simple; components are split up into 2 categories based on a couple of loosely-defined factors:

How to distinguish between Container & Presenter Components

It’s important to understand that the distinction between the presentational components and the containers is not to be made from a technical standpoint, but rather, from the standpoint of the purpose that they aim to serve.

According to Dan Abramov, there is some misunderstanding between various common technical distinctions, which shouldn’t necessarily be the driving factor when deciding what is and what is not a Container/Presenter Component:

Stateful and Stateless

Some components use React setState() method and some don’t. While container components tend to be stateful and presentational components tend to be stateless, this is not a hard rule. Presentational components can be stateful, and containers can be stateless too.

Classes and Functions

Since React 0.14, components can be declared both as classes and as functions. Functional components are simpler to define but they lack certain features currently available only to class components. Some of these restrictions may go away in the future but they exist today. Because functional components are easier to understand, I suggest you to use them unless you need state, lifecycle hooks, or performance optimizations, which are only available to the class components at this time.

Pure and Impure

People say that a component is pure if it is guaranteed to return the same result given the same props and state. Pure components can be defined both as classes and functions, and can be both stateful and stateless. Another important aspect of pure components is that they don’t rely on deep mutations in props or state, so their rendering performance can be optimized by a shallow comparison in their shouldComponentUpdate() hook. Currently only classes can define shouldComponentUpdate() but that may change in the future.

He strives to make it clear that there is a difference between the afore-mentioned dichotomies and where the line is actually drawn between what constitutes a Presentation or Container Component (technical vs purpose reference).

There are certain observations made by him from his experience, such as the fact that Presentational Components tend to be pure, stateless functions, whilst Container Components tend to be pure, stateful classes:

Both presentational components and containers can fall into either of those buckets. In my experience, presentational components tend to be stateless pure functions, and containers tend to be stateful pure classes. However this is not a rule but an observation, and I’ve seen the exact opposite cases that made sense in specific circumstances.

Ultimately, his last comment on this subject enforces the fact that the line between Presentation & Container components is to be drawn whenever the purpose of a certain component or block of components is clear:

Don’t take the presentational and container component separation as a dogma. Sometimes it doesn’t matter or it’s hard to draw the line. If you feel unsure about whether a specific component should be presentational or a container, it might be too early to decide. Don’t sweat it!

Benefits of the Container-Presenter Pattern

Container Components

Characteristics:

Examples:

Presentation Components

Characteristics:

Examples:

A simple and appropriate example of when and how to split up a component according to the Container/Presenter pattern could be found here.

You might also find these articles useful:

This article was originally published here.