Solid principles are a set of five principles aimed at making software design maintainable, scalable and easy to modify. These principles can be applied to any object-oriented programming language…

DevGenius serves as a platform for sharing insights and experiences in software development, offering articles and interviews with industry experts to gain  insights into various aspects of software engineering. By exploring DevGenius's curated content, developers can learn from real-world experiences, best practices, and lessons learned from seasoned professionals across different domains of software development. Whether you're looking for career advice, technical insights, or inspiration for your next project, DevGenius provides a  knowledge and expertise to help you succeed in your software development journey.

Dev Genius

SOLID principles in ReactJS are a set of five principles aimed at making software design maintainable, scalable and easy to modify. These principles can be applied to any object-oriented programming language, including ReactJS. In this blog post, we’ll discuss the importance of the SOLID Principles in React JS and how they can improve your code.

SOLID principles in Reactjs

This article is riddled with bad practices when using React. For instance, you should NEVER extend another comment class. React is not a “pure” OO library, it is built on principles of functional programming. Inheritance is accomplished via composition, not class extension. SOLID are principles of OO design and not all of them will, nor were meant to, apply and/or be used when using React.

Seeing so many upvotes, I opened the article, but on seeing class components being used, I had to close it.
Just one question. Why Class components?

The SOLID principles are a set of five design principles for writing clean and understandable code that can be easily extended and modified. The article explains each principle in detail and shows how it can be applied to ReactJS development:
<ol>
<li>
Single Responsibility Principle (SRP): Components should have only one responsibility, and should not be responsible for multiple tasks.
</li>
<li>
Open/Closed Principle (OCP): Components should be open for extension but closed for modification. This means that new functionality can be added to a component without changing its existing code.
</li>
<li>
Liskov Substitution Principle (LSP): Child components should be able to replace their parent components without affecting the behavior of the application.
</li>
<li>
Interface Segregation Principle (ISP): Components should not be forced to depend on interfaces they don’t use.
</li>
<li>
Dependency Inversion Principle (DIP): High-level components should not depend on low-level components, but instead should depend on abstractions.
</li>
</ol>