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!
This talk has been presented at React Day Berlin 2023, check out the latest edition of this React Conference.
FAQ
Los Componentes del Servidor React (RSC) son una tecnología que permite ejecutar componentes React en el servidor, enviando solo las partes necesarias al cliente. Esto ayuda a evitar el envío de datos innecesarios y props, mejorando la eficiencia en la transmisión de datos.
Los beneficios incluyen la reducción del tamaño inicial del paquete, la capacidad de realizar iteraciones más rápidas con despliegues de componentes individuales y la optimización del tiempo de interacción inicial al descargar solo los componentes necesarios.
Aunque React Native tradicionalmente no utiliza RSC debido a su enfoque en paquetes únicos descargados de tiendas de aplicaciones, existe la posibilidad de integrar RSC para optimizar la carga de componentes y datos según la demanda, especialmente en aplicaciones que se benefician de actualizaciones frecuentes y dinámicas.
Sí, React Native admite actualizaciones over-the-air mediante tecnologías como Expo y Repack, permitiendo a los desarrolladores enviar actualizaciones de código directamente a los usuarios sin requerir un proceso completo de revisión de la tienda de aplicaciones.
Implementar GraphQL en grandes bases de código puede ser complicado debido a la alta barrera de entrada y la necesidad de cambios significativos en la arquitectura backend, lo que puede llevar mucho tiempo y recurso.
Para manejar baja conectividad, React Native puede implementar estrategias como caché de datos, estados de carga visibles, y manejo de errores para mantener una experiencia de usuario fluida y evitar pantallas en blanco durante la pérdida de conexión.
Los Componentes del Servidor React permiten despliegues más rápidos y específicos de componentes, reduciendo la necesidad de actualizar y revisar la aplicación completa en la tienda de aplicaciones, lo cual es especialmente útil para cambios urgentes o frecuentes.
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.
React server components simplify server-side rendering and provide a mental model of components as pure functions. Using React as a library for server components allows for building a basic RSC server and connecting it to an SSR server. RSC responses are serialized virtual DOM that offload code from the client and handle interactivity. The client manifest maps serialized placeholders to real components on the client, enabling dynamic rendering. Server components combine the best of classic web development and progressive enhancement, offering the advantage of moving logic from the client to the server.
This Talk introduces React Server Components (RSC) and explores their serialization process. It compares RSC to traditional server-side rendering (SSR) and explains how RSC handles promises and integrates client components. The Talk also discusses the RSC manifest and deserialization process. The speaker then introduces the Waku framework, which supports bundling, server, routing, and SSR. The future plans for Waku include integration with client state management libraries.
In this Talk, Kent C. Dodds introduces React Server Components (RSCs) and demonstrates how to build them from scratch. He explains the process of integrating RSCs with the UI, switching to RSC and streaming for improved performance, and the benefits of using RSCs with async components. Dodds also discusses enhancements with streaming and server context, client support and loaders, server component rendering and module resolution, handling UI updates and rendering, handling back buttons and caching, and concludes with further resources for diving deeper into the topic.
React query version five is live and we'll be discussing the migration process to server components using Next.js and React Query. The process involves planning, preparing, and setting up server components, migrating pages, adding layouts, and moving components to the server. We'll also explore the benefits of server components such as reducing JavaScript shipping, enabling powerful caching, and leveraging the features of the app router. Additionally, we'll cover topics like handling authentication, rendering in server components, and the impact on server load and costs.
This Talk introduces server components in React, which provide an intermediate format for rendering and offer advantages for both client-side and server-side rendering. Server components reduce bundle size on the client and improve search engine optimization. They abstract the rendering process, allowing for faster rendering and flexibility in choosing where to render components. While server components are still in the experimental stage, Next.js is a good starting point to try them out.
This Talk explores the experience of shipping server components in production and highlights the benefits and challenges of using Server Components in Next.js apps. The Talk discusses the deployment of UploadThing and the use of AppRouter for safe production usage. It delves into the implementation of different layouts, data fetching, and code centralization for improved performance. The Talk also covers the use of server components for performance optimization and latency handling. Additionally, it explores the use of Edge and Lambda for partial pre-rendering and the challenges faced with webpack performance and hydration. Overall, the Talk emphasizes the benefits and challenges of working with Server Components in Next.js applications.
Presentando FlashList: Construyamos juntos una lista performante en React Native
Top Content
WorkshopFree
3 authors
En esta masterclass aprenderás por qué creamos FlashList en Shopify y cómo puedes usarlo en tu código hoy. Te mostraremos cómo tomar una lista que no es performante en FlatList y hacerla performante usando FlashList con mínimo esfuerzo. Usaremos herramientas como Flipper, nuestro propio código de benchmarking, y te enseñaremos cómo la API de FlashList puede cubrir casos de uso más complejos y aún así mantener un rendimiento de primera categoría.Sabrás:- Breve presentación sobre qué es FlashList, por qué lo construimos, etc.- Migrando de FlatList a FlashList- Enseñando cómo escribir una lista performante- Utilizando las herramientas proporcionadas por la biblioteca FlashList (principalmente el hook useBenchmark)- Usando los plugins de Flipper (gráfico de llamas, nuestro perfilador de listas, perfilador de UI & JS FPS, etc.)- Optimizando el rendimiento de FlashList utilizando props más avanzados como `getType`- 5-6 tareas de muestra donde descubriremos y solucionaremos problemas juntos- Preguntas y respuestas con el equipo de Shopify
A diferencia de las pruebas unitarias, las pruebas de extremo a extremo buscan interactuar con su aplicación tal como lo haría un usuario real. Y como todos sabemos, puede ser bastante desafiante. Especialmente cuando hablamos de aplicaciones móviles. Las pruebas dependen de muchas condiciones y se consideran lentas e inestables. Por otro lado, las pruebas de extremo a extremo pueden dar la mayor confianza de que su aplicación está funcionando. Y si se hace correctamente, puede convertirse en una herramienta increíble para aumentar la velocidad del desarrollador. Detox es un marco de pruebas de extremo a extremo en caja gris para aplicaciones móviles. Desarrollado por Wix para resolver el problema de la lentitud e inestabilidad y utilizado por React Native en sí como su herramienta de pruebas E2E. Únete a mí en esta masterclass para aprender cómo hacer que tus pruebas de extremo a extremo móviles con Detox sean excelentes. Prerrequisitos- iOS/Android: MacOS Catalina o más reciente- Solo Android: Linux- Instalar antes de la masterclass
- Introducción- Prerrequisitos para la masterclass- Estrategias de obtención: fundamentos- Estrategias de obtención – práctica: API de obtención, caché (estática VS dinámica), revalidar, suspense (obtención de datos en paralelo)- Prueba tu construcción y sírvela en Vercel- Futuro: Componentes de servidor VS Componentes de cliente- Huevo de pascua de la masterclass (no relacionado con el tema, destacando la accesibilidad)- Conclusión
Esta masterclass te guiará a través del ciclo de vida del desarrollo de productos para crear una aplicación web del mundo real. Aprenderás sobre los Componentes del Servidor React, construyendo un sistema de diseño dentro de Storybook, y utilizando el desarrollo frontend para acercarte a convertirte en un desarrollador full-stack. La masterclass cubrirá el aumento de la confianza en tu aplicación con pruebas unitarias e implementando autenticación y autorización. Tendrás la oportunidad de trabajar a través de las características del producto y examinar un proyecto real de RedwoodJS, obteniendo valiosa experiencia en el desarrollo de productos del mundo real. RedwoodJS hace que sea simple acercarse al desarrollo full-stack, y esta masterclass te dará las habilidades que necesitas para crear tus propias aplicaciones web del mundo real.
- Introducción - Cleo & nuestra misión- Lo que queremos construir, cómo encaja en nuestro producto & propósito, revisar los diseños- Comenzando con la configuración del entorno & “hola mundo”- Introducción a la animación de React Native- Paso 1: Hacer girar la rueda al presionar un botón- Paso 2: Arrastrar la rueda para darle velocidad- Paso 3: Agregar fricción a la rueda para frenarla- Paso 4 (extra): Agregar hápticos para una sensación inmersiva
El ecosistema de desarrolladores siempre está avanzando rápidamente y este año no ha sido una excepción. Los Componentes de Servidor React pueden ofrecer una mejora significativa a la experiencia del desarrollador y al rendimiento de la aplicación. Pero creo que es justo decir que este nuevo paradigma de servidor primero puede ser complicado de entender!En la primera mitad de esta masterclass, exploraremos los Componentes de Servidor React desde cero: construyendo nuestro propio mini marco meta para ayudarnos a entender cómo funcionan los RSCs. Descubriremos exactamente qué se produce en una construcción RSC y conectaremos esas piezas para formar una aplicación completa.A continuación, ¡lo desplegaremos! Cloudflare también ha tenido un año ocupado — Smart Placement, en particular, es una nueva tecnología que hemos desarrollado que se ajusta perfectamente al modelo RSC. Exploraremos por qué eso tiene sentido para nuestra aplicación de masterclass, y realmente lo desplegaremos en la Plataforma de Desarrolladores de Cloudflare.Finalmente, ampliaremos un poco más nuestra aplicación, utilizando D1 (nuestra base de datos SQL sin servidor) para mostrar realmente el poder del Componente de Servidor React cuando se combina con Smart Placement.Deberías salir de esta masterclass con una mayor comprensión de cómo funcionan los Componentes de Servidor React (tanto detrás de las escenas como también cómo tú como desarrollador puedes usarlos día a día), así como una visión de algunos de los nuevos patrones de despliegue que ahora son posibles después de las recientes innovaciones en el espacio de la plataforma.
Comments