SOLIDifica Tu Código React

Rate this content
Bookmark
Slides

Escribiendo un código más limpio en React siguiendo los Principios SOLID

Islem Maboud
Islem Maboud
11 min
12 Dec, 2023

Comments

Sign in or register to post your comment.

Video Summary and Transcription

El código limpio es fácilmente entendible, legible, modificable, extensible y mantenible. Los principios SOLID imponen buenas prácticas para un software escalable y mantenible. El Principio de Responsabilidad Única (SRP) asegura que los componentes tengan una sola razón para cambiar. El Principio de Abierto-Cerrado (OCP) permite que los componentes se extiendan fácilmente sin modificar el código fuente subyacente. El Principio de Sustitución de Liskov (LSP) permite intercambiar elementos hijos dentro de un componente de subtipo. El Principio de Segregación de Interfaz (ISP) establece que los componentes solo deben depender de las props que realmente utilizan.

Available in English

1. Introducción a Clean Code y los Principios SOLID

Short description:

Hola a todos. Soy Islam Aboud, un ingeniero de software full stack que trabaja con TopTel. Hoy, cubriremos la Introducción a Clean Code y los cinco principios SOLID. El código limpio es fácil de entender, legible, modificable, extensible y mantenible. Los principios SOLID, introducidos por Robert C. Martin, imponen buenas prácticas para un software escalable y mantenible. Son Responsabilidad Única, Abierto Cerrado, Sustitución de LispConv, Segregación de Interfaces y Inversión de Dependencia. SOLID funciona bien en entornos de equipo, y el uso de TypeScript con React permite un código más limpio siguiendo estos principios.

Hola a todos. Soy Islam Aboud y bienvenidos a la charla de hoy sobre cómo solidificar su código React. Así que un poco más sobre mí. Soy Islam Aboud, un ingeniero de software full stack que trabaja con TopTel. Soy el fundador del canal de YouTube Code One en youtube.com codeone. También, soy un gran fan de ayudar a los desarrolladores a construir mejores aplicaciones web con tutoriales educativos y tutoriales en video en YouTube y publicaciones de blog y cosas así. Y puedes encontrar mi portafolio en islamaboud.com.

Así que esto es lo que vamos a cubrir hoy desde la Introducción a Clean Code hasta realmente pasar por los diferentes principios SOLID y exactamente cómo puedes aplicarlos dentro de React. Así que primero, vamos a ver una rápida introducción a Clean Code. Entonces, decimos que el código es un código limpio si puede ser entendido fácilmente por todos en el equipo. Así que el código limpio puede ser leído y mejorado por el desarrollador que no sea su autor original. Así que cualquier persona en el equipo, incluso si no es la persona correcta o la persona original que escribió ese fragmento de código, puede entender fácilmente exactamente lo que está pasando. Así que con la comprensibilidad viene la legibilidad, la capacidad de cambio, la extensibilidad y lo más importante, la mantenibilidad. Así que aquí puedes leer sobre, ya sabes, el código limpio, las best practices, y cómo escribir código limpio. Cuáles son las best practices para hacer tu código más limpio, más fácil de leer por todos, y por supuesto, eventualmente, serías capaz de escribir un código mejor.

