Llevando los Componentes del Servidor React a React Native

Rate this content
Bookmark

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!

29 min
08 Dec, 2023

AI Generated Video Summary

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

Short description:

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

Short description:

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

Short description:

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.

hay aplicaciones online-first y hay aplicaciones offline-first. Y, por supuesto, para las aplicaciones offline-first, RST no tendría sentido. Pero creo que habrá aplicaciones que tendrán una o se beneficiarán enormemente de tener RST. Entonces, ¿cuáles son realmente los beneficios? Digamos que estamos trabajando en una aplicación y la mayoría de las aplicaciones tienen una barra de pestañas. Y tenemos la Navidad a la vuelta de la esquina y nuestro cliente quiere agregar un nuevo botón, un nuevo botón especial de Navidad. Y en la web, es solo cuestión de codificar y desplegar. Es un proceso fácil. Pero en el mundo móvil, es un poco más difícil. Entonces, ¿cómo es el flujo estándar para publicar aplicaciones móviles? Entonces, primero, necesitamos, por supuesto, crear un botón. Luego necesitamos construir una aplicación binaria. Después de eso, necesitamos enviar la aplicación a la tienda de aplicaciones. Y luego necesitamos esperar unos días para la aprobación. Y este proceso puede ser doloroso, especialmente cuando tienes algún error crítico en producción y necesitas esperar unos días, incluso semanas para la publicación de la aplicación. Pero gracias a la Arquitectura React Native, tenemos actualizaciones over-the-air. Entonces, una aplicación de producción de Arquitectura React Native contiene la parte nativa y la parte del paquete de modo que podemos reemplazar el paquete de forma remota. Entonces, ¿cómo se ve el flujo con OTA? Entonces, estamos creando el botón. Luego estamos empaquetando el código. Y luego estamos subiendo el paquete al servidor. Y gracias a Expo o Repack, la próxima vez que el usuario visite la aplicación, se descargará el nuevo paquete. Y eso es genial. Pero, sabes, aquí necesitamos reemplazar todo el paquete. Y a veces descargar el paquete desde un servidor remoto puede llevar un tiempo. Y esa no es la mejor experiencia. Pero con los componentes React podemos iterar a un nivel superior. Podemos iterar más rápido. Entonces, la cuestión de publicar cambios en las aplicaciones móviles con RSC se verá así. Por supuesto, necesitamos crear un botón. Y luego solo necesitamos empaquetar un componente. No necesitamos empaquetar todo el paquete para la aplicación. Solo un componente. Y luego con alguna solución en la próxima entrada del usuario a la aplicación, el paquete solo para este pequeño botón será

4. Super Apps Federadas y Componentes React

Short description:

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.

ser descargado. No para toda la aplicación. Otro gran ejemplo son las super apps federadas. Este concepto suena un poco complicado. Pero intentaré explicarlo. Las super apps son este tipo de aplicaciones que pueden dividirse en fragmentos más pequeños. Podemos pensar en algunos ejemplos. Por ejemplo, la aplicación de Facebook. Contiene un montón de modules. Mercado, módulo de citas, módulo de juegos, muchos. Y aquí tenemos algunas aplicaciones de ejemplo colocadas en fragmentos más pequeños. Y podemos ver shawl. Eso es un contenedor de aplicaciones. Y los modules de reservas y compras. Estos modules viven en un servidor. Podemos acceder a ellos a demanda. Entonces, por ejemplo, podemos ocultarlos bajo algún botón. Y cuando un usuario hace clic en él, gracias a la federación de módulos, estamos descargando paquetes desde el servidor. Y eso es genial. Pero cuando el paquete, el paquete remoto es grande o incluso pequeño, pero el usuario tiene una conexión a internet lenta, puede llevar un tiempo descargarlo. Pero con los React components, podemos acelerar la evaluación de los fragmentos remotos para que el tiempo de interacción y el primer fragmento, el primer componente para interactuar se descargue rápidamente

5. Beneficios de los Componentes de Servidor de React Native

Short description:

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.

