Cómo un Framework RSC Habilita Acciones del Servidor

Soy Daisuke Kato, y estoy muy emocionado de dar una charla en React Advanced London por primera vez. Soy un desarrollador de código abierto, y en los últimos años he desarrollado varias bibliotecas de React, incluyendo Zest, Jota y Valsio.

Mientras sigo manteniendo esos proyectos, mi trabajo más reciente se ha centrado en crear un nuevo framework de React. Así que el título de mi charla hoy es Cómo un Framework RST Permite Acciones de Servidor. Espera, déjame modificarlo. El título es Cómo un Framework RST Permite Funciones de Servidor. Ese es un término nuevo. En esta charla, compartiré algunas ideas que he aprendido durante el desarrollo. Por favor, ten en cuenta que lo que presento hoy podría no ser 100% preciso. Dicho esto, comencemos.

El framework que estoy desarrollando se llama Waku. Es un proyecto en equipo porque desarrollar un framework es complicado, y no puedo hacerlo solo. A diferencia de mis otros proyectos, que son pequeños, Waku es más grande y amplio. Esto solo fue posible gracias a nuestros colaboradores. El proyecto comenzó hace aproximadamente un año y medio, y cuando empecé, mi conocimiento sobre la implementación de un framework de React era literalmente cero. Ha habido muchas iteraciones con prueba y error, y todavía continúa. Una de las tareas recientes fue apoyar funciones de servidor.

Esta charla trata sobre funciones de servidor, pero en la primera parte, dedicaré algo de tiempo a discutir React Server Components, o RSC. React 19 introduce varias características nuevas, pero una de las más significativas es RSC.

RSC significa React Server Components, pero cuando decimos RSC, a menudo nos referimos a toda la capacidad de ejecutar React en un servidor. Así que, RSC incluye componentes de servidor, funciones de servidor, y tal vez más. Una cosa complicada es que RSC no siempre requiere un servidor en tiempo de ejecución. Puede renderizar varios componentes en tiempo de compilación y generar sitios estáticos. Así que, RSC incluso puede ayudar con aplicaciones de una sola página.

Técnicamente, la capacidad central de RSC es la serialización, y es proporcionada por una biblioteca de React, pero para consumirla, necesitas un framework o al menos un empaquetador. Ahora, exploremos cómo funcionan los componentes de servidor. Antes de que existieran los componentes de servidor, el concepto era simple, como sabes. Todo se ejecutaba en el cliente. Por cierto, una de las fortalezas de React, como veo, es esta representación intermedia, a veces llamada el DOM virtual. Gracias a esto, podemos renderizar un componente varias veces antes de comprometer o aplicar ciertas extensiones. Los componentes de servidor pueden considerarse como una de esas extensiones.

Ahora, con los componentes de servidor, tenemos dos tipos de componentes. Ambos se renderizan por separado y se fusionan en una sola representación. Los elementos JSX se serializan en un formato similar a JSON y se envían al cliente. Es difícil mostrar en este diagrama, pero los dos procesos de renderizado no ocurren realmente simultáneamente. Debido a que los componentes de servidor apuntan a los componentes del cliente, el renderizado realmente ocurre en el servidor al principio. Una vez que el cliente recibe los elementos JSX del servidor, renderiza los componentes del cliente y fusiona los dos resultados. ¿Hasta ahora, todo bien?

Veamos cómo se implementa esto. Me gustaría explicar la idea con código. Aquí, dos escenas de código básicamente representan el código del cliente y el código del servidor. Son pseudocódigo, pero están bastante cerca de la implementación real en mi framework. Veamos el código del cliente. CreateRoot es una función que debería ser familiar para la mayoría de los usuarios de React. Por otro lado, createFromFetch es una nueva función de la biblioteca de React y es típicamente utilizada por frameworks. Ahora, en el lado del servidor, cuando recibe una solicitud, el servidor renderiza el componente de la aplicación y crea un flujo. Este flujo se llama la carga útil RST que el cliente recibe y renderiza. La función clave aquí es renderToReadableStream.

Me gusta enfatizar que esto es sin SSR o renderización del lado del servidor. Agregar SSR es complicado, y no es el alcance de esta charla, pero una conclusión clave es que RST no está vinculado a SSR. SSR se utiliza solo para la renderización inicial, mientras que todas las re-renderizaciones posteriores en el cliente ocurren sin SSR pero con RST. Como puedes ver, el componente de la aplicación es un componente de servidor.

