Vanilla Server Components

Hola a todos, soy Krasnzony de Bulgaria, y voy a hablar sobre los componentes de servidor vanilla. La motivación detrás de esta presentación fue otra conferencia que ocurrió a principios de este año, React Summit. Estuve allí, y tuve esta charla con un par de personas de Verceo, de Meta, sobre los componentes de servidor. Mi pregunta principal era cómo usar estos componentes fuera del mundo de un framework. La respuesta fue básicamente, y mi conclusión, fue básicamente que es realmente, realmente difícil. Así que decidí explorar esta área, estas ideas, y de ahí viene esta presentación.

En mi cabeza, el ecosistema en React está dividido en tres casos de uso diferentes. El primero es la antigua forma de construir aplicaciones de una sola página, donde tenemos el compilador, que es algún tipo de herramienta de construcción como Webpack o Vite o algo más, Babel. Tenemos esta canalización donde construimos el paquete, lo lanzamos a un CDN y lo preparamos desde allí. Si no hay renderizado del lado del servidor, es solo una aplicación de una sola página que se ejecuta en el navegador. Luego está este otro grupo de aplicaciones donde controlamos el compilador, lo que significa que elegimos lo que queremos usar. Pero tenemos nuestro propio servidor HTTP, que está entregando el HTML principal, que tal vez esté entregando los activos y todo. En este caso, sí tenemos un renderizado del lado del servidor, lo que significa que podríamos realmente renderizar React en el servidor y manejar esto por nuestra cuenta.

Y la tercera opción es básicamente depender de un framework, lo que inmediatamente elimina la pregunta sobre elegir un compilador, cómo funciona todo, básicamente está oculto allí. Así que no tenemos que pensar en esto, simplemente funciona desde el primer momento. El mundo en el que vivo desde hace mucho tiempo es básicamente este grupo intermedio, que es donde controlamos el compilador, Vite o Webpack. Controlamos el servidor HTTP, usualmente Express, y hacemos todo nosotros mismos. Así que esta es el área que en el trabajo, estoy usando en mis proyectos personales. Y creo que desde el punto de vista de un desarrollador, es bastante interesante porque tenemos la opción de explorar cosas. Pero en el contexto de esta presentación, esto es de lo que voy a hablar, hacer que varios componentes funcionen dentro de este tipo de configuración.

Entonces, digamos que tenemos un servidor HTTP realmente simple sin React en absoluto. Este es un servidor ExpressJS. Pedimos desde el navegador, oye, dame una página. Luego respondemos solo con HTML simple. Tenemos los estilos, el bundle, y eso es todo. Entonces este era el caso donde todo es estático. No tenemos que obtener nada, es solo HTML devuelto. Pero entonces, ¿qué pasa si tenemos que obtener algunos datos? En este ejemplo, me basaré en el caso típico donde tenemos un blog. Básicamente, necesitamos obtener la publicación del blog en los comentarios para cada publicación del blog. Así que tenemos que hacer algo de trabajo, que es asincrónico. Tenemos que ir a la base de datos, obtener algunos datos, renderizar los datos, y así sucesivamente.

Entonces, lo que sucede en el manejador del servidor HTTP es que esperamos, básicamente. Esperamos obtener las publicaciones, luego el servidor está haciendo su trabajo, yendo a la base de datos, obteniendo las publicaciones. Esperamos obtener los comentarios. Ensamblamos algún tipo de respuesta, lo que significa que combinamos las publicaciones y los comentarios. Y luego devolvemos todo de una vez. Y luego la conexión TCP se cierra, y eso es todo. El problema con esto es que la experiencia del usuario es mala. Y este es básicamente el desafío que teníamos con las aplicaciones de React, que estaban en el cliente siempre. Así que el usuario no ve nada hasta que obtenemos todos los datos y renderizamos todo. Así que desde el punto de vista del producto, podríamos decir, está bien, no nos importan mucho los comentarios, así que vamos a renderizar el shell, básicamente el HTML básico de la página, todo el diseño y cosas, y renderizar las publicaciones, las publicaciones del blog, y luego obtener los comentarios en el cliente.

