Pasando de Css-In-Js en tiempo de ejecución a gran escala

Tengo muchas diapositivas, así que seré muy rápido al respecto. A principios de este año, me encontré pensando en componentes, pensando en estilos, pero también pensando mucho en la cantidad de JavaScript que necesitábamos para renderizar nuestros estilos. Estaba en este espectro de JavaScript, deberíamos tener muy poco JavaScript para hacer nuestros estilos, ¿realmente necesitamos mucho más JavaScript para hacerlo? Pasé mucho tiempo inclinándome en esta línea.

Cómo llegué hasta aquí fue básicamente asignado a esta tarea. Que es, encontrar la arquitectura de estilos para Primer React. ¿Qué es Primer React? Primer React es el sistema de diseño que impulsa GitHub. Soy Siddharth. Trabajo en el equipo de ingeniería de diseño en GitHub. Esta fue una tarea épica. Y antes de GitHub, solía trabajar en todas estas empresas y durante los últimos seis años he estado trabajando básicamente en sistemas de diseño y bibliotecas de componentes. Dato curioso, al igual que React, también comencé mi carrera exactamente hace 10 años hoy, así que gracias por eso. Aprecio el globo. Gracias.

Bien, volvamos a la diapositiva en movimiento. ¿Y por qué esta tarea fue tan confusa? Porque cuando intentaba encontrar la arquitectura de estilos para Primer, terminó siendo la arquitectura de estilos para gran parte de React en GitHub. Cualquier cambio pequeño que haga tendría efectos en cascada, ¿lo entiendes? Cascada? Efectos en todo GitHub. Y eso es algo aterrador de hacer. Así que primero hablemos de cómo llegamos al espacio en el que estamos.

Esto no es solo GitHub. Esto es principalmente toda la infraestructura de estilos. Piénsalo. Es 2015, y este meme acaba de salir. Es tan antiguo. La mejor película de todos los tiempos, Mad Max, también se estrenó en 2015, y Drake nos dio esta canción extremadamente genial. Internet Explorer 11 todavía estaba presente. Edge no se lanzaría hasta más tarde ese año. Lo que también significa que cosas como variables CSS que ahora damos por sentado en realidad no eran compatibles en mucho, excepto tal vez en Chrome o el nuevo Firefox. Creo que Firefox fue el primero en implementarlo en 2014. Tiempos diferentes. Requiere muy poco JavaScript para obtener tus estilos.

Escribes tu estilo de esta manera. Este es un componente de botón. Colocas tus colores, colocas tu relleno. Ves muchos códigos hexadecimales, valores de píxeles codificados aquí. No es tan agradable como te gustaría, pero había algunas tooling que existían.

Lo puse un poco más de JavaScript porque tienes que usar Node.js y el compilador JavaScript está escrito en JavaScript. Con una pequeña cantidad de JavaScript, estas son las cosas que podrías hacer. Podrías anidar tus estilos y tener una mejor experiencia de desarrollo y luego podrías compilarlo en CSS.

Lo otro que obtuviste fueron variables. Podías definir estas variables en un solo lugar, lo cual es enorme para nuestros sistemas de diseño. Y luego en nuestros componentes solo tenías que usar esas variables. Así que cuando React apareció en 2013, y luego cuando comenzamos a usar React, lo usarías algo así. Tienes un componente de botón y usa el nombre de la clase. Y luego podrías usar este componente de botón en otro tipo de página.

Lo bueno que acabamos de hacer, al definir un componente en un archivo diferente y luego usarlo en un nuevo archivo, es que hemos creado esta relación. Hemos creado un árbol de dependencias entre componentes. Eso nos ayuda a crear paquetes más inteligentes, eliminar código inactivo. Obtienes muchas tooling de eso. Pero el mismo tipo de tooling realmente no existía para... O no existía realmente para CSS.

Esta clase que proviene de botón, no había una buena manera de saber de qué archivo proviene. Solo tenías que adivinar y empaquetar mucho más CSS. Eso, por supuesto, cambió muy rápidamente con un poco más de JavaScript con CSS modules. Entonces podías configurar CSS modules, básicamente podías simular una importación, eso es lo que llamaría. Porque no hay una importación real de CSS que esté sucediendo de esta manera. Pero estamos creando un árbol de dependencias. Ahora que tu árbol de dependencias de CSS coincide con tu árbol de dependencias de JavaScript, obtienes esta relación realmente agradable uno a uno entre el componente JavaScript y CSS. Y luego puedes empaquetarlos juntos. Puedes eliminar código inactivo muy rápidamente.

