Explorando los fundamentos de los Componentes del Servidor React

¡Hola a todos! Estoy muy emocionado de dar una charla este año, especialmente porque es sobre mi nuevo proyecto. Se trata de los React Server components, con los que he estado aprendiendo y experimentando durante varios meses. Hoy, voy a compartir lo que he aprendido hasta ahora. Mi nombre es Daishi Kato. Soy un desarrollador de código abierto, y algunos de mis proyectos populares son Jotai y Zustand. Tal vez lo sepan, pero ambos son para la gestión de estado. Son como competidores, pero en realidad es bueno porque nos aportan más feedback. Actualmente, Zustand está adelante y Jotai está persiguiéndolo. En el React Day Berlin 2022, hablé sobre Jotai. Es un honor estar aquí hablando de nuevo este año.

En la primera parte de esta charla, exploraremos los fundamentos de RSC. Tengo una demostración usando solo Node.js sin ningún framework. No es una codificación en vivo, pero espero que lo encuentren disfrutable. Si están interesados, pueden probarlo por su cuenta más tarde. Esta demostración es principalmente para los autores de bibliotecas o aquellos que quieren entender los comportamientos internos de RSC.

En la segunda parte hablaremos de mi proyecto, Waku. Es un framework de React centrado en RSC. Permítanme comenzar con una respuesta mía. ¿Qué es RSC? RSC significa Componente del Servidor React. Sin embargo, la parte del servidor en el nombre puede ser confusa. Se trata más de usar React en lugares diferentes a, digamos, el navegador. Y solo una nota rápida, técnicamente también puedes usar RSC en los navegadores. Profundizando, ¿cuál es el núcleo de RSC? Creo que la esencia es la serialización. Antes de RSC, React trabajaba dentro de un solo espacio de memoria. Pero con RSC, React ahora puede trabajar en espacios de memoria separados. Esto podría ser entre un servidor y un cliente, dos servidores o incluso dentro de los hilos de trabajo del navegador. Ahora, procedamos con la demostración. Comencemos configurando un proyecto de prueba. Por ahora, usaremos el canal canario de React hasta que salga una versión estable. El paquete React-ServerDOM-webpack está aquí para darnos las características de RSC.

Está diseñado específicamente para webpack porque algunas de sus características tienen una relación cercana con los empaquetadores. Sin embargo, no usamos webpack en nuestra demostración de todos modos.

Ahora sigamos adelante. Comenzaremos con un ejemplo simple sin RSC. Aquí está nuestro primer ejemplo. Es React tradicional, y no tiene nada que ver con RSC. Al mirar el código, encontrarás que simplemente estamos definiendo un AppComponent y mostrando el resultado con console.log. Cuando ejecutas el código, mostrará un objeto JSON. A esto se le suele referir como un elemento React o un elemento JSX. Lo importante a tener en cuenta aquí es que este elemento JSX no es serializable. Por ejemplo, contiene un símbolo para su propiedad de tipo especial. En este ejemplo, la propiedad type es una función que no es serializable. Exploraremos cómo RSC aborda esto en breve, pero antes de eso, veamos el renderizado del lado del servidor tradicional con nuestro próximo ejemplo.

El renderizado del lado del servidor o SSR es un proceso para generar contenido HTML en el servidor. Es importante tener en cuenta que SSR es diferente de RSC. Aunque RSC puede ejecutarse en el servidor, no produce HTML. Por cierto, SSR técnicamente también puede ejecutarse en navegadores. Ahora, examinemos el código. Utilizamos la función RenderToPipeableStream de react-dom-server. Esta función está disponible en la versión estable del paquete react-dom. Dado que RenderToPipeableStream devuelve un stream, no podemos simplemente usar console.log. En su lugar, lo dirigimos a Process.standard.out. Al ejecutar este código, se mostrará el HTML resultante. SSR se utiliza comúnmente durante la carga inicial de la página para mejorar la user experience y la optimization del motor de búsqueda. En nuestro próximo ejemplo, veremos cómo funciona RSC en comparación con este ejemplo de SSR.

Ahora, exploremos cómo se desempeña el aspecto de serialización de RSC. En esta demostración, utilizamos la función renderToPipableString() de react-server.webpack/.server. Tenga en cuenta, esto está disponible solo en la versión Canary. Excepto por importar la función de un paquete diferente, el resto permanece igual que en el ejemplo anterior. Al ejecutar este código, obtenemos una salida similar a JSON.

A esto se le conoce comúnmente como la carga útil de RSC. Esta carga útil es una representación interna y a menudo se considera como un detalle de implementación. RSC es independiente del renderizador, lo que significa que, aunque se use con frecuencia con react-dom, RSC no está estrictamente vinculado al DOM.