y rápidamente. Si quieres aprender más sobre este concepto, ve a ver la charla de nuestro jefe de tecnología, Mike Pioschkowa. Mike está presentando este concepto y cómo esto puede acelerar el desarrollo, especialmente dentro de grandes equipos. Así que, para resumir, ¿cuáles son los principales beneficios de los componentes de servidor de React Native? Así que, para empezar, no estamos enviando datos innecesarios por la red. Solo cosas que se mostrarán. Son capaces. Podemos, como presenté con este ejemplo, podemos iterar más rápido con banderas de características y despliegue. Y también, gracias a la arquitectura de React, están bien diseñados. Trabajan con los componentes del cliente y con el mecanismo de suspense. Y eso es solo el principio. No tenemos ninguna implementación. No hay información sobre este concepto. Y esperamos que, el próximo año, tengamos alguna implementación en producción, quizás una implementación experimental. Pero es genial empezar la discusión y ver cómo podemos beneficiarnos de tener RST en móviles. Y me gustaría presentar un ejemplo de cómo podemos encajar los componentes de servidor de React en alguna aplicación de ejemplo. Hay esta genial aplicación llamada Blue Sky. Y esta es una nueva plataforma de medios sociales. Y por cierto, el código fuente es de código abierto. La aplicación está escrita en React Native con Expo. Y están enviando un código fuente a tres plataformas. Así que, eso es realmente genial. Y muchos dicen que con RST en móviles, perderemos la sensación de UX nativa de la aplicación. No estoy de acuerdo con esta opinión. Para mí, los componentes de servidor de React correctamente implementados en una aplicación móvil simplemente acelerarán nuestro proceso de desarrollo y nos ayudarán. La sensación de la aplicación antes de aplicar los componentes de servidor de React y después será la misma. Entonces, ¿cómo podemos encajar los componentes de servidor de React aquí? Como podemos ver aquí, en la pantalla, tenemos algunos componentes principales. Así que, tenemos un encabezado. Tenemos una vista de feed. O tenemos una vista de feed, vista de lista, lo que sea en cada aplicación de medios sociales. Y tenemos nuestro navegador superior con algunas pestañas para navegar por la aplicación. Y por supuesto, cuando se trata de trabajar con redes dentro de las aplicaciones móviles y las aplicaciones web,

QnA

Desafíos de la aplicación React Native y Componentes de Servidor

Short description:

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.

necesitamos cuidar dos estados. Entonces, cuando un usuario tiene una conexión a Internet baja, necesitamos presentar alguna vista de carga, indicador de actividad, para que la pantalla no quede en blanco. Y también, necesitamos cuidar los errores. Entonces, cuando los usuarios no tienen conexión a Internet. Y para tener la sensación nativa de la aplicación, necesitamos agrupar este encabezado, vista de carga, límite de error y navegador superior en el paquete inicial. Porque los usuarios deben navegar a través de la aplicación inmediatamente después de hacer clic en el icono de la aplicación. No podemos esperar a que se resuelvan los fragmentos remotos. Los usuarios deben poder simplemente pasar por la aplicación. Y un componente que podemos migrar aquí para hacerlo como componentes de servidor es, por supuesto, una vista de feed, una vista de lista que está haciendo muchas llamadas a la database, está obteniendo publicaciones, avatares y todo tipo de información. Y al hacer esto como componentes de servidor, podemos beneficiarnos mucho. No estamos transmitiendo data innecesaria. Y por ejemplo, si queremos agregar un nuevo tipo de publicación o eliminar algún tipo de publicación o hacer algunos cambios de design, podemos hacerlo y desplegarlo sin la revisión de Apple. Y creo firmemente que la aplicación antes y después de aplicar los componentes de React, la experiencia de la misma se mantiene igual. Pero las cosas de las que podemos beneficiarnos. Entonces, podemos iterar más rápido y solicitar solo nuestro tenemos GraphQL listo para usar, podríamos decir. Y sí. Eso sería todo. Gracias. Muy bien. Entonces, tenemos nuestra primera pregunta. En primer lugar, muchas gracias por la charla. Creo que fue realmente interesante. Entonces, la primera pregunta que tenemos es, ¿cuándo crees que esto podría terminar siendo el enfoque equivocado al construir con React Native? Entonces, cuando nuestra aplicación es offline first. Y luego los componentes de React no se aplican para este caso de uso. Y también, si el próximo año o en el futuro, tendremos algunas implementaciones de producción para RSC, necesitamos preocuparnos por el caché de esos componentes para que todo y la experiencia se mantenga igual, se mantenga nativa. Esa es la mejor experiencia. Sí. La siguiente pregunta que llegó fue en realidad la que iba a hacer a continuación. Así que muchas gracias por hacerla. ¿Crees que Apple o Google podrían terminar rechazando aplicaciones donde efectivamente podrían eludir un proceso de revisión y enviar nuevos paquetes directamente a los usuarios?