Así que esta es una de las opciones. La mejor opción, sin embargo, es enviar el shell, mostrar un spinner, por ejemplo, cargando, luego obtenemos las publicaciones, y luego obtenemos los comentarios. Y esta es la idea de todo este ejercicio. Queremos proporcionar una mejor experiencia al usar React. Así que ahora la respuesta a esto es en realidad HTTP streaming. Y cuando comencé a explorar los componentes del servidor, esto fue básicamente lo primero que me di cuenta, es que esto no es algo nuevo. Está ahí desde la versión 1.1 del protocolo HTTP. Así que es realmente antiguo.

Es una técnica de patrón realmente antigua para enviar datos desde el servidor al navegador. Pero cómo funciona esto. Así que si volvemos a nuestro servidor HTTP, tenemos lo mismo. Simplemente ejecutamos el servidor. Pero lo primero que sucede cuando pedimos una página es que devolvemos el tipo de contenido tipo, texto HTML. Aquí está el segundo encabezado, que es lo más importante en toda esta historia. Creo que cuando estaba aprendiendo y básicamente haciendo ingeniería inversa de cómo funciona el componente del servidor, este fue el punto clave, en realidad. Está abriendo la puerta para que el servidor notifique al navegador, oye, hombre, te voy a enviar múltiples cosas. No es solo una. Así que decimos transfer encoding chunked, lo que significa que tengo muchas cosas que decir. Así que cuando te doy una respuesta, no cierres la conexión TCP. Solo espérame. Te diré cuando haya terminado.

Y mantengamos lo mismo sin React al obtener las publicaciones del blog, obteniendo los comentarios. Lo primero que devolvemos es solo el shell. Así que básicamente enviamos solo el HTML básico sin la publicación del blog, tal vez un spinner. Y luego, mientras tanto, comenzamos a obtener las publicaciones del blog. Y luego lo siguiente que obtenemos, que enviamos desde el servidor al navegador, es en realidad una etiqueta script. Y la idea detrás de esto es que el tipo de contenido de nuestro servidor, lo primero que enviamos de vuelta al cliente es HTML. Así que no podemos simplemente enviar las publicaciones del blog como JSON. Tenemos que enviar algún tipo de HTML. Y lo que podríamos hacer es enviar una etiqueta script, que contiene una llamada a función, lo que significa que hay dos puntos importantes aquí. El primero es que esta función debería existir en la página para poder aceptar lo que viene. Y la segunda cosa es que cuando obtenemos de vuelta las publicaciones del blog, deberían ser serializables, lo que significa que no podemos simplemente enviar una función o una promesa. Deberíamos poder convertir en cadena cualquier dato que tengamos y pasarlo de esa manera.

Por supuesto, hay formas de enviar una promesa en vivo desde un servidor al cliente, y es un concepto realmente interesante cómo se hace. Pero en general, esto es lo que tenemos que hacer. Mantenemos la conexión TCP abierta. Transmitimos de vuelta algo de HTML en forma de una etiqueta script y una llamada a función, y esto renderiza las publicaciones del blog. Y hacemos lo mismo para los comentarios.

Básicamente enviamos exactamente lo mismo, una etiqueta script con los comentarios. Y luego, al final, básicamente cerramos la conexión TCP.

Vamos a incluir React en toda la historia. Así que digamos que quiero renderizar una aplicación ahora. No es solo HTML, como un HTML estático. Quiero usar React ahora. Así que si empiezo con esto, básicamente estoy obteniendo las publicaciones del blog, obteniendo los comentarios de la misma manera, y luego estoy usando render to string. Esta es la API proporcionada por React durante mucho tiempo.

