Los Componentes del Servidor React son un nuevo tema en la comunidad, un montón de marcos de trabajo los están implementando, la gente está discutiendo sobre este tema. Pero, ¿qué pasaría si pudiéramos usar los Componentes del Servidor React en React Native? ¿Y llevar todas las características de optimización que los RSC permiten a las aplicaciones móviles? En esta charla presentaría lo que somos capaces de hacer con los RSC en React Native!
Llevando los Componentes del Servidor React a React Native
Video Summary and Transcription
Los Componentes del Servidor React (RSC) ofrecen un enfoque más accesible dentro del modelo React, abordando desafíos como el gran tamaño inicial del paquete y los datos innecesarios a través de la red. Los RSC pueden beneficiar el desarrollo de React Native al agregar una nueva capa de servidor y permitir solicitudes más rápidas. También permiten una publicación más rápida de cambios en las aplicaciones móviles y pueden integrarse en super aplicaciones federadas. Sin embargo, la implementación de RSC en aplicaciones móviles requiere una cuidadosa consideración de las aplicaciones offline-first, el almacenamiento en caché, y el proceso de revisión de Apple.
1. Introducción a los Componentes del Servidor React
Hola a todos, hola Berlín. Estoy realmente emocionado de presentar los componentes del servidor React y discutir su relevancia en el desarrollo de React Native. Vamos a explorar los desafíos de la red en el desarrollo de aplicaciones y cómo los Componentes del Servidor React pueden abordarlos. Dona Bramov introdujo esta idea, con el objetivo de resolver problemas como el gran tamaño del paquete inicial y el envío de datos innecesarios a través de la red. Con la implementación lista para producción de Next.js y soluciones como Relay y GraphQL, los Componentes del Servidor React ofrecen un enfoque más accesible dentro del modelo React.
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.
2. Componentes del Servidor React y React Native
Con los Componentes del Servidor React (RSC), añadimos una nueva capa de servidor y solo transmitimos las partes necesarias al cliente. Este formato, específico para RSC, permite el acceso a los recursos del servidor y habilita solicitudes más rápidas. React Native también puede beneficiarse de RSC, ya que fueron desarrollados inicialmente para tecnologías impulsadas por el servidor en Native. La lógica para RSC se encuentra en los paquetes React Client y React Server, con lógica personalizada implementada a través de archivos de configuración. Aunque las aplicaciones móviles pueden no priorizar el tamaño del paquete, RSC aún puede ser valioso, especialmente para aplicaciones en línea y offline-first.
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
3. Beneficios de los Componentes del Servidor React en Aplicaciones Móviles
Para las aplicaciones offline-first, los Componentes del Servidor React (RSC) pueden no ser relevantes. Sin embargo, hay aplicaciones que pueden beneficiarse enormemente de RSC. El flujo estándar para publicar aplicaciones móviles implica crear un botón, construir una aplicación binaria, enviarla a la tienda de aplicaciones y esperar su aprobación. Este proceso puede ser lento y frustrante, especialmente cuando se necesitan solucionar errores críticos. Con la Arquitectura React Native, tenemos actualizaciones over-the-air (OTA), que nos permiten reemplazar el paquete de forma remota. En lugar de reemplazar todo el paquete, RSC nos permite iterar en componentes específicos, lo que resulta en una publicación más rápida de cambios en las aplicaciones móviles.
4. Super Apps Federadas y Componentes React
Las super apps federadas, como Facebook, pueden dividirse en módulos más pequeños. Estos módulos más pequeños, como el mercado, citas y juegos, pueden ser accedidos a demanda desde un servidor. Al usar componentes React, podemos acelerar la evaluación de los fragmentos remotos, permitiendo que el primer componente se descargue rápidamente.
5. Beneficios de los Componentes de Servidor de React Native
Si quieres aprender más sobre este concepto, ve a ver la charla de nuestro jefe de tecnología, Mike Pioschkowa. Así que, para resumir, los principales beneficios de los componentes de servidor de React Native no son enviar datos innecesarios por la red, una iteración más rápida con banderas de características y despliegue, y la bien diseñada integración con componentes de cliente y mecanismo de suspense. Vamos a explorar cómo los componentes de servidor de React pueden integrarse en la aplicación Blue Sky, una nueva plataforma de medios sociales de código abierto escrita en React Native con Expo. A pesar de las preocupaciones sobre la pérdida de la sensación de UX nativa, los componentes de servidor de React correctamente implementados pueden acelerar realmente el desarrollo sin afectar la experiencia general de la aplicación.
QnA
Desafíos de la aplicación React Native y Componentes de Servidor
Cuando los usuarios tienen una conexión a Internet baja, necesitamos presentar vistas de carga y manejar errores. Para lograr una sensación nativa, agrupamos componentes esenciales en el paquete inicial. Migrar la vista de feed a los componentes del servidor permite una iteración y despliegue más rápidos sin la revisión de Apple. Sin embargo, las aplicaciones offline-first y la necesidad de caché en futuras implementaciones pueden no ser adecuadas. La pregunta de si Apple o Google rechazarán las aplicaciones que eluden el proceso de revisión es complicada.
Restricciones de Apple y Actualizaciones OTA
Las restricciones de Apple sobre los cambios importantes en las aplicaciones nos obligan a ser cautelosos. Sin embargo, los cambios menores y las actualizaciones OTA, que implican reemplazar el paquete de forma remota, son aceptables para Apple. Esta es un área interesante para explorar, considerando la naturaleza hipotética de la implementación de los Componentes de Servidor de React y su aceptación en las App Stores.
La Solución de CoreStack para los Componentes de Servidor de React
¿Está CoreStack trabajando en una solución para los Componentes de Servidor de React? He estado investigando sobre los Componentes de Servidor de React en móviles y tenemos Repack, una biblioteca para usar Repack en aplicaciones de React Native. Repack tiene características que Metro no tiene, como la federación de módulos. Si se debe usar Metro o Repack depende del caso, especialmente si se quiere construir una super aplicación o añadir Componentes de Servidor de React.
Componentes de Servidor de React y Restricciones de Paquete
¿Pero cómo resuelven los Componentes de Servidor de React las restricciones de un solo paquete en las aplicaciones de React Native con actualizaciones en el aire? Implementar los Componentes de Servidor de React es difícil y requiere múltiples paquetes para las aplicaciones móviles. El éxito de los Componentes de Servidor de React en móviles depende de una buena experiencia de desarrollo. La herramienta actual puede requerir el envío de un nuevo paquete completo, lo que afecta la viabilidad de este enfoque. Los Componentes de Servidor de React no deberían reemplazar toda la aplicación, ya que la experiencia nativa debería permanecer igual. Los componentes del cliente son necesarios para mantener la sensación nativa y las expectativas del usuario. Renderizar toda la aplicación en el servidor podría llevar al rechazo de la aplicación en las tiendas de aplicaciones.
Orquestando Versiones de Aplicaciones y Actualizaciones
¿Cómo orquestarías diferentes versiones de aplicaciones con diferentes versiones de componentes de servidor? Esto necesita hacerse en el lado del marco, y debería haber una forma sencilla de gestionar esto. Se debe considerar la expectativa de cuándo pedir a los usuarios que actualicen una aplicación y la gravedad de los cambios. Debería haber un estándar para determinar cuándo es una versión de actualización de la aplicación y cuándo se pueden enviar pequeñas actualizaciones a los usuarios.
¿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
Componentes del Servidor React y Almacenamiento del Dispositivo
Hubo una pregunta sobre si los componentes del servidor React se mantienen en memoria o se persisten en el dispositivo. Al enviar componentes del servidor React a móviles, se puede hacer caché en el disco del dispositivo. En caso de pérdida repentina de la conexión a la red, el marco debería manejarlo mostrando el estado y el error adecuados en el cliente. El paquete se almacena en el dispositivo, pero si necesita actualizarse y se pierde la conexión, se pierde la capacidad de mostrar los componentes. Sin embargo, algunos componentes aún deben ser componentes del cliente para mantener la experiencia de usuario nativa. La charla enfatiza que no todas las partes deben ser componentes del servidor React, solo las que se benefician de sus propiedades. Hay tiempo para un par de preguntas más, y seguirá la sesión de preguntas y respuestas del orador. El orador está colaborando con Meta en este proyecto, aunque no se pueden compartir detalles. Existe el riesgo de desviarse de cómo Facebook usa React Native, pero se está trabajando para mitigarlo.
¿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
Futuro de los Componentes del Servidor React
¿Cuándo esperas que los componentes del servidor React sean utilizables? El próximo año, esperamos tener soluciones experimentales, y en unos años, una implementación de producción. Estamos trabajando en ello y esperamos colaborar. ¿Hay diferencias significativas al probar localmente los componentes del servidor React con React Native? No lo sé, no lo he probado. Veremos. Gracias por la perspicaz mirada al futuro.
Check out more articles and videos
We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career
Workshops on related topic
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop
In this three-hour workshop we’ll address these questions by discussing how to integrate Detox into your development workflow. You’ll walk away with the skills and information you need to make Detox testing a natural and productive part of day-to-day development.
Table of contents:
- Deciding what to test with Detox vs React Native Testing Library vs manual testing- Setting up a fake API layer for testing- Getting Detox running on CI on GitHub Actions for free- Deciding how much of your app to test with Detox: a sliding scale- Fitting Detox into you local development workflow
Prerequisites
- Familiarity with building applications with React Native- Basic experience with Detox- Machine setup: a working React Native CLI development environment including either Xcode or Android Studio
Appflow is the cloud mobile DevOps platform built by Ionic. Using a service like Appflow to build React Native apps not only provides access to powerful computing resources, it can simplify the deployment process by providing a centralized environment for managing and distributing your app to multiple platforms. This can save time and resources, enable collaboration, as well as improve the overall reliability and scalability of an app.
In this workshop, you’ll deploy a React Native application for delivery to Android and iOS test devices using Appflow. You’ll also learn the steps for publishing to Google Play and Apple App Stores. No previous experience with deploying native applications is required, and you’ll come away with a deeper understanding of the mobile deployment process and best practices for how to use a cloud mobile DevOps platform to ship quickly at scale.
But it doesn’t have to be this way. React Native Testing Library (RNTL) is a great library for component testing, and with the right mental model you can use it to implement tests that are low-cost and high-value. In this three-hour workshop you’ll learn the tools, techniques, and principles you need to implement tests that will help you ship your React Native app with confidence. You’ll walk away with a clear vision for the goal of your component tests and with techniques that will help you address any obstacle that gets in the way of that goal.you will know:- The different kinds React Native tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting text, image, and native code elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RNTL tests and how to handle them- Options for handling native functions and components in your JavaScript tests
Prerequisites:- Familiarity with building applications with React Native- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Native Testing Library- Machine setup: Node 16.x or 18.x, Yarn, be able to successfully create and run a new Expo app following the instructions on https://docs.expo.dev/get-started/create-a-new-app/