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.
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
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
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,
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.
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
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
¿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
¿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
¿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.
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
¿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.
React Advanced Conference 2022
Comments