La cuestión es que esta es una API sincrónica, lo que significa que necesito tener los datos antes de eso, antes de llegar a este punto. Así que hago eso, y luego simplemente armo algo de HTML, lo enviaré de vuelta al navegador. Así que esto es genial, pero por supuesto, es la misma mala experiencia de usuario básicamente. ¿Qué pasa si incorporo todo el trabajo asincrónico? Básicamente digo, está bien, ahora sé que mis componentes de React podrían ser funciones async, lo que significa que el componente de React en el servidor podría ser una función async. Así que hago esto. Básicamente traigo la obtención de las publicaciones y la obtención de los comentarios dentro de mi componente.

Así que esto es bueno, pero en realidad no funciona porque render to string realmente no funciona con datos asincrónicos. Entonces, la forma de resolver esto es usar otra API llamada render to pipeable string. Y la forma en que esto se ve es así. Así que el punto realmente clave aquí es este, stream.pipe, y pasamos la respuesta del trabajo manual de Express.JS. Por supuesto, hay algunos detalles aquí sobre cómo funciona todo en términos de API. Proporcionamos el código de estado junto. Proporcionamos el punto de entrada, este bundle se importa en el HTML. Pero el punto clave aquí es que básicamente decimos con estas líneas, estamos diciendo, hey, React, comienza a renderizar este árbol, y cada vez que obtenemos algo de vuelta, simplemente canalízalo al navegador. Y todo esto, esta API, está usando el tipo de contenido chunked y enviando diferentes fragmentos al navegador usando esta API.

Cómo se ve esto desde el punto de vista de un componente, es una API realmente natural. Simplemente dejamos caer la función async await, y hacemos todo como si nada realmente pasara. Sin embargo, detrás de escena, no es exactamente así. Tenemos que usar esta función de canalización de renderizado de un stream para que esto funcione. De lo contrario, las funciones async no funcionan realmente bien. Así que si volvemos a la experiencia del usuario, sin embargo, si simplemente hacemos esto, como un async y luego hacemos await de cosas dentro, tenemos la misma mala UX. Lo que queremos es mejorar eso, nuevamente, haciendo la misma experiencia donde enviamos el shell, obtenemos la publicación del blog, y luego obtenemos el comentario. Y la forma en que esto funciona es que deberíamos usar el componente de suspense y usar una función que no es realmente un hook, es una función. Es, creo, una API realmente emocionante que viene con React. Se usa para diferentes cosas, pero en el contexto de esta presentación, use aceptará una promesa. Entonces, lo que sucederá ahora es que tan pronto como pregunte sobre una página, y hay un límite de suspense si hay un componente dentro de este árbol, este sub-árbol, que está bajo el límite de suspense, y si hay una función use que acepta una promesa, React básicamente está esperando. Está esperando que esta promesa se resuelva y luego revela lo que sea que esté dentro del suspense. Así que dentro del componente post, tengo esta función getPost, que básicamente está devolviendo una promesa. Este cinco es solo un retraso, así que simulo correctamente. Pero lo importante aquí es que no tenemos await aquí. Simplemente pasamos la promesa tal como está. Y suspense sabe que hay un componente dentro que está usando use y hay una promesa. Así que básicamente espera. Así que si vuelves a todo esto y preguntamos sobre nuestra página, entonces lo que sucede es que enviamos primero un shell y mostramos un spinner. Este es el fallback del suspense, básicamente. Y luego, mientras tanto, las publicaciones del blog se están obteniendo por esta función getPost.

Y luego, cuando esto está hecho, enviamos la publicación del blog. El límite de suspense está básicamente abierto ahora. Y luego cargamos los comentarios, y tenemos un fallback del suspense aquí en las publicaciones. Cargamos los comentarios. Hacemos lo mismo. Y sí, básicamente tenemos la misma experiencia usando React. Sin embargo, tenemos que usar el límite de suspense y usar callback. Y esto está básicamente hecho ahora.

