¿Espera, Estás Enviando React Native a la Web?!

Hola a todos. Soy Taz Singh y aquí está Marc Delgliche, y tuve el placer de charlar con él en Australia donde se tomó esta foto justo después de que él dijo, espera, estás usando React Native en la web. ¿Por qué en el mundo harías eso? Y así, si no conoces a Marc, él es el creador de CSS modules, vanilla extract, y más recientemente ha trabajado en React Native design systems en Rainbow. Hoy, está haciendo un trabajo increíble en el equipo de Remix en Shopify, y esta es la respuesta que le di en aquel entonces.

Dije, bueno, Marc, esta es la razón. Guild es la plataforma para comunidades, y las comunidades están en todas partes. Existen en todas formas y tamaños, y necesitamos construir una aplicación que también esté en todas partes y pueda existir en cualquier forma y tamaño en que estas comunidades se presenten en todas las diferentes plataformas en las que nuestros usuarios están hoy. Y así, hoy en día cuando estás construyendo una aplicación moderna, necesitas atender tanto a móviles como a escritorios de todos modos. Así que, mirando las métricas de uso de Guild, el 51% de nuestros usuarios están en dispositivos móviles, y el 49% están en escritorio. Esto tiene sentido porque las personas interactúan con nuestra plataforma en movimiento, están buscando eventos para asistir y presentaciones para ver, y todo eso sucede, ya sabes, principalmente en un dispositivo móvil.

Además de eso, somos una startup en etapa temprana con un equipo pequeño. Necesitamos que cada miembro de nuestro equipo sea lo más eficaz posible al enviar código. Cada cambio en nuestro código debe tener el mayor impacto posible. Sin embargo, si tuviéramos que enviar código a cada plataforma, también tendríamos que soportar y probar todas ellas. Así que tendríamos que probar contra cada navegador web, tendríamos que probar cada sistema operativo móvil, y es la misma historia en el escritorio también. Necesitaríamos un montón de dispositivos físicos para probar todo esto, desde dispositivos Android de gama baja hasta cajas Linux hasta básicamente todo lo que hay. Puedes imaginar además soportar múltiples idiomas, por ejemplo, inglés y español, donde el número de elementos a probar y soportar empezaría a aumentar exponencialmente, y simplemente se volvería inviable para un equipo pequeño como el nuestro. Por eso hoy nos estamos enfocando en la plataforma web en el idioma inglés en este momento. Solo para soportar, mantener el soporte manejable para nuestro pequeño equipo.

Y eso es porque la forma en que lo veo funcionar es un poco así, donde esta es la web plataforma para la que estamos construyendo hoy. Una vez que introduzcamos las aplicaciones de iOS y Android, podemos ver que se ve un poco más así, donde tal vez hay un área común en el medio, y a medida que continuamos añadiendo más plataformas como MacOS, Windows, y aplicaciones nativas de Linux, puedes ver el diagrama pareciendo un poco más así. Y para mí, aquí es realmente donde el poder de aprovechar React resulta útil. Donde veo a React como el superconjunto de todas estas plataformas, y React Native puede encapsular la lógica y la orquestación para que todas ellas trabajen juntas. Así que centrémonos en React, ¿de acuerdo? ¿Qué quiero decir con eso? Bueno, digamos que tengo una aplicación en React que se ve así. Renderiza algún componente, ¿verdad? Tal vez empieces a pasar algunos data a ese componente, y obtienes algunos data de ese componente. Ese es el contrato que le importa a tu aplicación. Ese componente subyacente podría estar haciendo cualquier cosa. Ese componente subyacente podría estar usando React Native. Podría estar usando una vista de React Native y renderizando a un elemento de texto de React Native. Ese componente subyacente podría estar usando elementos HTML, de una manera que te resulte familiar si estás usando React DOM hoy en la web.