Lo que se vuelve interesante es cuando comenzamos a usar componentes de cliente. Como sabrás, un archivo de componente de servidor puede importar un archivo de componente de cliente. Distinguimos esto con useClientDirective. El servidor tiene que serializar el componente cliente en la carga útil RST. Todo el propósito de useClientDirective es hacerlo serializable, creando una referencia de cliente. Una referencia de cliente es básicamente un identificador que apunta al componente cliente.

Veámoslo brevemente. Este diagrama muestra cómo se utiliza conceptualmente una referencia de cliente. En el lado del servidor, un componente cliente se convierte en una referencia de cliente y se codifica en una carga útil RST, que luego se transfiere al cliente. El cliente encuentra la referencia en la carga útil y recupera el componente cliente real. Recuperar el componente cliente real es un trabajo del framework, y por ahora puedes asumir que una referencia de cliente actúa como una URL. Hasta ahora, nuestra discusión fue algo conceptual. Pero en la práctica, ¿cómo se crea realmente una referencia de cliente? La respuesta es la transformación de código. Veamos cómo se transforman estos componentes de cliente.

Primero, necesitamos una función especial llamada registerClientReference. Esta función es proporcionada por una de las bibliotecas de React. Ahora, ¿cómo usamos esta función? Envolvemos la función real con ella, y devolvemos el resultado como componente cliente. Se pasan dos cadenas a la función. La primera representa el archivo, y la segunda es el nombre de la función exportada. Estas cadenas se utilizan para identificar el componente cliente. Técnicamente, pueden ser cualquier cosa siempre que puedan identificar la función exportada. Como acabamos de ver, para que los componentes de servidor y cliente funcionen, necesitamos transformar el código del usuario. El framework se sitúa entre el código del usuario y el tiempo de ejecución de JS, manejando la transformación del código. Esta es una de las razones por las que RST necesita un framework o empaquetador. Necesitamos transformar nuestro código antes de ejecutarlo, y la transformación difiere entre diferentes tiempos de ejecución. En el ejemplo anterior, el código del usuario fue transformado a un tiempo de ejecución de servidor.

Pero, ¿alguna vez necesitamos transformar el código para el runtime del cliente? Sí, la función de servidor puede requerirlo. Ahora hablemos rápidamente sobre las funciones de servidor. La idea de las funciones de servidor no es muy difícil. Básicamente, permite que el componente cliente llame a una función en el servidor. Esto también requiere serialización, lo cual no es muy sorprendente.

Bueno, creo que eso es prácticamente todo. Así que he hablado sobre componentes de servidor y ahora funciones de servidor. ¿Cómo están relacionados? Resulta que las funciones de servidor y los componentes cliente tienen algo en común. Ambos son solo funciones, y necesitan ser serializables porque son problemáticas entre el servidor y el cliente. Algunos identificadores se utilizan para esta serialización llamados referencias. Las transformaciones son activadas por directivas. Por otro lado, hay algunas diferencias, una de las cuales es que hay varias formas de crear referencias de servidor. Mientras que crear las referencias de cliente básicamente tiene solo una forma de ser creadas. Supongamos que ya hemos obtenido una referencia de servidor.

Usarla no es complicado. Podemos pasarla al servidor y el servidor puede identificar la función real a llamar. Lo que no es tan obvio aquí es cómo el cliente obtiene la referencia de servidor en primer lugar. A diferencia de una referencia de cliente, hay múltiples formas de crear una referencia de servidor. Y esta es la razón por la que soportar funciones de servidor es una tarea no trivial. ¿Qué queremos decir con múltiples formas de crear referencias de servidor? Por ejemplo, hay directivas de usuario de servidor de nivel superior y directivas de usuario de servidor en línea. Además, hay diferentes formas de pasar referencias de servidor. En el resto de esta charla, discutiré algunos casos típicos y cómo un framework transforma el código del usuario para diferentes situaciones. Este es el primer caso, y creo que es el más simple. En la parte superior, el archivo de función de servidor contiene una directiva de usuario de servidor de nivel superior. Y este archivo expone una función llamada greet. En la parte inferior, el archivo de componente de servidor importa el archivo de función de servidor y pasa la función greet a un componente cliente. Si estás familiarizado con las funciones de servidor, esto debería parecer bastante sencillo. Pero, ¿cómo funciona realmente? ¿Cómo se transforma el archivo de función de servidor? Veamos cómo un framework transforma este código de usuario. Este es el mismo código que acabamos de ver. En primer lugar, ya no necesitamos la directiva, ya que su propósito es decirle al framework que el código necesita ser transformado.

Ahora que lo estamos transformando, la directiva puede ser eliminada. Importamos la función register server reference. Es proporcionada por React, pero de qué biblioteca importar depende del framework. Así que en este fragmento, lo envolvemos como punto, punto, punto.