Antes de avanzar, quiero mostrarte rápidamente aquí cómo todo realmente se hace. Y puedes verlo muy fácilmente. Si actualizo la página ahora y vuelvo a la respuesta, como una respuesta en bruto de la página, verás que al principio, solo tengo esto. Así que esto es básicamente el shell que viene del renderizado de React. Y ves que después de un tiempo, obtengo un montón de otras cosas, que son básicamente un diff que está oculto conteniendo todos mis datos. Así que si colapso todo ahora, verás que este diff con los datos tiene algún ID. Luego hay algo de JavaScript enviado desde el servidor al cliente. Este no es JavaScript que yo escribí. Este es JavaScript que es enviado por React. Y lo que esto está haciendo es básicamente reemplazar un marcador de posición, la plantilla con el contenido de otro diff que está oculto. Y ves que no es tan mágico, realmente. Es solo una combinación de HTTP streaming, un poco de reemplazo inteligente porque aquí tenemos un comando y no es realmente solo eliminar esto y colocar otro diff o algo.

Hay algo de complejidad en cómo esto se reemplaza realmente. Pero así es como funcionan los componentes del servidor. El servidor está transmitiendo estos diffs ocultos con todo el marcado y tenemos esta función que es realmente pequeña y está reemplazando algo de HTML, que ya viste en el DOM. Por supuesto, después de eso, debe haber algún renderizado en el cliente. Hasta ahora, vimos renderizado del lado del servidor completamente estático, es decir, sin React. Solo enviamos HTML. Vemos renderizado dinámico del lado del servidor, donde tenemos un componente async de renderizado y luego esperamos al principio por las publicaciones y los comentarios. Y luego tenemos una buena experiencia de usuario usando suspense y use. Pero todo esto es solo en el servidor. No tenemos nada en el cliente, lo que significa que si quiero algo ligeramente diferente en el cliente, como algo de interactividad, como un botón que necesita ser clicado o algo, esto no está hecho aún.

Ahora solo tenemos cosas renderizadas del lado del servidor. Entonces, ¿qué pasa con el cliente? Y aquí es donde viene la magia del componente del servidor. Digamos que tengo este componente de comentarios, que ya vimos, pero luego dentro tengo este use state, que muestra los comentarios solo cuando el usuario quiere verlos. Así que, es importante decir aquí que aunque se supone que esto es un componente del cliente, es completamente renderizable en el servidor, lo que significa que el servidor no va a exportar o nada si es este use state. Esta función se ejecuta solo una vez en el servidor, y siempre será falsa, lo que significa que el estado visible, y siempre habrá solo el botón.

Aunque los datos están ahí, lo que llegará al cliente, el navegador, es en realidad solo este botón. Así que, si avanzamos y si tenemos que enviar esto al cliente, tenemos que decir que no puedo realmente llamar a esta función get comments by post ID cada vez, porque cuando este estado cambia aquí, esta función se ejecutará múltiples veces, lo que significa que se creará la misma promesa múltiples veces. Así que, necesita haber un caché de la promesa, y se está volviendo realmente complicado. Así que, digamos que es una buena práctica que enviemos la promesa como una prop a los comentarios, lo que significa que queremos enviar la misma promesa cada vez al componente de comentarios. Por supuesto, tenemos que usar client. Esto es para instruir al empaquetador, básicamente para saber que esto va al cliente. Necesita ser incorporado en el paquete, porque si estamos tan, tan lejos, no tenemos un paquete en absoluto.

