Los Componentes del Servidor son posiblemente el cambio más grande en React desde su lanzamiento inicial, pero muchos de nosotros en la comunidad hemos tenido dificultades para entenderlos. En esta charla intentaremos desglosar las diferentes partes móviles para que tengas una buena comprensión de lo que está sucediendo bajo el capó, y exploraremos la línea entre React y los marcos que se construyen sobre él.
This talk has been presented at React Advanced Conference 2023, check out the latest edition of this React Conference.
FAQ
Le tomó a Mark Dalglish 21 horas de vuelo llegar desde Melbourne, Australia hasta Londres.
Mark Dalglish empezó a trabajar con React debido a sus capacidades de renderización del lado del servidor, lo que le pareció fundamentalmente diferente a todo lo que había usado antes.
Según Mark Dalglish, JSX son llamadas a funciones, una forma de describir los elementos que se quieren renderizar en la pantalla mediante el uso de sintaxis de JavaScript.
El servidor RSC tiene como única función renderizar componentes de servidor y pasarlos al servidor SSR o al cliente para actualizaciones en vivo. Utiliza una corriente de nodos para obtener una corriente RSC que luego se envía al consumidor.
Los componentes del servidor permiten enviar DOM virtual serializado a través de la red, lo que permite una interactividad dinámica sin requerir que el código se ejecute nuevamente en el cliente, optimizando así la carga y ejecución en los dispositivos del usuario.
Trabajar con componentes de servidor en marcos como Next.js implica aprender sobre el uso de componentes de servidor y las opiniones adicionales que los marcos de trabajo proporcionan, lo que puede complicar la implementación directa en React.
Los componentes del servidor de React simplifican la renderización del lado del servidor y proporcionan un modelo mental de componentes como funciones puras. Usar React como una biblioteca para componentes de servidor permite construir un servidor RSC básico y conectarlo a un servidor SSR. Las respuestas RSC son DOM virtual serializado que descarga el código del cliente y maneja la interactividad. El manifiesto del cliente mapea los marcadores de posición serializados a componentes reales en el cliente, permitiendo la renderización dinámica. Los componentes del servidor combinan lo mejor del desarrollo web clásico y la mejora progresiva, ofreciendo la ventaja de mover la lógica del cliente al servidor.
1. Introducción a los Componentes de Servidor de React
Short description:
Mi nombre es Mark Dalglish, y estoy aquí desde Melbourne, Australia. He estado trabajando en el espacio de React durante una década, con un enfoque en la renderización del lado del servidor y la mejora progresiva. Actualmente, estoy trabajando en el equipo de Remix en Shopify. Los componentes de servidor de React han despertado mi interés, pero inicialmente parecían intimidantes. Sin embargo, siempre he tenido un modelo mental simple de cómo funciona React, con componentes siendo funciones puras que describen lo que debería estar en la pantalla. JSX son solo llamadas a funciones. Al principio, era extraño devolver elementos HTML desde funciones de JavaScript.
Entonces, como escucharon, mi nombre es Mark Dalglish, y estoy aquí desde Melbourne, Australia, lo que significa que me tomó 21 horas de vuelo llegar aquí. Así que, muchas gracias por recibirme. Es un placer estar aquí en Londres. Ahora, he estado trabajando en el espacio de React, ¿puedes creerlo?, durante una década en este punto. Solo me di cuenta cuando estaba preparándome para esta charla. Ahora, algunos de ustedes, como escucharon, pueden estar familiarizados con mi trabajo en React en términos de espacio de design system, CSS modules, vanilla, Extract, design systems, pero volviendo a por qué empecé en React en primer lugar, fueron realmente sus capacidades de renderización del lado del servidor las que me convencieron de que React era fundamentalmente diferente a todo lo que había usado antes, no solo en el espacio de JavaScript, sino en el desarrollo web en general. Y para mí, la parte realmente emocionante fue que finalmente pude cerrar la brecha entre lo que estábamos tratando de hacer con la rica interactividad del lado del cliente en JavaScript, mientras también manteníamos la mejora progresiva que hasta ese punto, hasta el impulso por JavaScript en el cliente, la mejora progresiva había sido durante mucho tiempo un valor en el espacio web, y ahora React me permitió obtener lo mejor de ambos mundos y resolver algunos problemas muy reales que tenía en el trabajo en ese momento, tratando de tener una rica interactividad del lado del cliente, mientras también tenía esa primera carga de página performance, así como importante, soporte SEO para Google para nosotros en ese momento. Así que ese trabajo, ese antecedente para mí en la renderización del lado del servidor es lo que finalmente me llevó a mi trabajo a tiempo completo actual en el equipo de Remix en Shopify, trabajando muy duro para hacer realidad esa experiencia de mejora progresiva para todos ustedes. Así que es con, es en ese contexto que estoy seguro de que no es ninguna sorpresa para ustedes que estoy muy interesado en los React server components, porque es un gran cambio en términos de cómo pensamos sobre React. Pero tengo que admitir que cuando miré por primera vez los componentes del servidor los encontré bastante intimidantes. No desde una perspectiva de API de alto nivel, sino más bien desde el sentido de que tenía menos idea de cómo se supone que debo pensar en la architecture de mi aplicación, ¿cuáles son las implicaciones en cómo pienso y construyo mis aplicaciones, ¿cómo funciona incluso, y especialmente si estoy en un contexto de marco, qué significa construir un marco sobre los componentes del servidor? Hay muchas preguntas abiertas, y personas que respetaba que sabían mucho sobre React también estaban luchando con esta pregunta. Para mí, esto estaba en marcado contraste con mi experiencia con React hasta ese punto, porque encontré que, en general, siempre pude tener un modelo mental muy simple de cómo funcionaba React. Por ejemplo, si tenía mi componente de aplicación con el que todos estamos acostumbrados a trabajar, podría renderizarlo en un elemento en la pantalla, pero igualmente, podría tomar ese mismo componente de aplicación, y podría renderizarlo en una cadena de HTML en el servidor. Esto es lo que me interesó en React en primer lugar. Y para mí, este modelo mental era agradable y simple. Cuando se trataba de renderizar un componente, por supuesto, al principio, la pregunta natural sería qué es un componente, dado que cada marco tiene una visión diferente de lo que ese tipo de concepto podría significar. Y lo que fue interesante en React es que la respuesta era agradable y simple, es que conceptualmente los componentes son básicamente funciones puras que simplemente describen lo que debería estar en la pantalla en ese momento dado. Entonces, en los primeros días de React, no teníamos componentes funcionales. Teníamos React.create class, y tendría un método de renderizado, entre otras propiedades en ese objeto. Y dentro de ese método, tendríamos acceso a this.props en la instancia del componente. Así que es una API muy diferente. Pero si te fijas, se sentía como trabajar con una función pura. Y así es como lo describí a las personas que eran nuevas en React. Y curiosamente, eso terminó siendo la API con la que tratamos hoy. Ahora literalmente son funciones. Y, por supuesto, nuestros componentes van a estar renderizando JSX y la pregunta entonces sería ¿qué es JSX? Para muchos de nosotros, especialmente en esos primeros días, fue una pregunta muy interesante con la que tuvimos que lidiar, pero la respuesta fue bastante simple. Es que JSX son solo llamadas a funciones. Esa es simplemente la forma en que tenías que pensar en ello. Entonces, cuando vimos código como este que, de nuevo, en los primeros días de React, para muchos de nosotros, era casi herético que estuviéramos devolviendo elementos HTML desde nuestras funciones de JavaScript.
2. Entendiendo los Componentes de Servidor
Short description:
Cuando se nos explicó que JSX son solo llamadas a funciones, se volvió sencillo. Sin embargo, la respuesta simple de que los componentes de servidor son componentes que solo se ejecutan en el servidor no es suficiente. Quiero simplificar los componentes de servidor y proporcionar un buen modelo mental de cómo funcionan más allá de las API de alto nivel.
Casi no tenía sentido para nosotros. Pero cuando se nos explicó que realmente es solo una azúcar sintáctica para escribir código como este donde simplemente estás llamando a una función, pasando algunos argumentos para describir qué elemento quieres, el tipo de elemento, las propiedades, los hijos, fue bastante sencillo. Así que ahora eso nos lleva a la última pregunta en React, que es ¿qué son los componentes de servidor? Parece una pregunta bastante sencilla. Y la respuesta simple a la que la gente tiende a llegar, he encontrado, es algo en la línea de esto donde dices que los componentes de servidor son componentes que solo se ejecutan en el servidor. Ahora, el problema que tengo con esto como respuesta, más allá del hecho de que básicamente es solo reorganizar las palabras de la pregunta, es que no me deja con un modelo mental de cómo funcionan, cuáles son las restricciones o compensaciones, qué significa eso para mi architecture, qué puedo hacer, qué no puedo hacer con ellos, cómo los uso a nivel de API desde React? Así que tenía muy poco para trabajar aquí. Así que el objetivo aquí para mi charla es ayudar a hacerles a ustedes lo que tuve que trabajar para lograr, que es simplificar los componentes de servidor. Esperemos que no los simplifique demasiado, pero los simplifique lo suficiente para que tengan un buen modelo mental de cómo funcionan más allá de las API de alto nivel
3. Usando React como una Biblioteca para Componentes de Servidor
Short description:
React puede verse tanto como una biblioteca como un marco de trabajo, dependiendo de cómo se utilice. Al trabajar con componentes de servidor, a menudo se utiliza Next.js, que introduce opiniones adicionales. Para entender los componentes de servidor directamente en React, construiremos un servidor RSC básico y lo conectaremos a un servidor SSR. El servidor SSR es responsable de la pre-renderización del lado del cliente, mientras que el servidor RSC se encarga de renderizar los componentes del servidor. Importamos las bibliotecas necesarias, como Express y el servidor React, para facilitar este proceso.
que podrías escribir para generar componentes de servidor. Ahora, lo primero que hace que esto sea complicado es el hecho de que React está dividido entre si es una biblioteca o un marco de trabajo dependiendo de si lo estás usando directamente o si más probablemente lo estás usando a través de algún tipo de meta marco de trabajo. Eso significa que hoy, si quieres ensuciarte las manos trabajando con componentes de servidor, probablemente vas a estar usando Next.js lo que significa que no sólo estás aprendiendo sobre cómo usar componentes de servidor, estás aprendiendo sobre un montón de opiniones adicionales que los marcos de trabajo naturalmente tienen que proporcionar. Así que podrías argumentar que no estás mucho más cerca de saber qué significa usar componentes de servidor directamente en React. Hoy, lo que quiero hacer es mostrarte cómo se ve usarlo a través de React como una biblioteca porque finalmente React, es un proyecto independiente y así que lo que vamos a hacer es tomar una aplicación como esta, muy, muy simple para los propósitos de hoy, ni siquiera vamos a tratar con componentes anidados aquí, sólo una aplicación básica que renderiza una etiqueta HTML, una etiqueta de cuerpo y un encabezado con algo de texto plano dentro. Así que lo que vamos a hacer hoy es empezar construyendo un servidor RSC básico. Su trabajo, como podrías adivinar, es renderizar componentes de servidor. Ahora lo menciono porque eso es literalmente su único trabajo, es sólo renderizar componentes de servidor y pasarlos al servidor SSR o al cliente para actualizaciones en vivo durante el curso de tu aplicación en ejecución. Así que como dije vamos a mantener esto muy muy simple, vamos a incorporar express. Ahora quiero mostrarte código real aquí y no diagramas, porque esto es lo que sentí que necesitaba para tener una idea de lo que está pasando aquí. Estamos incorporando express y aquí estamos trayendo esta función de renderizar a la corriente canalizable desde react server dom web pack slash server. Así que volveremos a eso más tarde. Pero tenemos esta función aquí y ahora como dije vamos a mantener esto muy simple donde literalmente cualquier solicitud a nuestro servidor express vamos a renderizar lo mismo, pero obviamente puedes imaginar en una aplicación del mundo real vas a estar lidiando con datos que entran al servidor para describir exactamente lo que quieres renderizar. Así que aquí vamos a renderizar a la corriente canalizable o una corriente de nodos nuestro componente de aplicación que vimos antes y de él vamos a obtener una corriente RSC y vamos a enviar eso a nuestro consumidor. Así que estamos creando una corriente de una corriente de la respuesta de renderizar este componente de aplicación en nuestro servidor RSC. Así que ahora que tenemos nuestro servidor RSC más básico posible, vamos a conectarlo a un servidor SSR. Ahora voy a señalar el elefante en la habitación de inmediato que es que ya tenemos un servidor ahora tenemos un servidor SSR. La palabra servidor se está utilizando mucho. Tenemos componentes de servidor y ahora todavía tenemos este concepto relativamente antiguo ahora en la renderización del lado del servidor reactivo y estos dos conceptos están sentados uno al lado del otro. Para ayudar a desmitificar estos dos conceptos lo que he encontrado es que ayuda en este mundo a reenmarcar el servidor SSR como algo sobre la pre-renderización del lado del cliente su trabajo es simplemente tomar esa vista inicial de lo que el navegador va a renderizar, renderizar eso a HTML en el servidor, y a partir de ese punto, el servidor SSR desde una perspectiva de renderización, su trabajo está hecho. Nunca vas a hablar con ese servidor para obtener componentes de React o HTML de nuevo así que es como si sólo estuviera pre-renderizando. El aspecto del servidor todavía ocurre en el servidor RSC más tarde. Así que aquí nuestro servidor SSR va a incorporar algunas bibliotecas, por supuesto vamos a traer el módulo HTTP, el módulo HTTP de node, vamos a incorporar Express. Ahora una cosa que quiero señalar aquí que es interesante es que estamos importando desde React server en webpack slash client. Ahora eso puede parecer sorprendente al principio que estamos importando desde el cliente, pero piénsalo en el mismo sentido que tu servidor podría tener un cliente REST en él o un cliente GraphQL. De la misma manera aquí tenemos un cliente RSC y vamos a llamar a esta función crear desde la corriente de nodos y luego también vamos a devolver una corriente de esto también. Así que de nuevo para mantenerlo simple, cualquier solicitud que entre vamos a renderizar lo mismo. Vamos a hablar con nuestro servidor RSC y obtener la respuesta RSC. Así que ese componente de aplicación que vimos antes viene del servidor RSC. Y esto es donde se pone interesante llamamos a esta función crear desde la corriente de nodos. Tenemos la respuesta RSC entrando y de eso estamos obteniendo algo de DOM virtual y de eso podemos crear
4. Entendiendo las Respuestas RSC
Short description:
Estamos convirtiendo las respuestas RSC, que son DOM virtual serializado, en HTML y enviándolas al cliente. Esto nos permite descargar código del cliente y obtener un marcado fresco sin tener que volver a ejecutar el código. Tratar con HTML estático es simple, pero el desafío es manejar la interactividad en las aplicaciones del lado del cliente.
HTML y enviarlo al cliente. Así que aquí hemos convertido ese servidor RSC en HTML y lo hemos enviado al cliente. Así que esta es la línea de código en la que realmente quiero profundizar porque para mí fue la que más me abrió los ojos a lo que realmente está sucediendo es que estamos obteniendo una respuesta RSC, estamos obteniendo algo de la red y lo estamos convirtiendo en DOM virtual. ¿Por qué es interesante? Bueno, el DOM virtual es un concepto fácil para los desarrolladores de React establecidos porque lo manejamos todo el tiempo cada vez que tienes un componente que renderiza elementos JSX como este o los asigna a una variable en este caso. Estás creando estos elementos en memoria basados en el código que se está ejecutando en vivo en ese entorno, pero la diferencia aquí, supongo que lo interesante es que los componentes de servidor son simplemente DOM virtual serializado. Está tomando los elementos de React que se renderizaron en un servidor en un entorno y los está enviando por la red para renderizar en otro lugar sin necesidad del código que lo generó. Así que esto significa, por supuesto, que podemos descargar código del cliente. Este es todo el punto de que podemos obtener un marcado fresco sin tener que volver a ejecutar el código. Así que el HTML estático es fácil de manejar. Así que de nuevo, si estamos mirando este componente que estábamos simplemente renderizando algunas etiquetas básicas con cadenas dentro. Por supuesto, si te gusta, hablamos de antes, si estás familiarizado con JSX, sabes que esto se mapea a llamadas a react create element y ya que todos estos argumentos aquí son valores primitivos de JavaScript, incluso sin RSE podrías haber hecho esto hace años, podrías serializar esto en una cadena de arrays anidados y enviar eso por la red y podrías imaginar escribir código que luego haría lo contrario, convertir esta data estructura en un árbol de elementos de react. Así que eso como problema en realidad no es demasiado complicado. Pero el problema entonces se convierte en que nuestras aplicaciones no son solo HTML estático como este ¿cómo manejamos la interactividad que esperamos con las aplicaciones del lado del cliente? Así que tomemos el ejemplo canónico de un componente contador, tenemos algún estado aquí donde estamos configurando este estado de conteo con una función set count y luego tenemos un componente botón que tiene un manejador de clics y dentro de eso llamamos a set count, así que hemos
5. Serialización y Manifiesto del Cliente
Short description:
Si anidamos el componente contador dentro del árbol de elementos de React, la serialización se convierte en un problema. La función contador no puede convertirse en una cadena y enviarse al cliente. La interactividad es un desafío en los componentes del servidor. El JSX se compila en una referencia de cliente de React, que es un marcador de posición para los componentos que necesitan ejecutarse en el cliente. El manifiesto del cliente mapea estas referencias a instrucciones para resolver el código detrás del componente. El servidor RSC define dinámicamente el código que el cliente debe descargar, permitiendo la representación dinámica de componentes basados en datos de usuario. Los componentes del servidor permiten que el servidor le diga a cada consumidor qué código necesitan descargar para renderizar elementos. Con React, podemos obtener un nuevo marcado de servidor dinámicamente mientras mantenemos el estado del cliente. El manifiesto del cliente mapea marcadores de posición serializados a componentes reales en el cliente. La serialización es crucial, y las props deben ser serializables. Los manejadores de clic en los componentes del cliente no pueden ser serializados en el árbol de elementos de la red.
tenemos cierta interactividad aquí. Entonces, si tomamos este componente contador y lo anidamos dentro de este árbol de elementos de React ahora tenemos un problema si intentamos serializarlo. Entonces, si tomamos nuestra implementación básica de convertir en cadena los argumentos para crear elementos de React no podemos convertir esta función contador en una cadena, no hay forma de representar eso en ese formato para que podamos enviarlo al cliente. Necesitan acceso al código detrás de esto no solo el componente en memoria. Eso significa que no se trata estrictamente de componentes, sino de poder convertir estas cosas en una cadena para enviar a través de la red para serializarlos. Entonces, si tuvieras un componente de botón con un manejador de clics te encontrarás con el mismo problema. Entonces, ¿cómo obtenemos interactividad? Hagamos esto incluso un poco más complicado aquí y digamos que vamos a renderizar nuestro componente contador en el árbol con algunas props. Estamos diciendo que el valor inicial es cero. Entonces, ¿en qué se compila el jsx en un mundo RSC si no podemos enviar el componente real a través de la red? Entonces aquí tenemos nuestro componente de aplicación y por supuesto el jsx se va a compilar en algo como esto. Tenemos nuestra llamada para crear elemento a html. Tenemos nuestra llamada para crear elemento a body como hemos visto antes. Pero aquí es donde se pone interesante porque tenemos este componente en la mezcla lo que realmente estamos haciendo en términos de en qué se convierte el jsx es una referencia de cliente de react. Entonces esto es como un marcador de posición en el árbol diciendo que no tenemos los elementos reales aquí, tenemos una referencia a un componente que necesita ejecutarse en el cliente. Tiene un id aquí de contador y luego, por supuesto, siendo crear elemento, también tenemos las props en línea. Entonces este id de contador aquí eso necesita mapear a algo para que sepamos cómo resolverlo al componente real. Y ahí es donde entra el concepto de este manifiesto del cliente. Este es un objeto que mapea estos ids de vuelta a básicamente instrucciones de cómo resolver el código real detrás de este componente. Entonces aquí el id es el id del módulo en el sistema de módulos, por lo que el cliente va a necesitar importar desde slash components slash counter en este ejemplo. Name es el nombre de exportación, por lo que si era export const counter verías contador aquí. Si era export default function verías default aquí y luego chunks con alguna información sobre qué código cargar también. Lo que quiero destacar aquí que para mí fue como el verdadero descubrimiento de cómo funciona esto es que el servidor RSC puede definir dinámicamente qué código debe descargar el cliente. Eso es interesante porque si piensas en el caso de uso que probablemente esto viene de en un sentido de Facebook es como el feed de noticias donde puedes tener un feed de componentes que se renderizan dinámicamente basado en data por usuario y qué componentes van a estar en la pantalla es completamente dinámico en tiempo de ejecución. Los componentes del servidor significan que el servidor puede decirle a cada uno consumidor de qué código necesitan descargar para renderizar los diferentes elementos en ese feed algo que sería realmente difícil sin RSC. Entonces, en cierto sentido, si entrecierras los ojos, puedes sentir como si estuvieras volviendo atrás en el tiempo un poco aquí de una buena manera en que sabes que estás yendo de vuelta a este modelo de tener plantillas del lado del servidor que solo renderizan marcado plano y luego el partes dinámicas de tu página son etiquetas de script que tienen scripts en línea o referencias a scripts externos de cómo dar vida a ese marcado estático. Entonces es como volver a ese modelo pero lo hacemos de una manera que se ajusta a la forma en que hemos llegado a esperar que React funcione donde obtenemos un solo árbol de componentes, llegamos a pensar en ese tipo de paradigma relativamente único incluso a través del servidor y el cliente y no tenemos que lidiar con las complejidades de bajo nivel de las etiquetas de script podemos pensar a nivel de componente. Entonces, desde la perspectiva del cliente, esto significa que podemos obtener nuevo marcado de servidor del servidor RSC dinámicamente durante la vida útil de la aplicación mientras mantenemos el estado del cliente. Esta es toda la razón por la que usamos React versus simplemente estableciendo inner HTML todo el tiempo. Entonces, si tenemos nuestro manifiesto del cliente, tenemos este objeto que dice cómo hacemos mapear estos marcadores de posición en el árbol que hemos serializado a componentes reales en vivo en el cliente y nuevamente el cliente siendo tanto el servidor SSR como el navegador. Lo que necesitamos hacer es pasar eso como el segundo argumento antes tenía un objeto vacío solo para mantenerlo simple pero aquí cuando renderizamos nuestro flujo RSC estamos pasando el manifiesto del cliente para que los consumidores de nuestro servidor RSC puedan obtener instrucciones de cómo resolver estos componentes del cliente que están anidados dentro del árbol. Entonces, lo importante que hay que darse cuenta aquí es que todo se trata de serialización, se trata de tomar un árbol de elementos de React y serializarlos y eso significa que las props necesitan ser serializables también. Entonces, en nuestro ejemplo básico, puedes ver que porque nuestro valor inicial aquí es el número 0 eso está completamente bien para serializar pero es por eso que no puedes hacer cosas como de nuevo poner un manejador de clic en tu componente del cliente, porque si piensas en ello al final del día necesita ser serializado en este árbol de elementos para pasar por la red y nosotros
6. Entendiendo los Componentes de Servidor y Cliente de React
Short description:
Los componentes de servidor son solo DOM virtual a través de la red. RSC se trata de tener componentes serializables y árboles de elementos React que podemos enviar a través de la red. Combina lo mejor del desarrollo web clásico y la mejora progresiva con los beneficios del desarrollo moderno. La complejidad de la infraestructura, las herramientas y las consideraciones del desarrollador no deben subestimarse, pero un modelo mental simple puede ayudar a entender cómo funcionan los componentes del servidor y sus compromisos en aplicaciones reales.
aquí es el número 0 que está completamente bien para serializar, pero es por eso que no puedes hacer cosas como poner nuevamente un manejador de clic en tu componente de cliente, porque si piensas en ello al final del día necesita ser serializado en este árbol de elementos para pasar por la red y no podemos hacer eso. Entonces, si quieres tener manejadores de clic, necesitan estar en el código fuente de el componente pero no en las props que están en ese árbol de elementos. Curiosamente, por supuesto, en el mundo de React, los hijos son básicamente solo props. Al final del día, se serializan de una manera similar y esto es lo que nos permite hacer esta interesante técnica de anidar componentes de servidor dentro de componentes de cliente. Porque si piensas de nuevo en ese árbol de React, tenemos nuestro marcador de posición aquí, esta referencia de cliente de React para un componente de alerta con una prop de título, eso es todo serializable, y luego los hijos aquí es una llamada de createElement, por lo que es un elemento html plano. Ahora, obviamente en la vida real en un proyecto real podría complicarse mucho más y podría tener componentes de servidor anidados, pero el punto clave aquí es que tenemos un componente de cliente cuyos hijos es el resultado de otro componente de servidor. Y para mí, creo que verlo como un problema de serialización me ayuda a entender el mecanismo de cómo puedo anidar componentes en el árbol de React, pero no puedo hacerlo en el código fuente. Entonces, hay dos tipos de elementos con los que estamos lidiando aquí, el primero son los viejos elementos html serializables, de nuevo, es como solo marcado estático de lo que estamos hablando, y luego para cualquier cosa más complicada que eso o interactiva tenemos instrucciones en el árbol de React para resolver y renderizar componentes, y aquí es donde entra todo el concepto de componentes de cliente. Ahora, por supuesto, no escribes esto a mano, al igual que JSX que mostramos antes, esto está extendiendo JSX para poder hacer mucho más, de hecho, y aquí es donde entran los empaquetadores, todo el punto de usar empaquetadores es lidiar con este tipo de complejidad para nosotros, y entonces cuando como desarrollador pones una directiva use client en la parte superior de un archivo de componente de cliente, y luego en otro lugar de tu aplicación, en un contexto de servidor, estás importando este componente de contador, no obtienes una referencia a la función real, porque, de nuevo, no podemos poner eso en el árbol de React, el contador en ese contexto se convierte automáticamente en este objeto que vimos antes, esta referencia de cliente con el ID de contador puesto allí para nosotros, y por supuesto, este ID necesita mapear a algo en el manifiesto, y eso también va a ser administrado para nosotros, esta generación de este objeto, de cómo mapeamos estos marcadores de posición en el árbol de React a los componentes que van a ejecutarse en el cliente, todo esto se gestiona para nosotros. Debido a que necesitas esta integración con el bundler, es por eso que existen estos paquetes de nombre largo existen, tienes el servidor de React, Webpack, VEET, estos existen para manejar las diferencias entre los diferentes empaquetadores para nosotros. Y por supuesto en la práctica, al igual que SSR fue hace años cuando empezamos con SSR, conectar esto en una aplicación real es complicado, y aquí es donde entran los frameworks, por supuesto, es por eso que, de nuevo, hoy vas a optar por un framework si quieres usar componentes de servidor hoy. Pero si alguien te pregunta, ¿qué son los componentes de servidor?, espero que como resultado de esta charla no solo vayas a decir, de nuevo, reorganizando las palabras que los componentes de servidor son componentes que solo se ejecutan en el servidor. Puedes decir algo como que los componentes de servidor son solo DOM virtual a través de la red. Puedes pensar en el hecho de que en última instancia RSC se trata de tener componentes serializables, tener árboles de elementos React que podemos enviar a través de la red y con eso obviamente vienen algunas restricciones, pero cuando entiendes el mecanismo tiene más sentido. Lo que me gusta, como alguien que ha estado haciendo desarrollo web durante mucho tiempo en este punto, es que puedo pensar en ello de manera más primitiva como plantillas del lado del servidor con etiquetas de script, pero hecho de una manera que se siente más en casa en React. De nuevo, acercándonos a ese mundo de lo mejor de el desarrollo web clásico y la mejora progresiva, pero con los beneficios del desarrollo moderno que he llegado a esperar con React. No quiero restar importancia a la complejidad, la muy real complejidad que está en juego aquí, tanto en términos de la infraestructura, las herramientas, y lo que tienes que pensar como desarrollador, pero espero, lo que he hecho es darte un modelo mental simple para trabajar con él de modo que cuando vuelvas a tu trabajo y mires los componentes del servidor, tal vez por el primera vez, o tal vez has estado trabajando con él durante un tiempo, tienes un modelo mental simple para cómo funciona en la práctica y qué significan esos compromisos para ti en términos de tu aplicación.
QnA
Entendiendo los Componentos del Lado del Servidor
Short description:
Eso es todo por mi parte. Muchas gracias por escuchar. Realmente disfruto de esto porque uso Next.js. Ahora, es mi opción predeterminada siempre que estoy construyendo una aplicación y entiendo cómo uso los componentes del lado del servidor, pero nunca necesariamente profundicé en cómo esa información va del servidor al cliente. Una cosa que quería preguntar es cuando ves los componentes del lado del servidor y la forma en que se utilizan, ¿qué tipo de modelos mentales crees que las personas pueden usar para tomar la decisión de si algo debería ser un componente del lado del servidor o si deberían hacerlo en el cliente? Ahora, las preguntas definitivamente están llegando. Tenemos una que pregunta, para los componentes del lado del servidor, ¿hay alguna herramienta de React que recomendarías para trabajar con su depuración? También tenemos otra pregunta. Esta es, bueno, esto vuelve a por qué las personas usan el servidor, por qué las personas deberían usar componentos del servidor. ¿Cuáles son algunas de las grandes ventajas de los componentes del lado del servidor en tu opinión?
Eso es todo por mi parte. Muchas gracias por escuchar. Realmente disfruto de esto porque uso Next.js. Ahora, es mi opción predeterminada siempre que estoy construyendo una aplicación y entiendo cómo uso los componentes del lado del servidor, pero nunca necesariamente profundicé en cómo esa información va del servidor al cliente. Definitivamente voy a volver a ver esta charla y comparar notas con ella también.
Para aquellos de ustedes que se están uniendo, si tienen alguna pregunta también, asegúrense de dirigirse a Slido. Creo que tal vez el código QR de Slido no estaba funcionando para algunas personas en dispositivos específicos, así que solo quería hacerles saber que pueden ir a slido.com y usar el código 2010, es decir, 20 y luego 10, para hacer sus preguntas. Y luego, a medida que las preguntas llegan, se las haré a Mark. También me encantó el punto de que los hijos son solo props.
Una cosa que quería preguntar es cuando ves los componentes del lado del servidor y la forma en que se utilizan, ¿qué tipo de modelos mentales crees que las personas pueden usar para tomar la decisión de si algo debería ser un componente del lado del servidor o si deberían hacerlo en el cliente? Bueno, supongo que en primer lugar, como decíamos en la charla, hasta cierto punto te lo imponen tan pronto como hay ciertas cosas que estás tratando de hacer. Así que de nuevo, si estás tratando de tener componentes interactivos que de nuevo no pueden ser serializados, simplemente no tienes opción. Pero una cosa que supongo que es interesante que, quiero decir, no puedo hablar desde mi propia experiencia, pero sé que una de las compensaciones incluso al pasar a los componentes del servidor es que a pesar de que estás moviendo el código fuera del cliente, todavía tienes que serializar todos esos elementos y enviarlos como data en esa carga útil. Así que a veces hay una compensación donde terminas serializando mucho contenido como HTML que podrías haber enviado simplemente como data como lo hacemos hoy, bien antes de los componentes del servidor en React. Así que creo que incluso podrías encontrar que hay casos donde algo estrictamente podría estar solo en el servidor, pero decides moverlo al cliente porque te das cuenta de que esas cargas útiles de RSC se están volviendo demasiado grandes. Así que hay, creo que más allá del hecho de si algo tiene que ser un componente del cliente, incluso puedes encontrar que hay momentos en los que podrías querer mover el deslizador en términos de cuánto sucede en el servidor versus el cliente. No, eso tiene sentido. Eso tiene sentido. Ahora, las preguntas definitivamente están llegando. Tenemos una que pregunta, para los componentes del lado del servidor, estamos muy cómodos. Hay tantas herramientas para depurar los componentes del lado del cliente, pero para los componentes del lado del servidor, ¿hay alguna herramienta de React que recomendarías para trabajar con su depuración? Sí, es una buena pregunta. Entonces, quiero decir, no me he metido tanto en términos de ejecutar aplicaciones reales. Esto fue muy para mí, un ejercicio teórico de verlo desde un perspectiva de marco de trabajo de cómo incluso implementar algo? Pero lo que diría es, de nuevo, para hablar de la complejidad, mi perspectiva sobre esto es que creo que es por eso que, a pesar de que la gente está emocionada por ello, también hay cierta sensación de aprensión en torno a adoptarlo. Porque es un gran cambio en la forma en que tu aplicación se ejecuta en producción y eso trae muchas preguntas alrededor, como dijiste, alrededor de la depuración o mirar cosas como performance. Estoy seguro de que hay personas trabajando activamente en este espacio, así que lo siento si no he mencionado tu trabajo, pero, sí, es una buena pregunta, que definitivamente cambia el modelo de una manera importante. Si alguien tiene alguna recomendación de herramientas de depuración, déjala en el Discord. También tenemos otra pregunta. Esta es, bueno, esto vuelve a por qué las personas usan el servidor, por qué las personas deberían usar componentes del servidor. Las personas preguntan sobre SEO o un tiempo de carga más rápido, y el hecho de que hay un costo asociado con la ejecución del servidor y si vale la pena. ¿Cuáles son algunas de las grandes ventajas de los componentes del lado del servidor en tu opinión? Para mí, creo que el gran beneficio es simplemente hacer menos trabajo en el cliente, y es una de esas cosas donde si eso es importante para ti realmente depende del tipo de producto que estás construyendo. Por ejemplo, en mi trabajo más temprano con React haciendo la renderización del lado del servidor, como dije, la razón principal por la que nos decantamos por React fue
Beneficios de los Componentes del Servidor
Short description:
A pesar de las desventajas del rendimiento de React, aún proporciona HTML real y una renderización rápida. Sin embargo, para páginas estáticas con mínima interactividad, la cantidad de código y el trabajo de hidratación pueden ser excesivos. Los componentes del servidor ofrecen la ventaja de mover la lógica del cliente al servidor, proporcionando más poder para adaptar el producto.
debido a su renderización del lado del servidor. Y a pesar de las desventajas de React desde una perspectiva de performance, fue un gran avance para nosotros, porque cuando Google o los usuarios visitan nuestro sitio, obtienen un HTML real y ven algo en la pantalla bastante rápido. Pero hay ciertas clases de aplicaciones donde la cantidad de código que se descarga en el cliente y el trabajo de hidratación necesario es demasiado, considerando quizás cuán estática puede ser gran parte de la página. Y creo que realmente depende de cuánto de un sitio web versus una aplicación eres definitivamente una consideración. Si sientes que, en el extremo, estás diciendo, tengo un blog, por ejemplo, para mí es un caso extremo donde ¿por qué necesito rehidratar una pared de texto estático? No tiene sentido. Quizás hay algunas piezas interactivas en la parte inferior o en el medio del documento y solo necesito código para esas. Pero si quiero permanecer en ese entorno de React, porque me gusta construir incluso cosas simples como blogs, disfruto construyéndolos en React. Para mí, el beneficio de algo como los componentes del servidor es que tenemos más poder a nuestra disposición para mover la lógica del cliente al servidor donde tiene sentido para tu producto. No, eso tiene mucho sentido. Y una cosa, aunque, porque la siguiente pregunta que está más votada, creo que también se conecta con eso, que es cuando tienes una mala conexión de red, ¿hace que los componentes, los componentes del lado del servidor se sientan lentos, con errores? ¿Cómo trabajas alrededor de eso y te aseguras de que eso no suceda en tu aplicación? Para mí, el beneficio de mirar cómo funcionan es que me dio una mejor comprensión de que finalmente se trata de poder volver dinámicamente al servidor en runtime y obtener el marcado después del hecho y luego actualizar la página como resultado. Eso significa que puedes ir a un ciclo de vida más tradicional en términos de cuando haces clic en un enlace en lugar de navegar en el navegador y hacer una llamada para obtener algún JSON, vas a volver al servidor para obtener el marcado de toda la página, básicamente. Creo que eso puede ser un pro o un contra dependiendo del tipo de cosa que estás intentando construir. Puedo ver que algunos desarrolladores podrían sentir que podría parecer un poco de regresión, que ahora dependes demasiado del servidor para lo que necesita ser renderizado. Mientras que, si estás buscando más una aplicación offline primero, puedes hacer clic alrededor y renderizar cosas de inmediato. Obviamente, los data entran a medida que navegas. Lo que se renderiza en la pantalla sucede inmediatamente. Definitivamente hay un compromiso allí también. Por supuesto. Muy bien. Sé que hay muchas más preguntas. Recuerda, si quieres hacerlas, puedes preguntarle a Marc en persona. Va a ir a la sala de discusión de los oradores más tarde también. Vamos a tener una pregunta más. Y esta es sobre Remix. ¿Qué opiniones tendrá Remix sobre RSC que quizás difieran de las opiniones de Next? Sí, es una buena pregunta. Quiero decir, es difícil de responder en el sentido de que todavía hay un desarrollo activo en el equipo de Remix tratando de averiguar exactamente cómo se ve eso. Por eso creo que el valor de mi charla es mostrarte que RSC como concepto todavía es bastante de bajo nivel en comparación con un marco de trabajo y por lo tanto todavía, como un marco de trabajo tiene que tomar decisiones sobre cómo hacer, cómo manejar cosas como cookies o redirecciones y cosas como eso. Cosas que van más allá de solo renderizar como ¿cómo se conecta esto realmente a un servidor web real y las respuestas que obtienes de ese servidor? Y también hay decisiones que se deben tomar sobre, por ejemplo, no lo toqué en la charla, pero cosas como las acciones del servidor. ¿Cómo funcionan? ¿Qué tan flexibles son? ¿Hay alguna restricción adicional y así sucesivamente? Así que todavía hay alguna exploración sucediendo allí. Muchas gracias. Todos aplaudan a Mark.
This Talk introduces React Server Components (RSC) and explores their serialization process. It compares RSC to traditional server-side rendering (SSR) and explains how RSC handles promises and integrates client components. The Talk also discusses the RSC manifest and deserialization process. The speaker then introduces the Waku framework, which supports bundling, server, routing, and SSR. The future plans for Waku include integration with client state management libraries.
In this Talk, Kent C. Dodds introduces React Server Components (RSCs) and demonstrates how to build them from scratch. He explains the process of integrating RSCs with the UI, switching to RSC and streaming for improved performance, and the benefits of using RSCs with async components. Dodds also discusses enhancements with streaming and server context, client support and loaders, server component rendering and module resolution, handling UI updates and rendering, handling back buttons and caching, and concludes with further resources for diving deeper into the topic.
React query version five is live and we'll be discussing the migration process to server components using Next.js and React Query. The process involves planning, preparing, and setting up server components, migrating pages, adding layouts, and moving components to the server. We'll also explore the benefits of server components such as reducing JavaScript shipping, enabling powerful caching, and leveraging the features of the app router. Additionally, we'll cover topics like handling authentication, rendering in server components, and the impact on server load and costs.
This Talk introduces server components in React, which provide an intermediate format for rendering and offer advantages for both client-side and server-side rendering. Server components reduce bundle size on the client and improve search engine optimization. They abstract the rendering process, allowing for faster rendering and flexibility in choosing where to render components. While server components are still in the experimental stage, Next.js is a good starting point to try them out.
Envelope is a powerful GraphQL plugin system that simplifies server development and allows for powerful plugin integration. It provides conformity for large corporations with multiple GraphQL servers and can be used with various frameworks. Envelope acts as the Babel of GraphQL, allowing the use of non-spec features. The Guild offers GraphQL Hive, a service similar to Apollo Studio, and encourages collaboration with other frameworks and languages.
React server components solve the problem of interrupting user interfaces caused by CPU-bound or network-bound web applications. They allow for read-only content to be rendered on the server and interactive elements to be shipped to the client, reducing code shipped and improving performance. Server-side rendering and server-side fetching improve the user experience by reducing delays and flash of unstyled content. Soft navigation with server components enables re-rendering without hard navigation, and using frameworks like Next.js helps with debugging and deployment challenges.
- Introducción- Prerrequisitos para la masterclass- Estrategias de obtención: fundamentos- Estrategias de obtención – práctica: API de obtención, caché (estática VS dinámica), revalidar, suspense (obtención de datos en paralelo)- Prueba tu construcción y sírvela en Vercel- Futuro: Componentes de servidor VS Componentes de cliente- Huevo de pascua de la masterclass (no relacionado con el tema, destacando la accesibilidad)- Conclusión
Esta masterclass te guiará a través del ciclo de vida del desarrollo de productos para crear una aplicación web del mundo real. Aprenderás sobre los Componentes del Servidor React, construyendo un sistema de diseño dentro de Storybook, y utilizando el desarrollo frontend para acercarte a convertirte en un desarrollador full-stack. La masterclass cubrirá el aumento de la confianza en tu aplicación con pruebas unitarias e implementando autenticación y autorización. Tendrás la oportunidad de trabajar a través de las características del producto y examinar un proyecto real de RedwoodJS, obteniendo valiosa experiencia en el desarrollo de productos del mundo real. RedwoodJS hace que sea simple acercarse al desarrollo full-stack, y esta masterclass te dará las habilidades que necesitas para crear tus propias aplicaciones web del mundo real.
El ecosistema de desarrolladores siempre está avanzando rápidamente y este año no ha sido una excepción. Los Componentes de Servidor React pueden ofrecer una mejora significativa a la experiencia del desarrollador y al rendimiento de la aplicación. Pero creo que es justo decir que este nuevo paradigma de servidor primero puede ser complicado de entender!En la primera mitad de esta masterclass, exploraremos los Componentes de Servidor React desde cero: construyendo nuestro propio mini marco meta para ayudarnos a entender cómo funcionan los RSCs. Descubriremos exactamente qué se produce en una construcción RSC y conectaremos esas piezas para formar una aplicación completa.A continuación, ¡lo desplegaremos! Cloudflare también ha tenido un año ocupado — Smart Placement, en particular, es una nueva tecnología que hemos desarrollado que se ajusta perfectamente al modelo RSC. Exploraremos por qué eso tiene sentido para nuestra aplicación de masterclass, y realmente lo desplegaremos en la Plataforma de Desarrolladores de Cloudflare.Finalmente, ampliaremos un poco más nuestra aplicación, utilizando D1 (nuestra base de datos SQL sin servidor) para mostrar realmente el poder del Componente de Servidor React cuando se combina con Smart Placement.Deberías salir de esta masterclass con una mayor comprensión de cómo funcionan los Componentes de Servidor React (tanto detrás de las escenas como también cómo tú como desarrollador puedes usarlos día a día), así como una visión de algunos de los nuevos patrones de despliegue que ahora son posibles después de las recientes innovaciones en el espacio de la plataforma.
Construyendo Componentes de Servidor Reutilizables en NextJS
Workshop
2 authors
React continúa evolucionando su capacidad beta, los Componentes de Servidor de React, y continúan desarrollándolos en asociación con marcos como NextJS.En esta masterclass, los asistentes aprenderán qué son los Componentes de Servidor de React, cómo construirlos y usarlos eficazmente en NextJS, y se centrarán en una de las principales ventajas de React/NextJS: la reutilización a través de componentes.También cubriremos tecnologías beta relacionadas habilitadas por el directorio `app`, como los layouts anidados y las acciones del servidor (capacidad alfa/experimental).¡Únete a nosotros para esta masterclass práctica de 120 minutos!Tecnologías: React, JavaScript/Typescript, NextJS, Miro
¡Prepárate para potenciar tus habilidades de desarrollo web con los Componentes del Servidor React! En esta inmersiva masterclass de 3 horas, desbloquearemos el potencial completo de esta tecnología revolucionaria y exploraremos cómo está transformando la forma en que los desarrolladores construyen aplicaciones web rápidas y eficientes. Únete a nosotros mientras nos adentramos en el emocionante mundo de los Componentes del Servidor React, que combinan sin problemas el renderizado del lado del servidor con la interactividad del lado del cliente para un rendimiento y una experiencia de usuario inigualables. Obtendrás experiencia práctica a través de ejercicios prácticos, ejemplos del mundo real y orientación experta sobre cómo aprovechar el poder de los Componentes del Servidor en tus propios proyectos. A lo largo de la masterclass, cubriremos temas esenciales, incluyendo:- Entender las diferencias entre los Componentes del Servidor y del Cliente- Implementar Componentes del Servidor para optimizar la obtención de datos y reducir el tamaño del paquete JavaScript- Integrar Componentes del Servidor y del Cliente para una experiencia de usuario fluida- Estrategias para pasar datos efectivamente entre componentes y gestionar el estado- Consejos y mejores prácticas para maximizar los beneficios de rendimiento de los Componentes del Servidor React
Construye una Tienda Personalizada en Shopify con Hydrogen
Workshop
2 authors
Hydrogen es un marco de trabajo y SDK React con opiniones para construir tiendas personalizadas rápidas, alimentadas por Shopify. Hydrogen adopta los Componentes del Servidor React y utiliza Vite y Tailwind CSS. En este masterclass, los participantes tendrán una primera vista de Hydrogen, aprenderán cómo y cuándo usarlo, todo mientras construyen una tienda personalizada completamente funcional con el equipo de Hydrogen.
Comments