Mastering SOLID Principles in React: A Guide for Junior Developers

If you are a self-taught developer, it is so normal that you may have lack of information about some disciplines such as design patterns, solid principles, software development lifecycles, etc.

In this article, I will try to help you by explaining one of them. We will learn SOLID principles with the help of examples from React. Why React? Because I am aware of a global reality:

As Frontend development was the easiest way to dive into programming, most of junior developers started developing React apps before learning fundamentals 😅

I think that is not a shame or fault. That is, exactly, how nature works. You were so eager to code and couldn’t wait to learn methodologies, design patterns etc and React / Vue / Angular gave you this change. But now, it is time to learn. Don’t be afraid. I have a really joyful style of teaching. Let’s start.

“React mom give us food until we get strong and learn how to get it”

Firstly, understanding and applying design principles is important to be sure about writing clean, maintainable, and scalable code. One such set of principles is SOLID, which stands for:

• Single Responsibility Principle
• Open/Closed Principle
• Liskov Substitution Principle
• Interface Segregation Principle
• Dependency Inversion Principle

Let’s focus on each principle and give an example from React Mom.

1. Single Responsibility Principle (SRP)

A class (or component) should have only one reason to change, meaning it should have only one job or responsibility.

Imagine we have a component that both fetches and displays user data. This violates SRP because it has two responsibilities. Instead, we can separate these concerns:

2. Open/Closed Principle (OCP)

Software entities should be open for extension but closed for modification.

Suppose that we have a button component that we want to extend with different styles without modifying the existing button code:

3. Liskov Substitution Principle (LSP)

If you are new to SOLID principles, you may forget this principle easily because its name does not give any clue about its content 😅 Here you see the reason for its name, Barbara Liskov!

Wikipedia: Liskov substitution was introduced by Barbara Liskov

Sorry, dear Barbara Palvin :( I love you but I couldn’t find a new principal to give your name. Instead of finding a new one, can I replace the name of Barbara Liskov with Barbara Palvin 🥲

Ah ok! Liskov principle is also about replacement!

Liskov Principle claims that objects of a superclass should be replaceable with objects of a subclass without affecting the correctness of the program.

Imagine that we have a base Shape component and extend it with specific shapes like Circle and Square. Each shape should be usable wherever Shape is expected.

4. Interface Segregation Principle (ISP)

Here the keyword is “segregation”. It is described as setting someone or something apart from others. But how can it be important for clean code?

ISP says that a client should not be forced to depend on interfaces it does not use. Splitting a large interface into smaller, more specific ones is advised by it.

For React developers, it can be explained with a context example. Remember that we always create a new context for our apps’ settings. Such as theme, user, items etc.

5. Dependency Inversion Principle (DIP)

DIP says that high-level modules should not depend on low-level modules.

Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions.

Imagine you’re at a fancy restaurant. You (the high-level module) want a delicious meal, but you don’t want to worry about the nitty-gritty details of cooking (the low-level module). Instead, you depend on the chef (the abstraction). The chef, in turn, doesn’t rely on a specific brand of ingredients but rather on a set of qualities for the ingredients they need.

In our React world, we want our components to be like you at the restaurant — enjoying the meal without worrying about the kitchen chaos. Here’s how we can achieve this with hooks for data fetching:

In this scenario, useDataFetcher is our chef. It knows how to get the data (cook the meal) but doesn’t depend on the specifics of where this data will be used (who the diners are).

Okay guys! I tried my best to explain this SOLID principles in a easy way. I hope you all, one day, remember me and send a connection request!

Here my Instagram (for Barbara Palvin 🚀)

https://www.instagram.com/alimuratumutlu

and here my LinkedIn account:

https://www.linkedin.com/in/murat-umutlu

Feel free to ask if you need any further details or clarifications on any part of the article!