Lo siguiente interesante que se obtiene, aunque tengas variables en Sass, wow, veo tus ojos, lo siento por eso.

Entonces, cuando tienes que hacer múltiples theming, y theming no se trata solo de modo claro u oscuro, theming hay modo claro, modo oscuro, hay diferentes tipos de daltonismo, lo mismo ocurre con el modo oscuro, hay oscuro atenuado, por lo que tienes muchos más temas. Y con algo como Sass, porque estas variables se compilan en tiempo de compilación, no en tiempo de ejecución, básicamente tienes que generar muchos archivos de tema para cada uno de ellos. Así que tendrías tu biblioteca de componentes en claro, tendrías tu biblioteca de componentes en oscuro, tendrías tu biblioteca de componentes en Teletopia, por lo que terminas creando todas estas combinaciones. Pero con un poco más de JavaScript, en realidad podríamos hacer esto en tiempo de ejecución con algo como style components. Porque JavaScript ya tenía variables en ese momento, CSS no. Así que terminas en algo como esto. Donde en lugar de escribir el nombre de la clase, defines todas tus clases con style components, y se parece un poco a CSS, pero no es CSS, y obtienes variables de JavaScript en medio de CSS. Obtienes muchas cosas buenas. Puedes hacer referencia a tu tema y este tema puede cambiar en tiempo de ejecución y propagarse por todas partes.

Algunos de ustedes pueden estar utilizando este estilo. Y pueden envolverlo con un proveedor de temas que se encargue del resto. Entonces, algo interesante es que si agrego este color adicional, no tengo realmente una forma de saber si este es el color correcto, si este color está definido. Segundo, ¿se aplicará este color? Tengo que escribir esto, renderizarlo en el navegador, ver si funciona. Probablemente sea simplemente negro, así que hago clic derecho, inspecciono el elemento, y ahí es cuando puedo saber si es el color correcto.

Entonces agregamos un poco más de JavaScript y TypeScript. Y con TypeScript, ahora obtienes la línea ondulada roja, que te indica que esta propiedad, FGHover, en realidad ni siquiera está definida en el tema, por lo que no es lo correcto para usar. Y luego puedes corregirlo. Lo otro, si no lo has notado, es que cometí un error en alguna parte de las diapositivas donde el color de fondo solo apunta al fondo del botón y no al fondo del hover, y con el tema, porque ahora controlas tu tema, controlas tus estilos, puedes escribirlos de manera más inteligente y puede darte errores más inteligentes. Por ejemplo, el color del borde, estoy usando button.bg, que en realidad no es un estilo válido, que no es una variable de color válida en nuestro sistema de componentes, por lo que podemos darte estos errores, como que no es el correcto, tal vez quisiste decir button.borderColor. Lo mismo ocurre con el estilo de hover, dice, HellasPentaCast, un tipo, themeColorBackground no es asignable. Debes usar hover background. Y debido a que tienes TypeScript, tienes un compilador detrás de esto, también obtienes características como autocompletado, que te ayudan a elegir los fondos de hover correctos.

Entonces, las personalizaciones siguen siendo interesantes. Esta es la forma predeterminada o recomendada de personalizar componentes con style components, donde envuelves el componente de botón en un estilo y luego puedes agregar tus estilos adicionales allí. Algo así es agradable, pero también es un poco de plantilla, es mucho más trabajo. No soy un gran fanático de este estilo porque se aleja un poco del botón. Tendrías un botón de página y luego otra cosa usaría el botón de página y te alejarías cada vez más de la fuente original. Entonces, con solo un poco más de JavaScript, este es el logotipo de team UI, pero team UI, system UI, esta clase de bibliotecas hizo popular esta sintaxis que es la propiedad SX o la propiedad CSS. Y con esta propiedad, en lugar de definir un nuevo componente, defines tus anulaciones en este nivel de uso del componente. Es como una etiqueta en línea, pero no lo es, se compila. Entonces, lo que obtienes es algo como esto, donde tus estilos de botón son los estilos predeterminados y luego los fusionas con los estilos de anulaciones SX que se proporcionan. Y, por supuesto, escribes el SX para obtener el mismo autocompletado de tipos incluso en la aplicación con las anulaciones. Una API bastante agradable, bastante genial. Hemos pasado de menos, como muy poco JavaScript, a mucho JavaScript. Pero hemos obtenido muchas características en el camino, como anidamiento, variables de tema, pero también linting, dependencias de importación. Tenemos un autocompletado muy opinado que podemos configurar, lo cual sería más difícil de hacer sin JavaScript. ¿Es ese el éxito? ¿Es eso lo que queríamos? Supongo que sí. Pero, por supuesto, las cosas vienen con compensaciones. Ha sido un gran éxito, tanto que hay alrededor de 4,000 componentes de presentación en GitHub que tienen la propiedad SX solo para anulaciones de estilo. Y eso ha causado problemas de éxito, como problemas de champú.

