Escalando Componentes en Múltiples Frameworks

Entonces, esta es una conferencia de React, y para escalar tus componentes a diferentes proyectos, la respuesta es, bueno, simplemente usar React.

Entonces, bien, gracias por asistir. Ahora que sabemos cómo hacer que los componentes funcionen en cada una de tus aplicaciones web, en toda tu organización, porque como todos sabemos, durante los últimos 30 años, todas las aplicaciones web solo han utilizado React. Así que gracias por asistir.

Bien, sé que no engañé a nadie allí. Puede haber esta suposición de que una organización solo utiliza una tecnología, pero lo que ven aquí se acerca más a la realidad, especialmente a medida que pasa el tiempo y la tecnología cambia. Esta charla es más para los desarrolladores que están construyendo componentes dentro de organizaciones que se ajustan a esta categoría.

La realidad es que muchas organizaciones grandes utilizan muchos frameworks y bibliotecas e incluso diferentes versiones de estos frameworks. Las organizaciones están compuestas por numerosos departamentos, y dentro de cada departamento, puedes encontrar muchos equipos de software diferentes. Estos equipos manejan una amplia gama de cosas, desde sitios web de contenido, aplicaciones web para dispositivos móviles y de escritorio, aplicaciones nativas para iOS y Android, y así sucesivamente. Y generalmente, cada equipo elige el framework con el que le gustaría trabajar.

Entonces, mientras los equipos eligen el software que mejor les funciona, rápidamente nos encontramos con algunos problemas para administrar componentes con una apariencia y sensación consistentes. Y debido a que los diferentes proyectos se inician en diferentes momentos por diferentes desarrolladores que utilizan diferentes frameworks, a menudo nos encontramos con muchos problemas. Es común, pero más bien un requisito, que una organización cree un sistema de diseño, básicamente poder tener una apariencia y sensación consistentes entre todos sus activos y software web.

Y aquí hay algunos de los sistemas de diseño más conocidos y ampliamente utilizados. El más notable, creo, tendría que ser Material Design de Google. Pero esos fueron solo algunos de los sistemas de diseño notables que se ven geniales. La lista continúa. Si bien no todos nosotros podemos tener un nombre elegante para nuestras bibliotecas de UI, o al menos aún no, muchos tienen los mismos objetivos, y eso es una apariencia consistente y proporcionar una biblioteca de UI bien documentada para varios equipos, tanto dentro como fuera de sus organizaciones, para poder utilizarla. Y algo que hemos escuchado a los desarrolladores decir muchas veces es que han creado un sistema de diseño y simplemente esperaban que otros equipos lo adoptaran. Pero rápidamente se encontraron con este obstáculo, porque otros equipos simplemente no están utilizando el mismo framework.

Entonces, si quieres que tu biblioteca de componentes sea utilizada por diferentes equipos, lo mejor es seguir las mejores prácticas y pautas de su framework. Esto significa que debes poder proporcionarles componentes que ya funcionen en su framework. Y un tema común es utilizar bibliotecas solo de CSS. Y luego cada framework construye una capa encima de esa biblioteca de CSS común. Esto incluye bibliotecas similares a algo como Twitter Bootstrap, pero más bien una biblioteca de CSS personalizada para organizaciones. Ahora, los desafíos al utilizar bibliotecas de CSS dentro de los frameworks de JavaScript es que en el momento en que la estructura HTML cambia o cambia una clase de CSS, básicamente todas esas implementaciones dejan de funcionar. Y aquí hay un gran riesgo al depender de una cierta versión de bibliotecas de CSS. Aquí es donde se introdujo por primera vez la idea de Stencil.

Y antes de seguir adelante, realmente quiero decir que Stencil no intenta reemplazar a los frameworks, ni siquiera actuar como un framework. React y todos los demás ya hacen un excelente trabajo. En cambio, Stencil es una herramienta para ayudar a construir componentes que funcionan naturalmente en cada uno de los diferentes frameworks. Es para ayudar a los desarrolladores a crear componentes que necesitan funcionar en tantos proyectos desconectados como sea posible. Y para hacer esto, utiliza un modelo de componente común en el que se basan todos los frameworks.

Entonces, la gran pregunta es, ¿cómo podría funcionar eso? ¿Cómo puede un componente funcionar en todos los frameworks? Para que un componente funcione en todas partes, debe haber una capa común con la que cada framework interactúe. Y no es sorprendente, la capa común es el DOM, el modelo de objeto de documento. Esto es lo que permite que las páginas web y las aplicaciones web se representen y actualicen en nuestros navegadores.