Ahora, cuando se trata de los principios SOLID, hay cinco principios de design conocidos como SOLID y se utilizan para crear software orientado a objetos escalable y mantenible. Fueron introducidos originalmente por Robert C. Martin. Él es el tipo que originalmente escribió y publicó el libro Clean Code, y realmente propuso estas ideas dentro de ese libro. Desde entonces, han estado involucrados en la guía de cómo escribir un código más limpio en diferentes lugares. Y uno de estos lugares es React. Así que hay cinco de ellos empezando con el Principio de Responsabilidad Única, el Principio Abierto Cerrado, el Principio de Sustitución de LispConv, el Principio de Segregación de Interfaces, y lo más importante, el Principio de Inversión de Dependencia. Así que SOLID impone un conjunto de buenas prácticas que básicamente te permitirá escribir un código más simple, más fácil de leer y mejor o más limpio, y funciona realmente, realmente bien especialmente cuando se trabaja en un entorno de equipo. Así que si estás trabajando con un equipo de desarrolladores, seguir los principios SOLID, te ayudará mucho a escribir un código más limpio que puede ser entendido y mantenido por todos en el equipo. Y por supuesto estos principios fueron originalmente creados para la programación orientada a objetos así que algo como Java tal vez o C++. Algunos lenguajes tienen OOP. Pero por supuesto, porque usamos JavaScript con React mucho, JavaScript no es un lenguaje que apoye mucho el OOP, así que tenemos que introducir y usar el hermano mayor de JavaScript, que es TypeScript. Así que usando TypeScript con React, nos puede permitir escribir un código más limpio siguiendo los principios SOLID. Por supuesto, tendremos que hacer una adaptación menor y un pequeño cambio minúsculo a esos principios SOLID para hacer que funcione el flujo de trabajo de React. Así que vamos a ver los principios SOLID aplicados en React.

2. Principio de Responsabilidad Única (SRP)

Short description:

El principio de responsabilidad única (SRP) establece que cada componente debe hacer exactamente una cosa. Asegura que los componentes y funciones tengan una sola razón para cambiar. Por ejemplo, un mal componente puede tener múltiples responsabilidades, lo que lo hace difícil de leer y entender. En contraste, un buen componente sigue el SRP encapsulando la lógica en hooks y renderizando componentes encapsulados.

Así que empezamos con el principio de responsabilidad única o el SRP. Así que para la definición original, cada clase debería tener solo una responsabilidad para la definición extrapolada para hacerla funcionar con React. Así que cada componente debería hacer exactamente una cosa. Así que SRP es la regla para asegurar que nuestro componente y funciones o modules son responsables de hacer solo una cosa y por lo tanto tienen solo una razón para cambiar.

Para entender mejor el SRP, por ejemplo, podemos tomar este simple componente React aquí que es como el mal componente aquí. Es un componente normal. Utiliza el useState aquí. Tiene una función para buscar el producto, tiene un useFx aquí para llamar a la búsqueda del producto y aquí hay alguna función para manejar la calificación y el clic del botón y todo otro usando useMemo para filtrar los productos dependiendo de la calificación. Y por supuesto, renderiza un montón y quiero decir un montón como un montón de GSX aquí. Todo esto es realmente complicado y es realmente difícil de leer. No sabes exactamente qué está pasando. Así que todas las cosas de filtrado están sucediendo. Se está renderizando el componente de calificación. Estoy como mapeando a través del SVG aquí para renderizar las estrellas o las estrellas de calificación y un montón de cosas y literalmente muy difícil de leer. Ahora si vamos a una mejor implementación como el buen componente aquí, es mucho mejor y ahora en realidad utiliza un hook que es used products para hacer la búsqueda. Eso en realidad ha encapsulado toda la búsqueda. Usa otro. Usa el filtrado de tasa aquí para hacer las cosas de filtrado. Así que todo está encapsulado dentro de ese hook y solo renderizamos estos dos componentes. Así que toda la lógica en el GSX ha sido encapsulada en el componente de filtrado y aquí solo lo estamos mapeando y estamos renderizando este componente de producto encapsulado.

3. Principio de Apertura-Cierre (OCP)

Short description:

El principio de apertura-cierre (OCP) establece que las entidades de software deben estar abiertas para la extensión pero cerradas para la modificación. En el contexto de React, esto significa que un componente debe ser fácilmente extendido sin modificar el código fuente subyacente. Al usar íconos en lugar de roles, podemos hacer que el componente de botón sea más flexible y evitar la necesidad de cambiar el código fuente para cada nueva característica.

Ahora, el segundo principio, el principio de apertura-cierre o OCP, la definición original es que las entidades de software deben estar abiertas para la extensión, cerradas para la modificación. Y ahora la definición explorativa para React es que un componente debe ser fácilmente extendido sin modificar el código fuente subyacente. Así que OCP es solo para hacer componentes extensibles que son a prueba de futuro sin tener que entrar dentro de los componentes y cambiar el código fuente para cada nueva característica que estás intentando añadir.