Las grandes actualizaciones de estilo son lentas. Por lo tanto, cuando tienes muchos estilos que necesitan actualizarse según el comportamiento del usuario, las actualizaciones tardan un tiempo. La recolección de estilos para SSR también lleva mucho tiempo. Y por significativo, me refiero a alrededor del 10 al 15 por ciento del tiempo de renderizado del servidor. Y luego, el streaming y el suspense lo hacen más interesante, porque ahora tienes que sincronizar tus actualizaciones de estilo de manera muy inteligente. Al observar todas estas actualizaciones, comencé a pensar en cuándo se inyectan los estilos. Y tal vez no necesito hacerlo en tiempo de ejecución. Tal vez podamos compilar estos estilos. Así que agregué otra función justo al final y quería resolverlo con un poco más de JavaScript. Podría ser un complemento de Babel que lea el AST, examine los estilos y luego los compile en archivos CSS.

Así que primero exploré otras soluciones. Vanilla extract es un buen ejemplo de esto, donde te piden que escribas tus estilos en una extensión CSS.TS. Entonces estás escribiendo los mismos estilos de objeto, pero estos pueden ser compilados y obtienes la seguridad de tipos y todas las cosas agradables. Estoy un poco corto de tiempo, así que voy a omitir las partes aburridas. Esto es aburrido.

Otra solución interesante es Atlassian compile, que coincide más con la API de style components y compila tus estilos en archivos .CSS, para que los usuarios solo obtengan archivos .CSS. Así que un buen ejemplo de esto sería tomar todo este código, ponerlo en un archivo .CSS y luego volver a poner el nombre de la clase. Eso es lo que obtienen los usuarios, eso es lo que los desarrolladores crean, eso es lo que ven los usuarios. Bastante bueno. Por supuesto, no es perfecto, hay algunos matices al compilar los estilos. Uno, tu experiencia de creación es un poco peor porque JavaScript es muy componible, puedes hacer muchas cosas, pero si quieres que se compilen, tu conjunto de JavaScript se restringe a cosas que se pueden compilar. Y eso puede causar confusión, puede causar APIs extrañas para que eso suceda. Tengo un pequeño concepto de prueba de esto, se llama CSS-out.js, es un complemento de Babel, si quieres verlo, son como 50 líneas de código solo para ver cómo funciona. Está en Github, esto podría ser una buena introducción a ello.

Entonces, ¿éxito, verdad? Ahora esto definitivamente debería funcionar. Tenemos nuestros estilos, podemos compilarlos y el pequeño problema con el que nos encontramos es que GitHub.com, el que la mayoría de ustedes usa, en realidad no utiliza Babel, utiliza SWC. Y ahí es cuando descubrí que si avanzas lo suficiente en el espectro de JavaScript, terminas en Rust, donde un montón de empaquetadores como SWC, Parcel, todos están escritos en Rust, y luego hay cosas como efbuild que en realidad están escritas en Go. Así que me encontré, si tengo que escribir un complemento, tal vez debería aprender algo de Rust y escribir un complemento en Rust para que podamos usarlo con SWC. Eso realmente me asustó. Así que hay 4000 componentes de presentación, pero están en 20 subpaquetes, y 20 subpaquetes en muchos equipos, y toda esta complejidad que les estamos pidiendo que asuman, 20 subpaquetes diferentes en múltiples equipos, tienen un nivel muy diferente de familiaridad con toda esta herramienta de JavaScript, TypeScript, Rust. A menudo hablamos de la herramienta adecuada para el trabajo adecuado, pero creo que hay un asterisco ahí. Tiene que ser la herramienta adecuada para el trabajo adecuado, para las personas que necesitan hacer ese trabajo. También me di cuenta de que ya no estamos en 2015. Y muchas de estas cosas que obtuvimos al avanzar en el espectro, muchas de ellas ya están ahí. Por ejemplo, las variables de CSS ya forman parte de la especificación de CSS y son ampliamente compatibles. El theming ya está ahí. Hay una propuesta para el nesting que es compatible y algunos navegadores están llegando a más. Hay consultas de contenedor que se están convirtiendo en una especificación muy amplia. Del mismo modo, existen soluciones para el linting y las importaciones que son más nativas del mundo CSS. Por ejemplo, Tileint para el linting, y PostCSS puede brindarte características similares a los módulos de CSS fácilmente.

Así que parecía que probablemente podríamos usar mucho menos JavaScript ahora que CSS se ha vuelto más similar a JavaScript, más variable. Lo único que no tenemos aquí es un autocompletado con opinión y hay algunos buenos ejemplos de esto.

Oh mierda, me olvidé de algo. De acuerdo. Hay una mayor diversidad en los empaquetadores de JavaScript. Hay parser, ESBit, SWC, etc. Pero la diversidad en los editores de código en realidad va en la dirección opuesta, donde VS Code parece ser la opción predeterminada. Incluso los navegadores en línea como Code Sandbox o StackBlitz también utilizan VS Code en el fondo para hacerlo posible. Si puedes admitir VS Code, puedes hacer feliz a una gran parte de la población de desarrolladores. Esa es la dirección en la que comencé a buscar.

Tailwind hace un trabajo realmente bueno en esto. Usa la extensión, utilizan un servidor de lenguaje para comprender lo que estás tratando de hacer, mirar tu tema y luego sugerir clases que realmente coincidan con tu propio tema. Eso es muy inteligente. De manera similar, esto es de Polaris de Shopify. Polaris es el sistema de diseño de Shopify, y tienen una extensión que utiliza algo similar para sugerir variables CSS en CSS que realmente forman parte de su sistema. Entonces, nuevamente, puedes tener cosas muy opinadas, puedes ver que no solo sugiere todo, sugiere shadow porque entiende que estás tratando de usarlo en box shadow. Creo que eso es muy genial. Así que también intenté jugar con esto. Fue sorprendentemente difícil de la manera equivocada y fácil en las cosas que pensé que eran difíciles. Y puedes obtener cosas muy opinadas, también puedes obtener errores de lint, donde puede evitar que no uses las variables que el equipo del sistema de diseño no quiere, pero usa las que queremos que uses, incluso si los valores son los mismos. Entonces hay mucha inteligencia que puedes incorporar a tu herramienta de desarrollo. Aún no existe una buena API de código abierto, una biblioteca de código abierto para hacer esto. Así que si alguno de ustedes quiere ser popular, tener esa fama de estrella de GitHub, esta es una idea gratuita para ustedes. Finalmente, eso debería ser todo. Ahora estamos usando CSS, tenemos las herramientas para ello, esto definitivamente debería ser suficiente. Casi. Recuerda que dije que tenemos 4,000 componentes de presentación que usan SX. Así que tenemos que moverlos todos a CSS para poder usar estas nuevas herramientas. Y una forma de hacerlo sería hacerlo uno por uno, refactorizarlo, pedir a los equipos que lo hagan, posponer a los usuarios, posponer los errores y priorizar la migración a CSS. O podríamos usar algunas herramientas. Así que recuerda esta cosa mágica que mostré antes que puedes hacer con un complemento simple y decidí que sería difícil hacerlo para tantos empaquetadores diferentes al mismo tiempo.

Podríamos hacerlo en el paso del desarrollador en lugar del paso de construcción. Hay una muy buena biblioteca llamada TS Morph. Básicamente, analiza el AST de TypeScript y te permite escribir transformadores que pueden cambiar tu código. Es bastante inteligente en los tipos que te proporciona. Dependiendo del tipo de la variable, puede ser un elemento de apertura JSX o un elemento de autocierre, puede diferenciar los dos, puedes ver los atributos JSX y luego puedes ser muy inteligente con ello.

