Componentes, Patrones y cosas difíciles de manejar

Rate this content
Bookmark

Todo el mundo tiene una biblioteca de patrones o sueña con tener una. Pasamos por conversaciones y la codificación de nuestro diccionario visual y luego terminamos con un hermoso documento vivo.

Pero ¿qué sucede cuando necesitamos reutilizar nuestros componentes y no encajan en el diseño? ¿Cómo reutilizamos nuestros patrones en casos de uso ligeramente diferentes?

Tenemos toda la tecnología para hacer que el front-end sea realmente modular, tenemos técnicas y metodologías que nos permiten evitar las partes malas de los lenguajes que usamos. Cada parte del rompecabezas parece estar encajando en su lugar correcto.

Sin embargo, a veces nos cuesta manejar las variaciones de nuestros patrones de manera confiable y mantenible. Nuestro código se está llenando de excepciones y anulaciones y se vuelve imposible refactorizar los patrones base.

No es una receta para el éxito, más bien una forma de enmarcar el problema, identificar algunas ideas que hemos probado y volver a discutir la forma en que abordamos la componentización.

29 min
22 Oct, 2021

Video Summary and Transcription

Esta charla discute arquitecturas modulares, patrones y componentes en el desarrollo de software. Explora el concepto de crear componentes y bibliotecas de patrones, así como los desafíos y beneficios que presentan. La charla también profundiza en la gestión del código para el uso flexible de patrones y la responsabilidad de los módulos. Aborda problemas como la inyección de nombres de clase, patrones especializados y la modificación de componentes. Además, enfatiza la importancia de la comunicación y colaboración con los diseñadores, la prueba de la complejidad de la interfaz de usuario y la responsabilidad organizativa de la interfaz de usuario.

Available in English

1. Introducción a las Arquitecturas Modulares

Short description:

Hola a todos, hoy hablaré sobre arquitecturas modulares, enfocándome específicamente en componentes, patrones y los desafíos que presentan.

Hola a todos. Es un poco incómodo porque, nuevamente, es posible que escuchen de todos en este escenario y otros escenarios que no hemos estado frente a personas durante un par de años ahora. Es realmente intimidante estar, nuevamente, en un escenario y frente a personas. Pero ninguno de los otros oradores pidió hablar después de Max. Eso aumenta el estrés, para ser honesto. Pero afortunadamente, tengo un tema que es completamente diferente al suyo, así que eso me pone en un campo completamente diferente.

Este discurso también ha recorrido un largo camino. Max fue en 2018. El mío es un poco más atrás. Lo verán en un minuto. Y todo comenzó cuando quería hablar sobre arquitecturas modulares. Así que ese edificio, si me lo preguntan, desde la última vez que estuve en una conferencia, alguien preguntó y no sabía la respuesta. Se llama Habitat 67 y está en Montreal. De todos modos, quería hablar sobre la arquitectura modular y estaba tratando de entender qué decir al respecto, porque la arquitectura modular ha sido algo que he visto recurrentemente en muchos trabajos que he tenido en los últimos años y nadie realmente lo ha entendido bien. Bueno, al menos no en ninguna empresa en la que estuve. Es difícil. Y luego, mientras hablaba del problema en el que estaba tratando de enfocarme, terminé mirando los componentes y las clases. Así fue a donde fue mi mente. Aunque llamar a una charla clases y componentes no está de moda en estos días. Así que necesito darle un giro de marketing. Componentes y modificadores, pero eso suena muy 2012 como enfoque. ¿Alguno de ustedes trabajó con un enfoque similar a BEM en su carrera en algún momento? ¿Escribir CSS y componentes de esa manera? Sí, es bastante antiguo. No es algo que harías hoy en día, tal vez. Quiero decir, es posible que lo hagas, pero no es muy atractivo.

Y de todos modos, el problema no eran tanto los componentes y los modificadores. Era más sobre las anulaciones. Como cuando no funciona. Como cuando tenemos que hacer algo para deshacer lo que abstraímos o generalizamos, de todos modos. Y nuevamente, tratando de entenderlo, terminé hablando sobre componentes, patrones, y es difícil lidiar con eso. Porque eso es realmente de lo que quiero hablar.

2. Explorando Patrones y Componentes

Short description:

