Así que, sumergiéndonos directamente, los React Server Components, probablemente la mayor charla de 2023 después de la IA. Si has estado en Twitter o X, probablemente has visto a la gente hablar de ello todos los días. A algunas personas les encantan. A algunas personas les disgustan. Y la mayoría de la gente simplemente está confundida. Tenemos preguntas como, ¿qué es RSC, como en React Server Components? ¿No es lo mismo que SSR? ¿Por qué React está volviendo a PHP? ¿Cómo encaja todo esto con Next.js? ¿Y puedo usarlo sin Next.js? Ahora mismo, es un poco un lío. Haré lo posible por desenredar ese lío para ti.
Así que antes de eso, una pequeña auto-presentación. Soy Adrian, el fundador de JavaScript Mastery. Hemos publicado muchos videos educativos diferentes en YouTube sobre temas como JavaScript, React, y durante el último año, mucho de Next.js. Y también, he sido reconocido como una estrella de GitHub, una especie de posición ofrecida por GitHub para personas que realmente intentan devolver a la audiencia y a las personas que se centran en la educación. Así que doy lo mejor de mí para crear más de cientos de videos basados en proyectos donde enseñamos a los desarrolladores cómo construir aplicaciones reales de principio a fin. Y he estado trabajando mucho con el nuevo Next.js, desde que salió, casi usándolo en todos nuestros videos de YouTube. Lo hemos tenido mucho, construyendo aplicaciones reales, enseñándolo en nuestro curso de Next.js también. Y es completamente nuevo Next.js. Desde el 13 al 14 e incluso más allá, hay muchas cosas nuevas sucediendo con Next.js. También creamos el curso de Next.js aquí mismo al que casi 3,000 personas se han unido. Y en esta masterclass, explicaré lo que he aprendido sobre los componentes del servidor React y cómo se conectan con Next.js de una manera fácil de entender.
Así que comencemos con un calentamiento en la era previa a los componentes del servidor React. Las cosas eran simples y directas. React estaba garantizado para funcionar en el navegador del cliente, nada más. Simplemente envía grandes fragmentos de paquetes de JavaScript con un mínimo archivo HTML individual y dile al navegador del cliente que maneje todo lo demás. El proceso, tal como lo conocemos, el cliente hace una solicitud al servidor, que parece algo así. El servidor responde a HTML y al paquete de JavaScript. El cliente renderiza HTML y descarga todo lo mencionado en el paquete de JavaScript. El cliente ejecuta ese JavaScript y luego pinta el contenido en la pantalla. Esta fue una sorprendentemente increíble invención web. Todavía lo es, pero como todas las cosas, todavía tiene inconvenientes.
Sí, incluso React tiene inconvenientes, los más importantes son el performance. Cuanto más JavaScript envíes, más tiempo tardará tu sitio en cargar inicialmente. Y en el mundo de hoy, la primera impresión es crucial para mantener a tus usuarios comprometidos en nuestros sitios web. También no debemos olvidar los dispositivos de gama baja, donde presumimos que todos los usuarios tienen dispositivos, redes y navegadores de primera línea y confiando en que su navegador podría manejar eso. Sin embargo, no todos poseen los dispositivos más recientes, y no podemos pasar por alto el hecho de que con el tiempo, estamos incorporando características cada vez más advanced en los sitios web. Si has experimentado con Next.js durante el desarrollo, podrías haber observado que no funciona de manera óptima en MacBooks con chips Intel. Son máquinas potentes, pero la nueva tecnología es exigente. A medida que evoluciona la nueva tecnología, también lo hacen los desafíos para los usuarios en configuraciones menos advanced que fueron poderosas algún día. Y por supuesto, no podemos hablar de los inconvenientes de React sin mencionar el SEO. Sí, sí, has oído eso varias veces, React no se lleva bien con el SEO. Habría sido increíble si los rastreadores web entendieran JavaScript, pero desafortunadamente, ese no es el caso. Y con el mínimo HTML de React, nuestro sitio web no llega a entender correctamente el SEO. Entonces, para abordar este problema, Next.js implementó SSR. SSR, renderizado en el lado del servidor, este método implica renderizar React en un servidor, generando HTML, y luego enviándolo al cliente. Luego, el cliente es responsable de renderizar esos nodos y elementos HTML e incorporar el JavaScript necesario para habilitar contenido interactivo. Es importante entender que hasta ahora, SSR solo puede renderizar los componentes React que son aptos para renderizar en el servidor. Los componentes que requieren interactividad, como aquellos con oyentes de eventos o dependencias en las APIs web, no son ejecutados por SSR. Puedes pensar en SSR como un método para crear un plano de nuestro sitio web. Genera y muestra cómo aparecerá inicialmente tu página web.
Por ejemplo, considera el siguiente escenario en la página. Tenemos un archivo home.js, o tenemos un contador típico que has visto cientos de veces. Creo que también se presentó en los documentos de React.js como uno de los primeros ejemplos de uso de estados cuando salieron los hooks. ¿Cuántos de ustedes estuvieron aquí para React 15, React 16, cuando pasamos de componentes basados en clases a solo hooks? No dudes en decírmelo en el chat. No muchas de las nuevas generaciones de desarrolladores que están programando ahora han pasado por ese tiempo. ¿Has estado aquí para esa transición? Sí, es una locura pensar que algunos de nosotros hemos empezado con componentes de clase y algunos de nosotros, o algunos de ustedes tal vez, nunca han usado componentes basados en clases, lo cual es bastante interesante para pensar. Tenemos este ejemplo aquí, y el resultado de la salida SSR sería así, donde simplemente tenemos bienvenido a mi nueva aplicación Next.js. Donde tenemos el botón y el contador. Eso es el SSR. Se produce una página HTML aquí, que comprende una lista de elementos y nodos, que representan los componentes de esa página. ¿Pero qué pasa con la interactividad? Todos los estados y oyentes de eventos se envían al cliente y como paquetes de JavaScript, que el navegador del cliente carga e inicia la construcción del DOM virtual. El cliente compara el DOM estático que recibimos inicialmente con el DOM virtual que creará utilizando el código JavaScript proporcionado, y luego determina si coinciden correctamente. Si no, lanzará un error, diciendo que muchos desarrolladores de Next.js están frustrados, que va a parecer algo así. Un error de hidratación. Todo este proceso de reconciliación del DOM virtual, que el cliente cree que representa la página, con el DOM estático real que el servidor entregó, se llama hidratación. El favorito de todos, Dan Abramov, lo puso de esta manera, a través de sus modelos mentales. Antes, así sin el SSR, tenemos el árbol de React, donde renderizamos componentes a HTML. Tenemos el main.js y luego agrupamos el código para interacciones como esta. Y luego después del SSR, va a parecer algo así. Donde tenemos el árbol del servidor, con el sistema de archivos, bases de datos, servicios internos, y muchas otras cosas. Y pasamos props al árbol de React, así. Básicamente, un DOM virtual, o árbol, creado por el cliente, que parece esto. Servidor, cliente, y ahora tenemos todo sucediendo en el cliente también. Sí, puedo ver en los mensajes también que Davie envió la superposición de hidratación de builder.io React. Así que, eso es algo bastante interesante para tener en cuenta. También podemos compartirlo definitivamente en el Discord, así que siempre que tengamos algo, tenemos un foro y podemos mantener nuestra discusión allí. Es bastante útil saber que podemos tener mensajes de error mejores y mejorados cuando se trata de hidratación. Gracias por compartir eso. Pero eso es suficiente sobre SSR por ahora. Lo entiendes. Dado que tenemos este sólido enfoque de SSR, ¿por qué deberíamos molestarnos con los componentes del servidor React? Bueno, la hidratación convencional que discutimos anteriormente, antes de los componentes del servidor React y Next 13, implicaba una hidratación de página completa. Esto significaba que cuando se cargaba la página, todo el componente 3 de React, incluyendo todos los componentes, ya fueran inicialmente visibles o interactuados por el usuario, se hidrataban en el lado del cliente. ¿Qué significa esto para el performance? Aunque puedes ver algo en la página, no será interactivo hasta que el cliente cargue todo lo relacionado con esa página, específicamente el paquete de JavaScript necesario para hidratar el árbol estático. Claro, logramos una carga inicial más rápida en esta etapa, pero luego hay un retraso con el que podemos interactuar, y porque estamos esperando que el JavaScript se hidrate, hay una brecha. Para bases de código más extensas, puede llevar a cargas de página iniciales más grandes y procesamiento de JavaScript, incluso para componentes que pueden no ser inicialmente requeridos. Así es donde entran los componentes del servidor React. El componente del servidor React es un nuevo tipo de componente. Está asegurado para funcionar exclusivamente en el servidor. Nunca se hidratan en el lado del cliente. Así que como resultado, no se envía JavaScript extra, lo que resulta en un tamaño de paquete de JavaScript más pequeño, una carga de página más rápida, hidratación selectiva, y una experiencia mejorada tanto para la interfaz de usuario como para la experiencia del desarrollador. Pero antes de eso, permíteme explicar cómo funcionan los componentes del servidor React y cómo podemos usarlos. Es importante notar que los componentes del servidor React son exclusivamente una característica de React. Ha habido mucho debate en internet ahora.
Comments