- SOLID principles were designed for OOP languages but apply directly to React components, hooks, and props. - **S** — Single Responsibility: one component does one thing. If you can describe it with "and," split it up. - **O** — Open/Closed: extend components through props, not by modifying their source code. - **L** — Liskov Substitution: always pass through the props of any native element your component wraps. - **I** — Interface Segregation: don't pass a whole object when a component only needs one property from it. - **D** — Dependency Inversion: inject behavior through props instead of baking it into the component. - TypeScript makes all five principles easier to enforce — use interfaces and types throughout.

## What Are SOLID Principles and Why Do They Matter in React? SOLID is an acronym for five design principles — Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion — developed by Robert C. Martin (Uncle Bob). They were originally written for object-oriented programming languages, but every one of them translates directly to React. In React terms: a class becomes a component, a function, or a module. An interface becomes a props type. Inheritance becomes composition. The principles stay the same. The vocabulary shifts. Following SOLID in React produces components that are easier to read, easier to test, and easier to extend without introducing bugs in unrelated parts of the codebase. Ignoring them produces the opposite: one 400-line component doing seven things, props drilling through five layers, and a codebase where changing one thing always breaks another. This guide walks through all five principles with before and after TypeScript examples taken from real React patterns.

## S — Single Responsibility Principle **One component should do one thing. If you can describe what it does and the description includes the word "and," it is doing too much.** The most common SRP violation in React is a component that fetches data, filters it, and renders it — all in one place. Every concern mixed together means a change to the filtering logic risks breaking the fetch, and a change to the render risks breaking both. **Before — one component doing everything:** ```tsx // Bad: fetching, filtering, and rendering all in one place const ProductList = () => { const [products, setProducts] = useState([]); const [rating, setRating] = useState(0); useEffect(() => { fetch("/api/products") .then(res => res.json()) .then(data => setProducts(data)); }, []); const filtered = useMemo( () => products.filter(p => p.rating >= rating), [products, rating] ); return (

{[1,2,3,4,5].map(star => ( ))}

{filtered.map(product => (

{product.title}

${product.price}

))}

); }; ``` **After — each concern in its own place:** ```tsx // Custom hook: owns fetching const useProducts = () => { const [products, setProducts] = useState([]); useEffect(() => { fetch("/api/products").then(res => res.json()).then(setProducts); }, []); return products; }; // Custom hook: owns filtering const useRatingFilter = (products) => { const [rating, setRating] = useState(0); const filtered = useMemo( () => products.filter(p => p.rating >= rating), [products, rating] ); return { filtered, rating, setRating }; }; // Component: owns rendering a single product const ProductCard = ({ title, image, price }) => (

{title}

${price}

); // Component: owns rendering the filter UI const RatingFilter = ({ rating, onRatingChange }) => (

{[1,2,3,4,5].map(star => ( ))}

); // Parent: composes everything together const ProductList = () => { const products = useProducts(); const { filtered, rating, setRating } = useRatingFilter(products); return (

{filtered.map(product => )}

); }; ``` Two signals that SRP is being violated: a `map` function rendering a complex element inline (extract a component), and a `useState` plus `useEffect` living inside a component that also renders things (extract a custom hook).

## O — Open/Closed Principle **A component should be open for extension but closed for modification. Add new behavior through props — not by editing the component's source code.** The classic React violation: a `Button` component that uses a `role` prop to conditionally render different icons. Every new icon type means opening the component and adding another branch. **Before — adding a new icon means editing the component:** ```tsx // Bad: every new role requires modifying this component interface ButtonProps { role: "back" | "forward" | "home"; } const Button = ({ role }: ButtonProps) => { return ( ); }; ``` **After — new icons are passed in, source code stays closed:** ```tsx // Good: the icon is injected through props — no modification needed interface ButtonProps { icon: React.ReactNode; onClick?: () => void; } const Button = ({ icon, onClick }: ButtonProps) => ( ); // Adding a new icon = no changes to Button const BackButton = () =>