Antes de convertirme en gerente de ingeniería, solía ser un webmaster. Hoy quiero hablar sobre patrones, componentes y los desafíos que presentan. Comenzaré mencionando la película Perdidos en Tokio, que explora una relación no romántica entre Bill Murray y Scarlett Johansson en Japón. Esta película, al igual que mi charla, genera diferentes opiniones y deja espacio para la interpretación. No proporcionaré respuestas, sino que plantearé problemas y compartiré mis experiencias para enmarcarlos y resolverlos.

Así que mi nombre es Marco Chedero. Solía ser un webmaster. Solía ser un webmaster mucho antes de que fuera popular. Ahora soy gerente de ingeniería en PhotoBox. Por cierto, estamos contratando si estás interesado.

Es posible que notes que soy gerente de ingeniería, por lo que estoy un poco desconectado de la vida diaria del desarrollo front-end en estos días. Pero aún tengo una opinión y aquí estoy.

Entonces, los patrones, componentes y es difícil lidiar con ellos o se me ocurrió un buen uso de citas de Perdidos en Tokio. ¿Quién de ustedes ha visto la película Perdidos en Tokio de Sofia Coppola? Ok, algunos. ¿Les gustó? Sí, algunos. Ok. Perdidos en Tokio, en caso de que no lo conozcan, es una película en la que Bill Murray y Scarlett Johansson establecen una relación no romántica mientras están de viaje en Japón. Es un hombre de mediana edad que filma un comercial de whisky. Ella es una joven casada, no, lo siento, es la novia de un fotógrafo que está haciendo una sesión de fotos en Japón, y tienen mucho tiempo libre y mucho desfase horario. Comienzan esta relación no romántica hablando de su crisis de mediana edad y de cómo ella trata de descubrir qué hacer con su vida a principios de los 20. Es un poco conversacional y trata sobre encontrarse a uno mismo y encontrar su camino, su camino y demás. Esta película genera una amplia gama de opiniones de las personas. Me identifico en particular con esta. Lo siento por los chicos y chicas que les encantó. Y creo que mi charla, hasta cierto punto, podría dejarte con la misma sensación. Espero que no, pero podría ser. Podría ser. Y eso se debe a que, como advertencia, no te daré ninguna respuesta en esta charla. Te plantearé problemas. Te guiaré a través de algunas de las formas en que enmarco esos problemas y algunas de las formas en que esas soluciones funcionaron o no. Y luego me iré.

3. Lost In Translation y el Surgimiento de Componentes

Short description:

Lost In Translation comienza con un comentario de Alla Kolmatova sobre cómo se pierde el significado en la traducción. Ella habló sobre patrones de diseño y la creación de una biblioteca de patrones visuales para empresas. En 2013, un artículo cambió la forma en que veíamos el diseño, revolucionando el concepto de descomponer un diseño en pequeñas unidades de código y elementos visuales llamados átomos. Esta fue la primera vez que escuchamos sobre la mentalidad de crear componentes, lo cual fue un cambio significativo en comparación con el enfoque tradicional basado en PHP.

Y eso es todo. Así que eso es todo. Entonces, todo, en serio, Lost In Translation comienza con un comentario de Alla Kolmatova hace un tiempo. Ella dijo que el significado es complejo y a menudo se pierde en la traducción. Todos tienen su propio modelo mental de las cosas. Ella estaba hablando específicamente sobre patrones de diseño.

Así que estaba hablando sobre la creación de una biblioteca de patrones visuales para empresas, no específicamente componentes de código. Pero creo que representa bastante bien cómo me siento acerca de los componentes en general. Sí, así fue, esta fue una charla increíble que dio hace unos años. Creo que fue en 2015 o algo así. Pero sí, si puedes buscarla en YouTube, debería estar por ahí.

Entonces, como dije antes, esta charla viene de lejos. 2013. En 2013, acabo de mudarme al Reino Unido, estoy trabajando en Shazam. Estamos construyendo cosas con tecnologías muy poco modernas. Estamos usando Mustache, un pequeño framework de JavaScript interno cuando Required JS todavía era algo. Y usamos CSS, mucho CSS en realidad. Así que estamos haciendo cosas muy poco modernas, nuevamente. Y luego, en algún momento de 2013, salió este artículo. Algunos de ustedes pueden recordarlo. Y cambió completamente la forma en que veíamos el diseño. A partir de ese momento, revolucionó por completo la forma en que las personas pensaban en cómo descomponer un diseño y crear pequeñas unidades de código y elementos visuales llamados átomos, que luego se combinaban para crear moléculas, organismos, plantillas y páginas.

