Conoce React Flight y Conviértete en un Experto en RSC

Mi nombre es Mauro y trabajo para una empresa que se llama Doubleloop en Italia. Y mencioné esta empresa porque ha sido muy importante para mí estar aquí hoy. En primer lugar porque son mi principal patrocinador para estar aquí haciendo esta charla, pero también porque esta empresa tiene algunas tradiciones. Por ejemplo, tenemos viernes especiales. Los viernes no trabajamos para nuestros clientes, no hacemos ningún trabajo habitual. Diría que intentamos no trabajar en absoluto generalmente, pero hacemos algo diferente. Por ejemplo, exploramos algunos temas nuevos.

Y fue durante uno de esos viernes que decidí explorar RSC, React Server Components, porque todo el mundo hablaba de ellos, pero yo no sabía nada, así que tenía mucha curiosidad por aprender algo. ¿Cómo lo hice? Bueno, comencé estudiando un poco, leyendo artículos, blogs, que pude encontrar en internet, y finalmente encontré la masterclass de Kent Seagal que puedo sugerir a ustedes, que trata sobre crear un framework basado en React Server Components desde cero. Traté de seguirla, fue muy buena, pero no fue suficiente para mí porque para aprender y entender realmente algo necesito profundizar, escribir algo de código con mis propias manos. Así que decidí dar un paso adicional para crear algunos rompecabezas que tenía que resolver uno por uno. Y de esos rompecabezas básicamente también nació la idea para la charla.

Así que hoy lo que voy a hacer es compartir con ustedes mi viaje de aprendizaje a través de estos rompecabezas o desafíos, como lo llamaré durante la charla. Así que este fue el título original que envié con la propuesta, pero durante la preparación pensé en un punto de vista diferente, así que decidí asociar el acrónimo RSC a muchos significados diferentes, cada uno para cada desafío diferente que vamos a ver, solo para hacerlo un poco más divertido. Así que este es el nuevo título final. También recuerdo el enjoy flight, porque vamos a hablar un poco sobre flight.

El primer desafío es un simple hola mundo, comenzamos fácilmente. Así que intentamos usar la tecnología de React Server Components pero sin usar un servidor. Así que el desafío se llama React Serverless Components, este es nuestro primer significado para el acrónimo. Así que queremos crear un hola mundo muy simple, puedes verlo a la derecha, este es el resultado final. Y a la izquierda puedes encontrar un código muy simple que puedes ejecutar en un cliente, no necesitas un servidor para esto. Y este código lo que básicamente hace es algo que puedes hacer con la tecnología RSC, que es cargar algún contenido que está pre-generado en otro lugar, tal vez en un servidor, no lo sé, pero por ahora no nos importa el servidor.

Podemos obtener este contenido de algún lugar, luego podemos usar una nueva función que está disponible en React 19, en el paquete de React Server Components, obviamente, que se llama createFromFetch, que toma el contenido obtenido y lo decodifica de alguna manera para que pueda convertirse en algo que podamos renderizar desde React. También hay otra cosa que es nueva en React 19, una nueva característica en React 19, un nuevo hook llamado use, tal vez se les acabaron los nombres para los hooks, así que fueron por el más simple, se llama simplemente use. Puedes pensar que puedes usar todo con use, pero no es el caso, básicamente puedes usar cualquier tipo de recurso, llamémoslos, en particular por ahora, se usa para usar promesas y contexto, así que una forma simple de obtener algunos recursos remotos, promesas, y usarlos con una sintaxis sincrónica en lugar de usar async await y las cosas habituales.