React, Angular, Vue, todos ellos interactúan con elementos HTML y nodos de texto para representar sus componentes. La parte que a menudo se pasa por alto es que todos estos frameworks representan aplicaciones en nuestros navegadores debido al modelo de objeto de documento altamente estandarizado, que se utiliza en miles de millones de dispositivos en este momento. Y ni siquiera puedo imaginar cuántas veces el DOM ha representado un documento desde el comienzo de esta diapositiva. Cada framework se basa en esta API común, y lo interesante es que el DOM también se puede extender en el nivel más bajo, lo que nos permite crear componentes que se pueden utilizar en cada uno de estos frameworks. Esto nos lleva a la especificación de elementos personalizados. Es una API estandarizada que ya está integrada directamente en los navegadores actuales. Y de hecho, ha estado disponible sin necesidad de polyfills durante algunos años. La capacidad de tener un componente común de bajo nivel comienza con una especificación de elementos personalizados, y es bastante poderosa en su capacidad para ejecutar JavaScript personalizado para componentes individuales dentro del DOM. En el momento en que un elemento personalizado definido llega al DOM, ya sea mediante document.createElement, innerHTML, usando React, Angular, revisión, o cualquier otro, cuando ese elemento llega al DOM, el navegador ejecutará el JavaScript personalizado del elemento. Con esa capacidad sola, Stencil puede aprovechar la idea de generar un componente genérico que puede funcionar en todos los frameworks. Y sí, a pesar de toda la confusión que hay, React puede funcionar muy bien con elementos personalizados. La parte de pasar data a estos elementos, como pasar matrices u objetos, es donde el compilador de Stencil puede generar automáticamente las vinculaciones para eso, para ayudar a resolver ese problema. Y no, ni siquiera estoy insinuando que esto reemplace a React. Más bien, me gustaría mostrar cómo hemos logrado construir una biblioteca de componentes de interfaz de usuario de React que también se puede utilizar en Angular y en Vue, o incluso sin ningún framework, utilizando un componente común y el compilador de Stencil.

Ahora, en comparación con un framework completo como Angular, React o Vue, Stencil tiene muy poco tiempo de ejecución. Esto es bastante similar a Svelte, donde los componentes son generados por un compilador y solo con el código que necesitan. Y Stencil también es similar a Preact en el sentido de que depende en gran medida de las API web existentes ya presentes en el navegador. Sin embargo, una de las mayores diferencias es cómo... La mayor diferencia con respecto a un framework tradicional es permitir que el navegador notifique cuando se ha agregado un elemento al DOM o cuando un atributo ha cambiado. Ahora, los componentes de Stencil extenderán el elemento HTML del DOM. Y debido a eso, podemos aprovechar las API existentes integradas directamente en el navegador. Y probablemente la más útil aquí sería el método ConnectedCallback. Con estas características solas, los componentes de Stencil pueden administrarse y actuar realmente como su propia aplicación autocontenida. Además de eso, hemos restringido intencionalmente nuestros componentes para que solo funcionen con las API proporcionadas por el navegador. Entonces, volviendo a la razón original por la que creamos Stencil, fue para poder mantener una versión central de Ionic al mismo tiempo que ofrecemos Ionic React, Angular en View, y lo que venga después. Ionic es una biblioteca de interfaz de usuario centrada en dispositivos móviles para la web. Pero no quiero centrarme demasiado en Ionic aquí.

En lugar de eso, quiero revisar nuestros requisitos como mantenedores de la biblioteca. Tiene más de 100 componentes, y enfrentamos muchos de los mismos desafíos que cualquier otro equipo. De hecho, los frameworks, las bibliotecas y las mejores prácticas siguen cambiando constantemente. Sin embargo, los componentes en sí se han mantenido relativamente iguales. Claro, actualizamos el diseño, solucionamos errores, manejamos problemas, pero eso no debería requerir reescrituras constantes de cada componente.