Además, como puedes ver en este ejemplo, proporcionamos una opción a nulljs, react-server-condition. Es esencial porque sin esto, el código no se ejecuta. Esta especificación es para determinar si el código se ejecuta bajo un entorno RSC. A continuación, veremos cómo se lleva a cabo el proceso de deserialización. En esta demostración, nos estamos centrando en la deserialización. Veamos el código. El react-server.webpack slash client se refiere al lado del cliente de la biblioteca. Normalmente se usa en navegadores, pero para esta demostración, estamos usando la versión de node.js. La función createFromNodeStream es para deserializar la carga útil de RSC. Para hacer que la demo funcione en una sola instancia de Node.js, estamos usando el stream de paso. En escenarios del mundo real, los datos de este stream podrían enviarse a través de una red.

El resultado en la consola puede parecer familiar. Es lo mismo que el elemento JSX que discutimos en nuestro primer ejemplo. De hecho, ejecutar la declaración console.log que está comentada al final del código mostrará el mismo resultado dos veces. Esta es la funcionalidad principal de RSC. Serializar un elemento JSX, transferir su stream por cualquier método y luego deserializarlo para reproducir el mismo resultado en otro lugar. Profundizaremos un poco más en los próximos ejemplos.

La capacidad de RSC para serializar datos no es solo para React. En realidad, puede manejar cualquier valor de JavaScript. Yo lo veo de esta manera. RSC soporta elementos JSX además de los valores estándar de JavaScript. Ahora, echando un vistazo al código y su salida, este ejemplo básico demuestra que RSC puede manejar objetos, arrays, cadenas y números. Aunque estamos destacando la serialización en este ejemplo, la deserialización funcionaría de manera similar. A primera vista, esto puede parecer muy básico. Algo que podemos hacer con el archivo de cadena JSON y las partes JSON. Entonces, ¿cuál sería el aspecto único de RSC? Podrías notar un prefijo extra antes de la cadena JSON, que en este caso es cero columna. Recuerda, la carga útil de RSC está diseñada como una cadena lo que significa que los datos se transfieren paso a paso.

Cada línea representa un fragmento de JSON con el prefijo actuando como un ID para que pueda vincularse a otro fragmento de JSON. En el siguiente ejemplo, veremos cómo se transfiere data con el tiempo. Este ejemplo muestra cómo RSC maneja las promesas. Normalmente, las promesas pueden ser serializadas. Pero RSC lo hace posible enviando el valor resuelto en un stream a medida que pasa el tiempo. En el otro extremo, al deserializar, obtienes lo que parecía ser la promesa original. Mirando el código, la función simplemente devuelve un array que contiene una nueva promesa. Si ejecutas este código, primero mostrará un array con un marcador de posición dentro. Espera un segundo, y aparece el valor resuelto. Y no tienes que preocuparte por cómo fue enviado. Simplemente funciona detrás de la escena.

Este ejemplo es sobre una promesa básica. Hasta donde entiendo, esto debería ser similar a cómo funciona React Suspense. Si usas suspense en el servidor, el servidor primero envía un fallback y un marcador de posición, que se resolverá después. En la siguiente diapositiva, ajustaremos ligeramente nuestro enfoque y veremos cómo funcionan los Componentes del Cliente con RSC. Una de las características más grandes con RSC son los Componentes del Cliente. RSC nos permite entrelazar los Componentes del Cliente con los Componentes del Servidor. Ahora, vamos a revelar cómo funciona la Serialización para los Componentes del Cliente. Echando un vistazo al código, hay un Componente Contador, que es un Componente del Cliente. A continuación, inspecciona el archivo Counter.js. En la parte superior, notarás el uso de useClientDirective. Esto es crucial, ya que indica que el archivo actúa como un punto de entrada para los Componentes del Cliente. Solo necesitamos la directiva para el punto de entrada. No necesitamos poner useClientDirectives para todos los archivos. La parte restante del archivo simplemente define un Componente React regular. De vuelta en nuestro archivo principal, hay una mención de ReactServer.webpack.node.register. Esta declaración registra un manejador para el useClientDirective. Aunque React ofrece múltiples métodos, hemos elegido este método en particular por su simplicidad en nuestra demostración. Para poner en marcha nuestra demo, se requiere un pequeño ajuste.

A continuación, echemos un vistazo breve a cómo funciona el aspecto de deserialización. En esta demo, estamos ampliando el ejemplo anterior añadiendo el proceso de deserialización. Las áreas marcadas con rectángulos rojos indican las diferencias con el ejemplo anterior. Como en una de las demos anteriores, utilizamos CreateFromNodeStream y Passthrough. El id dentro del objeto de manifiesto es el nombre del archivo en este caso, para que el cliente pueda importarlo desde el servidor más tarde. Además, hemos creado un objeto de configuración, que pasaremos a la función CreateFromNodeStream. Considera este enfoque una solución temporal. No representa la implementación real. Ahora veamos el resultado. El resultado muestra un elemento div con dos hijos. El primero es un elemento h1, y el segundo es un elemento lazy, que representa nuestro componente del cliente. Esto demuestra el árbol de React donde los componentes del servidor y del cliente están entrelazados. Teóricamente, si renderizamos este árbol, mostrará el contenido. No lo haremos en esta charla, pero será un desafío interesante.