O podría estar usando algún tipo de vista nativa que es completamente específica de la plataforma, en este caso una vista nativa de iOS que en realidad está recurriendo a algún tipo de lógica de renderizado nativa de iOS en sí. Fundamentalmente, React Native, y en nuestro caso Expo, facilita la escritura del código común a la izquierda, y luego anular eso con algo más específico de la plataforma hacia la derecha, simplemente por la convención de nomenclatura de archivos.

Puedes ver que estoy añadiendo el sufijo .web.js y .iOS.js para especificar uno para la web, y uno para iOS, y por supuesto, se recurrirá a la versión .js más generalizada para otras plataformas, como en este caso Android o así sucesivamente. Para nosotros, siempre comenzamos con el enfoque común a la izquierda proporcionado por Expo, y luego cuando necesitamos proporcionar algo más específico de la plataforma, lo anularemos con la extensión de archivo apropiada como he descrito aquí. Porque recuerda, el contrato sigue siendo el mismo. Es solo un componente de React que está pasando data y obteniendo data.

La capacidad de composición de este modelo es lo que realmente hace posible todo esto, y para mí, nunca siento que estoy renunciando a algo. Nunca siento que me están decepcionando. Nunca siento que me están dando vueltas y abandonando. Afortunadamente, el SDK de Expo tiene la mayoría de lo que necesitas para hacer que todas estas cosas funcionen. Solo mirando algunos de sus ejemplos de sus documentos, podemos ver que tienen una vista de desenfoque. Llegan hasta el punto de listar la compatibilidad de la plataforma para esto dentro de sus propios documentos. Así que podemos ver que es compatible con la web y con iOS. Pero, ¿qué hacemos para Android? Afortunadamente, una rápida búsqueda en Google me llevó a esta biblioteca, React Native Community Blur, que proporciona la misma funcionalidad para Android. De nuevo, simplemente nombrando estos archivos específicamente para cada plataforma, podemos crear una experiencia que funcione en todas partes con una API común que funcione en ambos.

Expo tiene un montón de otros componentes y APIs que puedes aprovechar al construir una aplicación cross-platform. Uno de ellos es Expo AV para mostrar audio o video. De nuevo, tienen una lista útil de plataformas con las que es compatible. Expo GL View, si estás renderizando Open GL, esto es, de nuevo, compatible en todas las plataformas. En la web, se renderiza a WebGL, y fundamentalmente, puedes ir a ver los documentos por ti mismo en la página de Expo. Tienen algo para casi todo lo que hay. Lo bonito es que todos estos componentes técnicamente funcionan en cualquier aplicación de React Native no Expo, y también técnicamente funcionan en cualquier aplicación web no Expo. Sin embargo, no he probado personalmente esas combinaciones, por lo que no puedo hablar de mi propia experiencia personal con ellas. Solo sé que todo es técnicamente posible, así que si quieres experimentar, adelante, siéntete libre de decirme cómo te funciona. Todo esto funciona porque los componentes son los bloques de construcción de React Native. Pensamos primero en los componentes, y componemos estos componentes para hacer aplicaciones. Si quieres desenfocar algo, simplemente compones en una vista de desenfoque en lugar de pensar en las propiedades CSS particulares para lograr algo similar. Si quieres mostrar un video, simplemente compones en la biblioteca Xboav y usas su componente de video justo ahí. Si quieres mostrar algunos gráficos, puedes hacer lo mismo con el componente Xbogl. Fundamentalmente, React Native es fiel al modelo de composición de componentes de React.

En lugar de preocuparnos por las especificidades de la plataforma, simplemente componemos estos componentes y dejamos que esos componentes subyacentes hagan todo el trabajo pesado por nosotros. Nos preocupamos solo por ese contrato de nivel superior, y eso es realmente de lo que se trata React. Genial. Entonces, básicamente así es como desarrollamos usando el sistema de componentes subyacentes de React Native. Como puedes ver, eso es todo lo que necesitamos y no nos sentimos excluidos porque siempre podemos recurrir a algo más específico de la plataforma y componer componentes de una manera que sea fiel a React. Pero, ¿cómo construimos una aplicación a partir de esto? Bueno, recomendaría revisar una presentación que di el año pasado llamada React Native Everywhere. Puedes encontrarla yendo a mi perfil y Gil, solo enlaza allí en la parte superior izquierda y revisa las presentaciones que he dado. Profundizo más en cómo pienso en los sistemas de diseño de React Native y también en la navegación dentro de cross-platform React Native.

