Video Summary and Transcription
Esta charla proporciona una visión general de los Componentes del Servidor de React. Explora la renderización del elemento raíz, utilizando react-read-in-a-tree para leer el manifiesto de webpack y realizar el trabajo y la serialización JSON. La charla también discute el controlador de drenaje y los componentes del lado del cliente, así como los desafíos y las mejoras futuras en los Componentes del Servidor de React.
1. Introduction to React Server Components
Hola y bienvenidos a mi sesión, React Server Components bajo el capó. He estado desarrollando web durante unos 20 años. Hoy hablaremos sobre los componentes del servidor de React y daré una breve introducción para empezar. Comenzaremos leyendo el RFC. El resumen es que hay componentes del lado del servidor, componentes solo del cliente y componentes híbridos. Vamos a abrir mi IDE y echar un vistazo a esto. Empezaremos mirando index.client.js. Creamos un elemento raíz utilizando create-root del modo concurrente experimental, y luego renderizamos el elemento en él.
Hola y bienvenidos a mi sesión, React Server Components bajo el capó. Mi nombre es Lee Rawlins y me pueden encontrar en la mayoría de los lugares de internet como le-rawlins. He estado desarrollando web durante unos 20 años. Estoy basado en Australia y hoy es un hermoso día de primavera aquí. Obviamente, esto está pregrabado. Durante la mayor parte de ese tiempo he estado trabajando con PHP, pero cada vez más he estado trabajando con JavaScript.
Durante el día, trabajo para una empresa llamada Previous Next y nos encargamos de algunos de los sitios web más grandes de Australia. Algunos de nuestros sitios tienen 80 millones de visitas al mes, por lo que estamos hablando de proyectos significativamente desafiantes. Si estás buscando algo interesante y estás en la zona horaria de Australia, estamos contratando, así que contáctanos en nuestra página de carreras.
Hoy hablaremos sobre los componentes del servidor de React y daré una breve introducción para empezar, pero esta es una conferencia avanzada, así que me adentraré en los detalles y espero continuar desde la sesión anterior a la mía. ¿Por dónde empezar con los componentes del servidor de React? Comenzaremos leyendo el RFC. Este documento detalla qué son los componentes del servidor, para qué se pueden utilizar, qué ventajas ofrecen y los problemas que intentan resolver. También hay un video explicativo del equipo de React. En resumen, hay componentes del lado del servidor que tienen acceso directo a la base de datos, microservicios, etc. Pero como resultado, no tienen acceso al estado o a los efectos. Es un inicio en frío cada vez, al igual que PHP. Luego están los componentes solo del cliente, que son simplemente lo que siempre hemos llamado componentes de React. Tienen todos los diferentes hooks de useState, etc. Pero no pueden tener hijos que sean componentes del servidor, lo cual tiene sentido. Y luego tenemos componentes híbridos que se pueden utilizar tanto en el cliente como en el servidor, y por supuesto tienen las limitaciones de ambos. No se puede utilizar estado, hooks ni nada, pero tampoco se puede utilizar la base de datos. Básicamente, son componentes puros que reciben props y devuelven resultados. Así que nos adentraremos en los detalles aquí. Cambiaré al IDE y comenzaremos a echar un vistazo a esto. Así que vamos a abrir mi IDE y lo pondré en modo de presentación para que puedan leerlo. Comenzaremos mirando index.client.js. Aquí comenzamos creando un elemento raíz, y esto utiliza create-root del modo concurrente experimental, que se implementará en React 18. El modo concurrente permite retrasar las actualizaciones en la pantalla hasta que estén listas. Si están interesados en conocer más sobre el modo concurrente, echen un vistazo a Cracking the Concurrent Mode de Sadanich Yadav más tarde esta tarde. Básicamente, creamos esta raíz y luego renderizamos el elemento en ella.
2. Rendering the Root Element
Estamos renderizando el elemento raíz con un envoltorio de suspense, un límite de error y un componente de contenido. El componente de contenido proporciona un proveedor de contexto para el estado global. Usamos useServerResponse para obtener una respuesta y renderizar el elemento raíz leído. useServerResponse utiliza la caché de suspense experimental para crear una solicitud mediante la serialización del estado de la aplicación a JSON. En el lado del servidor, al acceder al punto final de React, la ubicación se pasa de vuelta en un objeto JSON y se llama a react-read-in-a-tree con las props.
Entonces, el elemento que estamos renderizando es este elemento raíz, veamos eso. Tenemos un envoltorio de suspense alrededor de un límite de error alrededor de un componente de contenido. El propio componente de contenido tiene un proveedor de contexto que proporciona efectivamente un enrutador con un ID de selección, está editando y el texto de búsqueda, de hecho, básicamente el estado global. Estamos obteniendo una respuesta usando useServerResponse y estamos renderizando el elemento raíz leído en medio de eso.
Entonces, echemos un vistazo a useServerResponse. Esto utiliza una caché en memoria de otra API experimental de React, que es la caché de suspense experimental. Crea una solicitud mediante la serialización de los parámetros o el estado de la aplicación a JSON y pasándolo como una cadena de consulta. Así que carguemos la página y pongamos nuestro depurador y veamos qué está sucediendo en el lado del servidor cuando golpeamos ese punto final de React. Tengo la aplicación ejecutándose aquí y recargo. Y eso me lleva a un archivo llamado api.server.js, y básicamente es una aplicación express simple. Tiene algunos puntos finales en los que está escuchando, y el que nos interesa obviamente es slash React. Así que eso es solo el envoltorio delgado alrededor de send response, y send response, todo lo que hace es pasar esa ubicación que llega en la cadena de consulta de vuelta a un objeto JSON y llamar a react-read-in-a-tree con esas props.
3. Explorando react-read-in-a-tree
Vamos a adentrarnos en react-read-in-a-tree, que espera a que webpack termine de empaquetar y luego lee el manifiesto de webpack. La aplicación raíz, app.server.js, contiene una combinación de componentes del cliente y del servidor, así como componentes híbridos. El botón de edición establece el contexto o cambia la ubicación, y la lista de notas consulta la base de datos y muestra un componente de nota junto a cada entrada. En el árbol renderizado de React, el pop-to-node writable crea una solicitud a partir del modelo, empujando el segmento raíz a los segmentos. Start work intenta renderizar el segmento utilizando el despachador de React desde los internos compartidos de React.
Entonces, vamos a adentrarnos en react-read-in-a-tree. Lo primero que hace react-read-in-a-tree aquí es esperar a webpack, y lo que básicamente hace es asegurarse de que el empaquetado haya terminado, y una vez que haya terminado, puede leer de vuelta el manifiesto de webpack, y lo pasa a JSON y llama a pipe-to-node writeable con el elemento creado para la raíz de la aplicación.
Entonces, hagamos una pausa de nuevo, dejemos nuestro depurador en ejecución y veamos qué hace esta aplicación raíz. El componente en sí es app.server.js. Así que esto es efectivamente la estructura que está volviendo desde el servidor. Tenemos el elemento principal, tenemos una barra lateral con un logotipo y un título. Hay un botón de búsqueda y edición, y hay una lista de notas. Y luego, en el lado derecho, la parte principal de la página tiene una nota seleccionada que se puede editar. Las cosas a tener en cuenta aquí, y sin juego de palabras, esta es la aplicación de Notas, pero tenemos una combinación de componentes del cliente y del servidor aquí, así como algunos híbridos. La nota en sí es el componente del servidor, la lista de notas también es un componente del servidor, tenemos el botón de edición y el campo de búsqueda, que son componentes del cliente, y luego tenemos dos componentes híbridos que se han utilizado como alternativas para el contenedor de suspense, por lo que un esqueleto de la nota y un esqueleto de la lista.
Entonces, veamos ese botón de edición para empezar. Vamos a eso. Esto es solo un envoltorio delgado alrededor de básicamente establecer el contexto o cambiar la ubicación. Está utilizando, nuevamente, el modo experimental en modo actual para iniciar transiciones para que no veas una página de carga mientras se carga. Luego veamos la lista de notas. Así es donde el componente del lado del servidor está consultando la base de datos y luego, para cada uno, muestra un componente de nota junto a cada entrada, que también es un componente híbrido. Si retrocedemos al árbol renderizado de React, aquí, ahora veamos qué está haciendo. Tal vez solo ejecute el depurador hasta que lleguemos allí. Nuevamente, hay esta espera para webpack, este pop-to-node writable y veamos qué está haciendo. Eso proviene del módulo webpack del DOM del servidor de React. Lo primero que hace es, veamos pop-to-node writable, crea una solicitud a partir del modelo. Entonces, el modelo que se pasa aquí es el elemento de la aplicación, el destino es la respuesta y el mapa de webpack es el manifiesto actual pasado. Configura un controlador de drenaje, así que volveremos a eso, y llama a start work. Desempaquetemos primero create request. Básicamente es un objeto JavaScript plano con algunas matrices aquí para realizar un seguimiento de los fragmentos de módulo, los fragmentos de JSON y los fragmentos de error. Volveremos a esto más adelante, pero la pieza principal de trabajo que se está realizando aquí es que está empujando el segmento raíz a los segmentos, y si volvemos a ver qué es eso, en realidad es un segmento basado en el modelo, que es la raíz de la aplicación. Esto nos deja con start work. Si volvemos allí, ¿qué está haciendo start work? Bueno, está envuelto alrededor de este perform work, y el perform work básicamente obtiene el despachador de React y trata de renderizar ese segmento. Ahora, algo que me resulta interesante aquí es que si miramos de dónde proviene este despachador actual de React. Viene de los internos compartidos de React, y si miro el punto de interrupción allí, esto en realidad proviene de los internos secretos de React.
4. Explorando Perform Work y Serialización JSON
No lo uses o serás despedido. Echemos un vistazo a lo que estaba haciendo ese perform work. El segmento de reintento se encarga de resolver elementos del segmento anterior. Convierte el elemento de React en un formato de tupla. La representación serializada del árbol de elementos contiene una nomenclatura especial. La función resolve model to JSON convierte los elementos en un formato similar. El componente de lista de notas de la barra lateral renderiza varios componentes, incluido el componente de nota de la barra lateral del cliente. Las referencias a cinco en el JSON se reemplazan por elementos del lado del cliente. La función start flowing vacía los fragmentos completados.
No lo uses o serás despedido. Me pareció divertido. No sé qué dice eso sobre si eso va a cambiar en el futuro, pero sí, echemos un vistazo a lo que estaba haciendo ese perform work. Así que sí, es una referencia al segmento de reintento, que intenta renderizar ese elemento.
Así que si echamos un vistazo a esto, este segmento de reintento se encarga de resolver elementos que provienen del segmento anterior, y gran parte del trabajo se realiza en attempt resolve element. Y básicamente intenta traducir el elemento en una matriz que podemos serializar y enviar de vuelta como JSON. Puede manejar HTML, fragmentos, componentes del servidor, componentes del cliente, demos de React, pero el resultado final aquí es que convierte este elemento de React en una especie de tupla con el símbolo, el elemento, su clave y sus props. Y una vez que se ha reducido a este formato, se puede procesar como un fragmento de modelo por process model chunk.
Así que saltemos a eso. Básicamente, aquí se nos da el modelo y se convierte en una cadena y se serializa. Así que si dejo que el depurador se ejecute, podemos echar un vistazo al formato del contenido aquí. Así que vamos a abrir esto. Como podemos ver aquí, comienza con el tipo de elemento. Tenemos el nombre del elemento en sí y luego tenemos las props del elemento, y una de esas props es children, y luego se repite a sí mismo. Esta es efectivamente la representación serializada del árbol de elementos. Y tenemos una nomenclatura especial aquí que el cliente puede entender para determinar qué tipo de elemento estamos tratando aquí. Echemos un vistazo a cómo funciona esta función resolve model to JSON, que es la que genera este JSON. Básicamente, todo lo que ya se ha convertido en ese formato de tupla del que hablamos parece que se envía tal cual, pero todo lo demás se convierte en un formato similar. Parece que tiene protecciones alrededor de las cosas que no se pueden serializar en JSON, por lo que no puede serializar clases, solo puede serializar objetos JavaScript simples, no puede serializar funciones, controladores de eventos, todas las cosas que no tienen sentido representadas como una cadena. Si ejecutamos esto nuevamente hasta que lleguemos a donde se está renderizando la lista de la barra lateral, donde tenemos varios componentes, podemos ver aquí el UL. Esto está renderizando la lista de notas de la barra lateral, así que podríamos abrir ese componente de lista de notas y ver de qué está hecho.
Como vimos antes, tiene una nota de la barra lateral dentro, pero si echamos un vistazo a la nota de la barra lateral en sí, a su vez renderiza una nota de la barra lateral del cliente. Si echamos un vistazo a la nota de la barra lateral del cliente, podemos ver que tiene propiedades como ID, título, etc. Si volvemos a este JSON que se está generando, podemos ver aquí que hay muchas de estas referencias a cinco. Anteriormente, estábamos viendo un JSON en el que podíamos ver cosas como div, etc., cosas que podíamos racionalizar como elementos HTML. Pero ahora estamos viendo este at five y podemos ver las propiedades ID y título que coinciden con estas propiedades aquí, así como los hijos expandidos. Y estos marcadores de posición at five en el JSON que se envía de vuelta, y el cliente luego reemplazará estos espacios con los elementos del lado del cliente. Para concluir en el lado del servidor, lo único que queda es start flowing, que teníamos antes para el controlador de drenaje. Si vuelvo a eso. Este createDrainHandler aquí es un envoltorio alrededor de start flowing, y lo que hace start flowing es vaciar los fragmentos completados.
5. Explorando el Controlador de Drenaje y los Componentes del Lado del Cliente
El controlador de drenaje en el middleware de compresión vacía todos los fragmentos, incluyendo fragmentos de módulos, componentes del lado del cliente, fragmentos JSON y fragmentos de error. La función create-from-fetch en JavaScript del lado del cliente crea una respuesta y comienza a leer desde el flujo. Los fragmentos JSON se cargan primero, seguidos de los componentes del cliente. React carga perezosamente los fragmentos con el prefijo AT y crea elementos utilizando React create element.
Entonces, el controlador de drenaje es un evento que ocurre en el middleware de compresión, que está envuelto alrededor del servidor Express. Y cuando está listo para enviar, simplemente vacía todos los fragmentos, y eso pasa a través y emite primero los fragmentos de módulo. Así que esos son cada uno de los componentes del lado del cliente, y cualquier componente nuevo de Webpack que necesite cargarse, los fragmentos JSON que vimos antes, y también cualquier fragmento de error si algo salió mal.
Así que hagamos una pausa y reiniciemos el servidor sin debug. Y mientras se reinicia, echemos otro vistazo a los componentes del lado del cliente. Así que retrocedamos hasta esa caché del cliente, y veamos esta nueva respuesta del servidor. Ahora que está en funcionamiento, lo minimizaré y veamos este create-from-fetch. Así que ahora estamos en el JavaScript del lado del cliente. create-from-fetch tiene dos funciones aquí. Crea una respuesta y comienza a leer desde el flujo. Veamos primero create-response. Y no sorprendentemente, está creando algo para devolver ese JSON, y el meollo de esto parece estar aquí con esta cadena de modelo de paso y esta tupla de modelo de paso.
Así que vayamos al navegador y pongamos un punto de interrupción en esos métodos. Voy a abrir esto en mi depurador y hago clic en cargar. Tengo algunos puntos de interrupción predefinidos aquí, y voy a recargar la aplicación. Podemos ver que tenemos un paso de JSON que llega aquí, y lo primero que llega de esos fragmentos son los componentes, los componentes del lado del cliente. Esto tiene los nombres de los fragmentos de Webpack aquí también, para que podamos cargar esas importaciones. Sigamos adelante. Así que ese fue el botón de búsqueda del cliente, ahora tenemos el botón de edición del cliente. Tengo el componente del cliente SOAD BAR NOTE. Y luego llegamos a nuestro JSON real que enviamos de vuelta por el cable. Podemos ver aquí de nuevo que tenemos estas referencias a AT5, y básicamente lo que sucederá es que terminaremos en aquellos que tienen el prefijo AT. React se encarga de cargar perezosamente esos fragmentos e inyectarlos de nuevo. Y luego, para las tuplas, si echamos un vistazo a esta aquí, tenemos el símbolo que era el elemento React, el elemento en sí es p, y luego tenemos las propiedades del elemento. Así que para cada uno de esos elementos en el JSON, se llama a React create element, y se crean elementos y se colocan donde deben estar. Así que detengamos eso y volvamos a mis diapositivas.
Entonces, supongo que la pregunta después de ver esto es, ¿qué sigue? Y, bueno, ¿cuándo estará listo para producción? Y el mejor lugar para responder eso es ver las áreas abiertas de investigación en el RFC. Y no es una lista corta. Sabes, una de las cosas que probablemente notaste antes es que la aplicación Express pasaba un parámetro de ubicación codificado. Así que hay trabajo por hacer para hacerlo genérico, y eso está identificado en su lista, lo tienen listado como enrutamiento.
6. Desafíos y Mejoras Futuras
Están trabajando en resolver el problema del punto final codificado de manera rígida, enfocándose primero en los frameworks. Mejorar las herramientas de desarrollo, especialmente para identificar los componentes renderizados en el front-end y back-end, es una prioridad. La espera de Webpack en el proceso de empaquetado necesita mejoras. Volver a renderizar toda la aplicación para cada solicitud del servidor es un desafío que se resolverá.
Entonces, ese punto final codificado de manera rígida es algo que esperan resolver encontrando soluciones para los frameworks primero, y luego las lecciones aprendidas en esos frameworks pueden ser cosas que se apliquen de manera más general. También quieren hacer un trabajo para mejorar las herramientas de desarrollo. Ya sabes, React en el navegador tiene una excelente extensión para ayudarte a debuggear lo que está sucediendo. Pero cuando tienes algunos componentes que se renderizan en el front-end y algunos componentes que se renderizan en el back-end, saber identificar eso en el árbol será crítico.
Empaquetado. La espera por el Webpack se siente un poco incómoda. Básicamente, está esperando hasta que pueda ver que index.js se ha escrito en el disco, y luego sabe que Webpack ha terminado, y luego sabe que puede leer ese JSON. Así que parece que hay un poco de trabajo por hacer allí. Y luego la paginación y los parciales. Una cosa que probablemente hayas notado es que estamos enviando el contexto global de vuelta a la aplicación, lo que significa que estamos volviendo a renderizar toda la aplicación cada vez que una solicitud regresa al servidor. Obviamente, esto es menos que ideal. Así que creo que eso es una de las cosas que se resolverán.
Así que sí, espero que hayas disfrutado eso. Gracias por quedarte hasta el final. Fue un tema realmente interesante para aprender, y disfruté ensuciándome las manos con el depurador. Si tienes alguna pregunta, no dudes en contactarme. Como dije, mi nombre de usuario es L.A. Rowland. Estaré en el Discord de GitNation. También estoy en Jamstack Slack, y puedes contactarme en Twitter si es necesario. Una vez más, gracias.
Comments