Ahora veamos cómo usamos esta función. Como puedes ver, simplemente llamamos a esta función al final. Esto registrará una referencia de servidor para la función greet. Echa un vistazo a los dos parámetros de cadena pasados a register server reference. Como aprendimos con las referencias de cliente, esos son para identificar la función registrada. En este caso, son la ruta del archivo y el nombre de la función. Pero como dije, técnicamente pueden ser cualquier cosa.

Esta lógica de transformación es bastante simple y de hecho es proporcionada por una de las bibliotecas de React. Así que soportar este patrón es bastante fácil. Desearía que este fuera el único patrón que necesitamos soportar, pero no lo es. Aprendamos algunos otros casos.

El segundo caso es cuando tienes la directiva inline use server en el componente del servidor. Veamos el código. En el ejemplo anterior, la función greet se importó de un archivo separado. Pero aquí, es un directorio de función inline en el JSX. Veamos la directiva use server, que desencadena la transformación. Primero, importamos register server reference como antes. Segundo, tenemos que elevar la función inline al nivel del módulo. Tercero, registramos la referencia del servidor, agregando los dos parámetros de cadena como identificador. Finalmente, la función debe ser exportada desde el módulo porque necesita ser invocable cuando el servidor recibe la solicitud. ¿Me sigues? Pasemos al siguiente caso.

En este ejemplo, tenemos una variable dentro del componente. Para simplificar, es solo un número aleatorio. Este número aleatorio se usa tanto en la cadena JSX como en la función greet. La función greet tiene una directiva use server, lo que significa que es una función de servidor que necesita ser transformada. La parte complicada aquí es que cada vez que el componente de la aplicación se renderiza, se genera un nuevo número aleatorio. De todos modos, veamos cómo va. Como siempre, comenzamos importando register server reference. Al igual que en el ejemplo anterior, elevamos la función inline a la parte superior. Pero ahora, la variable de cierre, rand, ha desaparecido. Entonces, ¿qué deberíamos hacer? Como puedes ver, podemos usar el método bind para adjuntar tales variables, y la función del servidor las recibirá como argumentos. Una nota aquí es que no estoy completamente seguro de este enfoque, pero por ahora, así es como está funcionando. Pasando a otro caso de uso.

Así que aquí hay un nuevo caso de uso. Tenemos dos archivos. Uno es una función de servidor con una directiva use server, y el otro es un componente cliente con una directiva use client. En este caso, el archivo cliente importa directamente el archivo del servidor. Esto podría parecer sencillo desde la perspectiva del usuario, pero en realidad es bastante complicado. Veamos cómo se transforma esto. Este es un archivo de servidor, que está siendo importado desde un archivo cliente. En la primera línea, importamos create server reference de una biblioteca de React.

Te das cuenta de que es diferente de register server reference que hemos estado usando. Esta es una versión del lado del cliente. En la segunda línea, importamos call server RSC, que es una función específica del framework para trabajar con last client en este caso. Reemplazamos completamente la función en la llamada create server reference. El primer argumento es un identificador de cadena, y el segundo argumento es la función del framework. Como puedes ver, esto requiere una integración más estrecha con el framework.

Ya hemos visto muchos casos, pero hay uno más que me gustaría mostrarte. Este ejemplo es un poco diferente de los anteriores. Así que, de hecho, cualquier función puede tener una directiva inline use server. En este caso, es una función dentro de un objeto, que luego se exporta. Veamos cómo se transforma esto. Primero, importamos register server reference. Y está hecho. La función se eleva y se exporta con register server reference. Y en el objeto original, la función se reemplaza con la exportada. Para que esto funcione, necesitamos revisar todos los objetos exportados profundamente hasta que encontremos directivas inline use server. Una vez encontradas, el resto es igual que antes. Pero esto parece una tarea muy costosa. Me pregunto si podemos optimizar esto de alguna manera.

Veremos. Muy bien. Hemos cubierto varios casos. ¿Alguno de ellos llamó tu atención? Aquí hay una lista de casos que hemos cubierto. ¿Recuerdas que hay cinco casos diferentes? Espero que esto cubra lo suficiente, pero la lista puede crecer. Y puede haber algunos casos que requieran más trabajo. El objetivo de esta charla era mostrar que, aunque no es trivial para un framework habilitar funciones de servidor, ciertamente es posible. Este es el mismo diagrama que mostré antes. El trabajo del framework es transformar el código del usuario para diferentes entornos de ejecución, como el cliente o el servidor. Así es como un framework RST habilita componentes de servidor y funciones de servidor.