Restricciones de Apple y Actualizaciones OTA

Short description:

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.

Sí. Esa es una cuestión complicada. Y por supuesto, Apple en sus aplicaciones tiene reglas. Lo han descrito. Por lo tanto, necesitamos ser muy cuidadosos. No podemos enviar características importantes, cambios importantes a nuestra aplicación que puedan perjudicar a Apple. Así que, solo podemos enviar algunos cambios menores o algunos cambios que a Apple no le gustarían. Sí. Creo que esto va a ser lo interesante, cómo este particular, quiero decir, esto es todo hipotético en este punto. Tanto en términos de implementación como de ser aceptado en las App Stores. Creo que esto va a ser- Y lo primero que me gustaría mencionar es que ya estamos haciendo esto. Nosotros ya estamos haciendo actualizaciones OTA. Así que, estamos reemplazando el paquete de forma remota. Y a Apple le gusta eso. Si somos cuidadosos y no estamos enviando cosas malas a la aplicación, a Apple le parece bien

La Solución de CoreStack para los Componentes de Servidor de React

Short description:

¿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.

eso. Y sí, eso es genial. Sí. Increíble. Y de nuevo, espero con ansias ver cómo se desarrolla eso en particular. ¿Está CoreStack trabajando en una solución para los Componentes de Servidor de React? Como mencioné, estoy trabajando en el equipo de I+D. Y como parte de mi trabajo, estoy haciendo la investigación. Y durante los últimos meses, estuve investigando sobre los Componentes de Servidor de React en móviles. Y veremos. Tenemos Repack. Esa es una biblioteca con la que puedes usar Repack dentro de las aplicaciones de React Native. Pero sí. Manténganse al tanto. Y quizás el próximo año lanzaremos algo. Ooh. Son insinuaciones. Vale. Esta es una pregunta. Ahora, voy a ser completamente sincero aquí donde no entiendo la terminología yo mismo. No sé qué es Metro. ¿Sabes qué es Metro? Sí. Maravilloso. Genial. Eso significa algo. Entonces, la pregunta es, ¿no crees que el enfoque con Repack está eludiendo a React Native al reemplazar a Metro? Parece un gran compromiso. ¿Podrías darnos una rápida introducción a lo que es Metro también? Entonces, Metro es un bundler predeterminado para React Native, y es mantenido por Meta. Y Repack es una solución que estamos manteniendo en CoreStack, con la que puedes probar Repack dentro de las aplicaciones de React Native. Y si entiendo correctamente esta pregunta, ¿crees que...? No lo creo. Repack tiene un montón de grandes características que Metro no tiene. Así que, por ejemplo, la federación de módulos y otros conceptos. Metro es una gran solución, y a menudo la gente pregunta si deberías usar Metro o Repack. Depende del caso. Y si quieres construir una super aplicación, o quizás

Componentes de Servidor de React y Restricciones de Paquete

Short description:

¿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.