Y esa fue la primera vez que algunos de nosotros, desarrolladores de tiempo completo, escuchamos sobre esa mentalidad de crear componentes. Y nos volvimos locos con las tecnologías que teníamos en ese momento. Porque veníamos de un mundo en el que PHP renderizaba la página completa y tenías algo de CSS aplicado, y eso era todo. Y JQuery encima con la interacción. Pero eso era todo lo que teníamos. No existía el concepto de unidades pequeñas. Podías descomponer los bloques de PHP e incluir cosas así. Pero se pensaba más en el sentido de que tuviera sentido en el servidor para que funcionaran los bloques de PHP, en lugar de construir un diseño.`

4. Componentes web y bibliotecas de patrones

Short description:

Los componentes web fueron anunciados unos años antes pero no cumplieron las expectativas. En 2011, prometieron aislar la lógica y encapsular la interfaz de usuario, pero el concepto de bibliotecas de patrones y componentización ya existía desde hace tiempo. La web se volvió más madura, requiriendo más abstracción. El objetivo es tener un desarrollo de interfaz de usuario portátil y escalable con menos especialización.

Entonces, esto cambió la forma en que veíamos las cosas. Sin embargo, unos años antes, se anunciaron los componentes web. Podemos decir que no cumplieron del todo. Para usar un alfaismo.

En 2011, cuando se anunciaron, representaron un cambio para el desarrollo web. Pensábamos que podríamos aislar por completo nuestra lógica, podríamos encapsular nuestra interfaz de usuario y podríamos entregar cosas en total aislamiento del resto de la página. Y lo esperábamos con ansias. Pero retrocedamos un poco más. Porque en el lado del diseño del desarrollo web, no es raro haber oído hablar de las bibliotecas de patrones y descomponer el diseño, incluso antes de 2010. Así que esto ha sido un largo camino hacia la componentización para la web. Nuevamente, la mayoría de nosotros lo experimentamos después del artículo en 2013. Pero nuevamente, ha sido un largo camino. Y eso se debe a que, en mi opinión, la web se volvió cada vez más madura y necesitamos más y más abstracción. Es lo que sucedió con la impresión. Hasta que obtuvimos los caracteres móviles, no era un medio principal. Y esa transición también llegó para la web. Queremos cosas portátiles. Queremos que 200 desarrolladores trabajen en una interfaz de usuario. No queremos un pequeño equipo de unos pocos, que funciona bastante bien. No me malinterpreten. Todas las tecnologías que estamos creando en la actualidad, sin embargo, son para resolver problemas organizativos, si lo piensas. Todo va en la dirección de que necesitas menos especialización y más personas que puedan rotar entre diferentes tecnologías. Perdón. Me estoy desviando. De todos modos.

Las bibliotecas de patrones, a lo que me refiero, porque, nuevamente, es difícil. Nos perdemos en la traducción. Tenemos diferentes modelos mentales. Quiero especificar lo que quiero decir. Así que con bibliotecas de patrones, no hago una distinción en esta charla entre diseño y código.

5. Gestión del código para el uso flexible de patrones

Short description:

Estoy hablando de un conjunto de componentes que construyen tu interfaz de usuario. Sin importar cómo los enmarques. Es algo que tienes en una herramienta. Es algo que tienes en Figma. En 2013, React salió y esta es la verdadera revolución de los componentes. Es cuando realmente comenzamos a hacer componentes de manera adecuada y más fácil. Profundicemos en el problema del que quiero hablar. El problema al que quiero apuntar es cómo gestionamos nuestro código para usar patrones sin hacerlos demasiado rígidos para la evolución diaria de ellos, las actividades diarias.

Estoy hablando de un conjunto de componentes que construyen tu interfaz de usuario. Sin importar cómo los enmarques. Es algo que tienes en una herramienta. Es algo que tienes en Figma. Donde sea que los tengas. Si los tienes. Pero en última instancia, es lo que usas para declarar tu interfaz de usuario. En cierta medida. Juntándolos. Si los codificas cada vez que hay algo nuevo en Figma y no lo presentas en tu código, está bien. Para mí, sigue siendo una biblioteca de patrones con el propósito de esta charla. Lo siento. Sí. Disculpas.

2013. React salió y esta es la verdadera revolución de los componentes. Es cuando realmente comenzamos a hacer componentes de manera adecuada y más fácil. Esta tecnología cambió completamente el enfoque. Tomó un tiempo antes de que se usara ampliamente como lo es hoy en día, por supuesto. Para mí, este momento y por eso estoy en esta conferencia, realmente cambió la forma en que comenzamos a construir cosas. Y, nuevamente, por supuesto, luego tenemos otras tecnologías que salieron y siguieron ese patrón y lo anunciaron. No me malinterpreten. No estoy diciendo que React sea la única solución, pero esta es la primera que recuerdo que realmente hizo ese cambio de mentalidad. Así que esa es un poco la historia detrás. Lo siento. ¿Cuánto tiempo me llevó contar la historia detrás? Bastante.

Profundicemos en el problema del que quiero hablar. Entonces, como dijo Ala en esa charla, cuando realmente intentas aplicar ese enfoque de modelo en tu día a día, no es tan simple. Y tengo esta imagen en mi mente todo el tiempo, como cuando te sientes como un niño intentando encajar un cuadrado en un círculo, eso es exactamente lo que intento entender cómo no hacer. Entonces, el problema al que quiero apuntar es cómo gestionamos nuestro código para usar patrones sin hacerlos demasiado rígidos para la evolución diaria de ellos, las actividades diarias.

6. Modularidad y Responsabilidad del Módulo

Short description:

Esta charla trata sobre la modularidad y la responsabilidad de los módulos. Los ejemplos no son específicos de React, pero se pueden aplicar en un contexto más amplio. El código mostrado en las diapositivas proviene de mi experiencia previa en producción.

¿O cómo reutilizamos patterns en casos de uso ligeramente diferentes? Entonces, esta charla no trata sobre React. Es una charla que habla sobre la modularidad, es una charla que habla sobre la responsabilidad de los módulos y cómo los descompones, cómo piensas en ellos. Todos mis ejemplos no están en React, y eso es a propósito, porque no quiero que nos perdamos en pensar específicamente en React sino en un contexto más amplio de cosas. Verás cosas que podrías estar haciendo de manera similar en React, verás cosas que podrías estar haciendo de manera diferente en React. Pero en el fondo, es un problema que también tenemos en React. Y todo el código que he mostrado en las diapositivas es código que he utilizado en producción en uno de los trabajos que tuve antes de PhotoBox.

7. Inyección de Nombres de Clase y Modificadores Ad Hoc

Short description:

El primer ejemplo es la inyección de nombres de clase en React. Permite inyectar un nombre de clase en los elementos subyacentes, pero tiene inconvenientes. El CSS personalizado puede desconectarse del componente base, lo que puede causar problemas potenciales. No se utiliza comúnmente la prueba de regresión visual, lo que dificulta detectar cambios en la interfaz de usuario. Además, la flexibilidad puede llevar a desviaciones de los patrones de diseño y a la creación de variantes innecesarias. Otra tecnología son los modificadores ad hoc.

Entonces, el primer ejemplo, la solución técnica para reutilizar componentes en casos de uso ligeramente diferentes que he visto y personalmente odio, pero llegaremos a eso, es la inyección de nombres de clase. Así que cuando tienes... Oh, este es un ejemplo de React. Entonces, cuando tenemos un componente que tiene una propiedad de nombre de clase que puedes inyectar en los elementos subyacentes.

Mucha gente lo hace. No me malinterpreten, en mi opinión es malo. Funciona bastante bien para mucha gente. Entonces, esto te permite inyectar un nombre de clase, aplicar el nombre de clase a los elementos hijos que tengan sentido para este botón de icono, y aplicar tu CSS como quieras.

Hay algunos problemas que veo con esto porque tienes un archivo de CSS dedicado, normalmente, y luego no sabes cómo interactúa con la base de ese componente. Tienes un CSS personalizado que se agrega a una extensión que está lejos del botón base original y si el botón base cambia, ¿qué sucede con esto? ¿Cómo interactúa eso? Tal vez esto se usa solo en un lugar de tu sitio web y cambias la base que se usa en todos los demás lugares, y rompes algo y ni siquiera lo sabías. A menos que tengas una prueba de regresión visual. Pero, ¿quién hace eso? Quiero decir, algunas personas lo hacen. Pero realmente, en el día a día, ¿lo usas? ¿Cuántos de ustedes hacen una aprobación de regresión visual para implementar cambios en la interfaz de usuario? Ok, dos. Eso es lo que pensé. Es costoso. No me malinterpreten. Es lo correcto. Es muy costoso configurar y mantener y crear un proceso de compilación adecuado para eso. Es... No es fácil.

Además, si tienes ese nivel de flexibilidad, podrías crear cosas que no siguen los patrones que tu diseñador quiere. O tal vez tu diseñador cometió un error y creó excepciones que no deberían estar ahí. Hay patrones por una razón. Pero, ¿por qué esto tiene colores diferentes para el estado de hover y activo? ¿Tiene algún significado semántico? No lo sé. Para mí parece... Parece una mancha en el código.

Entonces, de nuevo, funciona muy bien porque es la forma más flexible de extender cualquier cosa. Pero los cuatro estilos podrían haberse escrito de formas esperadas y estamos creando muchas variantes que dependen del capricho del momento de quien las diseñó.

Entonces, otra tecnología son los modificadores ad hoc. Estoy seguro de que los usamos.

8. Clases Específicas y Patrones Especializados

Short description:

Crear clases específicas mediante el enmascaramiento de IDs con nombres de clase puede ser interesante, ya que mantiene la excepción dentro del espacio del diálogo. Sin embargo, el uso de IDs en lugar de clases puede llevar a enviar CSS innecesario a la aplicación. El tamaño del archivo CSS puede aumentar significativamente con nuevo código, lo que lo hace menos escalable. Por otro lado, los patrones especializados se consideran extensiones apropiadas de un componente.

Es cuando creas una clase que es para un uso muy específico. Básicamente, estás enmascarando un ID con un nombre de clase. Es interesante, porque mantiene la excepción dentro del espacio del diálogo, en este caso, por lo que aún tienes el contexto del cambio, para que sepas cómo funciona la anulación en relación al componente principal basado en el padre. Pero son IDs. No son clases. ¿Cuántos de ellos tendrás en tu sitio web? Y, nuevamente, todo este código es real que agregamos. Estábamos enviando mucho CSS que era completamente innecesario para la aplicación, porque la intención del juego, por ejemplo, se usaba solo una vez en un viaje muy específico para el usuario, y sin embargo, el diálogo es CSS, se enviaba a todas partes. Y en ese momento, realmente estábamos eliminando duplicados de CSS. Entonces, es flexible. Mantiene la proximidad entre la extensión y la base, pero luego, en el otro extremo de la escala, tienes que hay muchas implementaciones muy específicas, el tamaño del archivo de CSS podría aumentar mucho con el nuevo código y realmente no escala. ¿Cuántos puedes agregar? Lo que me lleva a los patrones especializados, que es lo que en BAM llamaríamos la extensión apropiada de un componente, por lo que este es un tipo específico de diálogo.

9. Modificación de Componentes y Disposición del Padre

Short description:

Se puede utilizar varias veces, no se identifica semánticamente con uno, no es un ID, es una clase adecuada y es lo que harías como un modificador. Los patrones y la biblioteca de patrones vuelven al centro, ya que tienes algunos sabores predefinidos de ese componente básico que se extienden, todos están en el mismo lugar y se utilizan ampliamente en todo el sitio web. Esto no se trata tanto de cómo reutilizamos los patrones. Es más bien, ¿qué estoy tratando de resolver cuando creo estas excepciones? Porque esto es más interesante. Así que noté que la mayoría de estas excepciones y patrones estaban relacionados con tres cosas en particular. La primera era la disposición con los componentes padres. Así que quería asegurarme de que el componente hijo que quería extender estuviera posicionado de cierta manera en relación al padre.

Se puede utilizar varias veces, no se identifica semánticamente con uno, no es un ID, es una clase adecuada y es lo que harías como un modificador. Este es un modificador normal, mantiene todo en estrecho contacto con la base original y tiene un valor semántico que no es un ID enmascarado por un nombre de clase. Así que funciona mejor de esa manera.

Los patterns y la biblioteca de patrones vuelven al centro, ya que tienes algunos sabores predefinidos de ese componente básico que se extienden, todos están en el mismo lugar y se utilizan ampliamente en todo el sitio web. Podría impulsar la abstracción preventiva, porque ves una excepción y dices, OK, esto es algo nuevo que voy a introducir, y nunca lo volverás a usar, convirtiéndolo efectivamente en otro ID. Pero, de nuevo, podría impulsarlo. De todos modos, tampoco es muy escalable. Solo tienes un número finito de ellos de todos modos. Nuevamente, si quieres traducir eso a un mundo más reactivo, no usaría clase Así que cuando los montes, sabes inmediatamente lo que estás montando. Pero es posible que hayas usado algunos de estos patterns de todos modos en algún momento.

Entonces, algunas cosas que he visto en los últimos años, pero esto no era lo que quería hacer cuando empecé a escribir la charla. Te dije que no tengo respuestas. Solo te estoy mostrando lo que teníamos. Así que estaba atascado. Esto no era lo que tenía en mente. Y en este punto de la charla, me di cuenta de que realmente no es tan simple. Así que volví al problema y traté de redefinirlo. Esto no se trata tanto de cómo reutilizamos los patterns. Es más bien, ¿qué estoy tratando de resolver cuando creo estas excepciones? Porque esto es más interesante. En lugar de mirar la solución técnica para resolver el problema, volvamos a la mesa de dibujo. Echemos un vistazo profundo al problema en sí mismo.

Así que noté que la mayoría de estas excepciones y patterns estaban relacionados con tres cosas en particular. La primera era la disposición con los componentes padres. Así que quería asegurarme de que el componente hijo que quería extender de alguna manera estuviera posicionado de cierta manera en relación al padre. Y para lograr eso, otra solución podría ser esta. En lugar de tocar el diálogo, podría hacer un diálogo que se adapte al tamaño del padre y el componente padre es responsable de aplicar las restricciones de tamaño, por ejemplo. Entonces, el componente padre tiene la responsabilidad de definir el espacio al que el diálogo se adapta. En este caso, el diálogo es muy genérico, no tiene que saber nada sobre ningún tipo de extensión, y la página de Intención del Juego es la responsable de definir las restricciones. Lo cual, hasta cierto punto, es realmente bueno. Nuevamente, el principal problema que veo con esto es que obtendrás mucho HTML que normalmente no tendrías si no estuvieras pensando de manera componentizada.

10. Resolviendo el Espaciado y la Flexibilidad de los Componentes

Short description:

Sabes, lo que llaman devitis en una conferencia no-React, esto es lo que lleva a eso. Así que sí, no es genial. La otra cosa que estamos tratando de resolver es el espacio entre componentes. En lugar de mirar la posición del padre, es la posición del hermano. En este caso, tiene más sentido tener ayudantes, clases definidas en la biblioteca de patrones y espaciado predefinido. Los componentes abiertos son una solución que requiere más atención desde el punto de vista de la ingeniería. Es cuando defines una API para tus componentes, permitiendo flexibilidad y evitando la necesidad de soluciones improvisadas.

Sabes, lo que llaman devitis en una conferencia no-React, esto es lo que lleva a eso. Así que sí, no es genial. Es una solución, pero no es genial. La otra cosa que estamos tratando de resolver es el espacio entre componentes. Así que en lugar de mirar la posición del padre, es la posición del hermano. Y en este caso, para mí tiene más sentido tener ayudantes, clases que estén definidas en la biblioteca de patrones y traer de vuelta el pensamiento allí en el espacio de design y tener espaciado predefinido. Nuevamente, es posible que no mires el estilo aquí del CSS específicamente. Pueden ser variables en tu CSS o algo así. Pero en última instancia, el punto es que estás volviendo a la biblioteca de patrones, pensando en cómo debería ser la distancia entre los elementos y el espaciado amplio entre los elementos ya no es algo que necesites resolver improvisadamente para cada componente que tengas, está predefinido.

Nuevamente, no escala mucho, porque la flexibilidad ya no está ahí. Como tienes que predefinir todo. Y es algo que podría, si tú y el diseñador no están muy atentos, rápidamente volverse obsoleto y dejar de ser útil y terminarás agregando margen y relleno nuevamente en tu CSS. Componentes abiertos. De acuerdo. Esta es la que más me gusta, personalmente. Creo que esta es la solución para la mayoría de los problemas. Requiere mucha más atención desde el punto de vista de la ingeniería. Básicamente, es cuando defines una API para tus componentes. Hacemos eso en React todo el tiempo. Como, usamos las props para hacer eso. Pero en última instancia, aquí se hace en un CSS, pero en última instancia es cuando dices, okay, este componente puede tomar un ancho y una altura para el icono, por ejemplo, y lo voy a pasar desde afuera, y eso es todo. No hay anulación. No hay nada específicamente que sea un comportamiento predefinido de ese componente. Nuevamente, en este caso, nuevamente el icono hace eso. Podría ser una estructura. Hay muchas formas interesantes de hacerlo en CSS. Incluso hay mejores formas en React. Nuevamente, la responsabilidad de ser flexible recae en el componente que estás diseñando, y debes estar atento para crear una API que tenga sentido para él, y que sea consumida por el padre aplicando la API disponible. Nuevamente, esto es cómo se vería un componente de React si hiciéramos algo así. Puedes pensar en cómo lo harías con styled components.

11. Complejidad y Patrones de Diseño

Short description:

Es una forma común de hacer las cosas, devolviendo el control y la visibilidad al código. Sin embargo, puede volverse más complejo, especialmente al tratar con múltiples tipos de configuración de propiedades. Es importante ser estricto y no abrir todo de inmediato. Otra consideración es el papel de una biblioteca de patrones de diseño en la definición de tamaños y el uso de variables en lugar de números fijos.

Es una forma bastante común de hacer las cosas. Devuelve el control y cuando ves tu código, inmediatamente sabes cómo se ve. No es algo que esté oculto para ti. Hay un lado negativo, que es que, nuevamente, es más complejo. Es una pendiente resbaladiza. He visto componentes con diez tipos diferentes de configuración de propiedades. En ese punto, comienzas a preguntarte cómo interactúan entre sí. Podría ser extraño. Necesitas ser bastante estricto y no abrir todo de inmediato.

Lo otro que para mí es más una cuestión semántica es, si un icono puede tener cualquier tamaño, entonces, ¿cuál es el punto de tener una biblioteca de patrones de design? La biblioteca de patrones de design debería definir esos tamaños de todos modos. Por lo tanto, es posible que desees usar variables de todos modos, no números en general. Pero en general, intentaría volver a pensar en cómo definimos los patterns antes de comenzar a abrir nuestras APIs.

12. Comunicación y Colaboración con Diseñadores

Short description:

Cuanto más sepas quién eres y lo que quieres, menos te dejas afectar por las cosas. Este es el problema cuando se trata de componentes. Necesitamos comunicarnos mejor con los diseñadores, crear un diccionario compartido y comprender sus necesidades. No culpes a los diseñadores, cuestiona las excepciones y colabora estrechamente con ellos y las partes interesadas. Comprende el valor empresarial y de usuario que estás entregando.

¿Ahora, se vuelve más fácil? En este punto de la charla, voy a dejar que la película hable por mí. ¿Se vuelve más fácil? No. Sí. Se vuelve más fácil. ¿Ah sí? Mírate. Gracias. Cuanto más sepas quién eres y lo que quieres, menos te dejas afectar por las cosas. Así que convertirme en gerente de ingeniería me ayudó con eso. Cuanto más sepas quién eres y lo que quieres, menos te dejas afectar por las cosas. Y eso, creo, la siguiente oración es como, simplemente no sé qué se supone que debo ser, que es lo que Scarlett Johansson responde a eso. Y creo que este es el problema realmente cuando se trata de componentes. Tenemos una necesidad en nuestra empresa de comenzar a comunicarnos mejor con los diseñadores, comenzar a hablar el mismo lenguaje y hacer que comprendan nuestro lenguaje, creando un diccionario compartido para hablar de las cosas.

Necesitamos entender cómo podemos comprender lo que ellos quieren y transmitir lo que pensamos que es el significado de nuestras recepciones patterns, porque una recepción en sí misma es una señal. Hay razones para crear excepciones, pero cada vez que hay una excepción, debes preguntarte si esto es algo que realmente necesitamos o si es algo que nuevamente, el diseñador tal vez se fue en un viaje que no encaja en el panorama general que estamos construyendo. Y nuevamente, no culpes a los diseñadores. Ellos saben lo que están haciendo la mayoría del tiempo. Y a veces estas excepciones tienen mucho sentido, pero simplemente cuestiónalo. Habla con ellos. Intenta comprender lo que están construyendo. Intenta comprender la abstracción que te están pidiendo. No te abstraigas demasiado pronto e involúcrate muy temprano en el proceso de design y da retroalimentación sobre lo que ves. Intenta establecer esa relación con tus diseñadores y trabajar estrechamente con ellos. Habla con las personas. No solo con el diseñador. Habla con las partes interesadas. Intenta comprender lo que estás construyendo. Intenta comprender el valor empresarial y de usuario que estás entregando. Y recuerda eso. No estás desesperado. Eso era yo.

QnA

Testing UI Complexity and Snapshots

Short description:

Gracias. ¿Qué es? Oh. Está bien. Me extendí un poco, lo siento. Te pasaste un poco, pero está bien. Podemos hacer una pregunta y terminamos. Una pregunta de Anna. La interfaz de usuario puede volverse bastante compleja, incluyendo estilos dinámicos. ¿Cómo deberíamos probarlo? En mi experiencia, las pruebas manuales son muy útiles en la interfaz de usuario. Por eso, las bibliotecas de patrones y el código ayudan mucho. Estoy de acuerdo en que las instantáneas no son ideales. La detección visual de cambios podría ayudar, pero es difícil de configurar y costosa de mantener. Hay casos de uso en los que tiene sentido, pero sería cauteloso al introducirla en cualquier aplicación.

Gracias. ¿Qué es? Oh. Está bien. Me extendí un poco, lo siento. Te pasaste un poco, pero está bien. Podemos hacer una pregunta y terminamos. Así que toma asiento en mi guarida. Y obtendré la lista de preguntas. Que debería haber tenido abierta. Soy un maestro de ceremonias de la vida real bien preparado. No.

Una pregunta de Anna. La interfaz de usuario puede volverse bastante compleja, incluyendo estilos dinámicos. El desafío al que nos enfrentamos es asegurarnos de que se vea como debería. ¿Cómo deberíamos probarlo? Las instantáneas no son tan buenas. Así que esto no es una charla completa. No es una pregunta fácil. Es difícil. Y en mi experiencia, las pruebas manuales son muy útiles en la interfaz de usuario. Aprecio que no siempre sea posible y es muy difícil cuando hay un código más extenso. Por eso, creo que las bibliotecas de patrones y el código ayudan mucho. Porque si haces cambios en los componentes y los ves en un libro de estilos o algo así, será mucho, mucho más fácil de ver. Estoy de acuerdo en que las instantáneas no son ideales. Si confías solo en las instantáneas, algo saldrá mal. Nuevamente, la detección visual de cambios podría ayudar. Es difícil de configurar. Es costosa de mantener. No es algo que recomendaría para cualquier aplicación. Hay casos de uso en los que tiene sentido. Hay otros en los que sería un poco cauteloso al introducirla.

Responsabilidad Organizativa para la Interfaz de Usuario

Short description:

Para mí, es un problema organizativo. ¿Quién es responsable de la interfaz de usuario y en qué aplicaciones? Habla con tus gerentes de ingeniería y director para simplificar el flujo, el proceso y la mantenibilidad. Equipos verticales, desde la base de datos hasta el frontend, con una pequeña porción de responsabilidad, pueden simplificar el dominio a un área para tu sitio web.

Nuevamente, en general, para mí es un problema organizativo. ¿Quién es responsable de la interfaz de usuario y en qué aplicaciones? Intentaría hablar con tus gerentes de ingeniería y director y ver si hay una forma de simplificar el flujo, el proceso y la mantenibilidad de las cosas. Prefiero mucho más los equipos verticales. Así que de extremo a extremo, desde la database hasta el frontend y tener una pequeña porción de responsabilidad en eso. Eso simplifica bastante, porque tu dominio se limita a un área para tu sitio web. Nuevamente, no es fácil, sin conocer el contexto de esta pregunta. Estoy encantado de hablar de ello después, si estás cerca. ANA. ANA está aquí. Bueno, entonces ahora puedes votar por la mejor pregunta para una camiseta. Ana. Ana, bien. Ana, tengo una camiseta disponible para ti. Muchas gracias. Ahora tenemos un descanso de 10 minutos, corrígeme si me equivoco. 20 minutos. 20 minutos. Así que hay bocadillos justo afuera y algunas bebidas. Nos vemos en 20 minutos, o ve a la otra pista y disfruta del pequeño descanso.

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

React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
Top Content
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Advanced Conference 2023React Advanced Conference 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
React provides a contract to developers- uphold certain rules, and React can efficiently and correctly update the UI. In this talk we'll explore these rules in depth, understanding the reasoning behind them and how they unlock new directions such as automatic memoization. 
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Top Content
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.
React Advanced Conference 2021React Advanced Conference 2021
47 min
Design Systems: Walking the Line Between Flexibility and Consistency
Top Content
Design systems aim to bring consistency to a brand's design and make the UI development productive. Component libraries with well-thought API can make this a breeze. But, sometimes an API choice can accidentally overstep and slow the team down! There's a balance there... somewhere. Let's explore some of the problems and possible creative solutions.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured WorkshopFree
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Top Content
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn