A Prueba de Futuro Tu UI: Construyendo Con Web Components

Hoy, voy a hablar sobre cómo preparar tu UI para el futuro usando web components. Ahora, mi charla está algo relacionada con un reciente drama en Twitter, pero prometo que es anterior a ese drama y realmente no estaba buscando provocar nada con esto. Y otra confesión, el título es un poco un anzuelo, pero probablemente estaremos de acuerdo en que algo como, y cito, teníamos un caso de uso específico mejor resuelto con web components para hacer nuestro material a prueba de futuro, bueno, eso es un poco largo, ¿verdad? Así que vamos con este en su lugar.

Mi nombre es Darko. Me encanta Linux. Soy un nerd de Linux en toda regla. Me encanta todo lo abierto. Código abierto, la web abierta, estándares y demás. Actualmente estoy haciendo el DERL para SuperTokens, la empresa de autenticación de código abierto, échale un vistazo. Y estoy escribiendo en Darko.io. Ahora estoy en la mayoría de las redes sociales, si quieres seguirme a mí y a mi trabajo. Y también estoy en BlueSky porque BlueSky es increíble.

Para darte un poco de contexto sobre por qué comencé a hacer esto en primer lugar. Ahora, esto comenzó como un viaje y un experimento de I+D en mi trabajo en SuperTokens. Teníamos una pregunta frente a nosotros. ¿Cómo soportas, con una biblioteca de UI, todos los frameworks de UI que existen? Bueno, puedes responder a esa pregunta de una de dos maneras, generalmente. Una de ellas es emplear un ejército de ingenieros que te permita soportar Angular, React, Vue, Svelte, Solid y el resto de ellos. Hay muchos. O puedes optar por algo como Web Components. Ahora, no me malinterpretes. Los Web Components son una especie de compromiso en muchos sentidos. Pero dado el problema adecuado, bueno, son la herramienta perfecta para ello. Resulta que este experimento terminó siendo un éxito. Y veremos por qué terminó siendo un éxito. Es posible que publiquemos una biblioteca relacionada con UI, relacionada con autenticación, basada en este experimento.

Un poco de historia relacionada con el drama de Twitter que mencioné antes. Ahora, no me malinterpretes. Respeto completamente a Ryan y su trabajo. Y me encanta todo lo relacionado con Solid. Creo firmemente que SolidJS ha sido una de las mejores cosas que le ha pasado a la web en los últimos años.

Pero si contrastas este título, Web Components are not the future, que proviene del blog de Ryan con el título de mi presentación que es Future-proof your UI building with Web Components, obtienes un contraste. Realmente no va en la misma dirección. Y francamente solo estaba tratando de ayudar con el título aquí. Pero dejando de lado su título, estoy de acuerdo con la mayoría de lo que escribió allí. Así que ten eso en cuenta mientras avanzamos en esta presentación.

Lo interesante que surgió de este título fue como este drama de Twitter. Y ves como esta fenomenal representación artística usando mis fenomenales habilidades artísticas. Bueno, de un lado tenemos a las personas de frameworks que decían ¡Web Components apestan! Como que no nos gustan. Y las personas de estándares del otro lado decían Web Components all the things porque como razones. Sabes, hay muchas razones para hacer eso. Y está el resto de nosotros como refiriéndose al meme del campesino ahí abajo. Pero sabes que algunos de nosotros usamos ambos. Y como si estás involucrado en un drama de Twitter te hace sentir un poco raro digamos porque los dramas de Twitter tienden a ser muy polarizantes. Ignorando que hey hay un punto medio aquí. Sabes que puedes usar ambas herramientas adecuadas para el trabajo adecuado y todo eso. Así que desde el punto de vista de los autores que no son de frameworks y las personas que no son de estándares, ese es como el punto de vista del que estoy hablando. Me di cuenta de que los problemas de las personas de frameworks son reales y los problemas de las personas de estándares son reales pero estadísticamente hablando no son el tipo de problema más común. Así que solo ten eso en cuenta durante la presentación.

Así que bueno, suficiente drama. Vamos a lo que realmente son los Web Components. Entonces, en cierto sentido, puedes considerarlos etiquetas personalizadas de bricolaje. Tener tu propia etiqueta HTML para cualquier caso de uso que puedas imaginar. Se pueden distribuir a través de etiquetas de script, a través de declaraciones de importación, a través de todas las formas regulares en que puedes importar cualquier cosa en una página web, aplicación web. Estos funcionan a través de frameworks. En su mayoría. React no los estaba.. no los estaba soportando completamente hasta la 19. La 19 los soporta muy bien. Así que como que puedes usarlos prácticamente en cualquier lugar en realidad. Así que son un estándar como hemos establecido y pero bajo el capó puedes dividirlos en como tres cosas temáticas en general.

Como está la API de elementos personalizados, la API que te permite registrar esas cosas en el DOM. Está la API de shadow DOM que encapsula y oculta algunas cosas bajo el capó y están los elementos HTML, Slot y Templates que juntos crean lo que llamamos la familia de APIs de componentes web. Pero no vamos a entrar mucho en eso. Si estás interesado en la teoría, solo revisa MDN. Hay muchos recursos allí.

Sin embargo, tenemos algunos problemas. Bueno, las APIs son... ¿cómo lo digo suavemente? No son bonitas. En mi experiencia o al menos en mi opinión. Y sé que es sesgado. Pero acostumbrarse a una experiencia de desarrollador como la de JSX, bueno, no hay opción de volver de eso a menos que introduzcas algo mejor. Y de nuevo, en mi muy sesgada opinión, optar por la herencia de clases y la forma muy antigua de escribir componentes me parece un paso atrás, honestamente. Y hay otro problema.

Como hemos establecido recientemente a través de esa cadena de publicaciones de drama en blogs, como la idea de componentes web no se traduce exactamente bien a la idea de un componente de framework. Así que esos son dos de los mayores problemas actualmente. Ahora, en mi opinión, los componentes web están significativamente más cerca de los elementos HTML. A como la idea de un elemento. Y los componentes web pueden ser mucho más complejos, pueden hacer más cosas. No es que los componentes web no puedan, pero la complejidad que puedes manejar a través de componentes de frameworks en mi opinión es un poco mayor que lo que puedes hacer con componentes web. Ahora, debido a esto, la idea de compilar a componentes web desde un componente de framework no siempre se traduce bien. Y veremos por qué más adelante.

Ahora, en primer lugar, el problema de la experiencia del desarrollador se aborda muy fácilmente. Tenemos muchas herramientas modernas que te permiten escribir un componente en, como, SolidJS, en Vue, en Svelte, lo que sea, y compilarlo a un componente web que puedes distribuir en cualquier lugar. Ahora, mi herramienta preferida es Solid Element, porque me encanta Solid. Es increíble. Así que puedes usar cosas como Signals, todas las cosas buenas que vienen con Solid, y como empaquetarlo dentro de un componente web y enviarlo a cualquier lugar. Y como, el ejemplo que tenemos aquí a la izquierda me parece un poco anticuado, como, sin ofender, pero como Java circa 07. Y como el de la derecha aquí se siente muy moderno. Puedes escribir algo de JSX, se empaqueta como un componente web, ¿qué no te va a gustar, sabes? Tendría la experiencia adecuada, la experiencia adecuada para el desarrollador, cualquier día de la semana, comparado con el de la izquierda. OK, pero sabes qué, basta de drama y teoría.

Vamos a construir algunas cosas. OK, ahora para nuestra demo, estamos usando Vite, y estamos basando nuestra demo en el scaffold de Solid, que puedes encontrar en el scaffold regular de Vite Solid, pero con dos diferencias. Se va a construir en el modo de biblioteca, lo que significa que obtenemos un archivo JavaScript de él que podemos incrustar tal vez en un proyecto de React, y estamos usando este plugin aquí que ayuda con el empaquetado de CSS.

Ahora, CSS, hay un par de maneras de empaquetar CSS junto con un componente web, pero para propósitos de demostración, esta es probablemente una de las más simples que he encontrado, así que vamos a usar esa. Si echamos un vistazo al archivo index, porque como cada proyecto de Vite viene con un archivo index, podemos ver todas las cosas regulares que esperamos de un scaffold de Vite, pero tenemos este componente C básico aquí, vamos a ver qué es eso, pero en resumen, así es como se ven los componentes personalizados, o más bien, los componentes web.

Ahora, nuestro punto de entrada en todo esto es este archivo principal en el que importamos todo lo demás, y actualmente solo importa algo llamado básico, así que echemos un vistazo a básico. Básico es, bueno, una especie de componente solid en cierto sentido, pero está envuelto dentro de esta cosa llamada elemento personalizado, que viene de solid element, que es esta biblioteca que nos ayuda a construir componentes web usando solid js. La forma en que funciona es tomando un montón de argumentos de entrada, el primero siendo C básico, que le da a este componente el nombre bajo el cual podemos referenciarlo dentro del HTML, o en cualquier otro lugar para el caso. El segundo tiene que ver con props y atributos, pero entraremos en eso en el próximo ejemplo, y el tercero es una función, que nos permite básicamente escribir algo de JSX aquí, esto es JSX, y compilarlo a HTML, que puede ser inyectado dentro de cualquier DOM.

Así que echemos un vistazo a eso en el navegador. Ahora ya tenemos el servidor de desarrollo corriendo aquí, y si echamos un vistazo a la página, tenemos este hello world aquí, si lo inspeccionamos, vemos el componente C básico con esta cosa llamada shadow DOM, porque estamos usando el shadow DOM. Nos adentraremos un poco más en eso más tarde. Y volvamos a index. Si copiamos esto un par de veces, se va a comportar exactamente igual que en el HTML, así que básicamente lo que puedes esperar de una etiqueta que ya tiene alguna funcionalidad predefinida, estilos, lo que sea, y tenemos tres hello worlds en pantalla, así que deshagámonos de ese y pasemos al siguiente ejemplo.

A continuación, tenemos props. Ahora, una de las formas en que podemos pasar datos, tal vez incluso modificar el comportamiento, es props. No importa, en cualquier lugar, como, si estamos usando React, o si estamos usando Solid, si estamos usando Vue, funciona de esa manera en todas partes.

Si echamos un vistazo al archivo de props aquí, veremos que es muy similar al ejemplo básico ejemplo, le damos un nombre, pero estamos pasando algunos props. Entonces, este prop, myMessage, es como el predeterminado, digamos, y lo referenciamos por props.myMessage, que es el argumento de entrada de la función que es el tercer argumento de custom element.

Podemos usar estos datos si no los sobrescribimos en el HTML, así que echemos un vistazo a cómo eso realmente se ve. Solo pasa algunos props sin ningún props, y probablemente veremos otro hola mundo, ¿verdad? No muy emocionante. Sin embargo, si hacemos algo como esto, podemos personalizar el mensaje. Por supuesto, hola desde el otro lado. Y si le pasamos algo más, este cursor siendo un poco inteligente, claro, ¿por qué no? Y estamos obteniendo algo más.

Así que ya tenemos alguna forma de personalizar lo que sucede dentro del componente personalizado, o componente web, elemento personalizado o componente web desde el mundo exterior, en cierto sentido. Ahora, hay una advertencia aquí. Los únicos dos tipos que podemos usar de manera confiable aquí son cadenas, porque los atributos se pasan como cadenas, o más bien HTML admite atributos de cadena, o booleanos, teniendo la presencia o la ausencia de cierta cosa.

Hay formas de pasar otros tipos de datos, no podemos mostrar eso aquí, es un poco más complicado, pero intentaré hacer un ejemplo con eso un poco más tarde. Ahora, a continuación están los slots. Probablemente estés familiarizado con slots bajo un nombre diferente. En el mundo de React, los slots son algo equivalentes a los hijos de React.

Ahora echemos un vistazo a cómo se ven los slots en este mundo muy extraño de compilación de solid-to-web-components. Ahora, podemos usar una etiqueta de slot. Y los slots vienen en dos sabores en general, como slots nombrados y slots predeterminados. Los slots predeterminados son lo que puedes simplemente poner entre las etiquetas de tu elemento personalizado y aparece aquí, en este div en particular. Y si usamos un slot nombrado y le pasamos un atributo de slot en el otro lado, se renderiza dentro de este. Así que veamos cómo se ve eso en acción. Así que si usamos cslots y digamos que queremos hacer Hello World, claro. Hagamos esto. Eliminemos este por ahora, no lo vamos a necesitar. Y veamos realmente cómo se traduce esto del HTML al JSX que tenemos en el otro lado.

Entonces estamos registrando esto bajo cslots, claro, lo que devuelve un div con un montón de slots aquí. Le pasamos un h1 con un slot de header, que reemplaza esta parte aquí. Tenemos un párrafo que iría al slot predeterminado. Y tenemos un h2 nombrado, que baja al slot llamado footer. Así que bien, si echamos un vistazo a esto rápidamente. Vamos a ver, inspeccionar elemento, y tenemos header. Está haciendo referencia a este elemento aquí. Y este hace referencia al párrafo aquí, así que estamos haciendo lo correcto, y este hace referencia a este elemento aquí.

Ahora esto es, tenemos atajos para esto para que sepamos que estamos haciendo las cosas bien en las DevTools. Y si añadimos algo más aquí, digamos que añadimos un div aquí con, no sé, adiós mundo, un poco oscuro pero seguro, funciona. Podemos ver como esta cosa dentro del shadow root y aquí va, adiós mundo, ¿verdad? Así que está en el slot predeterminado de nuevo. Así que todo funciona, ¿verdad? Tenemos algunos slots, funciona. Sin embargo, tenemos una advertencia. La única forma en que esto funciona de manera confiable es usando el shadow DOM. Eso no siempre es conveniente porque el shadow DOM encapsula, estilos encapsulan un montón de otras cosas del mundo exterior. Y eso no siempre es apropiado para lo que podemos estar tratando de construir. Por ejemplo, en SuperTokens esto realmente no funcionó para nosotros, así que estamos usando polyfill para slots, pero eso no está tan mal, así que supongo que termina bien.

Como dije, esto es un compromiso. Para nuestro próximo ejemplo, vamos a echar un vistazo al manejo de eventos. Así que nuestro manejador de eventos debería estar aquí y estamos tratando de no usar el shadow DOM aquí, solo para cambiar las cosas. Y estamos registrando esto bajo C event handler para enfatizar cómo esta cosa maneja eventos. Y simplemente estamos devolviendo el botón simple que hace lo siguiente. Vincula esta función onclick, que registra onclick y nos muestra una alerta si no tenemos un element. handleClick. Ahora hay una diferencia importante con el ejemplo anterior. Estamos accediendo a otro argumento aquí, otro argumento de entrada aquí llamado element. Lo estamos desestructurando. Lo que element es, es una referencia al nodo DOM real en el que se renderiza este elemento personalizado. Ahora, cómo se ve eso en la práctica es algo como esto.

Eso significa que el comportamiento predeterminado se activará desde aquí. Y si hacemos clic en la cosa aquí, dice que soy una alerta de respaldo. Lo que significa que no le pasamos ningún dato ni ninguna forma de anular el comportamiento de este componente manejador de eventos aquí.

Ahora, la forma en que podemos anular su comportamiento es algo así. Así que claro, está bien, veamos hasta dónde llegamos con copilot aquí. Así que tiene como un handleClick, de acuerdo. Así que, está bien, entiende correctamente lo que estoy tratando de hacer. Incluso como por cualquier medida, como esta pila y enfoque es un poco exótico, pero kudos a cursor supongo. Así que estamos seleccionando el elemento C event handler desde aquí. Le estamos pasando esta propiedad handleClick y estamos haciendo, estamos asignando una función a esta propiedad handleClick. Y si echamos un vistazo al archivo del manejador de eventos aquí, estamos esperando exactamente eso. Como estamos verificando si este elemento, el nodo DOM exacto que estamos esperando desde aquí tiene y si tiene una propiedad handleClick, la estamos ejecutando. Claro, esto es un poco como, esto es cualquier cosa, por supuesto, así que no tiene un tipo, lo que sea, pero oye, funciona. Estamos experimentando aquí. No estamos tratando de complacer a typescript. Así que si hacemos el clic aquí, va a anular el comportamiento predeterminado y va a decir que estoy en alerta desde el padre. Ahora, si te gustan las señales, por ejemplo, puedes hacer algo como, ya sabes, pasar la señal al exterior, hacer que inyecte cosas dentro del componente y así sucesivamente, pero eso va a tomar un poco de tiempo para mostrarlo adecuadamente y vamos a continuar con la demostración.

Nuestro ejemplo final aquí es básicamente un ejemplo completo. Hace todo. Tiene CSS, tiene un montón de otras cosas. No usa el shadow DOM, porque como, quiero complicar mi vida, no sé. Y vamos a probarlo. Veamos cómo como ccounter, si lo referencias aquí, dice ccounter, c-counter, ¿lo descomenté?, sí lo hice, y echemos un vistazo a cómo se ve eso. Sí, tenemos un contador completo aquí, que ya sabes, solo suma el conteo. Pero aquí está lo interesante aquí. No es realmente un elemento sólido en este punto, es un componente web completo. Así que la forma en que podemos usar esto, todo lo que producimos aquí dentro del proyecto de React, afortunadamente tengo algo así ya configurado, podemos simplemente hacer un npm run build desde aquí, y como va a construir como estos dos archivos, que podemos encontrar en dist. Tenemos una variante ES de ese módulo y un UMD, voy a copiar ambos. No es que necesitemos ambos, pero ya sabes, puedes.

Tengo estos en componentes, vamos a reescribirlos con la última versión de lo que acabo de construir. Y echemos un vistazo a lo que realmente tenemos allí. Así que vamos directamente a demos. Y dentro de demos, tenemos lo que podrías esperar de un andamiaje de Vite. Y revisemos lo que tenemos dentro de app.tsx. Ahora, solo para que conste, TypeScript se va a quejar. Lo hará. No tenemos ningún tipo. Hay formas de introducir tipos, pero bueno, solo estamos tratando de mostrar algo aquí. Primero eliminemos estas cosas de aquí arriba.

Estamos importando Solid Web Components.es, que es este archivo de aquí. Es un archivo Javascript, pero no importa, va a funcionar. Y primero intentemos C.basic. Y esto también va a ser un C.basic cerrado. Para que esto funcione, tendremos que hacer demos. Y vamos a la demo de React, y vamos a hacer un npm run dev. Y nuevamente, en localhost 5173, obtenemos un Hello World! ¿Es eso lo que estamos buscando? Vamos a comprobarlo. Echemos un vistazo a través de inspeccionar elemento. ¡Sí! Este es nuestro componente C.basic.