Entonces, si miras este componente de botón aquí, es un componente bastante simple. Es fácil, toma un texto aquí para renderizar dentro del botón. Toma un rol. Y un rol aquí en TypeScript, como puede ser hacia atrás, hacia adelante, principal o no encontrado. Y simplemente renderiza un botón y por supuesto, dependiendo del rol, si es hacia adelante, renderiza un icono en particular, ya sea a la derecha o a la izquierda. Ahora esto es realmente malo porque todo está encapsulado. Así que cada vez que quieres añadir un nuevo icono, tienes que ir y añadir un nuevo rol. Y si añades un nuevo rol, tienes que ir y cambiar el código fuente real de el botón. Pero en cambio, lo que deberías hacer si vas a la buena implementación aquí, en lugar de pasar un rol a ese, simplemente podemos pasar un icono. Y por supuesto, podemos simplemente decirlo específicamente fuera cuando intentamos renderizar cosas. Así que en lugar de usar un rol hacia adelante y hacia atrás y lo que sea, podemos dejar el icono aquí, podemos renderizar un nodo de React inmediatamente. Puedes simplemente pasarlo al botón y puede renderizar sin siquiera necesitar cambiar el código fuente.

4. Principio de Sustitución de Liskov (LSP)

Short description:

El principio de sustitución de Liskov (LSP) asegura que un elemento hijo o componente puede ser fácilmente intercambiado por el mismo tipo de elemento dentro de un componente de subtipo. Por ejemplo, extendiendo los atributos de entrada HTML de los elementos de entrada HTML, podemos pasar cualquier prop que la entrada tome a través del componente de entrada de búsqueda.

El tercero es el principio de sustitución de Liskov o LSP. Ahora la definición original es que los objetos de subtipo deberían ser substituibles por objetos de supertipo. Ahora para una definición más clara, un elemento hijo o un componente debería ser fácilmente intercambiable por el mismo tipo de elemento. Así que LSP es simplemente para asegurarse de que podemos intercambiar fácilmente algunos elementos con otros elementos del mismo tipo real dentro de un componente de subtipo. Puede parecer un poco extraño. Lo entenderás mejor con un simple ejemplo.

Así que digamos que tenemos este simple ejemplo aquí donde tenemos esta interfaz que realmente te indica la ruta de búsqueda. Ahora por ejemplo, digamos que tenemos este componente de entrada de búsqueda aquí que realmente subraya y utiliza un componente de entrada. Así que este componente de entrada aquí es nuestro componente original que realmente toma un montón de props por lo que podemos tomar un nombre de clase, ID, tipo, valor, en cambio y así sucesivamente. Ahora porque este componente de entrada de búsqueda está realmente encapsulando los elementos de entrada aquí, por lo que tiene que proporcionar todas las indicaciones que la entrada necesita a través de las props que realmente utiliza. Así que por ejemplo, cuando dices que busco props es realmente las props de la entrada de búsqueda y aquí sólo estamos proporcionando en cambio y valor, pero la entrada aquí por supuesto que toma muchas más cosas. Así que se necesitan muchas más props. Así que en lugar de hacerlo de esta manera, puedes seguir adelante y realmente extender. Así que haces extender los atributos de entrada HTML de los elementos de entrada HTML, así que en lugar de hacer eso puedes comentar el código y ahora puedes pasar lo que quieras desde como el marcador de posición a cualquier prop que la entrada tome a través del componente de entrada de búsqueda.

5. Principio de Segregación de Interfaces (ISP)

Short description:

El principio de segregación de interfaces (ISP) establece que las clases o objetos cliente no deberían depender de métodos o propiedades que no necesitan. En el contexto de los componentes de React, esto significa que los componentes no deberían depender de las props que realmente no utilizan. Por ejemplo, un mal componente puede pasar props innecesarias a otro componente, rompiendo el ISP. En cambio, los componentes solo deberían pasar las props específicas que requieren.