## L — Liskov Substitution Principle **A component that wraps a native HTML element should accept and forward all of that element's props — not just the ones it explicitly uses.** When you build a `SearchInput` that wraps a native ``, your component becomes a subtype of `input`. Liskov Substitution says that anywhere an `input` can go, your `SearchInput` should work too — with all of its props. **Before — wrapper accepts only a subset of input props:** ```tsx // Bad: only accepts isLarge — every other input prop is dropped interface SearchInputProps { isLarge?: boolean; } const SearchInput = ({ isLarge }: SearchInputProps) => ( ); ``` **After — extends native input props and forwards everything:** ```tsx // Good: extends HTML input attributes so nothing is dropped interface SearchInputProps extends React.InputHTMLAttributes { isLarge?: boolean; } const SearchInput = ({ isLarge, ...rest }: SearchInputProps) => ( ); // Now works exactly like a native input with an extra isLarge prop ``` The rule: whenever a component wraps another component or native element, extend its props interface and spread `...rest` through. Every prop the inner element supports should be reachable from the outside.

## I — Interface Segregation Principle **Components should not depend on props they don't use. Don't pass a whole object when only one property from it is needed.** This comes up whenever a parent passes its entire data object down to a child component that only needs one field from it. **Before — thumbnail receives the whole product but only uses the image:** ```tsx interface Product { id: number; title: string; price: number; rating: number; image: string; } // Bad: Thumbnail depends on Product even though it only needs image const Thumbnail = ({ product }: { product: Product }) => ( {product.title}

); // Caller ``` **After — thumbnail receives only what it needs:** ```tsx // Good: Thumbnail declares exactly what it needs interface ThumbnailProps { imageUrl: string; altText: string; } const Thumbnail = ({ imageUrl, altText }: ThumbnailProps) => ( {altText}

); // Caller passes only what Thumbnail needs ``` Now `Thumbnail` can be used anywhere — product thumbnails, user avatars, blog post covers — because it has no dependency on the `Product` type. It only knows about an image URL and alt text. The test: if a component receives an object prop but only accesses one or two properties from it, pass those properties directly instead.

## D — Dependency Inversion Principle **Components should depend on abstractions (props), not concrete implementations (hardcoded logic inside the component).** Inject behavior from outside rather than baking it in. The most common React violation: a form component that handles its own submission logic internally. The moment you need to use that form in two different contexts with different submission behavior, you're stuck — either duplicate the component or add conditional branching inside it. **Before — submit logic is baked into the component:** ```tsx // Bad: handleSubmit is hardcoded inside — cannot be reused with different behavior const SignInForm = () => { const [email, setEmail] = useState(""); const [password, setPassword] = useState(""); const handleSubmit = async (e: React.FormEvent) => { e.preventDefault(); // This URL is hardcoded — impossible to reuse for a different endpoint await fetch("/api/auth/login", { method: "POST", body: JSON.stringify({ email, password }), }); }; return ( ); }; ``` **After — behavior is injected through props:** ```tsx // Good: the form manages state and structure, caller provides the behavior interface FormProps { onSubmit: (email: string, password: string) => void; } const SignInForm = ({ onSubmit }: FormProps) => { const [email, setEmail] = useState(""); const [password, setPassword] = useState(""); const handleSubmit = (e: React.FormEvent) => { e.preventDefault(); onSubmit(email, password); // delegates to whoever provided it }; return ( ); }; // Login context const LoginConnectedForm = () => ( fetch("/api/auth/login", { method: "POST", body: JSON.stringify({ email, password }) }) } /> ); // Admin impersonation context — same form, completely different behavior const AdminSignInForm = () => ( fetch("/api/admin/impersonate", { method: "POST", body: JSON.stringify({ email, password }) }) } /> ); ``` `SignInForm` now knows nothing about HTTP. It manages UI state and delegates behavior. Two completely different submission contexts, zero code duplication, zero internal branching.

## How the Five Principles Work Together in React The principles are not independent rules. They build on each other. When you apply **S** and extract your fetch logic into a custom hook, you naturally end up with a hook that has one clear input and output — which makes it easy to **inject via props** (D). When components only receive the props they need (I), they become easier to reuse in new contexts without modification (O). And when a wrapper component properly extends the native element's props (L), it works as a drop-in replacement anywhere the native element does. Start with S and D. Extract logic into custom hooks. Inject behavior through props. Everything else follows more naturally from there.

