# 1.11 Smart vs Dumb Components in React
When building React applications at scale, engineers often debate how to organize components. A common pattern is separating components into **Smart** and **Dumb** buckets. This guide clears up the confusion around these terms, compares them to the Container/Presentational pattern, and breaks down when to use each approach for optimal frontend system design.
* * *
## 1\. Understanding Smart and Dumb Components
Instead of splitting logic and layout into separate parent-child files, the Smart vs. Dumb paradigm looks at how self-contained a component's responsibilities are.
### What is a Smart Component?
A **Smart Component** is an all-in-one component that handles everything required for its feature to work. It does not offload its logic to a parent layer.
* **All-in-One Execution:** It handles UI rendering, manages local state, connects to global state management, writes business logic, fires API calls, and handles browser events.
* **When to use it:** Perfect for self-contained pages or components that will **never be reused** anywhere else in the application.
> **Example:** A **Login Page**. The layout, email/password validation state, form submission handling, and the login API request are entirely unique to this view. There is no benefit to splitting them up because no other page will reuse a login form's specific layout or logic.
### What is a Dumb Component?
A **Dumb Component** focuses almost entirely on rendering UI, but it possesses one key structural difference from a purely presentational component: **it can hold minor local UI state**.
* **UI Focused with Micro-State:** It is built to display elements but can manage its own internal visual state (like keeping track of whether a dropdown toggle is open or closed).
* **No Core Logic:** It contains zero core business logic, never fires API calls directly, and doesn't know about global application stores.
* * *
## 2\. Comparison Breakdown: Smart vs. Dumb
To make the distinction clear, here is a breakdown of how responsibilities are distributed:
| Architectural Feature | Dumb Component | Smart Component |
| --- | --- | --- |
| **UI Rendering** | Yes | Yes |
| **Minor Local State (e.g., toggles)** | Yes (Limited to UI state) | Yes |
| **Global State Store Connection** | No | Yes |
| **Business Logic & Calculations** | No | Yes |
| **Direct API Data Fetching** | No | Yes |
* * *
## 3\. Architecture Blueprint: When to Choose Which Architecture
A common point of confusion is choosing between **Smart/Dumb single components** versus **Container/Presentational parent-child pairs**. Use this simple rule of thumb:
### Use Smart Components When:
* The component represents a highly specific page layer (like a **Login Page** or an isolated **Search Bar** configuration) where data isn't shared globally.
* The codebase or target feature is small, making hyper-splitting over-engineered.
* The component's layout will not be repeated elsewhere.
### Use Container vs. Presentational Pairs When:
* You need to reuse the exact same visual UI with entirely different datasets or behaviors.
* The UI is highly complex, making an all-in-one file cluttered and difficult to read.
* You are building a large-scale, enterprise application where clean separation of concerns is critical for automated testing.
* * *
## 4\. Code Implementation: The Smart Component Approach
Here is how a **Smart Component** handles its data fetching, interactive layout, and error boundaries all within a single unified file:
```jsx
import { useState, useEffect } from 'react';
export default function SmartProductCatalog() {
const [products, setProducts] = useState([]);
const [isLoading, setIsLoading] = useState(false);
// Smart Components manage their side-effects and network calls directly
useEffect(() => {
async function loadProducts() {
setIsLoading(true);
try {
const response = await fetch('https://fakestoreapi.com/products?limit=5');
const data = await response.json();
setProducts(data);
} catch (error) {
console.error("Failed to load catalog data:", error);
} finally {
setIsLoading(false);
}
}
loadProducts();
}, []);
const handleDisplayPrice = (title, price) => {
alert(`The item "${title}" retails for: $${price}`);
};
if (isLoading) return
Loading catalog elements...
;
return (
Catalog Items (Smart Component View)
{products.map((item) => (
{item.title}
))}
);
}
```
* * *
## Interview Q&A
### Q1: What makes a component "Smart" in React?
**Answer:** A component is considered "Smart" when it takes care of its own functionality. Instead of just accepting props to show a UI, a smart component writes its own API fetch calls, handles business logic, hooks into global state, and manages state changes all inside one file.
### Q2: Can a Dumb component have state?
**Answer:** Yes! This is a common misconception. A dumb component cannot have complex business state (like product lists from a database), but it can absolutely have *local UI state*. For example, tracking if a small card is expanded, or if a modal popup window is open or closed, is totally fine for a dumb component to handle.
### Q3: Why wouldn't we just use Container and Presentational components everywhere instead of Smart components?
**Answer:** While splitting everything into container and presentational components is clean, doing it for simple features adds unnecessary complexity. For a feature like a Login page—which has a unique layout that will never be reused anywhere else—splitting it into two separate files just forces you to write extra boilerplate code without any real benefit.
### Q4: If a Smart component handles its own network calls, does it mean we shouldn't use an API service layer file?
**Answer:** No, you should still use your API service layer wrapper utilities. Being a smart component just means the *execution trigger* (the `useEffect` hook that handles the component's state setting and data cycle) lives directly inside that component instead of being managed by an isolated parent container layer.