SOLID, YAGNI, DRY, KISS principles in React

As programming develops, the code becomes more complex and, accordingly, there are more and more errors and difficulties in understanding. To combat this, various development practices and principles are being created. One of these are SOLID principles.

These principles, of course, are more suitable for OOP, because they depend on classes and interfaces. But the modern code in React at the moment is far from OOP, but rather more functional. But the SOLID principles do not depend on the language, and they can be interpreted as you like and, accordingly, applied to the React functional code.

SOLID is an abbreviation, and each letter is one of the five principles: 

1. SRP is the principle of unified responsibility. The original definition states that each class should have only one responsibility. This principle is easiest to apply to functional code by translating this definition as follows: a component/function/module should do only one thing. This principle is the most effective for improving the code. In addition, it is easiest for him to follow all five principles. With regard to React, we can implement this principle in the following ways:

• divide large components with cumbersome logic into smaller ones.

• put it into separate general-purpose functions.

• move the logic associated with the component to user hooks.

2. OCP is the principle of openness-closeness. The original definition states that software objects should be open for expansion, but closed for modification. Actually, this definition, even in this form, is suitable for React. Giving an example, we can say that there are components that, depending on different conditions, show different content. Accordingly, over time, this component may expand, and conditions will become more and more. Thus, it is possible to implement this principle using render-props or children.

3. LSP is the substitution principle of Barbara Liskov. This principle indicates that objects of the subtype should be replaced by objects of the supertype. I.e., the child class should be able to do everything that the parent class does. But it turns out that this, as a rule, should be applied in class inheritance. And in modern React inheritance is practically not used due to the use of a functional approach.

4. ISP - the principle of interface separation. The basic idea is that clients shouldn't depend on interfaces they don't use. When using React, it can be rephrased into “components should not depend on props that they do not use". More than once you can notice when writing code that, for example, a large object is thrown through the propses into one small component. But only a couple of properties from it are used in the future. Actually, this component knows too much information that it does not use. This can become a problem when using TypeScript in cases where this component can accept objects with different structures.

5. DIP is the principle of dependency inversion. He says that one should rely on abstractions, not concretions. If we apply this principle to React, then one component should not depend on the other. And there should be a common abstraction on which both components will depend.

In addition to the SOLID principles, there are many more development principles. Some of which are DRY, KISS, YAGNI.

KISS - this principle translates as “leave the code simple and dumb.” It is immediately clear from the translation that you do not need to complicate your code. When some functions and components grow, try to divide them into smaller and understandable logical parts.

DRY - means “don't repeat yourself". When writing code, try to avoid duplicating code and putting it into separate components and functions. The consequence of avoiding this principle may be the presence of a lot of duplicated code, which will be difficult to change in the future. After all, it is easier to add some changes only in one place, and not in several at once.

YAGNI - this principle translates as “you won't need it.” The essence of this method is that it is not worth writing functionality that may be used in the future. It may not be needed, and the time for writing code will be spent. In addition, the written extra functionality may change, and it is not necessary at all.

Summing up, we can say that following these principles is not rigorous, but it can help to write high-quality code that will be both easy to expand and easy to read.