Pero en esencia, si tuviera que empezar hoy, lo que recomendaría es Tomagui para el sistema de diseño. De hecho, hemos comenzado a migrar a esto y estamos viendo resultados increíbles, recomiendo encarecidamente que lo revises. Es un compilador de optimización y kit de interfaz de usuario que unifica React Native y la web. Suena increíble. Tuve el placer de pasar un rato con Nate Vinehart a principios de este año donde charlamos sobre Tomagui en cámara, que también estará en mi perfil cuando lleguemos a publicarlo. Así que revisa eso para un análisis más profundo esencialmente con Nate.

En esencia, sin embargo, el compilador de optimización para las aplicaciones de React Native crea directamente código específico de la plataforma para tu aplicación. Esta captura de pantalla muestra cómo tomamos código genérico de React Native en la izquierda escrito, por supuesto, en el sistema de diseño de Tomagui. Y a la derecha, se compila directamente a la plataforma web en sí. Así que solo mira el código de la izquierda por un minuto y siéntete libre de pausar el video si quieres echarle un vistazo un poco más, solo está usando un componente de pila para el diseño y un componente de encabezado para el texto. Ese es el código que escribes, y eso es todo lo que necesitas pensar cuando estás creando interfaces de usuario. Solo el nivel superior de cómo funciona. Es altamente declarativo y no necesitas preocuparte por lo que está debajo debido al modelo de composición de componentes de React. Si me acercara a esa salida compilada, sin embargo, esencialmente parece lo que escribirías si estuvieras escribiendo código altamente optimizado específico de la plataforma usando React DOM y CSS variables para todo. El HTML semántico se ha compilado a un div con una etiqueta H1 en React y el CSS utiliza todas las consultas de medios apropiadas para hacer que todo funcione tal como esperarías si tuvieras que escribir todo esto desde cero tú mismo. Esto funciona obviamente extremadamente bien en la web, porque entonces puedes usar esos componentes de nivel superior para componer tu aplicación y dejar que las herramientas se preocupen por cómo crear algo mejor adaptado para las especificidades de esa plataforma. Cualquier aplicación seria debería, por supuesto, estar utilizando un sistema de diseño y Tamagui es uno excelente.

Para unirlo todo, recomendaría revisar el enrutador de URL de React Native para la navegación. Es esencialmente React router con toda su bondad de gestión de estado, más las pantallas de React Native para darle esa sensación de deslizamiento desde el borde a la que estás acostumbrado al usar una aplicación móvil nativa. Como actualmente estamos construyendo para la web ahora, en realidad solo estamos usando React router directamente en este momento. Sin embargo, planeamos usar el enrutador de URL de React Native cuando expandamos a las plataformas móviles también. Puedes pensar

Por supuesto, también está Remix, que tiene un gran motor de renderizado del lado del servidor incorporado directamente en él. Ahora diría que nuestra pila está más alineada con Remix ya que actualmente estamos usando React router, que también alimenta a Remix. Sin embargo, de nuevo, no soportan React native URL router. Y por lo tanto, avanzar con Remix significaría que necesitamos hacer algo diferente allí una vez más. Quizás sería menos intrusivo que Next porque actualmente somos un poco más compatibles con el enfoque de Remix. Y técnicamente, ambos son opciones fantásticas tal vez para ti. Si tienes un conjunto similar de preocupaciones, es por eso que menciono estos, porque son verdaderamente fantásticos opciones de clase mundial que existen. Pero para nosotros, es simplemente la forma en que pensamos en esto en que queremos unificar nuestra navegación y tener una pila de navegación en todo. Y fundamentalmente, ambos no son realmente soluciones para nosotros. Pero tal vez estas son soluciones para ti. Ahora, fundamentalmente, ¿qué hacemos? Esencialmente, ¿qué funciona para nosotros? Bueno, afortunadamente, tuve el placer de sentarme con Evan Bacon del equipo de Expo para charlar sobre esto. Puedes ver la grabación de eso siguiendo el enlace en la parte superior izquierda o simplemente yendo a mi perfil o simplemente yendo a Guild y buscando en Google también. En general, Evan es un

