SOLIDifica Tu Código React

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.

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.

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.

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.

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.