Este es el final de nuestra demo, pasemos al siguiente tema. Hemos aprendido cómo funciona RST, especialmente su proceso de serialización. En nuestra demo, simplemente usamos funciones exportadas por las bibliotecas de React. Ahora podrías preguntarte si podemos usar directamente esas funciones en el desarrollo de nuestra aplicación. Sería bastante difícil y podría requerir mucho esfuerzo. Se hace evidente que algo como un marco sería útil. Mi motivación era entender mejor RST e integrar algunas de mis bibliotecas. Y eso me llevó a crear un marco mínimo que apoya principalmente a RST.

El marco en el que he estado trabajando se llama WACU. No podemos entrar demasiado en detalles, pero permíteme contar brevemente qué características se están desarrollando. Entonces, ¿qué falta en el aspecto central de RST? En otras palabras, ¿qué se requiere más allá de la serialización? Discutiremos cuatro características ya que actualmente son compatibles con mi marco.

La primera característica es un bundler. Recuerda una de nuestras masterclass con la directiva use client. Aunque usamos la función de una de las bibliotecas de React, básicamente es trabajo de un bundler. Técnicamente podríamos crear una referencia del cliente utilizando una solución runtime, pero tal enfoque podría no ser ideal y podría afectar negativamente la developer experience. Por lo tanto, un bundler es esencial para admitir esas directivas. Junto con un bundler, las bibliotecas de React ayudan a manejarlas. Un bundler también es crucial para resolver una referencia del cliente para obtener el módulo del cliente. Creo que es justo concluir que se requiere un bundler para RSC.

La segunda característica es un servidor. La serialización de RSC resulta en un flujo. Para transmitir este flujo a través de una red, requerimos un servidor capaz de RSC, generalmente un servidor HTTP. Este servidor debe estar equipado para manejar solicitudes específicas y responder con cargas útiles de RSC. Un servidor es esencial para producir data dinámica. Sin embargo, cuando se trata de data estática, el servidor capaz de RSC no es estrictamente necesario. Esto se debe a que podemos construir cargas útiles de RSC en tiempo de construcción y luego implementarlas con un servidor HTTP estándar. Por lo tanto, RSC no siempre necesita un servidor. Para diferenciar los dos escenarios, podríamos referirnos a ellos como RSC dinámico, que involucra un servidor, y RSC estático, que no lo hace.

La tercera característica es un enrutador. Si bien la necesidad de un bundler y un servidor es sencilla, entender la importancia del enrutador para RSC puede ser menos obvio. Por favor, no lo entiendas mal, pero un enrutador no es estrictamente necesario, en mi opinión. Sin embargo, si tu aplicación utiliza un enrutador, podría ser de ayuda. Esto se debe a que un enrutador permite que el servidor conozca más detalles antes de que comience el cliente. Esto significa que el servidor puede hacer tareas antes de enviar data al cliente, y puede llevar a un mejor performance. Consideramos un enrutador como una característica adicional para un marco de RSC. Sin embargo, con un enrutador, podemos optimizar aún más el uso de RSC.

La última característica es SSR. SSR es típicamente una característica clave en un marco de React.

En nuestro contexto, SSR se refiere a generar HTML en servidores. Entonces, SSR en sí mismo no está relacionado con RSC, lo que implica que SSR no es necesario para un marco de RSC. Sin embargo, hay un beneficio de SSR, y eso es mejorar la carga inicial de la página. Recuerda que no contribuye a la performance para actualizaciones posteriores. Entonces, si la carga inicial de la página performance es una prioridad para tu aplicación, entonces SSR es esencial. Si la página inicial es contenido puramente estático, puedes generar el HTML durante el tiempo de construcción, también conocido como SSG. Los distinguimos como SSR Dinámico y SSR Estático.

He estado desarrollando Waku desde el pasado mayo. Incluye las cuatro características que acabo de presentar. Notablemente, estas cuatro características están apiladas, lo que te permite usarlas selectivamente. Para sitios estáticos, es posible que solo necesites un bundler. Para sitios dinámicos, sería apropiado introducir un servidor. Para aplicaciones más complejas, considera agregar un enrutador y SSR.

Mirando hacia el futuro, uno de mis objetivos es desarrollar una solución integrada con bibliotecas de state management del cliente, como Jotai y Zastand. Anticipo la necesidad de un enrutador dedicado para estas integraciones. Seguiremos explorando esta dirección. Waku es un proyecto en curso y si te interesa, es de open-source, tu contribución sería invaluable. No dudes en visitar el repositorio de Waku en GitHub para ver la implementación de estas características. Siempre es bienvenida tu retroalimentación. Y con eso he llegado al final de mi charla. Gracias por tu atención. Espero que hayas obtenido algo valioso de esta charla.