Sin embargo, hoy en día no está del todo ahí. No tienen renderizado activo del lado del servidor ni otras características específicas de la web como la división de código todavía. Con Expo Router v2, puedes renderizar tus web apps de React Native a archivos estáticos y servir archivos estáticos si eso funciona para tu aplicación. Pero para nosotros, necesitamos un renderizado activo del lado del servidor ya que tenemos datos dinámicos que queremos que se rendericen en el servidor. Evan mencionó que esto está por venir y él imagina que el proyecto Expo Router está a dos cuartos de su camino hacia la finalización basado en su iteración actual hoy. Así que quedan dos cuartos más para realmente cumplir su visión y uno de esos renderizados activos del lado del servidor y la división de código y etc será parte de ello. Así que definitivamente estaremos atentos a eso y tal vez buscaremos migrar cuando eso salga.

Sin embargo, soy un poco escéptico, porque están usando React Navigation en la plataforma web. Tengo la sensación de que porque React Navigation envía UI así como enrutamiento, resultaría en un paquete más grande. En cada proyecto en el que he trabajado, he sobrescrito la UI predeterminada de React Navigation. Así que preferiría si esos dos estuvieran quizás desacoplados. Sin embargo, de nuevo, el equipo allí es inteligente, son brillantes, son buenos amigos míos y sé que están trabajando duro en esto. Se lo toman muy en serio y escuchan los comentarios. Y eso es todo lo que podrías desear en términos de un proveedor de tecnología. Así que todas estas son cosas que ellos saben y estoy seguro de que ejecutarán bien esto a tiempo cuando alcancen esos otros dos hitos y lo lleven a un cuatro de cuatro en términos de finalización. Así que definitivamente estaremos atentos a esto y tal vez buscaremos mudarnos en el futuro. Pero fundamentalmente, ¿qué hacemos hoy? Bueno, supongo que, fundamentalmente, tendremos que construirlo hoy. Simplemente lo construiremos nosotros mismos. Así que nos arremangamos y construimos una pipeline completa de renderizado del lado del servidor sobre los trabajadores de Cloudflare para alimentar la Experiencia Web de Guilds. Utiliza todo lo último en React 18 concurrent rendering en términos de respuestas de streaming al usuario. Cloudflare también nos informa del tipo de dispositivo del usuario, que luego utilizamos para renderizar del lado del servidor en el punto de interrupción que esa persona probablemente obtendrá. Así, por ejemplo, si es un dispositivo móvil, renderizaremos en un punto de interrupción móvil. Si es un dispositivo de escritorio, renderizaremos en un punto de interrupción de escritorio y así sucesivamente, directamente desde el servidor mismo. Y esto es porque React Native utiliza la API de Dimensiones de Ventana y no las consultas de medios, a menos que estés usando algo como Tamagooie. Pero incluso renderizando en un punto de interrupción en Tamagooie, necesitas algo similar para decirte en qué tipo de dispositivo renderizar. Así que es genial que Cloudflare proporcione todo eso.