Si hay algo que quiero dejar claro es que Stencil es una herramienta de tiempo de compilación. Es una herramienta que nos ayuda a generar y mantener componentes reutilizables. El problema que Stencil resuelve para Ionic es permitir que nuestros componentes funcionen en muchos de los frameworks actuales, pero sin tener que mantener múltiples bibliotecas y diferentes bases de código para cada uno de los frameworks. Y un beneficio adicional es que también podemos adaptarnos fácilmente a los frameworks del futuro, o cuando uno de los frameworks tenga un cambio importante y rompa. Y podemos hacer todo esto sin tener que reescribir el componente una vez más.

Un gran desafío es que cada framework maneja la asignación y lectura de propiedades de manera diferente. Entonces, aunque está muy bien documentado cómo asignar una propiedad a un componente de React, los detalles de cómo funciona eso internamente son completamente diferentes a cómo funciona internamente para Angular y Vue. Aquí es donde entra en juego Stencil para generar estas vinculaciones de frameworks a partir de un modelo de componente común. Así que vamos a sumergirnos en algo de código y crear un componente de barra de progreso utilizando el modelo de componente estándar, y luego generaremos eso en las diferentes vinculaciones para cada uno de los diferentes frameworks y mostraremos cómo usarlo en cada uno de los diferentes frameworks.

Bien, así que vamos a sumergirnos en algo de código y crear un componente de círculo de progreso simple. Aquí estamos estableciendo el nombre de etiqueta del elemento personalizado, incluyendo este estilo directamente, ya que es un ejemplo simple, pero normalmente importaríamos un archivo CSS en su lugar. Y este componente tiene tres propiedades, tamaño, trazo y porcentaje, y actúan como propiedades y atributos en el elemento HTML. Y por último, tenemos una función de renderizado familiar que devuelve JSX. Ahora, me encantaría usar un lenguaje de plantillas estándar aquí, pero el problema es que no existe tal cosa como un lenguaje de plantillas estándar, al menos aún no existe. Y si usamos otro lenguaje de plantillas personalizado, volvemos a usar simplemente otro framework. Así que hoy en día, lo más cercano que tenemos a un estándar sería JSX, y creo que muchos de ustedes probablemente estarían de acuerdo. Entonces, lo que obtenemos es un elemento personalizado autocontenido. Dentro del Inspector de Dev, puedes ver que cambia sus atributos, y debido a que cambia esos valores, la función de renderizado se ejecutará nuevamente. Y lo mismo ocurre al editar las propiedades del elemento. Entonces, este componente funciona de manera independiente de cualquier estructura de la aplicación y se maneja a sí mismo. Esta es la parte realmente poderosa, porque ahora podemos envolver este elemento personalizado con vinculaciones de frameworks y enviar una versión específica del framework de este componente. Pero al mismo tiempo, no tenemos que mantener una base de código adicional para cada framework. Y este es un ejemplo del archivo de configuración de Stencil, donde podemos hacer que el compilador genere numerosos objetivos de salida. En nuestro caso, lo estamos configurando para generar archivos fuente de TypeScript en el directorio del paquete para todos los resultados de React, Angular y Vue. Pero también está generando solo elementos personalizados básicos, y está creando archivos README en formato markdown.

Entonces, el lado izquierdo muestra el componente interno generado automáticamente, y el lado derecho muestra el resultado de ese componente y cómo lo usaría un desarrollador de React. Importarían y usarían estos componentes de la misma manera que cualquier otro componente de React. Por ejemplo, el nombre de la etiqueta JSX está en Pascal case, que es la norma esperada para usar con componentes de React. Mientras que un desarrollador de Angular esperaría que las etiquetas de estos componentes estén en dashcase.

Con Ionic Angular, nos dimos cuenta rápidamente de que necesitábamos proporcionar a nuestros usuarios componentes de Angular y no elementos personalizados. Así es como los desarrolladores de Angular importarían Ionic y lo usarían en su plantilla. No importa que los componentes realmente utilicen elementos personalizados de componentes. Para los desarrolladores de Angular, están usando Ionic de la misma manera que el resto de sus bibliotecas. Esto incluye entradas, controles de formulario, escuchadores de host y todas las demás API de Angular. No estoy tratando de convencer a todos de que codifiquen elementos personalizados en lugar de React o Angular, pero ciertamente puedo mostrar cómo esa especificación de elementos personalizados ha sido extremadamente poderosa para Stencil para construir vinculaciones de frameworks y enviar Ionic en cada uno de los frameworks.

