Writing Scalable and Maintainable React Code with SOLID Principles

If you've been working with React for a while, you've probably heard about best practices like keeping components small, making them reusable, and separating concerns. But have you ever considered applying SOLID principles to your React projects? Originally introduced by Robert C. Martin (aka Uncle Bob) for object-oriented programming, SOLID principles help developers write scalable, maintainable, and robust software. While JavaScript’s dynamic nature doesn’t always align with traditional OOP paradigms, React’s component-based architecture makes it an excellent candidate for SOLID principles. In this article, we’ll break down each of the five SOLID principles—Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion—and explore how they naturally fit into React development. By the end, you'll have practical strategies to write cleaner, more modular React components that scale effectively. S - Single Responsibility Principle The Single Responsibility Principle states that a class (or function) should have one and only one reason to change. In the context of React, this means each component should have a single responsibility. React’s component-based architecture naturally encourages SRP by breaking down UI elements into small, focused components. Keeping components granular improves reusability, readability, and testability. ✅ Good Example: A well-structured dashboard page. Here, FinishedBooksGraph, NewBook, and NewReview are separate components handling their respective responsibilities, instead of one bloated Dashboard component trying to do everything. function Dashboard() { return ( ); } ❌ Bad Example: A component that does too much. This component violates SRP by handling both file uploading and displaying a file list. Instead, it should be broken into FileUpload and FileList components. function Dashboard() { function uploadFile() {...} return ( Your Saved Files Upload File {files.map(file => ( {file.name} ))} ); } O - Open-Closed Principle The Open-Closed Principle states that software entities (components, modules, functions) should be open for extension but closed for modification. In React, this means creating flexible, reusable components that can be extended without modifying their core logic. This is achieved using props and higher-order components (HOCs) or hooks. ✅ Good Example: A reusable Button component. Here, the Button component remains unchanged while allowing different variations through props. const Button = ({ text, style, onClick }) => { return ( {text} ); }; // Reusing the Button component with different styles and behaviors const CancelButton = () => ( ); const SubmitButton = () => ( ); ❌ Bad Example: Hardcoded button logic. This design violates OCP because modifying the button requires editing the original component instead of extending it. const Button = ({ type }) => { if (type === "cancel") { return Cancel ; } else if (type === "submit") { return Submit ; } }; L - Liskov Substitution Principle The Liskov Substitution Principle states that subtypes must be replaceable by their parent type without breaking functionality. In React, this principle applies when designing components with inheritance or composition. If a derived component cannot be seamlessly swapped in place of its parent component, LSP is violated. ✅ Good Example: Swappable button components - Both CancelButton and CTAButton can replace Button without breaking functionality, ensuring LSP compliance. const Button = ({ text, style, onClick }) => { return ( {text} ); }; const CancelButton = () => ( ); const CTAButton = () => ( ); ❌ Bad Example: A subclass that doesn’t follow the parent’s contract const Button = ({ text, style, onClick }) => { return ( {text} ); }; // This violates LSP because it breaks the expected contract of a button const LinkButton = ({ href, text }) => { return {text} ; // No onClick function }; 🔴 Why this breaks LSP: LinkButton does not support onClick, meaning it cannot replace Button in all cases. If another part of the code expects an onClick function, LinkButton will break the program when used as a Button replacement. The correct approach would be to extend Button instead of replacing it: const LinkButton = ({ href, text }) => { return window.location.href = href} />; }; Now, LinkButton maintains the expected behavior of a button, satisfying LSP. I - Interface Segregation Principle The Interface Segregation Principle states that components should only depend on the data they need—avoiding passing unnecessary props or forcing components to implement unused functionality. ✅ Good Example: Passing only necessary props. Here, DashboardHeader only receives the name, instead of an entire user object with unnecessary properties. const DashboardHeader = ({ name }) => { return Hello, {name}! ; }; function Dashboard() { return ( ); } ❌ Bad Example: Passing properties through multiple functions (Prop Drilling) function Dashboard() { return ( ); } const WidgetContainer = ({ userName, userImage }) => { return ( ); }; const UserInfoWidget = ({ userName, userImage }) => { return ( ); }; const UserAvatar = ({ userName, userImage }) => { return ( {userName} ); }; 🔴 Why this violates ISP: userName and userImage are unnecessarily passed through multiple components, even though only UserAvatar actually needs them. This forces WidgetContainer and UserInfoWidget to depend on props they don’t actually use, violating ISP. Better approach: Use React Context API or a state management tool instead of passing down unnecessary props. ✅ Fix with Context API: const UserContext = React.createContext(); function Dashboard() { return ( ); } const WidgetContainer = () => ; const UserInfoWidget = () => ; const UserAvatar = () => { const { name, image } = React.useContext(UserContext); return ( {name} ); }; 💡 Why this follows ISP: WidgetContainer and UserInfoWidget no longer depend on userName or userImage. UserAvatar directly gets the data it needs, avoiding unnecessary dependencies. D - Dependency Inversion Principle The Dependency Inversion Principle states that components should depend on abstractions, not concretions. This means avoiding direct dependencies on implementation details and instead using abstractions like hooks, context, or higher-order components. ✅ Good Example: Abstracting API calls with a separate service // apiService.js (Abstraction Layer) export const apiService = { createProduct: async (formData) => { try { await axios.post("https://api/createProduct", formData); } catch (err) { console.error(err.message); } }, }; // Custom Hook (Abstraction for Components) const useProducts = () => { return { createProduct: apiService.createProduct }; }; // UI Component (Only Handles UI) const ProductForm = ({ onSubmit }) => { return ( ); }; // Component Using the Abstraction const CreateProductForm = () => { const { createProduct } = useProducts(); return ; }; By separating API logic into a custom hook (useProducts), we decouple components from direct API calls, making them more flexible and testable. ❌ Bad Example: Hardcoding API calls inside components\ const CreateProductForm = () => { const createProduct = async () => { await axios.post("https://api/createProduct", formData); }; return ... ; }; This violates DIP by directly coupling API logic to UI components, making it harder to modify or test. Applying SOLID principles to React projects results in cleaner, more maintainable, and scalable applications. While these principles were originally designed for OOP, React’s component-based nature aligns well with them. By focusing on small, reusable, and well-abstracted components, you can build applications that are easy to understand and extend over time. If you've been working with React for a while, you've probably heard about best practices like keeping components small, making them reusable, and separating concerns. But have you ever considered applying SOLID principles to your React projects? React Originally introduced by Robert C. Martin (aka Uncle Bob) for object-oriented programming, SOLID principles help developers write scalable, maintainable, and robust software. While JavaScript’s dynamic nature doesn’t always align with traditional OOP paradigms, React’s component-based architecture makes it an excellent candidate for SOLID principles. In this article, we’ll break down each of the five SOLID principles—Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion—and explore how they naturally fit into React development. By the end, you'll have practical strategies to write cleaner, more modular React components that scale effectively. S - Single Responsibility Principle The Single Responsibility Principle states that a class (or function) should have one and only one reason to change. In the context of React, this means each component should have a single responsibility. Single Responsibility Principle React’s component-based architecture naturally encourages SRP by breaking down UI elements into small, focused components. Keeping components granular improves reusability, readability, and testability. ✅ Good Example: A well-structured dashboard page. Here, FinishedBooksGraph, NewBook, and NewReview are separate components handling their respective responsibilities, instead of one bloated Dashboard component trying to do everything. function Dashboard() { return ( ); } function Dashboard() { return ( ); } ❌ Bad Example: A component that does too much. This component violates SRP by handling both file uploading and displaying a file list. Instead, it should be broken into FileUpload and FileList components. function Dashboard() { function uploadFile() {...} return ( Your Saved Files Upload File {files.map(file => ( {file.name} ))} ); } function Dashboard() { function uploadFile() {...} return ( Your Saved Files Upload File {files.map(file => ( {file.name} ))} ); } O - Open-Closed Principle The Open-Closed Principle states that software entities (components, modules, functions) should be open for extension but closed for modification. Open-Closed Principle In React, this means creating flexible, reusable components that can be extended without modifying their core logic. This is achieved using props and higher-order components (HOCs) or hooks. ✅ Good Example: A reusable Button component. Here, the Button component remains unchanged while allowing different variations through props. const Button = ({ text, style, onClick }) => { return ( {text} ); }; // Reusing the Button component with different styles and behaviors const CancelButton = () => ( ); const SubmitButton = () => ( ); const Button = ({ text, style, onClick }) => { return ( {text} ); }; // Reusing the Button component with different styles and behaviors const CancelButton = () => ( ); const SubmitButton = () => ( ); ❌ Bad Example: Hardcoded button logic. This design violates OCP because modifying the button requires editing the original component instead of extending it. const Button = ({ type }) => { if (type === "cancel") { return Cancel ; } else if (type === "submit") { return Submit ; } }; const Button = ({ type }) => { if (type === "cancel") { return Cancel ; } else if (type === "submit") { return Submit ; } }; L - Liskov Substitution Principle The Liskov Substitution Principle states that subtypes must be replaceable by their parent type without breaking functionality. Liskov Substitution Principle In React, this principle applies when designing components with inheritance or composition. If a derived component cannot be seamlessly swapped in place of its parent component, LSP is violated. ✅ Good Example: Swappable button components - Both CancelButton and CTAButton can replace Button without breaking functionality, ensuring LSP compliance. const Button = ({ text, style, onClick }) => { return ( {text} ); }; const CancelButton = () => ( ); const CTAButton = () => ( ); const Button = ({ text, style, onClick }) => { return ( {text} ); }; const CancelButton = () => ( ); const CTAButton = () => ( ); ❌ Bad Example: A subclass that doesn’t follow the parent’s contract const Button = ({ text, style, onClick }) => { return ( {text} ); }; // This violates LSP because it breaks the expected contract of a button const LinkButton = ({ href, text }) => { return {text} ; // No onClick function }; const Button = ({ text, style, onClick }) => { return ( {text} ); }; // This violates LSP because it breaks the expected contract of a button const LinkButton = ({ href, text }) => { return {text} ; // No onClick function }; 🔴 Why this breaks LSP: LinkButton does not support onClick, meaning it cannot replace Button in all cases. If another part of the code expects an onClick function, LinkButton will break the program when used as a Button replacement. The correct approach would be to extend Button instead of replacing it: LinkButton does not support onClick, meaning it cannot replace Button in all cases. LinkButton does not support onClick, meaning it cannot replace Button in all cases. If another part of the code expects an onClick function, LinkButton will break the program when used as a Button replacement. If another part of the code expects an onClick function, LinkButton will break the program when used as a Button replacement. The correct approach would be to extend Button instead of replacing it: The correct approach would be to extend Button instead of replacing it: const LinkButton = ({ href, text }) => { return window.location.href = href} />; }; const LinkButton = ({ href, text }) => { return window.location.href = href} />; }; Now, LinkButton maintains the expected behavior of a button, satisfying LSP. I - Interface Segregation Principle The Interface Segregation Principle states that components should only depend on the data they need—avoiding passing unnecessary props or forcing components to implement unused functionality. Interface Segregation Principle ✅ Good Example: Passing only necessary props. Here, DashboardHeader only receives the name, instead of an entire user object with unnecessary properties. const DashboardHeader = ({ name }) => { return Hello, {name}! ; }; function Dashboard() { return ( ); } const DashboardHeader = ({ name }) => { return Hello, {name}! ; }; function Dashboard() { return ( ); } ❌ Bad Example: Passing properties through multiple functions (Prop Drilling) function Dashboard() { return ( ); } const WidgetContainer = ({ userName, userImage }) => { return ( ); }; const UserInfoWidget = ({ userName, userImage }) => { return ( ); }; const UserAvatar = ({ userName, userImage }) => { return ( {userName} ); }; function Dashboard() { return ( ); } const WidgetContainer = ({ userName, userImage }) => { return ( ); }; const UserInfoWidget = ({ userName, userImage }) => { return ( ); }; const UserAvatar = ({ userName, userImage }) => { return ( {userName} ); }; 🔴 Why this violates ISP: Why this violates ISP: userName and userImage are unnecessarily passed through multiple components, even though only UserAvatar actually needs them. This forces WidgetContainer and UserInfoWidget to depend on props they don’t actually use, violating ISP. Better approach: Use React Context API or a state management tool instead of passing down unnecessary props. userName and userImage are unnecessarily passed through multiple components, even though only UserAvatar actually needs them. This forces WidgetContainer and UserInfoWidget to depend on props they don’t actually use, violating ISP. Better approach: Use React Context API or a state management tool instead of passing down unnecessary props. ✅ Fix with Context API: const UserContext = React.createContext(); function Dashboard() { return ( ); } const WidgetContainer = () => ; const UserInfoWidget = () => ; const UserAvatar = () => { const { name, image } = React.useContext(UserContext); return ( {name} ); }; const UserContext = React.createContext(); function Dashboard() { return ( ); } const WidgetContainer = () => ; const UserInfoWidget = () => ; const UserAvatar = () => { const { name, image } = React.useContext(UserContext); return ( {name} ); }; 💡 Why this follows ISP: WidgetContainer and UserInfoWidget no longer depend on userName or userImage. UserAvatar directly gets the data it needs, avoiding unnecessary dependencies. WidgetContainer and UserInfoWidget no longer depend on userName or userImage. UserAvatar directly gets the data it needs, avoiding unnecessary dependencies. D - Dependency Inversion Principle The Dependency Inversion Principle states that components should depend on abstractions, not concretions. This means avoiding direct dependencies on implementation details and instead using abstractions like hooks, context, or higher-order components. Dependency Inversion Principle ✅ Good Example: Abstracting API calls with a separate service // apiService.js (Abstraction Layer) export const apiService = { createProduct: async (formData) => { try { await axios.post("https://api/createProduct", formData); } catch (err) { console.error(err.message); } }, }; // Custom Hook (Abstraction for Components) const useProducts = () => { return { createProduct: apiService.createProduct }; }; // UI Component (Only Handles UI) const ProductForm = ({ onSubmit }) => { return ( ); }; // Component Using the Abstraction const CreateProductForm = () => { const { createProduct } = useProducts(); return ; }; // apiService.js (Abstraction Layer) export const apiService = { createProduct: async (formData) => { try { await axios.post("https://api/createProduct", formData); } catch (err) { console.error(err.message); } }, }; // Custom Hook (Abstraction for Components) const useProducts = () => { return { createProduct: apiService.createProduct }; }; // UI Component (Only Handles UI) const ProductForm = ({ onSubmit }) => { return ( ); }; // Component Using the Abstraction const CreateProductForm = () => { const { createProduct } = useProducts(); return ; }; By separating API logic into a custom hook (useProducts), we decouple components from direct API calls, making them more flexible and testable. ❌ Bad Example: Hardcoding API calls inside components\ const CreateProductForm = () => { const createProduct = async () => { await axios.post("https://api/createProduct", formData); }; return ... ; }; const CreateProductForm = () => { const createProduct = async () => { await axios.post("https://api/createProduct", formData); }; return ... ; }; This violates DIP by directly coupling API logic to UI components, making it harder to modify or test. Applying SOLID principles to React projects results in cleaner, more maintainable, and scalable applications. While these principles were originally designed for OOP, React’s component-based nature aligns well with them. By focusing on small, reusable, and well-abstracted components, you can build applications that are easy to understand and extend over time.