Composición vs Configuración: Cómo Construir Componentes Flexibles, Resilientes y a Prueba de Futuro

Hey, hoy voy a hablar sobre cómo construir componentes flexibles, resilientes y a prueba de futuro en React. Voy a cubrir dos enfoques diferentes para construir componentes, composición y configuración. Pero primero, permíteme contarte un poco sobre mí. Mi nombre es Tomasz Findly y soy un desarrollador web y móvil full-stack con 10 años de experiencia en programación. Soy co-propietario de Findly WebTech, así como mentor y consultor en la plataforma CodeMentor.io. Además de eso, soy el autor de React, el Camino a Enterprise y Viewed el Camino a Enterprise libros. También escribo artículos para Telerik y los blogs de Camino a Enterprise. Bueno, eso es suficiente sobre mí. Ahora, los componentes. Entonces, seamos honestos. Construir componentes a prueba de futuro no es fácil. Quiero decir, bueno, si tienes un componente como este, es muy simple. Así que para este ejemplo, usaré un componente de alerta. Entonces, por ejemplo, si quisieras tener un componente de alerta que mostrara un mensaje de alerta básico, bueno, podríamos hacer algo como esto, ¿verdad? Podríamos recibir entradas de texto como props, tener algunos divs con estilos, y luego renderizar lo que se pasó, ¿verdad? Y así es como podríamos usarlo. Solo usa el componente de alerta y pasa el mensaje de texto dentro de él. Entonces, obviamente, eso es muy simple, pero el problema con la construcción de buenos componentes es que, a medida que necesitamos agregar más funcionalidad, la complejidad simplemente crece, ¿verdad? El code se está volviendo mucho más difícil de mantener y extender. Entonces, ¿qué pasaría si quisiéramos agregar más características a este componente de alerta? Digamos que solo queremos agregar un encabezado también. Entonces podríamos recibir un encabezado como una prop, y si se pasó uno, lo mostraríamos, ¿verdad? Como se muestra aquí en el ejemplo. Entonces, por ejemplo, en el lado derecho, tenemos una alerta solo con y la otra con tanto el encabezado de la alerta como el mensaje de texto. Así que eso sigue siendo bastante simple. Ahora, ¿qué pasa con las variantes? Bueno, supongo que podríamos agregar otra prop, como variante, ¿verdad? Y luego, en función de esa prop, y cualquiera que fuera la variante seleccionada, podríamos agregar estilos apropiados. Entonces, por ejemplo, podríamos admitir variantes como éxito, peligro, advertencia o información, como puedes ver en el lado derecho. Y así es como lo usaríamos. Solo pasa las props de encabezado y variante y algo de texto dentro.

Entonces, ¿qué pasa si agregamos, tal vez, un ícono? Bueno, de nuevo, otra prop, como ícono. Si se pasó, y encontramos un ícono compatible, entonces podemos renderizarlo. Simple, ¿no es así? Y así es como podríamos usarlo. Entonces, básicamente, por defecto, el ícono podría mostrarse a la izquierda Pero, ¿qué pasa si queremos especificar en qué lado queremos que se muestre? ¿Como, tal vez no a la izquierda, sino a la derecha? Bueno, ¿adivina qué? ¡Otra prop! Entonces, por ejemplo, podríamos pasar una prop como posición del ícono, ¿verdad? Por defecto podríamos establecerlo a la izquierda. Y luego, si, por ejemplo, era a la derecha, podríamos especificar algunas clases, ¿verdad?, que se agregarían en el contenedor de alerta. Ten en cuenta que estoy usando Tailwind aquí para las clases.

Y sí, así es como lo usaríamos, solo más props. Entonces, ese fue el enfoque de configuración, ¿verdad? Básicamente, cada vez que necesitamos agregar más funcionalidad, agregamos más props. Pero, bueno, eso puede ser problemático en algún momento. Porque lo que pasa es que, para cada nueva variante y funcionalidad, necesitamos agregar más y más props y lógica condicional, ¿verdad?