## When Not to Apply SOLID in React Not every component needs all five principles. A small utility component with 20 lines and one use does not need dependency injection. A one-off page component that fetches and renders does not need custom hooks if it will never be reused. Apply SOLID when: - The component is used in more than one place and needs different behavior in each - You are writing tests and the component is hard to test because of internal dependencies - Multiple developers are working on the same component and changes are cascading unexpectedly - You want to add a feature and realize you have to modify stable, tested code to do it Those are the signals. Until then, keep it simple.

## Wrap Up SOLID principles are not a React-specific idea, but React's component model maps to them more naturally than most frameworks. Props are the extension mechanism. Custom hooks are the separation mechanism. TypeScript interfaces are the contract mechanism. Start with Single Responsibility and Dependency Inversion. They give the highest return immediately and create the structure where the other three follow naturally. If you are building a React product and want your project management, deployment tracking, and analytics in one workspace while you ship clean code, check out [AdeptDev](https://adeptdev.io). Free for 7 days.

## What are the SOLID principles in React? SOLID in React means: S (Single Responsibility) — one component does one thing; split fetching, filtering, and rendering into separate components and hooks. O (Open/Closed) — extend components through props, not by editing their internals. L (Liskov Substitution) — wrappers around native elements should extend and forward all native props. I (Interface Segregation) — pass only the props a component needs, not a whole object it partially uses. D (Dependency Inversion) — inject behavior through props instead of hardcoding it inside the component. ## How do you apply the Single Responsibility Principle in React? Two signals tell you SRP is being violated: a map function rendering a complex element inline (extract a dedicated component), and useState plus useEffect living inside a component that also renders things (extract a custom hook). A well-applied SRP means your component tree has components that render, hooks that fetch or compute, and the two never mix. If you can describe what a component does and the description includes the word "and," it is doing too much. ## What is Dependency Inversion in React? Dependency Inversion in React means passing behavior into components through props instead of implementing it inside the component. A form component that hardcodes its own fetch URL cannot be reused for a different endpoint without modification. A form component that accepts an `onSubmit` prop can be reused anywhere — each context provides its own implementation. The component manages state and structure. The caller provides the behavior. This is the pattern that makes React components genuinely reusable. ## Why should React components extend HTML element props? When a React component wraps a native HTML element like an input, button, or div, it should extend that element's TypeScript interface (`React.InputHTMLAttributes`) and spread `...rest` through. This is the Liskov Substitution Principle applied to React — your wrapper should work anywhere the native element works, with all of its props still reachable. Without this, every prop not explicitly declared in your interface is silently dropped, and consumers cannot use standard HTML attributes like `disabled`, `placeholder`, or `aria-label`. ## What is Interface Segregation in React components? Interface Segregation in React means components should only receive the props they actually use. If a Thumbnail component receives a whole Product object but only accesses `product.image`, it has been given more than it needs. The fix is to pass `imageUrl` directly. This makes the component reusable in contexts that have no concept of a Product — user avatars, blog covers, anything with an image — because the component declares only what it genuinely requires. ## When should I not use SOLID principles in React? Skip or simplify SOLID for components that are used in exactly one place and will never be reused, one-off page components that fetch and render without complex logic, small utility components under 30 lines, and early prototypes where the goal is to validate whether something works at all. Apply SOLID when a component needs different behavior in different contexts, when you need to test it without real infrastructure, or when multiple developers are modifying the same component and changes are cascading unexpectedly. ## How does TypeScript help apply SOLID principles in React? TypeScript makes SOLID principles enforceable rather than advisory. Interfaces make the Liskov Substitution Principle explicit — extending `React.InputHTMLAttributes` tells TypeScript exactly what props should be accepted and forwarded. The Dependency Inversion Principle becomes a typed contract: `onSubmit: (email: string, password: string) => void` enforces what the injected behavior must look like. Interface Segregation is reinforced because TypeScript will error if a caller tries to use a component in a way that violates its declared props.