Por ejemplo, el primero es bastante fácil. Si es margin 10, entonces sé que tengo que tomar esto, ponerlo en un archivo CSS y poner un nombre de clase aquí. Pero como estamos usando un compilador completo de TypeScript, también tenemos la opción de seguir las variables. Por ejemplo, si en SX estás pasando estilos base, en realidad puedes rastrear estas variables en varios archivos y compilar el valor desde allí. De manera similar, si estás llamando a una función, puedes encontrar la definición de la función y desde la definición de la función, devolver una clase en lugar de un estilo de objeto. Así que puedes ser realmente ingenioso, realmente audaz con algo así. Y así es como espero que migremos esos 4,000.

Ahora, lo que las computadoras no son tan buenas es nombrar cosas. Aunque tenemos mucho contexto en el archivo, puedes usar el nombre del archivo, puedes usar el nombre de un componente. Muchos de los nombres de clase terminaron viéndose así, donde hay un contenedor de envoltura de pila y luego un hash al final. Y eso es en lo que las computadoras no son buenas. Supongo que lo son, pero no sé lo suficiente de IA para ser bueno en ello. Entonces, el código que se genera no es muy mantenible a largo plazo. La forma en que lo veo es que no es una migración automatizada. Es una migración asistida por automatización. Y así es como se hace. Ejecutas tu comando, te da un poco de código, lo revisas como lo haría un desarrollador y luego, si te gusta, puedes sugerir algunos cambios de nombres de clase y luego lo implementas. Estaré recaudando una ronda de financiamiento porque dice migración asistida por automatización, y eso califica como IA. Puedes encontrarme en la sesión de preguntas y respuestas después con tus propuestas.

Entonces, en resumen, ¿deberías dejar de usar CSS en JS también? Depende. Si te encuentras en algún lugar de este espectro y piensas que estamos bien donde estamos, no tenemos los problemas de rendimiento de los que habló este tipo, todos nuestros desarrolladores son muy buenos en JavaScript, realmente no necesitamos preocuparnos, entonces quédate donde estás. Es un lugar feliz para estar. Pasé muchos años aquí, estaba bastante feliz.

Si tienes un equipo que es muy bueno en JavaScript, muy bueno en herramientas, y te gustaría invertir más tiempo en mejorar tu experiencia de desarrollo mejorando el editor, mejorando tu sistema de complementos, entonces definitivamente ve más por JavaScript, ahí es donde está la mayoría de la diversión. Si eres como yo y te encuentras en un lugar donde tu equipo es muy mixto, con muchos diseñadores, desarrolladores, diferentes conjuntos de habilidades que contribuyen al mismo código, entonces te recomendaría ir completamente hacia la izquierda y usar las herramientas nativas de CSS, es realmente bueno ahora. Te sorprenderás de lo lejos que puedes llegar con muy poco JavaScript.

Eso es más o menos todo. Voy a hacerlo de nuevo porque pasé demasiado tiempo en esta diapositiva. Y eso es todo. Esa es mi charla.

Muy bien. Así que tenemos algunas preguntas en la diapositiva. La gente te ve como una opinión experta en CSS y las diferentes herramientas y bibliotecas de CSS. Así que tengo varias diferentes. Así que vamos a ir y me vas a dar tus opiniones sobre ellas.

La primera fue ¿qué opinas de panda CSS? Nunca había oído hablar de eso. No tengo opinión. Lo siento. Muy bien. Tal vez más tarde, en el turno de preguntas y respuestas, puedan venir y mostrártelo y podamos averiguarlo. Sí, me encantaría. Y luego tenemos otra. ¿Qué piensas de tailwind CSS? Esta te la esperabas. Sí. Sí. Definitivamente. Así que exploramos como parte de toda la exploración para este proyecto, también exploré tailwind. Y menos tailwind específicamente, pero más la idea de un CSS de estilo de utilidad que también tiene muy buenas herramientas. Y es una idea muy prometedora para nosotros. Hay ciertos aspectos en el ámbito de los componentes donde si tienes una biblioteca de componentes y quieres agregar anulaciones, es muy difícil hacerlo solo con nombres de clase. Porque el orden en el que das nombres de clase a un elemento HTML no importa realmente. Lo que importa es el orden en que aparecen en el CSS. Y si lo distribuyes por toda una gran aplicación, no puedes controlar realmente el orden. Así que necesitas un poco de CSS en tiempo de ejecución para asegurarte de que estás deduplicando estos nombres de clase para que eso suceda. Y ahí es donde empezamos a alejarnos de eso.

