As React applications grow, things can get messy fast—bloated components, hard-to-maintain code, and unexpected bugs. That’s where the SOLID principles come in handy. Originally developed for object-oriented programming, these principles help you write clean, flexible, and scalable code. In this article, I’ll break down each SOLID principle and show how you can use them in React to keep your components organized, your code easier to maintain, and your app ready to grow.
SOLID is an acronym that stands for five design principles aimed at writing clean, maintainable, and scalable code, originally for object-oriented programming but also applicable in React:
S: Single Responsibility Principle: Components should have one job or responsibility.
O: Open/Closed Principle: components should be open for extension **(easily enhanced or customized) but **closed for modification (their core code shouldn't need changes).
L: Liskov Substitution Principle: components should be replaceable by their child components without breaking the app's behavior.
I: Interface Segregation Principle: Components should not be forced to depend on unused functionality.
D: Dependency Inversion Principle: Components should depend on abstractions, not concrete implementations.
Single Responsibility Principle (SRP)
Think of it like this: Imagine you have a toy robot that can only do one job, like walking. If you ask it to do a second thing, like talk, it gets confused because it's supposed to focus on walking! If you want another job, get a second robot.
In React, a component should only do one thing. If it does too much, like fetching data, handling form inputs, and showing UI all at once, it gets messy and hard to manage.
const UserCard = () => {
const [user, setUser] = useState(null);
useEffect(() => {
fetch('/api/user')
.then(response => response.json())
.then(data => setUser(data));
}, []);
return user ? ( <div>
<h2>{user.name}</h2>
<p>{user.email}</p>
</div> ) : <p>Loading...</p>;
};
Here, the UserCard is responsible for both fetching data and rendering the UI, which breaks the Single Responsibility Principle.
const useFetchUser = (fetchUser) => {
const [user, setUser] = useState(null);
useEffect(() => {
fetchUser().then(setUser);
}, [fetchUser]);
return user;
};
const UserCard = ({ fetchUser }) => {
const user = useFetchUser(fetchUser);
return user ? (
<div>
<h2>{user.name}</h2>
<p>{user.email}</p>
</div>
) : (
<p>Loading...</p>
);
};
Here, the data fetching logic is moved to a custom hook (useFetchUser), while UserCard focuses solely on rendering the UI, and maintaining SRP.
Open/Closed Principle (OCP)
Think of a video game character. You can add new skills to the character (extensions) without changing their core abilities (modifications). That’s what OCP is about—allowing your code to grow and adapt without altering what’s already there.
const Alert = ({ type, message }) => {
if (type === 'success') {
return <div className="alert-success">{message}</div>;
}
if (type === 'error') {
return <div className="alert-error">{message}</div>;
}
return <div>{message}</div>;
};
Here, every time you need a new alert type, you have to modify the Alert component, which breaks OCP. whenever you add conditional rendering or switch case rendering in your component, you are making that component less maintainable, cause you have to add more conditions in the feature and modify that component core code that breaks OCP.
const Alert = ({ className, message }) => (
<div className={className}>{message}</div>
);
const SuccessAlert = ({ message }) => (
<Alert className="alert-success" message={message} />
);
const ErrorAlert = ({ message }) => (
<Alert className="alert-error" message={message} />
);
Now, the Alert component is open for extension (by adding SuccessAlert, ErrorAlert, etc.) but closed for modification because we don’t need to touch the core Alert component to add new alert types.
Want OCP? Prefer composition to inheritance
Liskov Substitution Principle (LSP)
Imagine you have a phone, and then you get a new smartphone. You expect to make calls on the smartphone just like you did with the regular phone. If the smartphone couldn’t make calls, it would be a bad replacement, right? That's what LSP is about—new or child components should work just like the original without breaking things.
const Button = ({ onClick, children }) => (
<button onClick={onClick}>{children}</button>
);
const IconButton = ({ onClick, icon }) => (
<Button onClick={onClick}>
<i className={icon} />
</Button>
);
Here, if you swap the Button with the IconButton, you lose the label, breaking the behavior and expectations.
const Button = ({ onClick, children }) => (
<button onClick={onClick}>{children}</button>
);
const IconButton = ({ onClick, icon, label }) => (
<Button onClick={onClick}>
<i className={icon} /> {label}
</Button>
);
// IconButton now behaves like Button, supporting both icon and label
Now, IconButton properly extends Button's behavior, supporting both icons and labels, so you can swap them without breaking functionality. This follows the Liskov Substitution Principle because the child (IconButton) can replace the parent (Button) without any surprises!
If B component extends A component, anywhere you use A component, you should be able to use B component.
Interface Segregation Principle (ISP)
Imagine you’re using a remote control to watch TV. You only need a few buttons like power, volume, and channel. If the remote had tons of unnecessary buttons for a DVD player, radio, and lights, it would be annoying to use.
Suppose you have a data table component that takes a lot of props, even if the component using it doesn’t need all of them.
const DataTable = ({ data, sortable, filterable, exportable }) => (
<div>
{/* Table rendering */}
{sortable && <button>Sort</button>}
{filterable && <input placeholder="Filter" />}
{exportable && <button>Export</button>}
</div>
);
This component forces all consumers to think about sorting, filtering, and exporting—even if they only want a simple table.
You can split the functionality into smaller components based on what’s needed.
const DataTable = ({ data }) => (
<div>
{/* Table rendering */}
</div>
);
const SortableTable = ({ data }) => (
<div>
<DataTable data={data} />
<button>Sort</button>
</div>
);
const FilterableTable = ({ data }) => (
<div>
<DataTable data={data} />
<input placeholder="Filter" />
</div>
);
Now, each table only includes the functionality that’s needed, and you’re not forcing unnecessary props everywhere. This follows ISP, where components only depend on the parts they need.
Dependency Inversion Principle (DIP)
Imagine you're building with LEGO blocks. You have a robot built with specific pieces. But what if you want to swap out its arms or legs? You shouldn't have to rebuild the whole thing—just swap out the parts. The Dependency Inversion Principle (DIP) is like this: your robot (high-level) doesn't depend on specific parts (low-level); it depends on pieces that you can change easily.
const UserComponent = () => {
useEffect(() => {
fetch('/api/user').then(...);
}, []);
return <div>...</div>;
};
This directly depends on fetch—you can’t swap it easily.
const UserComponent = ({ fetchUser }) => {
useEffect(() => {
fetchUser().then(...);
}, [fetchUser]);
return <div>...</div>;
};
Now, the fetchUser function is passed in, and you can easily swap it with another implementation (e.g., mock API, or another data source), keeping everything flexible and testable.
Final Thoughts
Understanding and applying SOLID principles in React can drastically improve the quality of your code. These principles—Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion—help you write components that are more modular, flexible, and easier to maintain. By breaking down responsibilities, keeping code extensible, and making sure each part of your app interacts in predictable ways, you can create React applications that scale more easily and are simpler to debug. In short, SOLID principles lead to cleaner and more maintainable codebases.
Top comments (0)