si quieres agregar React Server components, veremos. Pero no lo creo. Genial. Gracias. Esta siguiente pregunta es una que también me estaba preguntando. Entonces, ¿cómo resuelven los Componentes de Servidor de React las restricciones de un solo paquete que enfrentamos con las aplicaciones de React Native con actualizaciones en el aire? Actualmente, tanto las actualizaciones de Expo como Code Push solo admiten un solo paquete. ¿Cómo harías parcial? Sí, eso es difícil de implementar. Intenté implementar los Componentes de Servidor de React, y es difícil. Hay un montón de trabajo que necesita hacerse para implementar correctamente los Componentes de Servidor de React, y uno de ellos es tener múltiples paquetes que funcionen con las aplicaciones móviles. Y creo que para el éxito de los Componentes de Servidor de React en móviles, necesitamos tener una muy buena experiencia de desarrollo. Y el asunto de agregar los Componentes de Servidor de React a la aplicación sería simplemente agregar la directiva useServer, useClient dentro del componente. Y todo necesita hacerse en el lado del marco. Entonces, aún enviarías con la herramienta actual. Y podría ser que la herramienta actual no sea la herramienta en el momento en que esto realmente aterrice. Creo que eso es más o menos lo que estás insinuando. Pero en este momento, si eso no cambia, hay casi una deficiencia podría ser una palabra fuerte, pero habría esta advertencia de que vas a tener que enviar un nuevo paquete completo usando la herramienta actual, ¿es eso correcto? Sí. Sí, genial. Esperemos que eso cambie porque creo que eso realmente afecta la viabilidad de este enfoque. Voy a reformular ligeramente esta pregunta porque entiendo lo que está tratando de decir. Pero para reformularlo ligeramente, ¿son solo los componentes individuales los que abogarías se conviertan en Componentes de Servidor de React, o sería que básicamente toda la aplicación se renderiza dentro de los Componentes de Servidor de React? Entonces, como mencioné, en una charla, necesitamos ser muy cuidadosos. Y con los Componentes de Servidor de React, sin los Componentes de Servidor de React, y después de agregar los Componentes de Servidor de React a la aplicación, la experiencia nativa necesita ser la misma. Por lo tanto, siempre debe haber componentes del cliente, como una pestaña o navegadores, o estados de carga, o límites de error. No podemos permitirnos mostrar solo una pantalla en blanco, porque entonces estamos perdiendo el punto de la aplicación nativa. Entonces, no, toda la aplicación, para mí, nunca sería un servidor, renderizado en el servidor, porque entonces estamos perdiendo la sensación nativa de la aplicación. Sí. Y como dices, la sensación, creo que hay una expectativa del usuario, ¿verdad? Cuando abres una aplicación, actúa y se siente de cierta manera, incluso mientras se está cargando data. Entendemos estos patrones que buscamos, que algo está sucediendo en segundo plano. Además, creo que sería una forma segura de tener una aplicación rechazada en una tienda de aplicaciones, porque creo que estos estados se prueban durante el proceso de envío. También me estaba preguntando sobre esto. Dios, amo estas preguntas. Están justo en mi cerebro hoy.

Orquestando Versiones de Aplicaciones y Actualizaciones

Short description:

¿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

Short description:

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.

usuarios. Hubo otra... Pensé que vi la pregunta que era sobre el control de funciones, y tal vez no. Tal vez imaginé una pregunta, pero tenemos algunas más mientras tanto.

¿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

Short description:

¿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.

a través de alguna forma de trabajo en curso que se hablará en el futuro. Esto es interesante. Creo que lo insinuaste en algunos puntos de tu charla, pero ¿cuándo esperas que los componentes del servidor React sean utilizables? Espero que el próximo año tengamos algunas soluciones experimentales. Y en unos años, me gustaría tener una implementación de producción. Creo que estamos en el momento, creo, idea. Y, sí, no mostraré una demostración. También estamos trabajando en esto. Así que, espero que podamos colaborar y lanzar algunas cosas geniales. Genial. Tenemos tiempo para una pregunta más realmente rápida. ¿Hay alguna diferencia significativa al testing localmente los componentes del servidor React con React Native? No lo sé. No lo he probado. Veremos. Me encanta eso como un lugar realmente agradable para dejar esto. Veremos. Pero yo realmente aprecio la especie de mirada al futuro que nos diste hoy. Por favor, todos, aplaudan a Shimon por esa primera gran charla en el escenario.

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