Ahora hablamos mucho sobre patrones de JavaScript en cada modelo de componente, pero honestamente creo que la parte más desafiante de un componente es su estilo. Al igual que tener que encontrar un denominador común para el modelo de componente, también necesitamos llegar a un estilo que funcione en todas partes. Afortunadamente, los estándares web nos cubren nuevamente, y sorpresa, se llama CSS.

Ahora, por lo que he visto en la práctica, hay un aspecto de Shadow DOM que se ama u odia. Creo que la gran discusión es que Shadow DOM es excelente para algunas cosas, pero no es la solución definitiva para todos los problemas de componentes. Y en mi experiencia, Shadow DOM ha sido excelente para Ionic, especialmente porque muchas aplicaciones dependen de él y se desarrollan en nuestra API. Al mismo tiempo, estamos constantemente haciendo mejoras y cambios en Ionic, pero evitando cambios grandes y disruptivos en la estructura HTML y las clases CSS. Esto es un desafío que tiene Ionic, ya que somos utilizados por muchos proyectos externos.

Por otro lado, una aplicación independiente que no comparte componentes no tiene el mismo caso de uso que algo como su sistema de diseño. Piense en las actualizaciones importantes de versiones anteriores de una biblioteca CSS. Si la estructura HTML cambió o el nombre de la clase CSS cambió, a menudo las implementaciones del framework se rompieron. Entre Ionic v4 y v5, hubo una importante actualización de diseño para seguir de cerca el diseño de material en iOS. Lo que me enorgullece aquí es cómo muchos componentes tuvieron una reescritura importante en todos los niveles. Pero el usuario escribió estos componentes en sus aplicaciones de la misma manera entre v4 y v5. No hubo etiquetas HTML o clases CSS específicas que necesitaran cambiar.

Y los objetivos de salida de Stencil van más allá de las vinculaciones de frameworks. Utilizando la misma idea, el compilador puede tomar información de cada componente y construir varias salidas. Por ejemplo, puede generar automáticamente documentación y datos de componente. También puede crear componentes que se pueden pre-renderizar en Node.js. El compilador es capaz de aplicar optimizaciones pesadas después del análisis estático. Y lo hace mediante TypeScript recorriendo el AST de cada componente. Cada bit de metadatos se utiliza para personalizar el tiempo de ejecución y permitir que el tiempo de ejecución use solo lo que necesita. Y no solo puede aplicar optimizaciones, podemos utilizar esa información para generar automáticamente documentación. La fuente de los componentes de Stencil utiliza TypeScript y, bajo el capó, TypeScript tiene muchas características excelentes, una de ellas son los transformadores personalizados. En la transformación personalizada anterior, podemos recopilar metadatos útiles sobre cada componente. En la transformación posterior, podemos tomar esos metadatos y aplicar algunas optimizaciones tanto a nuestro tiempo de ejecución como a los componentes del usuario. Y no faltan generadores de sitios de documentación excelentes. El primero que me viene a la mente es DocuSource. Con Stencil, podemos generar un archivo json que incluye metadatos sobre cada componente en la biblioteca. Esto incluye documentación para props, atributos, eventos, listeners, variables CSS y muchos más.

Así que eres libre de tomar este data generado automáticamente y conectarlo a cualquier sistema, o simplemente puedes hacer que Stencil genere automáticamente archivos readme, que funcionan muy bien dentro de GitHub o npm. Para cerrar todo esto, realmente no puedes equivocarte al elegir React. Es una excelente opción para el desarrollo de aplicaciones. Pero lo que Stencil está resolviendo es un poco diferente. Con Ionic, queríamos mantener una base de código, pero trabajar en todas partes y poder adaptarnos rápidamente. Si tienes un proyecto con un caso de uso similar, entonces un proyecto como Stencil puede ser algo que vale la pena investigar más a fondo. Quiero agradecerte por tu tiempo, gracias por recibirme, lo pasé genial. Espero que pruebes Stencil y nos cuentes cómo te va. Gracias.

