Componentes, Patrones y cosas difíciles de manejar

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.

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é.

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.`

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.

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.

¿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.

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.

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.

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.

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.

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.

¿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.

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.

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.