Y porque lo construimos nosotros mismos, podemos hacer esa optimization nosotros mismos porque esencialmente conocemos las piezas del marco de trabajo con las que estamos trabajando. Pero si fueras a hacer esto en algo como Next.js o Remix o algo así que no soporta todo esto y realmente no sabe cómo hacer eso, como, esencialmente pegar esas piezas juntas, es posible que no tengas una buena experiencia. Y por lo tanto, somos capaces de hacerlo porque conocemos todas esas piezas juntas. Además, porque estamos usando un relay para nuestra obtención de data sobre GraphQL, somos capaces de integrar todos esos datos iniciales sobre esa carga inicial para evitar la reobtención en la carga inicial. Así que simplemente integramos la tienda de relay directamente en la carga inicial. Así que cuando cargas la página por primera vez, todo está ahí, no hay llamadas adicionales de data, no hay indicadores de carga, y eso es todo. Así que siéntete libre de probarlo. Carga gil.host tú mismo y simplemente ve cómo se carga. Sin indicadores de carga, debería cargar inmediatamente y debería funcionar genial. Y fundamentalmente, la razón por la que todo esto incluso funciona es porque es nativo. React Native es nativo. No es React Mobile. No es React Web. Es React Native porque es verdaderamente capaz de abordar la plataforma nativa en cualquier plataforma. En la web, es realmente como cualquier otra aplicación web. Por lo tanto, puedes renderizar del lado del servidor una aplicación web de React Native de la misma manera que puedes renderizar del lado del servidor cualquier otra aplicación web de React. Puedes usar Next, puedes usar Remix. Puedes usar lo que quieras. Es como renderizar cualquier otra aplicación de React. Porque, fundamentalmente, estás renderizando lo mismo una y otra vez. Todo esto me hizo pensar, sin embargo. Si React Native es verdaderamente nativo, ¿puedo integrar React Native en cualquier aplicación, independientemente de cómo esté construida? Quiero decir, la aplicación móvil de Facebook es técnicamente solo React Native integrado en otras vistas nativas, ¿verdad? Esa es más o menos la forma en que funciona toda la aplicación de Facebook. Es solo React Native junto a nativo. Si ellos pueden hacer eso con esta tecnología, quiero decir, seguramente es posible para cualquiera de nosotros hacerlo también, ¿verdad? Así que, para mí, intenté hacer exactamente eso. Intenté hacer eso para el SDK integrable de GIL, donde básicamente tomamos todos los bloques de construcción de nuestra UI, creada usando React Native en la web, y alimentada por Relay para declarar dependencias de data aisladas, y tomamos todo eso y lo proporcionamos como una biblioteca de JavaScript para que la gente lo integre de forma nativa en cualquier página. No está usando iframes, porque el desafío con los iframes es que realmente no puedes operar fuera del marco, así que no puedes abrir un modal con más información, por ejemplo. Como puedes ver en este sandbox de código público, al que puedes echar un vistazo por ti mismo yendo al enlace de arriba en la parte superior de la página, el enlace mxcfmh, el HTML está renderizando una lista de etiquetas div con IDs. Eso es lo que especificé en el sandbox de código HTML. En la parte inferior, estamos cargando el SDK de GIL JavaScript en la página, y proporcionándole todos los diferentes elementos para renderizar con los diversos argumentos de nuestro SDK, y el SDK de GIL simplemente está renderizando el resto. Con este enfoque, puedes tomar los mismos componentes exactos que nosotros usamos para construir GILD, y puedes renderizarlos de forma nativa dentro de tu experiencia de la forma que quieras