Así que, está bien, como React entiende los Web Components. Genial para nosotros. Así que, lo que podemos hacer a continuación aquí es, probemos el ejemplo completo, como digamos C, queremos hacer un C.counter aquí. Porque ya lo teníamos registrado en el archivo principal, lo que significa que ya ha sido registrado en el DOM. Y sí, tenemos un Web Component completo producido desde solid hacia un proyecto de React. Ahora, si queremos hacer algo como, digamos, no sé, probemos C.props. Para que podamos hacer algo extraño. Prueba C.props y digamos que vamos con MyMessage igual a Hello from the other side. Probablemente va a mostrar el Hello from the other side. Pero aquí está la parte interesante. Podemos hacer algo como esto, que se activará desde React.

No va a funcionar dentro del componente, pero va a funcionar desde fuera de él. Y aquí tenemos la alerta de clic. Esto, a su vez, tiene el agradable efecto secundario de permitirnos combinar partes de lo que queremos ejecutar dentro del Web Component, es decir, compilado desde Solid Land, y lo que podríamos querer ejecutar completamente dentro de nuestro código de framework. Así que puedes mezclar y combinar dependiendo de tu caso de uso.

Finalmente, algunas conclusiones. Los Web Components son geniales, diría yo, para algunos casos de uso. No son una solución mágica. Como habrás visto, la experiencia del desarrollador se vuelve un poco incómoda. Ciertamente no escribiría un proyecto completo con Web Components. Simplemente usaría algo como, no sé, SolidJS por ejemplo. Pero son geniales para algunos casos de uso. Especialmente cuando intentas producir algo que puedas importar en cualquier lugar. Ya hay un par de esos casos de uso que podríamos argumentar que son excelentes, pero veremos algunos de esos en la siguiente diapositiva. No son una solución mágica. Ni de lejos. No importa lo que la gente pueda decir. No son malos, no son lo mejor de lo mejor. Son solo una herramienta que se puede usar para resolver problemas que son apropiados para ese tipo de herramienta. Si te encanta la idea, porque me encanta la idea de los Web Components, pero no soy realmente un gran fan de las APIs, simplemente usa Solid, usa Preact, usa Lit. Incluso puedes usar React a partir de la versión 19. Así que estás bien, puedes producir cosas en una experiencia de desarrollador con la que estés familiarizado y cómodo.

Está bien, bien. Podría ser así. Pero, ¿para qué son realmente buenos los Web Components? Así que aquí hay algunos casos de uso que creo que son un ajuste perfecto para cosas como los Web Components. Uno, el más obvio, sistemas de diseño. Como Shoelace hace un gran trabajo con esto. Puedes usar Shoelace literalmente en cualquier lugar. Ya sea como una página HTML estática o algo como Next.js, puedes usarlo. Está bien, va a funcionar. Puede que no encaje perfectamente en todos los casos, pero funcionará.

Y si estás tratando de resolver un problema así, ese es un buen caso para ello. Proyectos como SuperTokens, que buscan atender a la audiencia más amplia posible en el desarrollo web. Queremos apoyar a todos, queremos ayudar a todos a construir su autenticación de la manera más fácil posible. Así que es una gran opción para nosotros. Tenemos un montón de desarrolladores de React a bordo y puede que no les guste escribir cosas en clases usando las APIs ya disponibles, pero podemos rectificar eso dándoles algo como Solid Element. Así que todos están contentos al final.

Son buenos para widgets y embebibles. Si solo quieres integrar un globo de diálogo o algo así, en lugar de pasar por todo ese incómodo proceso de incluir un script y luego incluir un script de inicio, seleccionando un nodo DOM y ejecutando algunas funciones extrañas y cosas así, en su lugar tal vez podrías simplemente usar un script y usar un componente personalizado en algún lugar del árbol DOM y simplemente va a funcionar. Suena un poco mejor y más limpio, ¿no?

Solo para componentes hoja. Los componentes hoja son un caso interesante. Los componentes hoja son literalmente lo último que se renderiza dentro del árbol. Para cosas que tienen una funcionalidad muy específica que no necesitan envolver nada, los web components son buenos para eso también. Gracias y disfruta de la conferencia.