Como desarrollador, estoy constantemente pensando en cómo hacer mi código más eficiente y mantenible, les comparto los principios SOLID aplicados a React, Clean Code, el acrónimo STUPID y algunos Code Smell.

Los principios SOLID y el Código Limpio son dos conceptos importantes con los que todo desarrollador debería estar familiarizado.

Veamos cómo estos conceptos se pueden aplicar a React, y también vamos a discutir algunos de los Code Smells más comunes en React.

SOLID es un acrónimo de cinco principios de diseño que fueron introducidos por primera vez por Robert C. Martin en su libro “Agile Software Development, Principles, Patterns, and Practices”.
---
Una de las principales ventajas de React es su arquitectura basada en componentes, esto significa que una aplicación se compone de piezas pequeñas y reutilizables que se pueden mantener y ampliar fácilmente.

Siguiendo los principios SOLID, puedes mejorar aún más la estructura de tu código y hacer que sea aún más fácil trabajar con él.

El acrónimo significa:

• Principio de Responsabilidad Única (SRP).
• Principio de Apertura-Cierre (OCP).
• Principio de Sustitución de Liskov (LSP).
• Principio de Segregación de Interfaces (ISP).
• Principio de Inversión de Dependencias (DIP).

Principio de Responsabilidad Única (SRP).

Este principio establece que un módulo o clase debe de tener una sola responsabilidad, cada módulo de software debe tener responsabilidad sobre una sola parte de la funcionalidad proporcionada por la aplicación.

Seguir el principio SRP tiene varias ventajas.

En primer lugar: Facilita la comprensión y el mantenimiento del código porque cada módulo o clase tiene un propósito bien definido.

En segundo lugar: Aumenta la reutilización del código porque los módulos pueden reutilizarse en otras partes de la aplicación donde encajen.

En otras palabras, cada módulo o componente debe hacer una sola cosa y hacerla bien.

Esto ayuda a mantener el software limpio y fácil de mantener, ya que es más fácil comprender qué está pasando si todo está dividido en pequeñas partes con funciones claramente definidas.

Aplicar el principio SRP en React significa dividir los componentes en pequeños pedazos que sean lo suficientemente simples como para ser entendidos fácilmente y no tengan demasiadas responsabilidades.

De esta forma, si algo sale mal, es mucho más fácil identificar el problema y arreglarlo sin tener que rastrear todo el código para encontrar dónde podría estar el error.

Todos los componentes deben tener un solo propósito, si tienes un componente para mostrar datos y otro componente para manipularlos, entonces tendría sentido separarlos en dos componentes diferentes.

De esta forma, el primer componente se encargaría solo de mostrar los datos y el segundo componente se encargaría solo de manipularlos, esto ayudaría a mantener el código relativamente limpio y simple.

El SRP es a menudo citado como el principio más importante en la POO, y definitivamente vale la pena seguirlo en tus aplicaciones React.

Por supuesto, como todos los principios, siempre hay espacio para la interpretación y el debate sobre si algo viola o no la SRP.

Mientras tengan en mente el objetivo general de mantener los módulos u clases centradas en áreas únicas de responsabilidad, estarán en el camino correcto hacia la creación código limpio y mantenibles.

Algunos ejemplos de cómo pueden aplicar el SRP en los componentes de React:
 

1. Si un componente necesita hacer una llamada Ajax para obtener datos de una API, entonces necesitaría depender de algo como Axios.
   
   Pero si el mismo componente también necesita acceder al almacenamiento local, entonces depender de algo como localStorage no sería necesario y podría conducir a un acoplamiento innecesario entre los componentes.
   
   Así que en este caso, adherirse al SRP significaría evitar dependencias innecesarias.
   Un componente solo debe tener dependencias directas de cosas que sean necesarias para su única responsabilidad.
    
2. Un componente que renderiza un formulario no debería ser también responsable de manejar el envío del mismo.
   
   Son dos responsabilidades diferentes y, por lo tanto, violaría la SRP.
   
   Un componente solo debe tener un trabajo o responsabilidad.
    
3. Si dos componentes necesitan acceder a la misma parte de un estado, entonces ambos se acoplan y los cambios en uno probablemente acabarán afectando al otro.
   
   Esto viola el espíritu de la encapsulación, que está en el corazón de este buen principio.
   
   Los componentes no deberían compartir el estado entre ellos a menos que sea absolutamente necesario.