Container vs. Presentational: A Component Separation Pattern

Why it exists

Applications often need to display the same data in different ways. Without a clear separation, you might duplicate data-fetching and state management logic across multiple UI components. This leads to brittle code that's hard to maintain and test.

The mental model

Think of a restaurant. The 'container' is the chef in the kitchen who sources ingredients (fetches data), follows the recipe (business logic), and prepares the final dish. The 'presentational' component is the waiter who simply takes the finished plate from the kitchen and presents it to the customer (renders UI), without needing to know the recipe. The waiter can present the same dish on different types of plates, reusing the chef's work.

How it works

This pattern divides components into two distinct roles.

Container Components (Smart/Stateful): These components are the brains of the operation. They are responsible for fetching data from services or APIs, managing application state, and containing the business logic. They pass data down to their children via inputs and handle events emitted from them. They know how things work.

Presentational Components (Dumb/Stateless): These components are focused solely on the UI. Their job is to look good and display whatever data they are given via inputs. They are unaware of services, APIs, or where the data comes from. They communicate with their parent container only by emitting events. They know how things look.

When to use it

Use this pattern when building features that have complex state and logic, or when you anticipate needing to display the same data in multiple formats (e.g., a list and a grid). It is a foundational pattern for building scalable, reusable, and easily testable UIs in frameworks like Angular, React, and Vue.

When not to use it

For very simple, static components with no state or logic (like a footer), this separation is overkill. Applying the pattern too granularly can lead to excessive boilerplate code for simple features. Judge based on the component's complexity and potential for reuse.

One canonical example

A ProductPage container component uses a service to fetch a list of products. It then passes this list as an input to a ProductTable presentational component. The ProductTable simply renders the data in a table. If a user clicks a 'delete' button in a row, the ProductTable emits a delete event with the product's ID. The ProductPage container listens for this event and calls the service to perform the deletion.