Ahora que tenemos las cosas decodificadas, podemos renderizarlas usando el método de renderizado habitual de React DOM, no hay nada nuevo en ello, pero tal vez tengas curiosidad por entender qué es este contenido pre-generado del que estamos hablando. Es básicamente algo como esto. Este es un nuevo protocolo que el equipo de React introdujo con RSE, se llama ReactFlight, esta es la razón por la que te dije que recordaras la palabra flight, porque es importante. Es un protocolo que se usa para serializar cosas para que puedas enviarlas de un lugar a otro, por ejemplo de un servidor a un cliente, así que puedes generar el contenido en algún lugar, enviarlo a otro lugar, y usarlo por ejemplo para compartir el trabajo de renderizado entre un servidor y un cliente. Es similar a JSON pero no es realmente JSON, veremos un poco más cómo se ve más adelante. Así que con esto podemos imaginar un flujo de trabajo hecho como este, por ahora sabemos cómo deserializar este tipo de contenido, usando la función createFromPatch, aún no sabemos cómo serializar algo en el lado del servidor, lo veremos más adelante.

Bien, puedo decir que el primer desafío está completado, así que vamos rápidamente al segundo. No es realmente tan diferente, así que lo llamo el primer desafío y medio, porque no es realmente muy diferente del primero, así que no era bueno llamarlo segundo. El acrónimo en este caso se traduce como contenido estático reemplazable, porque queremos agregar un paso adicional, ¿qué pasa si queremos cargar más contenido diferente usando RSC, no solo una sola página, queremos cambiar entre diferentes tipos de contenido. Eso es absolutamente posible, el ejemplo es el que ves a la derecha. No te preocupes por el código, porque hay un repositorio de GitHub con todos los fragmentos de código que estoy mostrando, te daré el enlace más tarde.

Así que con este ejemplo no usamos nada nuevo de React 19, porque lo único que necesitamos hacer es usar el hook useState, por ejemplo, para almacenar nuestro contenido en algún lugar, como estamos acostumbrados a hacer. Por ejemplo, podemos almacenar el resultado de la función createFromPatch que hemos visto hemos visto en el ejemplo anterior, y simplemente pasarlo como una propiedad a un componente no raíz o un componente raíz, como en este caso, y usarlo allí. Así que nuestro componente raíz es en realidad un muy dinámico, porque no renderiza nada por sí mismo, solo obtiene el contenido de otro lugar.

Bien, algo más sobre react-flight, porque probablemente estamos curiosos, ya hemos visto que en react-flight podemos incluir alguna representación de nuestro DOM en una especie de sintaxis similar a JSON. No es realmente JSON pero se asemeja. Pero la otra cosa importante es que el contenido no se limita a solo una fila de cosas. Podemos tener muchas piezas que se llaman fragmentos, cada uno tiene un prefijo que es una clave asociada a este fragmento, porque una propiedad importante de react-flight es la capacidad de componer diferentes fragmentos juntos, y la forma en que los compones es referenciando otros fragmentos con esta sintaxis $key. Así que también react-flight es componible, como todas las bibliotecas de React aspiran a ser. Así que, ¿qué podemos pensar hacer con todas estas cosas que hemos visto hasta ahora? Tal vez generación de sitios estáticos, podemos generar nuestra carga útil de react-flight en algún lugar y usarla desde un cliente sin tener un servidor real disponible. Pero lo mismo es posible con el viejo HTML, así que ¿por qué necesitamos RLC para hacer eso? Probablemente este no es un punto de venta muy fuerte para RLC, pero lo que puedo decirte por ahora es que el protocolo react-flight es un protocolo rico, puede compartir entre servidor y clientes muchas cosas más que simple HTML, así que probablemente veremos más adelante si esto es algo que podemos usar adecuadamente.

Bien, vamos rápidamente al segundo desafío, porque es hora de introducir un servidor en la mezcla. Esta es la razón por la que este desafío se llama react-server y cliente. Queremos entender si podemos usar efectivamente un servidor, porque la tecnología se llama un componente react-server, así que probablemente hay algo que podemos hacer en el servidor.

Lo primero que debo aconsejarte es que para usar RLC en un servidor necesitas iniciar tu Node.js con una bandera particular que habilita el modo RLC, si no, usarás React en el modo antiguo, que es un poco diferente, así que no podrás hacer este tipo de cosas si no inicias Node.js con esta bandera.