El cuarto es el principio de segregación de interfaces, o ISP. Así que para su definición es que las clases o los objetos cliente que utilizan una interfaz no deberían requerir depender de métodos o propiedades que no conocen. Y aquí para una explicación más sencilla es que los componentes no deberían depender de las props que no necesitan. Así que el ISP es simplemente para prevenir la creación de interfaces monolíticas demasiado grandes que obligan a los componentes dependientes a las props que realmente no utilizan. Así que, por ejemplo, tenemos este mal componente aquí que realmente rompe la ley del ISP aquí y lo utiliza tiene otro componente dentro de él como la miniatura.

Ahora la miniatura aquí para renderizarla no necesita todos los productos, pero aunque ellos Si lo miras, en realidad lo pasa a través de un producto completo. Así que vamos dentro de esos componentes de miniatura. Solo utiliza la imagen de los productos. Todo lo que necesita es la URL de la imagen o la propiedad de la imagen de los productos. Así que no hay necesidad de pasar los objetos completos para todos los hechos, o simplemente vas a hacer es en realidad ir a un buen componente aquí. Así que si miras en el solo pasando la URL de la imagen, así que solo toma la URL de la imagen en lugar de todos los productos. No hay necesidad de pasar todas esas props, si el componente o la miniatura los componentes no van a necesitar eso o incluso no van a usar eso en absoluto. Ahora para el quinto último, un principio de inversión de dependencia DIP es para el desacoplamiento módulos de nivel superior de módulos de nivel inferior donde dependen de la abstracción y no de la coalición. Y para la definición más sencilla para los componentes de React, los módulos o funciones no deberían depender directamente en componentes concretos antiguos, sino que deberían depender de un común. Y por supuesto, DIP es simplemente para promover el uso de abstracciones para lograr flexibilidad, extensibilidad y mantenibilidad en una base de código. Si por ejemplo, tomamos este mal componente aquí que es un formulario simple que solo renderiza un formulario aquí con un formulario de inicio de sesión. Y aquí tenemos este handle submit. Y por supuesto este formulario funciona perfectamente, pero esto en realidad depende de una implementación concreta del handle submit, donde tiene la URL y todo. Pero en lugar de hacer eso, y en lugar de ir a este componente de formulario, no necesitamos saber exactamente qué está enviando o cómo está enviando los datos o cuál es la URL o qué API utiliza. Podemos seguir adelante y reenviar eso a través de como en el submit, que es recibido por las props. Y podemos hacer handle submit on submit desde las props aquí. Y podemos crear otro componente que utilice ese componente se llama como, por ejemplo, formulario conectado. Así que este formulario conectado puede proporcionar la implementación concreta al formulario en aquí, y esto hará que el formulario sea un poco más general, un formulario más abstracto que puede ser utilizado ya sea en el lado de este componente de formulario conectado, o tal vez tienes otro componente de formulario conectado para el registro. Así que puedes llamarlo con esta API de registro aquí, puedes pasar en el handle submit creado. Y voila. Creo que la parte más importante es que en realidad no siempre puedes acertar con los principios de sole porque originalmente fueron introducidos para OOP. Y por supuesto, tuvimos que hacer algunos cambios para hacerlo funcionar con React en particular. Pero en realidad hay algunos escenarios de casos donde no puedes usar todos los principios o tú básicamente si solo usas todos los principios vas a arruinar todo el proyecto o todo el componente. Así que gracias a todos por unirse a nosotros.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

SolidJS: Why All the Suspense?
JSNation 2023JSNation 2023
28 min
SolidJS: Why All the Suspense?
Top Content
Solid caught the eye of the frontend community by re-popularizing reactive programming with its compelling use of Signals to render without re-renders. We've seen them adopted in the past year in everything from Preact to Angular. Signals offer a powerful set of primitives that ensure that your UI is in sync with your state independent of components. A universal language for the frontend user interface.
But what about Async? How do we manage to orchestrate data loading and mutation, server rendering, and streaming? Ryan Carniato, creator of SolidJS, takes a look at a different primitive. One that is often misunderstood but is as powerful in its use. Join him as he shows what all the Suspense is about.