Bueno, ahí vamos. Esta animación es, de nuevo, realizada utilizando reanimated. Todos estos componentes son componentes reales de React Native. Podemos interactuar con ellos y abrir un modal de React Native aquí, por ejemplo. Así que eso es solo un modal en React Native. Estos avatares de aquí abajo, oh, cuando llegamos a ellos, supongo, todos estos avatares, están todos creados utilizando mid journey AI, y usamos mid journey para crear los avatares virtuales para cada usuario también. Así que es mid journey encima de mid journey y la animación es, por supuesto, realizada con React Native reanimated. Estas tarjetas de presentación están utilizando la biblioteca Satori, que utiliza el sistema de diseño yoga de React Native que se ejecuta en un ensamblaje web dentro de un trabajador de CloudFlare para renderizar un SVG. Así que incluso estas imágenes, incluso estas tarjetas de imagen están realmente renderizadas utilizando React Native. Y luego bajando un poco, ahí vamos. Esta animación de red aquí es la única cosa específica de la web en toda la página. Podríamos haber utilizado React Native Skia, pero en el momento en que construimos esto, el tamaño del paquete para eso era de unos seis megabytes en la web, lo cual era demasiado grande para esto. Desde entonces, William Candillon, si estoy pronunciando su nombre correctamente, lo ha reducido a unos 20 kilobytes. Así que realmente podemos reutilizar React Native Skia en este momento. Y esto de nuevo es un modal de React Native, un modal nativo de React Native. Toda esta página está construida utilizando React Native en la plataforma web con una pequeña anulación específica de la plataforma para esa presentación de redes y gremios. Pero de nuevo, ahora podemos reescribir eso utilizando React Native también porque William ha hecho un gran trabajo en el proyecto Skia para reducir el tamaño del paquete a unos 20 kilobytes para eso. Así que un trabajo fantástico por parte de ese equipo. Sin embargo, necesito preguntarte, mirando esto, ¿habrías podido decir que algo de eso era React Native o simplemente pensarías que todo eso era solo alguna otra aplicación web construida de una manera más tradicional? Entonces, fundamentalmente, ¿qué significa esto? La forma en que lo vemos es que tenemos nuestra UI y tenemos nuestra API. Ambas existen como mecanismos para usar Guild. Los usuarios pueden ir a nuestra UI en nuestra plataforma y administrar su community. O pueden registrarse para nuestra API, administrar sus secretos, averiguar las consultas que necesitan, realizar sus mutaciones y construir toda una UI por sí mismos. Y esto puede estar bien si quieres una experiencia personalizada y tienes los recursos para soportar todo ese desarrollo de API. Pero hay fundamentalmente una gran brecha allí entre usar esos

Esto me hizo pensar, ¿qué pasaría si tomáramos en serio las experiencias incrustables? ¿Qué pasaría si construyéramos nuestras aplicaciones de tal manera que la interfaz de usuario de terceros fuera la misma que la interfaz de usuario de primera parte? ¿Cómo sería eso? Bueno, ahora mismo tenemos todas las diversas partes de nuestra aplicación construidas dentro de nuestro sistema de diseño como componentes individuales que se componen juntos. Estoy seguro de que muchos de ustedes también hacen esto, porque fundamentalmente así es como funciona React. Si estás usando Storybook, probablemente ya exportas todos estos componentes, ¿verdad? Entonces, al mirar esos bloques de construcción y exportarlos como experiencias incrustables, podemos simplemente renderizar nuestra interfaz de usuario a partir de eso. Y de nuevo, esto es simplemente cómo usarías React ahora mismo. Pero la brecha que encontramos es hacer eso incrustable. Tuvimos que escribir lógica personalizada para esencialmente contener todas estas experiencias para que funcionen dentro de otras experiencias. Permíteme apagar esa luz. Esa es la parte en la que necesitamos trabajar para mejorar, para que exponer estas experiencias de terceros sea tan fácil como montar un componente de React. Además, ahora mismo, tenemos que dividir agresivamente nuestro SDK para cargar solo el JavaScript requerido cuando lo usas. Pero, ¿y si pudiéramos aprovechar la hidratación basada en islas para cargar solo las partes que son verdaderamente interactivas, reduciendo aún más el paquete web? ¿Cómo se vería eso en un mundo incrustable? ¿Y cómo podemos facilitarlo para todos? Así que para nosotros en Guild, esta es nuestra próxima frontera. Es fundamental para nuestro negocio apoyar a las comunidades en todas partes en cualquier forma y tamaño en que se presenten en cada plataforma en la que estén. Necesitamos existir donde exista el tráfico. Y eso es lo que le dije a Mark en Australia. Espero con ansias volver y contarles más sobre nuestro viaje mientras trabajamos para finalizar esto y abrir el código de nuestro trabajo para facilitar que cualquiera use nuestra infraestructura, porque todo esto ha funcionado tan bien para nosotros. Y no puedo esperar a eso. Hasta entonces, gracias, y espero que hayan disfrutado de nuestro viaje. Nos vemos la próxima vez.