Veamos, hemos preguntado a nuestra audiencia, ¿cuál es tu experiencia con los componentes web? Y el 45% de ellos es el ganador. Han dicho que han oído hablar de ellos, pero no los han probado. Pero quieren hacerlo. Y el segundo lugar con un 20% los ha probado y planea usarlos en producción. ¿Qué opinas de estos resultados? Creo que es bastante positivo. Es mucho más alto de lo que pensaba. Así que eso está bien, es bueno ver que la gente está reconociendo su valor y cosas así. Así que creo que es una buena retroalimentación positiva. Sí, siempre es agradable escuchar que hiciste un esfuerzo para construir algo y que la gente quiere usarlo, por supuesto. Sí, eso es correcto. Sí, lo sé. Pero esto es bastante genial porque, ya sabes, tradicionalmente React y los componentes web suelen chocar. Y sin embargo, ha sido interesante cómo ha sucedido el desarrollo de ambos, ha sido interesante. Pero lo que intenté hacer en la charla fue ver más allá de todo eso e intentar simplemente exponer cómo nos ha sido útil y cómo lo usamos y cosas así. Así que espero que la gente también pueda ver, como, cómo nuestro caso de uso nos ayudó y cómo también podría ayudar a su caso de uso.

Sí, bueno, hablando de casos de uso, eso es un buen puente hacia nuestra primera pregunta, en realidad. La pregunta es de Frazili Shchalkov. Y la pregunta es, ¿crees que todavía es valioso usar Stencil en el caso de uso donde una empresa solo está usando un framework, probablemente React en nuestro contexto, para todos sus proyectos front-end? ¿Puedes dar un ejemplo que demuestre por qué todavía es valioso? Sí, esa es una pregunta difícil de responder porque es como tratar de predecir el futuro de qué framework estará presente en los próximos 20 años o algo así. Y así que creo que si esto fuera 2012, todos estaríamos diciendo, bueno, Angler.js es la forma de hacer las cosas. Ese es el mejor framework que todos están usando. Toda mi empresa usa Angler.js, así que vamos a usarlo para todo. Pero como sabes, los tiempos cambian, y React salió y Vue salió, y ninguno de ellos se deletreó mal, así que es difícil predecir el futuro, y eso es en gran parte por qué creamos Stencil para nosotros mismos, porque Ionic necesitaba seguir ajustándose. Y supongo que repito esto una y otra vez en la presentación. Porque tuvimos que seguir ajustándonos, necesitábamos ir al nivel más bajo de un elemento, ya sabes, y eso es solo un elemento personalizado. Y a través de eso, podemos ajustarnos para el futuro, ya sabes, y ajustar cosas así. Entonces, para una empresa que solo está desarrollando en React, como si estuvieras haciendo solo una aplicación web, ya sabes, con otros tres desarrolladores, y esta es una aplicación web autocontenida, y no comparte ninguno de los componentes con ninguna otra aplicación web, cosas así, entonces creo que es una elección fácil ir con todo en React, porque realmente no es el mismo caso de uso que Stencil está tratando de resolver, mientras que si estás tratando de crear una biblioteca de interfaz de usuario, un sistema de diseño que esta aplicación web va a usar, el que el equipo de marketing, ya sabes, en Europa está usando, el que el equipo de ventas en América está usando, si hay todos estos componentes compartidos, ahí es donde Stencil es una mejor opción para eso, porque entonces es más a prueba de futuro en el sentido de que puedes ajustar, como todos estos diferentes componentes pueden mantenerse en una cierta versión. Realmente no hay una versión cuando se trata de eso. El compilador tiene una versión, y un compilador puede hacer cosas diferentes, pero en su mayor parte, esos componentes no tienen versión, y eso es algo bueno, porque no sabes si están usando Backbone y están atascados en Backbone, o si podrían estar usando la última versión de React 25 o algo así. Es una pregunta difícil de responder, y creo que realmente depende de tu caso de uso y de cómo vas a hacer tus componentes. En nuestro caso, si es algo como un sistema de diseño, entonces un sistema de diseño para una organización grande, entonces creo que Stencil es una buena elección para eso. Sí. Creo que eso lo resume para mí. Estaba hablando con Adam un poco antes, y el caso de uso en el que estaba tratando de venderlo a la empresa en la que trabajaba en ese momento era que estábamos trabajando con muchos micro front-ends. Así que es una gran aplicación web con micro front-ends. Todos usaban React. Todo el equipo usaba React. Pero no sabemos si todavía lo haremos en cinco años, ¿verdad? Entonces, tal vez en cinco años quieras crear uno de estos micro front-ends en Svelte o cualquier otro nuevo framework de moda que salga para ese momento. Entonces sería muy fácil porque solo tendrían que construir la lógica, pero todos los front-ends, como los componentes, ya están ahí. Y eso es lo que realmente creo que es el poder que las personas pueden usar Stencil para protegerse un poco para el futuro. Sí, exactamente. Sí. Genial. La siguiente pregunta es de Zandro. ¿Funciona Ionic o cualquier otro framework basado en componentes web en un micro front-end? Cuando cada aplicación front-end integrada usa una versión diferente de Ionic, los componentes web son globales, por lo que pueden sobrescribirse entre sí. Sí, ese es un problema con los Custom Elements ya que window.defineCustomElement es global.