Todo está solo en el servidor, y no hay empaquetado. Así que, cuando estaba pasando por todo este viaje, me di cuenta de que la cadena de herramientas, en mi caso, es que tengo la carpeta de origen. Tengo un compilador que básicamente traduce mi TypeScript a JavaScript válido, y basado en eso, también está creando un paquete. Fuera de esta carpeta, estoy ejecutando mi servidor Node, y ahora cuando tengo el paquete, estoy enviando este paquete al navegador. Así es básicamente cómo se ve mi cadena de herramientas. Si uso un framework, no es nada así. Todo es realmente corto porque solo tengo mis archivos TypeScript, y luego ejecuto el servidor. Pero, ¿qué me pasa ahora? Bueno, estoy pensando en cómo implementar eso, cómo hacer que todo esto funcione.

Sé sobre HTTP streaming, sé cómo funciona suspense, así que probablemente tenga que implementar lo mismo para empezar a soportar los componentes del servidor en mi caso. Así que durante un tiempo, estuve pensando, tal vez un mes y algo, estuve tratando de construir un plugin de VIT para hacerlo. Sé que hay uno, pero quería hacerlo yo mismo, y fue realmente difícil. Y tuve que conocer tantos detalles sobre VIT, sobre cómo funciona todo, que empecé a pensar, tal vez ese es un enfoque equivocado.

Así que se me ocurrió la idea de básicamente importar esta magia antes incluso de llegar a los compiladores. Y decidí escribir una pequeña herramienta, que está obteniendo mis archivos TypeScript en bruto y preparándolos para el cliente, lo que significa que básicamente está eliminando todo lo que está en el servidor, y solo está obteniendo las cosas que se van a enviar al navegador en una carpeta, y luego haciendo lo mismo para el servidor. Y mientras hago esto, tengo la oportunidad de modificar los archivos, para básicamente implementar la lógica sobre cómo ejecutar componentes del servidor en el cliente, los límites del cliente y todo. Así que fue mucho más fácil y mucho más divertido, diría yo.

Y luego usé el compilador. Y esta biblioteca se llama ForkIt si quieres probarla. Esta es la URL, no voy a hablar de ello. Pero así es como funciona. Está soportando tal vez el 80% de todo lo que hay sobre componentes del servidor. Hay algunos casos extremos que son realmente difíciles de implementar, así que no los hice. Así que terminaré con dos cosas. La primera es que la mentalidad cuando trabajamos con componentes del servidor es ligeramente diferente.

Hasta ahora, pensábamos en React como algo que se ejecuta en el cliente, principalmente, más o menos. Y tenemos este dev que está lleno de todos nuestros componentes. Bueno, ahora está realmente orientado al servidor, lo que significa que todo está en el servidor y todo es un componente del servidor. Y ocasionalmente, solo un par de cosas son los llamados componentes cliente de Iowans. Y golpeamos la tasa en una porción realmente específica de las páginas. Así que esto es algo realmente importante cuando comenzamos a trabajar con componentes del servidor, la mentalidad ha cambiado.

Y la última cosa que quiero decir hoy es que hay problemas con los componentes del servidor. No son ideales. El modelo mental es diferente, así que tienes que estar preparado para eso. Tienes que pensar en la experiencia del desarrollador en tu equipo, en tu empresa. ¿Quieres esto? ¿Lo necesitas? Hay cierta complejidad de construcción, por supuesto. Necesita haber una cadena de herramientas. Probablemente tengas que cambiar tu conjunto de herramientas sobre cómo funciona todo. Y hay cosas que no están tan bien diseñadas, diría yo.

La validación personalizada, qué pasa si necesitas cookies o autorización y encabezados. Y tienes estos componentes cliente que se comunican con componentes del servidor, usando acciones del servidor. ¿Y qué pasa si necesito pasar un encabezado, un encabezado adicional allí? ¿Dónde? ¿Cómo? ¿Es seguro? Seguridad de tipos, restricciones de serialización, por supuesto, puedes serializar todo. Aunque en Next, por ejemplo, esto funciona de inmediato para la función de promesa. Bueno, función, depende. Pero sí. Y por supuesto, es difícil de probar. Si lo piensas, ¿cómo? Voy a probar el límite del cliente. Es complicado.