Luego, este es un ejemplo de un backend, muy simple, uso Fastify como tecnología de backend, puedes usar lo que te guste, como Express.js, Sono.js, todo está bien, no es importante. Luego necesitas algún endpoint, uno dedicado tal vez, donde puedas usar una función que está disponible en React 19 que hace esta parte de serialización. Esta función se llama renderToPipeableStream, recuerda la palabra stream porque la veremos más adelante y se está volviendo muy importante.

La función no devuelve directamente una carga útil de RLC que hemos visto, sino que devuelve una función que puedes usar para empujar la carga útil de RLC a algún tipo de stream, como el stream de respuesta en este caso. Bien, algo más sobre el React flight, ves otro ejemplo aquí a la derecha. El React flight solo puede contener el DOM final para el código que ha sido generado en el servidor, pero también una representación de alto nivel de tu aplicación que describe los componentes en sí mismos. Así que tienes una vista dual, diría yo, el DOM virtual final y también el árbol de componentes que se han utilizado para generar ese DOM.

Puede ser útil para depuración y otros tipos de cosas. ¿Qué más? Obviamente el React DOM generado también hace referencia a los componentes que los han generado con la misma sintaxis $key que hemos visto antes. $algo siempre es una referencia a algo. Y hemos completado el flujo de trabajo que hemos visto antes, ahora también sabemos cómo serializar cosas. Pero con este tipo de cosas hemos movido básicamente todo el trabajo al servidor. Ahora el cliente es muy tonto, solo toma alguna página pre-generada y la renderiza.

No es un trabajo muy importante, pero queremos compartir un poco la tarea de renderizar una página entre un servidor y el cliente, no solo hacer algo solo en un lado. También los componentes del servidor tienen algunas limitaciones con respecto al componente del cliente que siempre hemos usado en React, porque por diseño son sin estado, no hay estado por defecto en el servidor, si no lo implementas tú mismo. Así que, por ejemplo, no puedes usar ningún hook que maneje un estado, tampoco puedes usar el contexto en el servidor. Además, los componentes del servidor no son interactivos porque no son ejecutados por un navegador, no son JavaScript, digamos. Así que, por ejemplo, no puedo hacer un botón que haga algo como hacer una alerta en un componente del servidor. Si queremos hacer eso RSC nos da componentes solo para cliente, así que componentes que pueden ser ejecutados efectivamente en el cliente, y están prefijados por esta directiva. Si usas client, si pones la directiva use client en la parte superior de tu componente cliente, son reconocidos por RSC y manejados adecuadamente como componentes del cliente. Obviamente un componente cliente puede ser incluido en una página completa que es generada por un servidor, pero no al revés. Así que si tienes React en el cliente no puedes tener componentes del servidor allí, así que los componentes del cliente como este no pueden referenciar directamente otros componentes del servidor. ¿Y qué hay de React Lite en este caso? Los componentes del cliente son especiales, están incluidos en las cargas útiles en dos piezas diferentes. La primera le dice al cliente cómo cargar el código del componente cliente en sí, así que es una referencia simple a algún JavaScript.

Y luego tienes otro tipo de referencia, es $L, significa lazy, la L es de lazy. Así que los componentes del cliente son solo referencias lazy, algo que será cargado de manera lazy cuando sea necesario. Esta es la única diferencia con las referencias que hemos visto hasta ahora. Una nota adicional, usualmente este tipo de cosas no es una simple inclusión de un JavaScript para tus clientes. Usualmente hay un empaquetador en el medio que toma todos los componentes solo para cliente, crea un paquete, lo envía al navegador. Es un poco más complejo, pero dado que estamos tratando de simplificar las cosas en este caso no usé un empaquetador. Hay una alternativa que es usar un cargador de Node.js que está disponible a través de RSC para manejar estos componentes del cliente.

Bien, con este desafío aprendimos un poco cómo hacer renderización del lado del servidor de una manera alternativa, porque podíamos hacerlo también antes de RSC, pero es un poco diferente. Antes de RSC necesitabas usar la función renderToString que genera HTML. Ahora tenemos una nueva función, renderToPipelineString, que en su lugar genera payloads de React flight en lugar de HTML directo. Pero en mi opinión, esto todavía no es una característica decisiva para vender RSC. Si tuviera que vendértelo, probablemente no.

