Divide and Conquer: Smarter UIs with Container–Presenter

The Container–Presenter pattern splits a component into two parts:

• Container → handles logic, state, data fetching
• Presenter → handles UI and rendering only

In React, many components start small but quickly mix business logic (data fetching, state updates) with presentation logic (UI rendering). This leads to:

• Messy code that’s hard to test
• Difficulty reusing UI components
• Developers stepping on each other’s work in teams

The Container–Presenter pattern solves this by separating concerns.

How to Achieve It

// Container (logic only)
const UserContainer = () => {
const [user, setUser] = useState(null);

useEffect(() => {
fetch("/api/user")
.then(res => res.json())
.then(setUser);
}, []);

return <UserProfile user={user} />;
};

// Presenter (UI only)
const UserProfile = ({ user }) => (
<div>
{user ? <h1>Hello {user.name}</h1> : <p>Loading...</p>}
</div>
);

👉 The container knows how to get data;
👉 The presenter only knows how to show data.

Best Practices

• Keep presenter components stateless (only props).
• Use containers for data fetching, hooks, state management.
• Write unit tests for presenters, integration tests for containers.
• Don’t overdo it — small apps may not need this split.

Real-World Examples

1. User Dashboard → A container fetches user profile & stats, presenters render charts, cards, and details.
2. E-Commerce Product Page → A container fetches product info, presenters handle gallery, description, and price tag.
3. News Feed → A container manages API pagination, presenters handle the article cards layout.

Advantages

• Cleaner separation of logic and UI
• Easier to test components in isolation
• Improves team collaboration (backend logic devs vs frontend UI devs)
• Presenter components become reusable across different containers

Disadvantages

• Adds more files and boilerplate
• Can feel heavy for small projects
• May be overkill if logic and UI are already simple

Common Problems / Pitfalls

• Accidentally mixing logic back into presenters
• Creating too many containers → unnecessary complexity
• Passing down too many props (prop drilling) instead of using Context

Summary Recommendation

Use Container–Presenter when your React components start mixing logic and UI in ways that reduce clarity. It’s a powerful pattern for scaling apps and teams, but keep it light in small projects to avoid boilerplate.