Llevando los Componentes del Servidor React a React Native

Hola a todos, hola Berlín. Es realmente agradable estar aquí hoy. Estoy realmente emocionado y también un poco estresado porque es mi primera charla antes del gran escenario. Pero hoy tengo un tema realmente interesante para presentar, los componentes del servidor React. Pero me gustaría expandir este tema a la parte de React Native. ¿Tiene sentido tener RST en móvil? ¿Y qué posiblemente deberíamos hacer para llevarlos a las aplicaciones de producción? Pero primero, unas pocas palabras sobre mí. Mi nombre es Szumon Rybczak y tengo 17 años, desarrollador de React Native en Callstack. A diario, trabajo en un equipo de tecnología donde apoyo nuestras iniciativas de I+D y de código abierto. También mantengo la React Native Community CLI y soy el contribuyente más joven de React Native. Puedes encontrarme en Twitter o en GitHub bajo el nombre de Szumon Rybczak. Intento publicar allí muy a menudo cosas que estamos cocinando en Callstack.

Así que en el desarrollo de software, existe este principio de que puedes hacer algo que sea bueno, algo que sea rápido, y algo que sea barato. Pero solo puedes elegir dos. Así que puedes hacer algo que sea bueno, algo que sea rápido, pero no relativamente barato para hacer. O bien puedes hacer algo que sea barato, algo que sea rápido, pero no realmente bueno. O finalmente, puedes hacer algo que sea bueno, algo que sea barato de hacer, pero no rápido. Así es como Dona Bramov comenzó una charla presentando la idea de los Componentes del Servidor React. La obtención de Data con los Componentes del Servidor React es una nueva idea en el ecosystem. Y tal vez los Componentes del Servidor React resolverán nuestros problemas que encontramos al desarrollar aplicaciones. Y tenemos un montón de problemas, pero los dos que vienen con la red son el gran tamaño del paquete inicial y el envío de data innecesaria a través de la red. Este video fue publicado hace ya tres años, así que muchas cosas han cambiado en este tiempo. Dona y Laura estaban presentando la idea. Ahora, tenemos una implementación lista para producción, por ejemplo, con Next.js. En Meta, resolvieron el problema de enviar data innecesaria con Relay y GraphQL. Relay es una herramienta para recibir los data de GraphQL para React. Pero, ya sabes, no es una tarea fácil implementar GraphQL en una gran base de código de backend. Y con eso, la barrera de entrada es realmente alta. Pero el equipo central quería una solución que fuera lo suficientemente fácil de implementar y que simplemente funcionara dentro del modelo React. Entonces, ¿cómo funcionan los Componentes del Servidor React? Ahora, al desarrollar una aplicación React, cuando el usuario accede al dominio, el paquete se descarga y se ejecuta en el cliente. El paquete se evalúa y ahí es donde ocurre la magia.

Pero con el modelo RSC, estamos añadiendo una nueva capa. Estamos añadiendo una nueva capa de servidor. Así que, este es el momento más importante. Estamos ejecutando los Componentes React en el servidor. Y luego, estamos transmitiendo por partes al cliente. Y al transmitir, solo estamos transmitiendo partes que se mostrarán. Así que, no estamos transmitiendo data innecesaria, props innecesarios, o partes de los componentes. Gracias a esto, que estamos ejecutando en el servidor, podemos acceder a archivos en el servidor, podemos acceder a la base de datos, o podemos hacer algún movimiento inteligente con la caché para acelerar nuestra solicitud. Y todo esto gracias a este formato que, como dije, se transmite desde un servidor. Parece un JSON, pero no lo es. Es un formato específico de los Componentes del Servidor React que se consume en el lado del cliente. Contiene cosas que deben mostrarse referencia a los componentes, etc. Entonces, ¿cómo encaja React Native en esta imagen completa? ¿Y cómo incluso podemos implementar una parte del servidor dentro de React Native? Así que, todo el mundo está hablando sobre los Componentes del Servidor React en el contexto de la web, porque ahí es donde tenemos una implementación lista para producción. Pero en realidad, de hecho, los componentes del servidor se fundaron inicialmente en Meta debido a la promesa que mostraban al usar tecnologías impulsadas por el servidor en Native. Y eso es un giro de trama interesante. Mucha gente piensa en RSC solo en el contexto web, pero quizás tengan sentido en móvil. Pero ¿qué arquitectura y qué coste supondría implementarlo? Así que, React está en el repositorio, y los dos paquetes que son más importantes para nosotros hoy son React Client y React Server. Contienen la lógica para los Componentes del Servidor React, pero solo la lógica unificada. Por lo tanto, la misma lógica se aplicará para cualquier bundler y cualquier renderizador. La lógica personalizada se implementa a través de los archivos de configuración. Así que, como podemos ver aquí, por ejemplo, para TurboPack, tenemos un archivo de configuración, y para Webpack, tenemos otro. Y ahí es donde posiblemente podemos añadir un archivo de configuración para el renderizador de React Native y para Metro, que es el bundler predeterminado para React Native. El principal argumento para los Componentes del Servidor React, como mencioné, es reducir el tamaño inicial del paquete. Así que, el primer fragmento de la aplicación se mostrará realmente, realmente rápido. Pero en móvil, no nos importa tanto el tamaño del paquete. Lo descargamos una vez desde la tienda de aplicaciones, y luego la aplicación simplemente existe allí. Cada vez que el usuario visita la aplicación, el paquete simplemente está ahí. Y gracias a Hermes, el motor JavaScript diseñado para los propósitos de React Native, el tiempo de inicio de la aplicación es prácticamente el mismo para la aplicación que tiene un paquete de 10 megabytes o 100. Hay varias aplicaciones, pero creo firmemente que hay un espacio para RST en móvil. Hay