Porque realmente estábamos en el camino de no querer una solución en tiempo de ejecución. Lo mostré a varios desarrolladores. Algunos desarrolladores dijeron que les encanta, y otros desarrolladores dijeron que lo odian. Esto ya no es una conversación técnica. Así que no seguimos por ese camino.

Genial. Creo que los camarógrafos tienen un pequeño problema de CSS. Están como, pon el punto ahí. Es como una cuadrícula. Centrar y un div. Pero llegamos al final.

Otra pregunta que ha surgido es ¿qué piensas de las bibliotecas principales de CSS en JS como MUI, luchando con el renderizado del lado del servidor? ¿Deberíamos volver a los módulos de CSS? ¿O evolucionarán las bibliotecas? Esa es una muy buena pregunta. Hay un camino para que las bibliotecas evolucionen y funcionen muy bien con el renderizado del lado del servidor, suspense. Hay una dirección allí. Siento que hay un murmullo que está sucediendo de que tal vez no vayamos por ese camino. Y tal vez retrocedamos un poco y volvamos a CSS. Así que para bibliotecas como MUI, estoy realmente curioso por saber qué están pensando en términos de estoy seguro de que se encuentran en el mismo espectro donde podrían ir un poco más con JavaScript y comenzar a construir complementos para todos estos diferentes bundlers, o ir en la dirección opuesta y eliminar o compilar por completo el CSS en tiempo de ejecución.

Ahora eso tiene sentido, eso tiene sentido. Ahora esta siguiente pregunta, en retrospectiva, es 2020 y si pudieras reescribir prime desde cero, ¿qué pila usarías? Si comenzara hoy, con el equipo que tengo hoy, probablemente iría primero con CSS porque tenemos muchos desarrolladores de CSS muy buenos que también son diseñadores muy inteligentes. Así que iría por ahí, y siento que estamos en un punto en el que no sería tanto una decisión técnica, porque comparé todas estas opciones, hice todas las tablas de pros y contras y al final se redujo a que esta se ve más bonita, así que diría que la habilidad es cómo decidí hoy.

También me encanta eso, elegir una pila basada en los miembros del equipo y sus fortalezas. Buena elección, buena elección. Tenemos otra pregunta, ¿qué piensas sobre el CSS crítico ya que es un problema bastante resuelto con CSS en JS? Sí, lo es. Creo que una cosa que definitivamente mantendríamos, lo único que estamos tomando del mundo de CSS en JS es algo como los módulos de CSS, y aunque podríamos hacerlo con CSS, la idea de que cada archivo de componente tenga un archivo CSS asociado. Y luego, a medida que compilas tu árbol de JavaScript, también puedes adjuntar tu árbol de CSS encima de él. Creo que esa es una idea invaluable y perdurará por mucho tiempo. Y eso también te ayuda a resolver cosas como el CSS crítico, el tree shaking, saber cuándo eliminar código. Creo que el árbol de dependencias es algo que va a permanecer por un tiempo.

Genial. Una cosa que también me encanta de ver a los desarrolladores dar presentaciones es que a menudo me expongo a nuevas herramientas de desarrollo que realmente me dan envidia y realmente quiero.

Y alguien preguntó, ¿cuál es la extensión de TypeScript que estás usando? ¿La extensión de TypeScript para? Creo que estaba en tus diapositivas, pero tus diapositivas en el editor de código en tus diapositivas estaban usando TypeScript. Oh, nada. Eso es solo Keynote. Buen diseño. Buen diseño. Es como, escribí y dibujé el rectángulo para obtener la cosa de TypeScript. Sí. Lo estilicé muy bien. Bien, haremos esto como el último.

¿Qué hay del espaciado de nombres de CSS, algo que los componentes estilizados ya están proporcionando? Sí, creo que es interesante porque depende. Si es un... Estamos dividiendo esta implementación de media hora donde los componentes de biblioteca, no les estamos dando espaciado de nombres. Por lo tanto, podrías tener algo como un botón Primer. Y eso se mantiene igual en todo el stack. Pero algo como un componente de aplicación donde cosas como wrapper, stack, container son nombres legítimos, esos tienen espaciado de nombres porque no queremos conflictos. Entonces, el mismo árbol de dependencias que obtenemos, también obtenemos la capacidad de hashear estos y tener sin conflictos con eso. Algo como CSS modules. Gracias, Sid. Todos aplaudan. Gracias.