SOLID PRINCIPLES

SOLID is an acronym for five different design principles developed for the longevity of our code. The software design principles are used to make our code more functional, maintainable, and/or robust.

The five principles are:

1- S: Single Responsibility Principle ( SRP ).

Each function/class/component should do exactly one thing and this is the most important principle to follow when writing frontends in React.

( Large functions/components often indicate that they do more than one thing, try to keep functions/components small to ensure modularity.

The SRP encourages us to fragment our code from monolithic files with thousands of lines into dozens of smaller 50-100 line files. This makes our codebase more maintainable and robust, as it is much easier to test many smaller separate files than one

large file.

2- O: Open / Closed Principle ( OCP )

Software units should be open to enhancements but closed to changes. Following the SRP, the OCP explains that we should be able to add new functionality without having to rewrite parts of our code base.

3- L: Liskov Substitution Principle ( LSP ).

For classes, the LSB states that each subclass should be substitutable by its base class, i.e., if B extends class A. Then we should be able to use B wherever we use A without changing any functionality.

As with functional components, all code should be written using hooks over classes, i.e., objects in a program should be replaceable by instances of their subtypes without changing the correctness of the program. The most important conclusion from this principle is to use Typescript so that you can easily replace components if they have the same contract.

4- I: Interface Separation Principle ( ISP )

(give a component only the props it needs).

Give components only what they need. This means that implementation details for a particular higher-level function should not matter. Keep your interface small and coherent.

5- D: Dependency Inversion principle ( DIP )

Always have a high-level code interface with abstraction and not implementation details.

One should depend on abstraction [NOT] concretions

In conclusion, we use SOLID principles to outline some things we can do to make the architecture of our codebase a little easier to manage, all based on the idea of modularity in our code.

SOLID is an acronym for five separate design principles that were developed to help the longevity of our code, software design principles exist to make our code more functional, more maintainable, and/or more robust

The five principles are :

1- S: Single Responsibility Principle ( SRP )

every function/class / component should do exactly one thing, and this is the most important principle to follow when writing frontends in react

( large functions/components often indicate that they are doing more than one thing, try to keep functions/components small to ensure modularity.

The SRP encourages us to fragment our code from monolithic files containing thousands of lines into dozens of smaller 50-100 line files this makes our codebase more maintainable and much more robust, as it becomes far easier to test many smaller separate files than one

large file.

2- O: Open / Closed principle ( OCP )

software entities should be open for extension but closed for modifications. following nicely from the SRP the OCP explains that we should be able to add new features without having to rewrite parts of our codebase

3- L: Liskov Substitution Principle ( LSP )

for classes, the LSB states that any subclass should be substitutable for its base, class this means that if B extends A. Then we should be able to use B everywhere we use A. Without altering any functionality.

as for functional components, since all code should be written using hooks over classes anyway, objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program. The main takeaway from this principle is to use typescript, so you can easily swap components if they share the same contract.

4- I: Interface Segregation Principle ( ISP )

(only pass component props it needs )

Give components only what they need. This means implementation details should not matter to any specific high levels function, keep your interface small and cohesive. a component interface should only have the properties that are relevant to it.

5- D: Dependency Inversion Principle ( DIP )

Always have a high-level code interface with abstraction rather than an implementation detail.

One should depend upon abstraction [NOT] concretions

In conclusion, we use SOLID principles to outline some things we can do to make the architecture of our codebase a little easier to manage, these are all centered on the idea of modularity in our code.

for more details and examples you can find them in these resources that I read

#SOLIDPrinciples #react #reactjs #SOLID #bestpractices