Esto es lo que quería compartir en esta charla. Espero que te resulte esclarecedor. Nuestro framework, Waku, implementa todo lo que he hablado hoy. Apoyar la función del servidor es una tarea desafiante, pero lo hemos logrado. Y Waku ahora las soporta. Si estás interesado, no dudes en revisarlo en waku.gg.

Y con eso, esto termina mi charla. Soy Daishikato. Puedes encontrar enlaces para contactarme en daishikato.com. Gracias por escuchar y ver. No dudes en contactarme para más discusión. ¡Nos vemos!

Gracias por tu charla. Daishikato, has sido una persona muy ocupada manteniendo todas estas bibliotecas. ¿Puedes contarnos un poco sobre cómo, después de haber trabajado en tantas cosas, pensaste, Necesito Waku ahora, y qué estabas tratando de lograr? Sí. Gracias a algunos colaboradores, las tres bibliotecas de gestión de estado están bastante bien mantenidas. Y básicamente, está como terminado, así que solo necesito mantener algunas cosas. Así que fue un buen comienzo para iniciar un nuevo proyecto, Waku, que es un framework de React. Pero no sabía que sería tan difícil cuando comencé. Sí, es bastante desafiante. Mira, no lo hacemos porque sea fácil. Lo hacemos porque pensamos que sería fácil. ¿Verdad?

Sí. Así que pasemos a las preguntas de la audiencia. ¿Crees que apoyar el uso del servidor de tantas maneras diferentes fue una buena decisión de React en términos de complejidad de implementación versus valor para el usuario? Buena pregunta. No estoy seguro de si soy la persona adecuada para responder esto, porque está diseñado por React. Pero mientras esté claramente especificado con un estándar, creo que es un buen movimiento porque obviamente es bueno para la experiencia del desarrollador. Así que, sí, básicamente, estoy de acuerdo con esta decisión. Justo. Los componentes del servidor de React añaden mucha complejidad y muchas abstracciones. ¿Crees que el intercambio vale la pena? Claro.

Y tenemos una discusión más tarde, ¿verdad? Sí. ¿Y por qué no estamos usando suficiente suspense? Ya respondimos a esa.

Como consumidor de Waku, ¿todo lo que necesito preocuparme es dónde pongo mis directivas de cliente usado y servidor usado? Sí, eso es cierto. Pero depende de la pregunta. Requiere tener un buen modelo mental para diseñar qué deberían ser componentes del servidor, qué deberían ser del cliente. Así que no es solo agregar directivas, sino que tiene que estar bien diseñado.

Sí. Mark. Gracias, Mark. Mark preguntó, ¿cuánto tiempo, esfuerzo, prueba y error tomó determinar esos cinco casos de los que hablaste? ¿Hubo alguna documentación de React que ayudara o fue todo experimentos? Sí, esa es una buena pregunta porque no hay documentos. Así que aprendí a través del comportamiento y algunos de mis colegas me ayudaron. Y de hecho, tomó más tiempo antes de trabajar en esto porque no sabía nada sobre los componentes del servidor de React. Y toma más tiempo que esta capacidad de función del servidor.

¿Sientes que lo tienes ahora? Sí. Eres un experto. Si tienes alguna pregunta sobre componentes del servidor, este es tu chico. Esta es interesante. ¿Sientes que Waku es un proyecto a largo plazo para ti? Sí, va a ser un proyecto a largo plazo. Lo escuchaste aquí primero. Estará por aquí, así que échale un vistazo.

Voy a comprobar eso. ¿Waku se construye sobre alguno de tus otros proyectos o está inspirado por ellos? No está construido sobre mi otro proyecto. Y está basado en Vite y Hono. Pero la idea es bastante cercana a mi otro proyecto, Jotai. Porque intenta ser minimalista y proporciona algunos bloques de construcción. Así que tomé la idea porque pensé que era exitosa. Así que lo aprendí de eso.

¿Cómo, de alguna manera, obtienes retroalimentación o tienes probadores beta que te ayudan a probar la API? De hecho, necesito más probadores beta. Había cientos de desarrolladores aquí que podrían revisarlo. Nos estamos quedando sin tiempo, pero ¿puedes recordar a todos dónde encontrarte en internet y Waku? Sí, tengo un sitio de contacto que se mostró en el sitio web. Quiero decir, la diapositiva, es daishikato.com. Puedes encontrar todos esos enlaces para contactarme. Gracias por tu tiempo y gracias por tu charla. Aplausos de nuevo. Gracias.