The Container-Presenter design pattern was initially coined by and has been highly adopted due to the rather clean implementation of the principle, as well as the elegant way it deals with complex ‘stateful’ logic and the consistency it maintains throughout an application. Dan Abramov Separation of Concerns 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: Container Components Presentation/Presentational Components 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 , 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: Dan Abramov 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 , 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. Since React 0.14 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 . Currently only classes can define shouldComponentUpdate() but that may change in the future. shouldComponentUpdate() hook 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 ( vs reference). technical purpose There are certain observations made by him from his experience, such as the fact that , whilst : Presentational Components tend to be pure, stateless functions 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 Good Separation of Concerns Ease of reuse of components throughout the application, which not only speeds up development time but also improves the visual consistency between views/layouts More consistent applications Easier understanding of the project structure Container Components Characteristics: Concerned with how data is processed Don’t usually have markup language as a direct child (They usually nest other components within with the use of wrapper divs or other semantic tags) Are often stateful (Store and handle React & Redux/Context/MobX state) Provide data & behavior to nested components (Container or Presenter) through props (data & callbacks) Examples: , which would hold higher-up data and distribute it throughout the page’s components: Home page, Login page, Register page, blog post page, etc. Views (Pages) would be a component that fetches and stores comments in regards to a post or an article, and would distribute the contents throughout a generic list component, or map that data through a list of components CommentsSection , Comment , which would be a synced/real-time list of popular topics in regards to a Social Media platform that constantly fetches data in real-time to provide insightful information in regards to the most popular/relevant topics on the platform PopularTopics Presentation Components Characteristics: Are concerned with how things look Depend exclusively on passed down data & callbacks (via props) They mostly contain UI-related state (isDropdownOpen, isPopoverOpen, etc.) Aren’t concerned with how data is loaded or mounted Examples: , a generic navigation bar component that has some predefined data (Links), or could have some nested dynamic links (Possibly dynamic relevant categories) which might be encapsulated within a Container Component Navbar , similar to the previously mentioned component Sidebar Navbar , a generic component that takes an array as a prop and renders a list; its only concern is rendering the data accordingly (Semantics + Styles) List 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: React Hooks Series What are Higher-Order Components (HoCs) in React? React, Gatsby, Next.js. What to choose for your next app’s Frontend? How to simplify your life as a React Developer This article was originally published here.
