Video Summary and Transcription
La charla de hoy discute la construcción de componentes React flexibles, resilientes y a prueba de futuro utilizando enfoques de composición y configuración. El enfoque de composición permite flexibilidad sin lógica condicional excesiva mediante el uso de múltiples componentes y el paso de props. La API de contexto se puede utilizar para el estilo de variantes, permitiendo un estilo y especificación de clase apropiados. Agregar variantes e iconos se facilita al consumir el contexto de variantes. Los enfoques de composición y configuración se pueden combinar para lo mejor de ambos mundos.
1. Construyendo Componentes React Flexibles y Resilientes
Hoy, discutiré cómo construir componentes flexibles, resilientes y a prueba de futuro en React. Exploraremos dos enfoques: composición y configuración. Construir componentes a prueba de futuro puede ser un desafío a medida que la complejidad crece. Agregar características como encabezados, variantes e iconos requiere una cuidadosa consideración de las props y los estilos.
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.
2. Usando la Composición para Flexibilidad
El enfoque de configuración puede volverse problemático cuando agregar más funcionalidad requiere agregar más props y lógica condicional. Se vuelve más difícil extender o sobrescribir la lógica del componente. Por otro lado, la composición ofrece un enfoque diferente. Al usar múltiples componentes y pasar props, podemos lograr flexibilidad sin una lógica condicional excesiva. En el ejemplo, el componente de alerta se compone de los componentes de envoltura de alerta, contenido de alerta y cuerpo de alerta, lo que permite un mayor control y una extensión más fácil.
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,
3. Uso de la API de Contexto para el Estilo de Variantes
En este ejemplo, podemos usar diferentes componentes para construir la funcionalidad de alerta, incluyendo el marcado personalizado. Para proporcionar variantes a componentes como alertHeader y alertBody, podemos usar la API de contexto. La variante se pasa como una prop al proveedor de contexto de variante, que luego la proporciona a todos los componentes en el árbol de componentes. Esto permite un estilo y especificación de clase apropiados para el componente de alerta. La fábrica de contexto crea el contexto y el consumidor para un fácil consumo en otros componentes.
y ya tenemos algunos de los componentes, pero vale la pena al final. Solo recuerda que este es un ejemplo de contrato. Entonces, sí, así es como lo usamos. Ahora, si quisiéramos agregar, digamos un encabezado de alerta, bueno, no necesitamos agregar una prop. Solo agregamos otro componente, como alertHeader, básicamente. Entonces, todos estos componentes son solo bloques de construcción que nosotros usamos para componer la funcionalidad. Y ¿qué pasa si, digamos, sí, primero de nuevo, nuestro encabezado en este caso también es muy similar a otros componentes. Solo recibe las props, renderiza el diff con los estilos correctos y luego finalmente los children. Ahora bien, ¿qué pasaría si quisiéramos tener variantes? Bueno, supongo que podríamos pasar una prop al componente de alerta. Por supuesto, también podríamos crear un componente para ello. Pero para este ejemplo, esto servirá. Así que pasaríamos una prop de variante a la alerta. Pero ahora lo que pasa es que no podemos componer los componentes correctamente, para construir la funcionalidad de alerta. Pero lo que pasa es que nosotros también podemos usar no solo los bloques de construcción, los componentes que construimos específicamente para la alerta, sino que en realidad podemos usar cualquier marcado personalizado que queramos. Si realmente lo quisiéramos, no podríamos usar ninguno de estos bloques de construcción, solo el componente de alerta.
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.
4. Uso de Variantes e Iconos
Actualizamos los componentes de encabezado y cuerpo de alerta para tener acceso a la variante. Usamos el hook de variante y consumimos el contexto para aplicar estilos. Agregar un icono es fácil utilizando un componente preconstruido o un marcado personalizado. Usamos un mapa de configuración de iconos para mapear iconos a componentos. Consumimos el contexto de variante para agregar estilos apropiados al icono. El enfoque de composición es flexible y permite una fácil extensión de la funcionalidad. Sin embargo, requiere componer bloques de construcción y entender su composición. El enfoque de configuración solo requiere proporcionar props.
Ahora, encabezado de alerta. Sí. Así que necesitamos actualizar el componente de encabezado y cuerpo de alerta porque ahora también necesitan acceso a la variante. Así que importamos este hook de variante, consumimos el contexto y luego lo usamos para aplicar estilos apropiados. Y hacemos lo mismo en el cuerpo de la alerta, de nuevo consumimos el contexto y aplicamos los estilos.
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,
5. Combinando Composición y Configuración
El enfoque de composición ofrece más flexibilidad pero requiere más conocimiento de cómo componer bloques de construcción. El enfoque de configuración es menos flexible pero más sencillo de usar y ayuda a mantener la consistencia. Ambos enfoques pueden combinarse para obtener lo mejor de ambos mundos.
correcto, bajo el capó. Porque no sabes... es posible que no sepas lo que está pasando allí. Solo necesitas saber las props y qué valores necesitas pasar. Eso es todo. Mientras que con el enfoque de composición, sí necesitas saber qué están haciendo los bloques de construcción y cómo son... cómo deben ser utilizados. Y bueno, obviamente, otra desventaja es que lleva más tiempo y code, correcto, para crear lo mismo. Porque, de nuevo, necesitas componer los bloques de construcción tú mismo.
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.
Comments