Entonces, Ion-button es solo un Ion-button que se puede registrar en esa ventana. Sí, eso es un problema. Si tuvieras una aplicación que tuviera numerosas versiones de Ionic, ahí es donde habría un conflicto. Diré que creo que el último es el que gana, por lo que podrías tener un par de ellos registrados. El último será el ganador, o tal vez sea el primero. No recuerdo. De cualquier manera, no habrá un error. Se utilizará el más reciente.

Una cosa que hacemos específicamente con Ionic es dedicar mucho tiempo y esfuerzo en asegurarnos de que solo estamos corrigiendo errores, mejorando cosas como esa, mejorando el diseño. Pero la API en sí, las propiedades, atributos, cosas así, no están cambiando. Entonces, hablando por Ionic, creo que eso sería seguro. Siempre hay, ya sabes, el desafío de las versiones incompatibles entre las diferentes cosas así. Pero sí, creo que es una preocupación válida con los elementos personalizados y las cosas que podrían suceder. Pero también, ya sabes, realmente no quieres tener muchas de las mismas sistemas de diseño, muchas versiones diferentes del mismo sistema de diseño ejecutándose en la misma página web. Esperemos que no, pero supongo que una vez que tu empresa y, por lo tanto, tu proyecto crezcan y haya superposición de equipos y miembros del equipo que se van, miembros adicionales del equipo que llegan, entonces puede volverse tedioso mantenerlo, supongo. Sí. Sí. Y sé que están abordando esto en los estándares, pero no es algo que se use actualmente. Bueno, tendremos que esperar a que se solucione ese problema. Pero eso no es un problema de Stencil. Es un problema de la plataforma.

La siguiente pregunta es de Alex. ¿Existe un futuro con Stencil en el que no necesitemos tener pasos de enlace específicos del framework? Los Componentes Web parecen tan prometedores como una solución de escribir una vez y usar en todas partes para nuestros componentes, pero aún parece que tenemos un camino por recorrer antes de que sea realmente fácil comenzar con ellos, especialmente hablando de la integración con React.

No, creo que aún falta un tiempo hasta que podamos prescindir de ellos. Una cosa con la que comenzamos con Ionic Angular cuando comenzamos este proyecto alrededor de 2017 fue que podría ser todo Componentes Web. Ni siquiera iba a tener las vinculaciones de Angular. Y comenzamos con eso durante el desarrollo, y rápidamente nos dimos cuenta de que las personas esperarían los decoradores de salida y los decoradores de entrada y que NG model funcionara y todas las cosas de Angular funcionaran como esperan. Y ahí es donde decidimos que no podíamos ir completamente a Componentes Web en su totalidad porque las personas aún quieren usar Angular como quieren usar Angular. Entonces, en última instancia, depende de cada uno de los frameworks y cuánto están dispuestos a adoptarlo.

Afortunadamente, un elemento personalizado es realmente solo un elemento. Es solo un div que tiene devoluciones de llamada en su mayor parte. Y así podemos conectarnos a cualquier framework porque todos están utilizando el mismo DOM. Sí, creo que aún queda camino por recorrer. Pero ese es el punto de Stencil, que podemos adaptarnos a todo esto. Entonces, a medida que Angular mejora o Angular reduce su huella de lo que están usando y lo que no están usando, simplemente podemos ajustar el compilador. Y para nosotros, los desarrolladores de Ionic, no tenemos que cambiar nuestros componentes en absoluto. Todavía estamos manteniendo los mismos componentes que hace cuatro años. Genial. Creo que eso es todo el tiempo que tenemos para nuestras preguntas y respuestas. Pero estarás en tu chat especial. Así que todos los que aún tengan preguntas que no tuvieron la oportunidad de hacerle a Adam en esta sesión de preguntas y respuestas, por favor únanse a Adam en el chat especial. Adam, muchas gracias por unirte. Sé que te arrastré aquí y estoy muy feliz de que hayas estado dispuesto a unirte. Sí, feliz de unirme. Gracias por tenerme.