Así que vamos rápido porque tenemos mucho trabajo por hacer. El tercero, ¿recuerdas Stream? Encantado de conocerte. Así que el tercero se centra en el concepto de streaming y se llama React Streaming Components. Aquí es donde las cosas se ponen interesantes en mi opinión, porque esto es algo nuevo. Digamos que queríamos crear una aplicación que se actualice continuamente, tal vez infinitamente, indefinidamente, en teoría, pero en práctica. Muy simple. Un contador que se incrementa y actualiza periódicamente la página.

Lo interesante aquí es que en el servidor, los server components pueden ser asíncronos. Así que a través del uso de la funcionalidad async await se puede cargar datos y retrasar la renderización. La forma en que simularon la carga de algunos datos es solo un set timeout, pero imagina que aquí estás cargando algunos datos de una base de datos o de otro lugar. Entonces puedes renderizar inmediatamente lo que está disponible. Así que el valor actual del contador, por ejemplo.

A través del uso de suspense puedes retrasar la renderización de lo que viene después. En este caso, el valor del siguiente valor del contador. Y para hacerlo infinito uso recursión. Así que estamos usando el mismo componente una y otra vez, solo incrementando el contador. No lo hagas en casa, porque en algún momento se desbordará la pila. Esto es solo una demo, no un código de producción.

React flight también en este caso. Tercera cosa, los componentes internos de React se renderizan a través de esta notación $S que es para símbolos. Luego, lo más importante aquí es que en un chunk, el primero que enviamos al cliente, tenemos una referencia de lista, como la de los client components. Es lo mismo porque estamos esperando algo que aún no ha llegado. Referenciamos algo que no está allí, llegará algún día, y cuando llegue la página se actualizará. Bien, ahora podemos hacer streaming de contenido y podemos diferenciar el contenido rápido que llega inmediatamente, del contenido lento que aparecerá después. Esto es algo que probablemente no teníamos antes. Así que creo que esto es un verdadero cambio de juego de RSE.

Este es un punto donde RSE te ofrece algo nuevo. Vamos rápido al cuarto desafío. Llamo a este React Strange Constraints, porque hay algo que no pude entender. Si alguien lo sabe, por favor explíquemelo.

En este desafío estaba tratando de optimizar la renderización, así que quería enviar al navegador la página inicial como HTML, no solo el RSE y luego hacer la renderización del RSE en el propio navegador, en el cliente, porque sé que Next.js, por ejemplo, puede hacerlo. Si miras las páginas generadas por Next.js, son HTML con algo en ellas, pero son HTML. ¿Cómo puedo hacer esto?

Primero tengo que preparar dos backends diferentes. Esta es una forma posible, y te explicaré más tarde por qué necesito hacer eso. El primero estará dedicado a la generación de RSE, así que necesito comenzar con la bandera que te mostré antes. En este tengo el mismo endpoint que ya hemos visto. Lo listé en un puerto diferente porque tengo dos backends diferentes. Hay una forma alternativa, no tengo tiempo para mostrarla, pero la encontrarás en el repositorio de GitHub. En lugar de tener dos backends diferentes, puedes usar workers para iniciar dos procesos diferentes en el mismo backend, y esa es otra forma de hacer lo mismo.