Y a veces puede ser mucho más difícil sobrescribir la lógica ya definida dentro de un componente o incluso extenderlo. Entonces, eso no es realmente lo mejor. El enfoque de configuración lo hace mucho más difícil. Entonces, a veces, si un componente no puede ser extendido, podríamos necesitar construir una nueva versión de él. Bueno, en cuanto a las ventajas, obviamente un enfoque de configuración, bueno, un componente construido con un enfoque de configuración es rápido y fácil de usar, ¿verdad? Porque solo necesitas saber qué props están realmente disponibles y qué necesitas proporcionar. Entonces, sí. Básicamente, diferentes funcionalidades y variantes visuales pueden ser controladas a través de props y eso es todo. Y otro beneficio de eso es que es mucho más difícil desviarse del sistema de design, ¿verdad? Porque lo que pasa es que solo puedes proporcionar props y eso es todo. No puedes hacer realmente nada más con él. Entonces, bueno, esto mantiene la UI y el comportamiento consistentes.

Pero, sí, como mencioné, el problema es que no podemos extender fácilmente el componente de construcción de configuración o sobrescribirlo. Entonces, ¿qué podemos hacer? Bueno, quiero decir que obviamente podríamos proporcionar tal vez props como, digamos, un render icon, render header, ya sabes, render body y así sucesivamente. Pero de nuevo, más props serían solo más desordenados. Entonces, habría más lógica condicional dentro del componente de alerta. Entonces, en lugar de intentar configurar todo, ¿qué tal si usamos un enfoque diferente, la composición. Entonces, en este ejemplo, tenemos tres componentes. Primero, el envoltorio de alerta, luego el contenido de alerta y el cuerpo de alerta. Y al cuerpo de alerta, le pasamos el mensaje de texto. Sé que tres componentes solo para el mensaje de texto es un poco mucho, pero quédate conmigo. Entonces, ¿cómo podría verse? Básicamente, el componente de alerta, obviamente, recibiría algunas props. Luego renderizaría un div con estilos apropiados y children, ¿verdad? Entonces, en este caso, los children serían el contenido de alerta y el cuerpo de alerta. Luego tenemos el contenido de alerta. Como ves, es muy similar al componente de alerta. Porque, de nuevo, solo recibe las props. Y tiene un div con algunos estilos. Y en realidad, bueno, lo mismo se aplicaría al cuerpo de alerta. Sé que hay un poco de repetición,

Entonces, ¿cómo proporcionamos una variante a todos estos otros componentes como alertHeader y alertBody? Porque necesitan saber cuál es la variante. Porque necesitan tener estilos apropiados. Por ejemplo, el encabezado y el cuerpo para la variante de éxito tienen un texto verde oscuro, mientras que el fondo de la alerta es claro. Y también, tenemos el borde a la izquierda que es oscuro. Entonces, lo que podemos hacer es usar la API de contexto para proporcionar la variante que se especificó a todos los componentes en el árbol de componentes. Entonces, en este caso, recibimos la variante como una prop, y luego la pasamos al proveedor de contexto de variante. Además de eso, también lo usamos para especificar las clases apropiadas para el componente de alerta. Ahora, veamos cómo podemos construir este proveedor de contexto de variante. Así que he usado un pequeño ayudante de fábrica de contexto, llegaremos a él en un momento. Básicamente, solo devuelve un hook personalizado que consumirá el contexto y el contexto en sí. Y como puedes ver, en la línea cinco aquí, el useVariantContext se exporta para que pueda ser consumido en otros componentes. Y luego en el proveedor de contexto de variante, básicamente solo renderizamos el proveedor y pasamos la variante a él. Y eso es todo. A continuación. Así que aquí tenemos la fábrica de contexto, básicamente, crea el contexto, crea el consumidor y los devuelve.

Bien. Siguiente. Así que tenemos el componente de alerta con variantes e iconos, ¿verdad? Así que si quisiéramos añadir un icono, de nuevo, otro bloque de construcción, ¿verdad? Podemos simplemente usar un componente que ya fue construido como parte de, digamos, todos los componentes de alerta y pasar un icono específico. O si quisiéramos, incluso podríamos añadir algún marcado personalizado para ello. Ahora, ¿cómo lo usaríamos? Así que primero podemos tener un mapa de configuración de iconos, donde básicamente el icono se mapea a, digamos, iconos sfg o cualquier componente que quisieras usar. A continuación, usamos la prop de icono para recuperar uno de los iconos que son compatibles. Y luego si tenemos uno, entonces renderizamos el marcado para ello. Además de eso, también consumimos el contexto de variante para que podamos añadir estilos apropiados al icono, por ejemplo, colores correctos. Como en nuestro ejemplo, el icono de éxito obviamente será verde mientras que el icono de advertencia será naranja. Así que en cuanto a las posiciones, básicamente, podríamos mover el componente de icono de alerta al fondo y podríamos añadirle algunos estilos. Por ejemplo, en este caso, el icono de alerta, porque fue movido al fondo, se renderizará después del contenido de la alerta por lo que estaría en el lado derecho. Y luego, por ejemplo, podemos añadir algún margen izquierdo automático con algo de acolchado derecho con algún valor de margen derecho para tenerlo posicionado en el lado derecho, como puedes ver aquí.