¿Cómo orquestarías diferentes versiones de aplicaciones con diferentes versiones de componentes de servidor? Y sí, esto también necesita, para mí, esto también necesita hacerse en el lado del marco. Entonces, tenemos Expo que tiene, sí, si Evan Bacon está escuchando esto, espero que envíen alguna gran solución, y necesita hacerse por el marco. Entonces, sí, necesitamos tener alguna forma sencilla de gestionar esto. No sé si será un panel de control para el despliegue o alguna herramienta CLI. No lo sé, pero necesitará hacerse en la parte del marco.

Pero también hay algo más aquí, que es simplemente desde el punto de vista de las expectativas, y esto podría ser algo que se desarrolle en el transcurso de los próximos meses a medida que esto se convierte, de nuevo, en una solución viable con una implementación. ¿En qué momento estás realmente pidiendo a los usuarios que actualicen una aplicación? Hay tantas partes de eso. Hay que entender que hay una nueva versión, hay que consentir que hay una nueva versión, hay la gravedad de los cambios que están teniendo lugar. Porque en teoría, podrías hacer mucho de esto. Como dijiste, podrías hacer mucho de esto en el aire. Y creo que casi hay un estándar que necesita ser establecido sobre en qué casos es una versión de actualización de la aplicación, y en qué puntos podemos simplemente enviar pequeñas actualizaciones a

¿El componente del servidor React solo se mantendría en memoria o se persistiría en el dispositivo en sí? ¿Y qué pasaría en caso de pérdida repentina de la conexión a la red? Sí. Entonces, al enviar los componentes del servidor React a móviles, debemos tener en cuenta que tenemos un disco y allí probablemente podemos almacenar algunas cosas en caché. Entonces, dependerá del caso. Y si de repente se pierde la red, también debe estar debidamente cubierto por el marco. Entonces, se debe mostrar el estado adecuado, el error adecuado. Eso está en el cliente. Así que lo tenemos y podemos mostrarlo. Y sí.

Pero qué... Lo siento, no estoy seguro de que eso me haya quedado claro. Entonces, ¿estos componentes se almacenan... Supongo que el paquete es... El paquete se almacena en el dispositivo, pero si ese paquete necesita actualizarse, sabes, y pierdes la conexión durante eso, pierdes la capacidad de mostrar estos componentes. Sí. Pero tenemos los componentes de la caja completa que necesitan ser un componente del cliente porque estamos perdiendo la sensación de UX nativa de la aplicación. Creo que eso es algo que se repite en gran parte de tu charla, definitivamente no todo esto debería ser componentes del servidor React, sino las partes que realmente se benefician de las propiedades de los componentes del servidor deberían serlo. De lo contrario, debería ser nativo. Sí. Genial. Tenemos tiempo para un par de preguntas más, pero no dudes en seguir haciéndolas. Solo como recordatorio, tenemos una sesión de preguntas y respuestas del orador justo después de esto en el área de preguntas y respuestas del orador, que está cerca de la entrada aquí en el lugar. Y en línea, puedes llegar a eso usando la línea de tiempo en la parte inferior. ¿Estás colaborando con Meta en este proyecto? Y si no, ¿existe el riesgo de divergir entre cómo Facebook usa React Native versus proyectos como este? Entonces, no puedo compartir los detalles, pero estamos trabajando en esto. Y eso es lo que puedo decir ahora mismo. Y la segunda parte, si no, ¿no existe el riesgo de desviarse de la forma en que Facebook usa React Native en comparación con la community? Bueno, eso parece no ser el caso basado en tu indicado realmente no puedo hablar sobre la respuesta. Entonces, quiero decir, creo que la respuesta allí es, si puedo, parece bastante clara. Sí, existe el riesgo de divergir, pero ese riesgo se está mitigando