En el backend principal, lo que tengo es una especie de proxy que simplemente llama al endpoint de RSE y obtiene de vuelta el RSE, y luego hace lo que hicimos antes, RSE, renderizar a cadena algo. También hace otra cosa, que es añadir al HTML final, inyectar en él también la carga útil de RSE para el mismo contenido. Esto será utilizado por el cliente para la hidratación, así que necesitamos ambos, porque por ejemplo, si tenemos componentes del cliente mezclados con componentes del servidor, necesitamos hacer la hidratación en el cliente, no es suficiente con el HTML generado, así que también inyectamos el RSE. También inyectamos el RSE en el propio HTML y luego en el cliente podemos leerlo con este fragmento de código. Obtenemos la carga útil directamente de la página. Podemos usar un flujo legible. Esto es javascript estándar, nada de React, así que puedes leer el flujo y pasarlo a otra función. Crear desde flujo legible es lo mismo que crear desde fetch, pero usa un flujo en lugar del resultado de un fetch, pero hace exactamente lo mismo. Así que de esta manera estamos optimizando nuestra carga inicial de la página. Dimos un paso más en SSR, pero ¿por qué lo llamo las extrañas limitaciones de React? Porque React es extraño, porque en mi opinión, porque no te permite hacer renderizar a cadena y renderizar a flujo canalizable en el mismo proceso. Si pudiera hacerlo, no tendría la necesidad de dos backends diferentes o workers. No sé por qué en React no puedes hacer eso, así que si alguien sabe la razón, por favor dígamelo. Dormiré mejor esta noche.

Okay, we are almost there. The final challenge. ¿Qué pasa si quiero usar un lenguaje que no sea javascript en el backend? ¿RSC me permite hacer eso? A esto lo llamo Rust server components. Estaba en el video, tal vez alguien vino aquí porque escuchó la palabra Rust. Fue un cebo rápido, lo admito.

Así que creé tal desafío, pero no tenía forma de saber si podría hacerlo. Este es el único que no tenía idea si podría llegar al final. Finalmente lo hago, más o menos, porque encontré una biblioteca que se llama rscx de otro italiano como yo, Antonio Pitasi. Se llama Rust server components, la biblioteca, y básicamente permite hacer un par de cosas. Primero que nada, puedes etiquetar funciones con el atributo component y se convierten en una especie de server components. Son funciones como las que escribimos en javascript usando React, pero están en Rust.

También hay una macro, esta macro HTML bang, que permite escribir algo que es muy similar a JSX, que se parece, y de esta manera creo una especie de server components usando Rust. La macro HTML, como probablemente sugiere el nombre, genera directamente HTML. Lo que hice para completar el desafío fue escribir una función adicional que llamé flight que simplemente se usa en combinación con HTML para generar cargas útiles de flight en lugar del HTML en sí. Así que de esta manera creé un backend que es compatible con mi cliente RSC en el navegador. Es una prueba de concepto. Realmente no funciona para un ejemplo complejo. Solo funciona para cosas muy simples por ahora, pero era una idea. Quería demostrar si ReactFlight podría convertirse algún día en un protocolo independiente del lenguaje. En teoría podría ser. No es fácil, obviamente, porque lo más importante que necesitamos es que el protocolo debe estar documentado y ser estable. Eso no está tan lejos. Tengo una esperanza ya que recientemente React 19 tuvo un lanzamiento final, tal vez decidan al menos documentar el protocolo que ahora está documentado solo a través de ejemplos de ingeniería inversa de código de otras personas. Esta es la forma en que lo entendí. Entendí un poco de ello, pero tal vez alguien considerará esta opción, probablemente no yo, porque no soy un desarrollador de Rust, tengo que confesar, pero tal vez pueda hacer una versión en Java o algo así.

Bien, este fue el último desafío. Solo algunas conclusiones finales. Entonces, ¿cuáles son las partes positivas de RSC en mi viaje de aprendizaje? Puse el streaming en primer lugar porque para mí es algo muy nuevo y muy interesante. La otra cosa es la capacidad de equilibrar el trabajo del servidor y del cliente porque es muy flexible. Puedes decidir dónde hacer tu trabajo de renderizado, más en el servidor, más en el cliente, lo mejor de ambos, tú decides.

También puedes extender el significado de cliente-servidor, porque en el ejemplo de optimización hemos visto que tenemos tres entidades, tres entidades diferentes. Tenemos dos backends, uno dedicado a RSC, otro para generar el HTML final y hay soluciones que aprovechan este tipo de cosas. Así que diría que no hay un cliente y servidor reales, hay diferentes roles que puedes decidir dónde lograr. Y también el hecho de que el RSC es básicamente un conjunto de primitivas que son realmente básicas como el protocolo React flight y esto permite muchas implementaciones diferentes.

