Kelvin John

Sep 07, 2025ย โ€ขย 2 min read

Using SOLID in Reactjs.

๐—ง๐—ต๐—ถ๐—ป๐—ด๐˜€ ๐—œ ๐—ถ๐—ป๐—ฑ๐—ถ๐—ฟ๐—ฒ๐—ฐ๐˜๐—น๐˜† ๐—ฑ๐—ถ๐—ฑ๐—ป'๐˜ ๐—ธ๐—ป๐—ผ๐˜„ ๐—œ ๐˜„๐—ฎ๐˜€ ๐—ฑ๐—ผ๐—ถ๐—ป๐—ด.

Using SOLID in Reactjs.

Yeah, I've written react apps for a while now and I've indeed improved over the years. But little did I know, I have actually been using the ๐’๐Ž๐‹๐ˆ๐ƒ principle in React. Yes, SOLID principle. You read that right. And I got to know this from reading a colleague's code and advising them on some "๐˜ฃ๐˜ฆ๐˜ด๐˜ต ๐˜ฑ๐˜ณ๐˜ข๐˜ค๐˜ต๐˜ช๐˜ค๐˜ฆ๐˜ด".

S - Single Responsibility Principle (SRP)

"๐ด ๐‘๐‘™๐‘Ž๐‘ ๐‘ (๐‘๐‘œ๐‘š๐‘๐‘œ๐‘›๐‘’๐‘›๐‘ก) ๐‘ โ„Ž๐‘œ๐‘ข๐‘™๐‘‘ โ„Ž๐‘Ž๐‘ฃ๐‘’ ๐‘œ๐‘›๐‘™๐‘ฆ ๐‘œ๐‘›๐‘’ ๐‘Ÿ๐‘’๐‘Ž๐‘ ๐‘œ๐‘› ๐‘ก๐‘œ ๐‘โ„Ž๐‘Ž๐‘›๐‘”๐‘’".

Each component you create should focus on one responsibility. Mixing UI, state management, and API calls in the same component usually makes it hard to maintain. Use reusable components and custom hooks to minimise this.

O - Open/Closed Principle (OCP)

"๐‘†๐‘œ๐‘“๐‘ก๐‘ค๐‘Ž๐‘Ÿ๐‘’ ๐‘’๐‘›๐‘ก๐‘–๐‘ก๐‘–๐‘’๐‘  ๐‘ โ„Ž๐‘œ๐‘ข๐‘™๐‘‘ ๐‘๐‘’ ๐‘œ๐‘๐‘’๐‘› ๐‘“๐‘œ๐‘Ÿ ๐‘’๐‘ฅ๐‘ก๐‘’๐‘›๐‘ ๐‘–๐‘œ๐‘› ๐‘๐‘ข๐‘ก ๐‘๐‘™๐‘œ๐‘ ๐‘’๐‘‘ ๐‘“๐‘œ๐‘Ÿ ๐‘š๐‘œ๐‘‘๐‘–๐‘“๐‘–๐‘๐‘Ž๐‘ก๐‘–๐‘œ๐‘›"

In React, instead of modifying a component's core logic every time requirements change, extend it through props, composition or HOCs/hooks.

Another way you can look at this. Assuming your project uses a button but has different colours used at various portions, you can just use props to extend this by creating variants.

L - Liskov Substitution Principle (LSP)

"๐‘†๐‘ข๐‘๐‘ก๐‘ฆ๐‘๐‘’๐‘  ๐‘š๐‘ข๐‘ ๐‘ก ๐‘๐‘’ ๐‘ ๐‘ข๐‘๐‘ ๐‘ก๐‘–๐‘ก๐‘ข๐‘ก๐‘Ž๐‘๐‘™๐‘’ ๐‘“๐‘œ๐‘Ÿ ๐‘กโ„Ž๐‘’๐‘–๐‘Ÿ ๐‘๐‘Ž๐‘ ๐‘’ ๐‘ก๐‘ฆ๐‘๐‘’๐‘ "

In React, specialised components should behave like their general counterparts.

For example, if PrimaryButton extends Button, it should work anywhere a Button is expected, without breaking UI or functionality.

I - Interface Segregation Principle (ISP)

"๐ถ๐‘™๐‘–๐‘’๐‘›๐‘ก๐‘  ๐‘ โ„Ž๐‘œ๐‘ข๐‘™๐‘‘ ๐‘›๐‘œ๐‘ก ๐‘๐‘’ ๐‘“๐‘œ๐‘Ÿ๐‘๐‘’๐‘‘ ๐‘ก๐‘œ ๐‘‘๐‘’๐‘๐‘’๐‘›๐‘‘ ๐‘œ๐‘› ๐‘š๐‘’๐‘กโ„Ž๐‘œ๐‘‘๐‘  ๐‘กโ„Ž๐‘’๐‘ฆ ๐‘‘๐‘œ ๐‘›๐‘œ๐‘ก ๐‘ข๐‘ ๐‘’".

For this, simply do not create giant components with dozens of props, or even states you don't really need. Split responsibilities into smaller, focused interfaces, components or hooks.

D - Dependency Inversion Principle (DIP)

"๐ท๐‘’๐‘๐‘’๐‘›๐‘‘ ๐‘œ๐‘› ๐‘Ž๐‘๐‘ ๐‘ก๐‘Ÿ๐‘Ž๐‘๐‘ก๐‘–๐‘œ๐‘›๐‘ , ๐‘›๐‘œ๐‘ก ๐‘๐‘œ๐‘›๐‘๐‘Ÿ๐‘’๐‘ก๐‘–๐‘œ๐‘›๐‘ "

Components shouldn't directly fetch data or rely on low-level implementations. Instead, use hooks or contexts to provide data.

You will realise UserCard does't know how data is fetched. It depends on an abstraction, useUser, not on the actual API call.

So if you also write React and you try to

* Keep your components clean and focused

* make them reusable and substitutable.

* Design smaller, focused APIs and props.

* or even decouple UI from the implementation details.

If you do any of this, then you are also using the SOLID principle.

๐•‹๐•™๐•’๐•Ÿ๐•œ๐•ค ๐•—๐• ๐•ฃ ๐•ฃ๐•–๐•’๐••๐•š๐•Ÿ๐•˜ ๐•ฅ๐•™๐•š๐•ค.

Let me know what different ways you also use the SOLID principle.

Join Kelvin on Peerlist!

Join amazing folks like Kelvin and thousands of other builders on Peerlist.

peerlist.io/

Itโ€™s available... this username is available! ๐Ÿ˜ƒ

Claim your username before it's too late!

This username is already taken, youโ€™re a little late.๐Ÿ˜

0

7

0