React Advanced Conference 2023React Advanced Conference 2023
29 min
Raising the Bar: Our Journey Making React Native a Preferred Choice
At Microsoft, we're committed to providing our teams with the best tools and technologies to build high-quality mobile applications. React Native has long been a preferred choice for its high performance and great user experience, but getting stakeholders on board can be a challenge. In this talk, we will share our journey of making React Native a preferred choice for stakeholders who prioritize ease of integration and developer experience. We'll discuss the specific strategies we used to achieve our goal and the results we achieved.
React Finland 2021React Finland 2021
27 min
Opensource Documentation—Tales from React and React Native
Documentation is often your community's first point of contact with your project and their daily companion at work. So why is documentation the last thing that gets done, and how can we do it better? This talk shares how important documentation is for React and React Native and how you can invest in or contribute to making your favourite project's docs to build a thriving community
React Advanced Conference 2021React Advanced Conference 2021
21 min
Building Cross-Platform Component Libraries for Web and Native with React
Building products for multiple platforms such as web and mobile often requires separate code-based despite most of the components being identical in look and feel. Is there a way where we could use shared React component library on different platforms and save time? In this presentation I'll demonstrate one way to build truly cross-platform component library with a unique approach of using React & React Native in combination.

Workshops on related topic

React Advanced Conference 2022React Advanced Conference 2022
81 min
Introducing FlashList: Let's build a performant React Native list all together
WorkshopFree
In this workshop you’ll learn why we created FlashList at Shopify and how you can use it in your code today. We will show you how to take a list that is not performant in FlatList and make it performant using FlashList with minimum effort. We will use tools like Flipper, our own benchmarking code, and teach you how the FlashList API can cover more complex use cases and still keep a top-notch performance.You will know:- Quick presentation about what FlashList, why we built, etc.- Migrating from FlatList to FlashList- Teaching how to write a performant list- Utilizing the tools provided by FlashList library (mainly the useBenchmark hook)- Using the Flipper plugins (flame graph, our lists profiler, UI & JS FPS profiler, etc.)- Optimizing performance of FlashList by using more advanced props like `getType`- 5-6 sample tasks where we’ll uncover and fix issues together- Q&A with Shopify team
React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
WorkshopFree
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
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
React Summit Remote Edition 2021React Summit Remote Edition 2021
60 min
How to Build an Interactive “Wheel of Fortune” Animation with React Native
Workshop
- Intro - Cleo & our mission- What we want to build, how it fits into our product & purpose, run through designs- Getting started with environment set up & “hello world”- Intro to React Native Animation- Step 1: Spinning the wheel on a button press- Step 2: Dragging the wheel to give it velocity- Step 3: Adding friction to the wheel to slow it down- Step 4 (stretch): Adding haptics for an immersive feel
React Advanced Conference 2023React Advanced Conference 2023
159 min
Effective Detox Testing
Workshop
So you’ve gotten Detox set up to test your React Native application. Good work! But you aren’t done yet: there are still a lot of questions you need to answer. How many tests do you write? When and where do you run them? How do you ensure there is test data available? What do you do about parts of your app that use mobile APIs that are difficult to automate? You could sink a lot of effort into these things—is the payoff worth it?
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
React Summit 2023React Summit 2023
88 min
Deploying React Native Apps in the Cloud
WorkshopFree
Deploying React Native apps manually on a local machine can be complex. The differences between Android and iOS require developers to use specific tools and processes for each platform, including hardware requirements for iOS. Manual deployments also make it difficult to manage signing credentials, environment configurations, track releases, and to collaborate as a team.
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.
React Advanced Conference 2022React Advanced Conference 2022
131 min
Introduction to React Native Testing Library
Workshop
Are you satisfied with your test suites? If you said no, you’re not alone—most developers aren’t. And testing in React Native is harder than on most platforms. How can you write JavaScript tests when the JS and native code are so intertwined? And what in the world are you supposed to do about that persistent act() warning? Faced with these challenges, some teams are never able to make any progress testing their React Native app, and others end up with tests that don’t seem to help and only take extra time to maintain.
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/