Por ejemplo, tenemos Next.js desde hace algún tiempo, también tenemos otra implementación que es Waku y también Remix o la nueva versión, el React router v7 es compatible con RSC. Creo que también este framework TAN-stack start está yendo o ya lo está soportando, así que es algo que está siendo adoptado. Lo principal que veo en contra, pero probablemente es mi punto de vista, es que el protocolo en sí, o sea React flight, no está realmente bien documentado hasta ahora. No sé si los desarrolladores de React están dispuestos a documentar y hacer este protocolo estable.

Eventualmente abrirá la ocasión para extenderlo a otros ecosistemas y lenguajes. Y si tienes una pregunta que es ¿es este un mejor enfoque que otros enfoques para hacer renderizado del lado del servidor u otro tipo de cosas? No estoy seguro todavía porque creo que es demasiado pronto. Como dije, el equipo de React final ha sido lanzado creo que hace una semana o algo así. Así que creo que es un poco temprano pero durante el próximo año probablemente entenderemos un poco más. Aquí hay muchos enlaces, creo que se compartirán con ustedes en los próximos días. Así que finalmente no estoy solo porque hay otras personas que están bromeando con el acrónimo RSC. Encontré este React showloading air component. Fue realmente divertido así que lo incluí. Gracias a todos por escuchar.

Así que Mauro, gran charla. Muchas gracias por la conclusión, me encantó. Tengo una conclusión así que tomo una captura de pantalla. Así que las primeras preguntas que tenemos aquí. Al crear el archivo React flight, ¿el desarrollador tiene que asegurarse de que las cosas se carguen de forma diferida o hay un paso de optimización en el compilador? Bueno, algo que no tuve tiempo de decir durante la presentación pero creo que es muy importante así que tomo la ocasión. No generas esos archivos a mano. Lo hice porque estoy loco y quería entender cómo se hacían así que entré, pero el objetivo no era escribirlos a mano. Están escritos por esa función serialized to pipeable stream, render to pipeable stream. No tienes que hacerlo a mano y pero el framework RSC, las primitivas básicas que están en React 19 están haciendo todo el trabajo por ti así que solo necesitas preocuparte por el framework que elijas. Pero creo que creé esta charla porque creo que es, al menos para mí, para entender si algo es útil necesito ir dentro de ello así que necesito entender el porqué detrás de las escenas. Gracias.

Siguientes preguntas, ¿cómo funciona el streaming con las diversas opciones de infraestructura? Bueno, el streaming en este caso realmente no necesita una infraestructura especial porque funciona bien con el HTTP simple. Creo que puedes usarlo a través de sockets de servidor u otras formas.

bien con el HTTP simple. Creo que puedes usarlo a través de sockets de servidor u otras formas. Para tener, por ejemplo, el stream infinito que dije que no es para producción. Obviamente, si tienes un socket de servidor puedes seguir enviando contenido en ese caso. El consejo era para la comunicación estándar a través de HTTP.

Obviamente no puedes hacer streaming infinito allí porque el canal HTTP necesita ser liberado, si no estás desperdiciando recursos. Pero para sockets de servidor, por ejemplo, ¿por qué no? Gracias. Tenemos tiempo para una pregunta más. Entonces, ¿has visto si la hidratación de RSC es más rápida que la hidratación regular? Y se supone que sí, pero tengo curiosidad si la diferencia es significativa. No hice ninguna prueba específica de rendimiento, pero supongo que sí porque lo más importante de ReactFlight, en mi opinión, es que hace parte del trabajo en el servidor mientras que con las soluciones estándar de SSR obtienes algo que necesita ser elaborado más. En este caso, la mayor parte del trabajo porque ReactFlight cuando esto se realiza es básicamente la estructura interna del DOM virtual.

Así que la primera parte de generar el DOM virtual ya está hecha en el servidor.