Así que eso fue el enfoque de composición. Así que obviamente el enfoque de composición es extremadamente flexible, ¿verdad? Porque básicamente usas los componentes, que son bloques de construcción, para componer la funcionalidad. Si tú, por ejemplo, necesitas algo más personalizado, puedes simplemente crear un nuevo marcado, ¿verdad? Marcado personalizado, o puedes añadir más bloques de construcción y eso es todo. Así que sí, por eso el enfoque de composición es realmente flexible. Y no es difícil, ya sabes, extender la funcionalidad, o ni siquiera tienes que sobrescribir nada, ¿verdad? Porque simplemente compones todo. Así que, sí, es muy fácil crear diferentes funcionalidades y variantes de UI con el enfoque de composición. Sin embargo, hay algunas desventajas en este enfoque, ¿verdad? Porque obviamente necesitas componer los bloques de construcción tú mismo, ¿verdad? Para crear este completamente componente o característica funcional. Por eso, necesitas saber cómo funcionan los bloques de construcción, qué hacen y cómo deben ser compuestos. Esto no es el caso cuando se utiliza el enfoque de configuración. Porque con el enfoque de configuración, básicamente solo necesitas saber qué props se supone que debes proporcionar. Y eso es todo. En el enfoque de configuración, básicamente el componente se encarga de todo,

Y otra desventaja es que es mucho más fácil desviarse del sistema de design y enviar una UI y comportamiento inconsistentes. Obviamente, porque básicamente puedes componer los bloques de construcción, sabes, como quieras, correcto. Por lo tanto, sería más fácil cometer errores y enviar una UI inconsistente, básicamente, proporcionando clases incorrectas o ordenando los bloques de construcción de la manera incorrecta. Esto no ocurre con el enfoque de configuración. Porque, de nuevo, solo proporcionas props y eso es todo. Entonces, de nuevo, ambos enfoques tienen sus pros y contras, correcto. Entonces la pregunta es, ¿cuándo deberíamos usar cuál? Bueno, técnicamente, ¿por qué no ambos? Correcto, porque lo que podemos hacer es primero usar el enfoque de composición para básicamente construir, bueno, crear los componentes que son los bloques de construcción, correcto, y luego podemos usarlos para crear un componente de configuración, como aquí tenemos un ejemplo. De nuevo, como hicimos en el ejemplo de configuración recibimos una serie de props, correcto, para la alerta, luego tenemos el componente de línea base que básicamente acepta la variante y el nombre de la clase. Luego también tenemos el icono de alerta. Si se pasó el icono, entonces se renderizará. Y contenido de alerta, donde si se pasó el encabezado, entonces se renderizaría el componente de alerta. Y si se pasó el texto para los hijos, entonces se renderizaría el cuerpo de la alerta. Y sí, así es como puedes combinar composición y enfoques de configuración para básicamente construir componentes. Entonces la mayoría de las veces, solo puedes usar un componente configurado, pero si necesitas más flexibilidad, correcto, entonces tienes estos bloques de construcción disponibles para ti. Entonces, en resumen, el enfoque de composición ofrece más flexibilidad, pero sí requiere más conocimiento de cómo componer los bloques de construcción, ¿verdad? Y cómo funcionan. Por otro lado, el enfoque de configuración es menos flexible, pero es más sencillo de usar y facilita el apego al sistema de design. Pero sí, podemos combinar ambos enfoques para obtener lo mejor de ambos mundos. Así que puedes encontrar ejemplos de code para esta presentación en este repositorio de GitHub. Además, si te gustaría aprender más sobre advanced patterns, best practices, técnicas para muchos conceptos cruciales como la gestión de estado local y global, proyecto escalable architecture, performance optimization, gestión de APIs, testing, y mucho, mucho más, definitivamente deberías echar un vistazo a React.io's Road to Enterprise. Y si te gustaría ponerte en contacto, puedes encontrarme en Twitter, LinkedIn, CodeMentor, y también en la plataforma Road to Enterprise. Bueno, eso es todo por hoy. Espero que hayas disfrutado de la charla, y que tengas un gran día.