Componentes de Servidor React

♪ Escucha, yo, bueno, esto es... Uf, hombre, nunca me habían presentado así. Gracias, gracias, gracias, hermano. Eso fue tremendo. Mira, esta conferencia es extremadamente especial para mí porque vivo aquí. Berlín, lo llamo hogar. He vivido aquí durante ocho años y es un honor absoluto y un privilegio poder estar aquí y hablarles hoy en mi ciudad natal.

Este año, he hablado en más de 30 conferencias en todo el mundo, pero en Berlín, esta es la número dos. Y es extremadamente especial para mí ver a todos ustedes aquí desde Bélgica, desde los Países Bajos, todos estos lugares viniendo aquí, no solo para verme a mí, sino para celebrar React juntos, ¿verdad? Y eso es algo especial. Así que solo quiero darles las gracias por venir, por Git Nation. Increíble. Asombroso.

Siento que tengo una diapositiva de introducción, pero aparentemente no la necesito gracias a Nathaniel. Mi nombre es Tejas, se pronuncia como contagious. No lo soy, no te preocupes. Y a lo largo de los años, he trabajado en tecnología durante muchos, muchos años. Más de 20, perdí la cuenta. Y a lo largo de los años, he tenido el privilegio de trabajar con y en varios equipos por los que estoy realmente agradecido. Y realmente, es de eso de lo que quiero compartir con ustedes hoy, ¿vale? Hoy, soy consultor. Ayudo a las empresas enfocadas en desarrolladores a hacer DevRel. Y si necesitas ayuda con eso, estaré encantado de charlar después. Pero eso no es de lo que estamos aquí para hablar hoy. Hoy, estamos aquí para hablar sobre los componentes del servidor de React. Vamos a hablar de ello en profundidad. Tenemos 20 minutos, así que veremos hasta dónde llegamos. La última vez que di esta charla, duró 45 minutos, aunque estaba en un espacio de 20 minutos. Y luego, la gente de GitNation dijo: nunca más. De hecho, fue la última charla y se pasó de tiempo, así que ahora dijeron: te daremos la primera charla, así no puedes pasarte de tiempo. De todos modos, ¿cuántos de ustedes están usando los componentes del servidor de React? Bueno, eso es, diría yo, el 1% si acaso de la sala, lo cual está bien. Quiero decir, es nuevo, y por eso estoy aquí.

Lo que quiero hablarles es sobre el mecanismo de los Componentes del Servidor de React. Así que no voy a hablarles de cómo usarlo. La forma predominante de cómo usarlo es simplemente usar Next.js o un marco que maneje la complejidad por ti. Creo que esto es relativamente sencillo. Puedes encontrarlo, Tobias de Marcelo está aquí, probablemente te hablará de ello, etc. Lo que quiero enseñarte es el mecanismo, cómo funcionan. Porque tengo un problema aceptando abstracciones de caja negra de alto nivel como ingeniero.

¿Alguien, estoy solo en esto? ¿Alguien más? Sí, okay, la mayoría de la gente. Y entonces si me dices, solo usa Next.js, y está resuelto para ti, estoy como, okay, eso es genial, gracias, equipo de Next.js, pero ¿cómo funciona para que entienda el mecanismo subyacente? ¿Okay? Y eso es de lo que estamos aquí para hablar hoy.

En nuestro tiempo juntos, no cubriremos dos cosas. No vamos a cubrir los conceptos básicos de React, asumo que ya lo sabes. Y si no lo sabes, podemos charlar por separado, pero tengo 20 minutos aquí. Y no cubriremos las acciones del servidor porque en el momento de dar la charla, muchas de las cosas específicas de React con las acciones del servidor están en Canary, lo que significa que es prelanzamiento, no está listo para producción. Puedes usar acciones del servidor en Next.js, pero de nuevo, no estoy listo para hablar de eso en una capacidad de React. De lo que hablaremos es de los componentes del servidor desde el lado teórico. Veremos los problemas que resuelven, y luego veremos cómo puedes implementar la renderización de componentes del servidor en la práctica. Veremos los límites entre los componentes del servidor, los componentes del cliente, qué significan y cómo encajan juntos.

Okay, con eso, me quedan 15 minutos. Guau. Con eso, comencemos a hablar sobre los componentes del servidor. De hecho, retrocedamos un poco y hablemos de React. Recientemente tuve el privilegio de escribir un libro sobre React, y entonces estoy pensando, como, estilo de primeros principios. React, por su nombre, es un software que permite a las aplicaciones web ¿qué? Para React, para interactuar con el usuario. Ese es todo el punto. Y podrías pensar, okay, entonces hago clic en un botón y React hace cosas. Exactamente. Pero no se trata solo de reaccionar. Se trata de reaccionar bien. Se trata de reaccionar rápido. Se trata de cuando se está realizando un trabajo de CPU costoso, ¿verdad? Estás renderizando una lista grande, y luego un usuario ingresa una tecla en una entrada.

Esa entrada necesita responderles antes de que ocurra cualquier trabajo de CPU. Necesita react instantáneamente. Ese es el propósito de React de principio a fin. Y, por lo general, las aplicaciones web están limitadas por la CPU, lo que significa que están realizando trabajo en la CPU, o están limitadas por la red, lo que significa que hay una obtención de data. Y la obtención de data a veces puede interrumpir las interfaces de usuario. ¿Puedes pensar en un caso en el que esto sucede? Los spinners. De hecho, X, anteriormente Twitter, se renderiza completamente en el lado del cliente, y si entras allí, verás siete spinners diferentes al mismo tiempo. Y esto puede interrumpir tu experiencia de usuario. Y así React tiene como objetivo resolver ese problema, y los componentes del servidor son y son la respuesta a esto.

Ahora, podrías estar pensando, vale, pero la renderización en el lado del servidor era la respuesta a esto, ¿verdad? La renderización en el lado del servidor significa que renderizas todos tus React componentes en el lado del servidor, y luego solo envías HTML, o transmites texto HTML a tu navegador. Sí, resolvieron el problema del spinner, pero el nivel de granularidad no es ideal. Típicamente, antes de Next.js 13, renderizarías una página entera en el servidor. No podrías decir, como, esta tarjeta específica que formatea Markdown, esta cosa sola necesita renderizarse en el servidor e ir al cliente. Los componentes del servidor resolvieron eso.

Los componentes del servidor resolvieron el problema de la obtención de data. Algunos de ustedes pueden haber oído hablar de suspense para la obtención de data, ¿verdad? Los componentes del servidor son básicamente eso. Comenzó con la resolución del problema de los grandes paquetes de JavaScript, ¿verdad? Solíamos enviar mucho JavaScript. La aplicación entera era básicamente solo JavaScript que enviamos desde algún servidor al navegador. Los navegadores tienen que descargar el JavaScript, analizarlo, ejecutarlo, y luego la aplicación se vuelve interactiva. Eso es terrible. La renderización en el servidor resuelve eso enviando marcado y luego hidratando, por lo que el JavaScript se carga después. Los componentes del servidor lo resuelven aún más al renderizar componentes exclusivamente en el servidor. ¡Exclusivamente! Así que si tienes un blog, es de solo lectura, no hay interacciones. Puedes renderizar todo eso en el servidor y casi nunca en el cliente. ¿Y qué renderizas en el cliente? Solo envías los elementos interactivos. Un pequeño botón, un pequeño signo de más, el añadir al carrito, las cosas pequeñas. Y por lo tanto envías menos código. Así que es una solución de dos vías. Resuelve la obtención de data, porque incluso estás obteniendo en el servidor, y resuelve el problema del gran tamaño del paquete. Así que solo enviamos pequeños botones en lugar de aplicaciones enteras. Esa es la solución.

Así que con eso, ya estoy aburrido de escucharme hablar. Así que hagamos una demostración. ¿Qué te parece? Lo que quiero mostrarte es esta pequeña demostración que he preparado. Estos son chistes, y se están moviendo. Te prometo que hay lógica. Así que hablemos un poco de esto. Estos chistes vienen de una base de datos. Hay un miembro increíble de la comunidad de React llamado Shruti Kapoor.

Esta es Shruti, ShrutiKapoor08. Y ella tiene un repositorio en GitHub llamado devjoke. Y está lleno de chistes, chistes de desarrolladores. Necesitaba meter esto en una database. Así que hay un backend como un servicio llamado Kiel. Lo cargué aquí, y hay un montón de data aquí, preguntas y respuestas. Y básicamente quería darme data para obtener.

Así que ahora tengo esta database, y quiero obtenerla para mostrarles los componentes del servidor. Así que esta es la aplicación obteniendo data de mi database. Y lo que están viendo aquí es completamente renderizado en el cliente. Así que si recargo esto, verán algunos problemas con la renderización en el lado del cliente. Así que si recargo esto, exactamente. Intentémoslo de nuevo. Ahí vamos. Así que dice que no hay chistes. Así que hay este destello de contenido sin estilo o sin inteligencia. Obtiene la data, y luego la data se vuelve disponible. Pero ese no chiste no estuvo bien. Sería bueno si pudiera obtener esa data en el servidor y simplemente enviar los chistes directamente.

Luego hago clic en ¿qué es marrón y pegajoso? ¿Alguna respuesta? Hago clic en esto, y debería ver la respuesta. Pero dice sin respuesta y luego un palo, que un palo es marrón y pegajoso. De nada. Es muy seguro para el trabajo. Y luego cada vez que hago clic en otro chiste, obtengo la respuesta. Pero ven, tiene este destello de sin respuesta. Yuck. Y eso es porque todo está renderizado en el lado del cliente. Si miro la pestaña de Red aquí, en realidad verán las solicitudes de red que ocurren. Así que hago clic en esto, miren todas estas solicitudes.

Y si filtro en Fetch, está haciendo esto. Ahora, si hago esto en el lado del servidor, obtenemos cosas instantáneas. Veamos cómo podemos agregar la renderización del lado del servidor.

Entonces, este es un Git diff, y vamos a repasar lo que cambió. Entonces, en el primer paso, añadimos un servidor. Esto es literalmente un servidor Express que añade la renderización del lado del servidor. Entonces, lo que estamos haciendo es que importamos nuestras dependencias. Instanciamos un servidor, y escuchamos en el disco. Esto obtendrá nuestro JavaScript del lado del cliente. A partir de ahí, tenemos un parámetro de ruta slash page. Y lo que sea ese parámetro, simplemente lo requerimos. Esperamos que sea una exportación por defecto de algo en una carpeta de páginas. Así es como funciona Next.js. Obtienes un parámetro de ruta. OK, esto es probablemente un archivo JavaScript bajo páginas. Requiere. Muéstralo. Eso es lo que estamos haciendo aquí. Y luego tomamos eso, y usamos renderizar a cadena para convertir el componente en una cadena HTML, lo enviamos por la red. Eso es todo. Esto es la renderización del lado del servidor en pocas palabras. Es una simplificación excesiva, porque tenemos 20 minutos. Hay un montón de educaciones que no estoy manejando. Usa un marco. Pero esto es sobre el mecanismo. Así que vamos a ejecutar esto ahora. Entonces, voy a ir aquí, y haremos git checkout uno. npm run build. Así que estamos construyendo el servidor, y estamos iniciando el servidor. Eso es todo lo que estamos haciendo.

Y ahora volveremos a mi navegador. Esto es Arc, por cierto. El mejor navegador del mundo. Chicken necesita Hydra. Ni siquiera lo sé. Pero ahora estamos en el puerto 3000, no en 5.1.7.3 slash question. Y dice que no hay chistes, y en realidad no hay chistes en absoluto. ¿Alguien puede decirme por qué? No tenemos chistes, porque lo que estamos haciendo es obtener datos en el lado del cliente. Pero esto se renderiza en el lado del servidor, y no estamos hidratando. No estamos añadiendo el JavaScript después del hecho. De hecho, si miras aquí en las DevTools de React, esta página no parece estar usando React. Entonces, ¿una solución muy fácil a esto sería qué? Sería venir aquí a nuestro servidor, perdón, server.tsx. Y cuando renderizamos a cadena, enviamos el HTML, pero también hacemos script src slash client.js así. Y luego cargamos el JavaScript del lado del cliente. En teoría esto debería funcionar, pero no confío en el efecto de la demostración, así que veamos. Recargar. ¿Estás usando React? Sí, lo estás. Y entonces ahora recogimos React en el lado del cliente. Hidratamos, y funciona. Pero el problema todavía es malo, porque todavía estamos obteniendo datos en el lado del cliente. ¿Ves esto? Y tenemos esto porque la carga inicial es sin data, y luego todavía obtenemos datos en el lado del cliente. Sería genial si pudiéramos obtener datos en el lado del servidor.

Así que avancemos un poco en la historia de git. Vayamos al siguiente commit. Así que agregamos un servidor, pero observa que no cambiamos ningún código de la aplicación. ¿Qué es el código de la aplicación? Veamos el código de la aplicación aquí. Así que si vamos a nuestras páginas slash pregunta, preguntas, lo que estamos haciendo en preguntas, estamos obteniendo esto, yuck. Estamos obteniendo un useEffect, y estamos configurando juke. Nunca deberías hacer esto, por cierto. Esta es la forma menos ideal de obtener data en React. Quieres obtener datos en el lado del servidor lo más temprano posible, es decir, incluso en el ámbito del módulo, nunca en useEffect. Podemos hablar más sobre eso si tienes preguntas.

Entonces, esto es subóptimo, y es por eso que tenemos este feo yuck, sin respuesta, y luego llega la respuesta, y probablemente las bromas se cargarán en segundo plano. Lame, lame. Así que ahora obtenemos datos en el lado del servidor. Cuando obtenemos datos en el lado del servidor, podemos hacerlo de varias maneras. Los componentes de servidor son la forma premier de 2023-plus de obtener datos en el lado del servidor. Así que veamos cómo hacemos esto ahora con componentes de servidor. Si lo hacemos con componentes de servidor, básicamente podemos convertir este componente en un componente asíncrono. Oof. En realidad, tal vez no todo. Así que tendremos bromas iguales, oh espera, oh Dios mío. Mira, wow. Hermoso. Y en lugar de establecer bromas aquí, simplemente devolvemos los resultados, lo que sea que estemos haciendo. Y eso es todo. Pero el problema ahora es que, esto es asíncrono. Esto no es un componente de React, porque los componentes de React no son asíncronos. No puedes hacer esto. Excepto con los componentes de servidor, puedes. Veamos cómo. Así que voy a deshacer todo esto. En realidad, ¿sabes qué? Lo voy a guardar. Y luego vendré aquí y simplemente restableceré mis cambios. Veamos cómo agregamos componentes de servidor a la mezcla aquí. Así que esto es lo que estamos haciendo. Actualizamos nuestro componente de preguntas. Y convertimos este componente en un componente asíncrono. Eso es lo que hicimos. Literalmente, lo que acabo de escribir, lo estamos haciendo aquí. Y también lo estamos haciendo en el archivo de respuestas. Literalmente tomamos un componente y le agregamos async y obtenemos datos aquí en lugar de en use effect.

En nuestro servidor, ¿qué cambios estamos haciendo? Bueno, antes de renderizar a cadena, tenemos otra función llamada unwrap JSX. Unwrap JSX es una función asíncrona que requiere ser esperada. Y ten en cuenta, aquí estamos en el servidor. Y en el servidor, podemos esperar cosas, porque los servidores son asíncronos. Así que esperamos unwrap JSX.

Otra pregunta, ¿qué hace unwrap JSX? Literalmente va componente por componente por componente por componente. Y si un componente es un componente de función, y si ese componente de función es asíncrono, porque tiene un await con una dependencia de data, lo esperará, lo convertirá en un componente regular que no es asíncrono, y luego lo devolverá. Y el código para eso está aquí.

Así que unwrap JSX, si es una cadena o un número o Booleano, entonces no va a ser una función asíncrona. Simplemente lo devolvemos. Si es un array, esperamos todos los elementos en el array. Esto es un fragmento de React. Simplemente lo esperamos. Si es un objeto, entonces si es un elemento de React, y si es un componente incorporado, div, span, p, llamamos a unwrap JSX en sus hijos, a.k.a. props. Si es un componente de función, llamamos a unwrap JSX en sus props, porque las props tienen hijos que pueden ser asíncronos. Y luego esperamos el componente en sí, el componente de función. Lo llamamos con sus props, lo esperamos. Y finalmente, simplemente desenvolvemos todo de forma recursiva. Así que simplemente esperamos todo en el árbol de React. Y al final, lo que obtenemos es un gran árbol de JSX, pero todas las dependencias de data han sido resueltas. Y luego tomamos ese retorno y lo pasamos a renderizar a cadena y simplemente obtenemos una cadena de React. Esa es tu representación básica de componentes de servidor. Simplemente esperas un montón de cosas en el servidor, lo envías. Por supuesto, no necesariamente necesitas enviar una cadena de forma sincrónica. También puedes transmitir una respuesta. Esto es solo simplificado para el mecanismo. Esa es la esencia de cómo funciona. Y porque ahora estás renderizando el marcado inicial en el servidor, puedes hacer algunas cosas realmente geniales. Por ejemplo, puedes tomar todo ese JSX inicial que creaste en el servidor y almacenarlo en la ventana.

Luego, lo que puedes hacer es escuchar la navegación en el lado del cliente. Así que este es el paquete del servidor. Y estamos almacenando la representación inicial en el servidor. Si vamos al índice, lo que podemos hacer es crear una navegación suave. Así que venimos aquí. Escuchamos todos los clics en los elementos de anclaje. Y en lugar de navegar en el navegador, detenemos eso, y llamamos a navegar. Y navegar obtiene otro árbol JSX del servidor y simplemente lo vuelve a renderizar. Así que es una navegación suave.

Y me encantaría mostrarte el flujo completo de componentes del servidor ahora generando el HTML en el servidor para la próxima página y enviándolo y diciendo, hey, React en el lado del cliente, simplemente vuelve a renderizar este árbol. Así que si obtenemos checkout, checkout, discúlpame, checkout para PM run build. Así que este es un flujo completo de componentes del servidor basado en lo que acabamos de cubrir. Así que si venimos aquí y recargamos, iremos a slash question queue. Ahí vamos. No, no. Oh, wow. Redirigió.

Así que ahora tenemos un flujo completo de componentes del servidor donde estamos, si hacemos clic en la broma, ¿verdad? En primer lugar, no hay estilo de, no hay flash de contenido no cargado. Pero también, cuando hago clic aquí, navega. Y la posición de deslizamiento no se interrumpe. Mantenemos el estado. Porque no estamos navegando fundamentalmente en el navegador. Simplemente estamos volviendo a renderizar nuevo JSX. Obtenemos. Veamos qué sucede en el lado del servidor. O más bien, desde la pestaña de red. Así que una vez más, las bromas van a venir de aquí. Y lo que haré es, tengo el inspector de red abierto. Y obtengo. De hecho, pongamos esto a un lado.

Voy a buscar. Así que haré clic en una broma. ¿Por qué el Seis tenía miedo del Siete? Buscar. Y va a cargar. Y ahí. Porque fíjate, no perdimos el estado. Navegación suave a través de los componentes del servidor.

La pregunta es, ¿qué buscamos? Y si vamos a la respuesta, esto es lo que buscamos. Permíteme hacer esto grande y claro para que puedas ver. ¿OK? El tipo de es re. Props. Hijos. Así que tenemos head. Tenemos HTML head body. Y luego, en los hijos, tenemos un div. Es básicamente la próxima página expresada como React componentes desde el servidor al cliente.

React en el lado del cliente dice, oh, sé lo que es esto. Y luego simplemente llamamos a re-render. Decimos, vamos a renderizar. Haz tu diferenciación de DOM virtual. Y luego haz la próxima página sin ninguna navegación dura. Esta es la esencia de los componentes del servidor. Renderizas un montón de componentes en el servidor. Los esperas. Luego los pasas a un renderizador del servidor. Y luego los envías. Y esto permite la navegación suave. Si miramos el código, todo ahora es asíncrono. Así que literalmente async await. Este es un componente del servidor aquí.

Es ts-ignore porque las definiciones de TypeScript no saben cómo lidiar con las promesas devueltas por esto. Pero esa es la esencia de ello.

Así que en el lado del servidor, tenemos la función unwrap JSX que hace esto. Hemos hablado de esto. Y luego tomas el valor de retorno de la función unwrap JSX, lo pasas a renderizar a cadena, o incluso a renderizar a flujo, no importa. Y esa es la interacción entre los componentes del servidor y la renderización del lado del servidor. También puedes enviar eso directamente a un cliente. No necesitas eso. Pero así es como se hace normalmente.

Un comentario final al cerrar, no puedo creer que han pasado 20 minutos, al cerrar, es que los componentes del servidor desordenan un poco la semántica de las cosas. Porque los componentes del servidor React se renderizan en un servidor de componentes del servidor, y luego se pasan al renderizador del lado del servidor, que es un cliente del renderizador de componentes del servidor. Así que el servidor, en este caso, es el cliente. ¿Está claro? Si no está claro, no está claro para nadie. Pero no, hay un servidor. Y el renderizador del lado del servidor es un cliente de ese servidor. Pero el navegador es un cliente del renderizador del lado del servidor. Por eso los componentes del servidor es fundamentalmente un mal nombre. Al igual que los componentes del cliente, que, por cierto, no hablamos de los componentes del cliente. Y no lo teníamos en la demostración. Pero un componente del cliente comienza con la directiva, use client. Y esto es una señal para el bundler, el sistema de construcción, TurboPack, Tobias. Cuando el bundler ve use client, mientras compila las dependencias, dice, OK, esto, voy a dividirlo en un paquete separado, enviar ese paquete al navegador, y luego cargarlo solo en el lado del cliente. Así que el renderizador del servidor renderizará un pequeño hueco que el navegador llenará para los elementos interactivos del cliente. Así es como funciona.

20 minutos, no es suficiente para profundizar tanto como queremos, pero estaré todo el día. Estoy feliz de hablar de esto con ustedes y realmente solidificar su comprensión de los componentes del servidor React. Porque creo, en resumen, que tengo que concluir, desafortunadamente. Pero creo que hay mucho síndrome del impostor en este espacio. Hay mucho lenguaje esotérico donde la gente puede no tener la comprensión más sólida de esto. Y me encantaría desmitificar algo de eso.

Me encantaría darte la confianza para tener conversaciones de alta calidad. Así que entra en Slido, entra en x, anteriormente Twitter, avísame. Y estoy feliz de responder a tus preguntas. Para concluir, hay mucho contenido sobre esto en YouTube. Y también recientemente escribí un libro sobre React que profundiza en este tipo de cosas. Saldrá a la venta en marzo del próximo año. No lo compres si no quieres. No estoy aquí para hacer un discurso de venta. Honestamente, es solo si encuentras interesante este material. Con eso, React Deberlin, muchas gracias por tenerme. ¡Woohoo! ¡Woohoo! Muy bien.

Tenemos una pregunta entrante. Y estoy bastante seguro de que están llegando. La gente está tan absorta con la charla. Una cosa que me intriga, porque me encanta esta filosofía de sumergirse en la caja negra. Porque creo, y definitivamente he sido culpable de esto, a veces es fácil simplemente decir, ah, alguien más ya lo ha pensado. No necesito preocuparme. Sé que esto no se limita necesariamente al lado del servidor, a los componentes del servidor. Pero en general, ¿cuáles son algunos enfoques que alguien puede seguir, si quiere descubrir qué hay debajo de la caja negra? ¿Cómo pueden ir y encontrar esa información? Es una gran pregunta.

Esta charla fue inspirada por el trabajo de la community, como la mayoría de las cosas en React. ¿Alguien conoce a Dan Abramov? Dos personas. Toma eso, Dan. No, pero probablemente le gustaría eso. No, pero Dan escribió un largo artículo sobre cómo creas React components desde cero. Y eso fue lo que me enseñó. Y luego también, estuve en React Advanced London. Saludos, Git Nation, donde Dan vive en Londres, estaba allí. Y tenía algunas dudas, pero simplemente le pregunté. Le dije, explícame esto. Y no paré. Quiero decir, él es una persona muy inteligente, pero yo no. Y entonces cuando una persona no tan inteligente habla con una persona muy inteligente, te preguntas, ¿estás hablando en griego? Y entonces siento esta tendencia a, OK, tal vez solo fingiré que lo entiendo para al menos parecer cool. Pero no hice eso. Y creo que esto es algo que puedo dar a la gente para aprender las cosas subyacentes es encontrar a un experto. Hay muchos en esta conferencia, en otras conferencias. Tú eres uno. Y hazles preguntas, y luego no, creo que tengo esta tendencia a fingir que lo entiendo cuando no lo hago. No pares hasta que lo entiendas. Y creo que lo apreciaríamos. Si vienes a hacerme preguntas personalmente, y casi me acosas, como tengo que entenderlo, no lo entiendo. Genial.

Genial. Vamos a hacerlo. Por cierto, el acoso va en contra del código de conducta. Uso el término a la ligera, pero espero que lo entiendas. Bueno, en primer lugar, Lies, eres una persona muy inteligente, en general. Así que muchas gracias por participar. Algunas de las preguntas del público han deslizado. Y también, asegúrate de votar a favor de las preguntas que realmente quieres que se respondan, porque no tenemos tiempo para pasar por todas ellas.

Pero la siguiente realmente es sobre TypeScript. Entonces, ¿cuál es la solución de TypeScript para los componentes asincrónicos? Gran pregunta. Así que simplemente no me gustó NPM install at type slash react at latest. Pero la nueva definición de tipo es buena. Muy fácil. Sí, ni siquiera necesité hacer TS Ignore. Bien, bien.

Y hablemos también de la gestión del estado en la renderización del lado del servidor. Entonces, ¿puedes hablar de eso? Danos algunos tips. Sí, el estado del lado del servidor es muy diferente al estado del lado del cliente, ¿verdad? Porque un servidor presta servicios a múltiples clientes, mientras que el estado del cliente suele ser personalizado. Este es un gran problema. Y gran parte de él se resuelve utilizando estrategias de caché inteligentes en el lado del servidor. Así que idealmente, tienes algún tipo de caché donde la clave es tu ID de usuario único, y puedes mantener su estado allí. Sí. No sé cuánto en profundidad quieres ir, pero ahí es donde empezarías, pensando en la caché y luego invalidando por usuario, por ruta, algo así. De nuevo, Next.js tiene ayudantes para esto, para revalidar la ruta, y así sucesivamente, que te ayudan con eso. Pero esa es la dirección. Creo que hay una cosa donde siempre, tal vez, hay algunas rutas establecidas que puedes empezar para esas, especialmente en Next.js, que es bastante opinado, y luego puedes ir y hacer muchas más cosas también.

Sí, y si organizas tus rutas por ID de usuario, por ejemplo, ya tienes una clave de caché. Absolutamente. Bien, la siguiente, esta es de Ricardo. Gracias, Ricardo. Hola, Tejas, ¿cuál crees que es el mayor obstáculo para llevar RSE a producción en este momento? Nada, que yo sepa. Bueno, me retracto. Creo que es difícil, y esto es solo por falta de educación, creo que uno de los mayores obstáculos es, necesitas re-arquitecturar muchas cosas si tienes una aplicación React existente, especialmente si comenzaste con create React app, o si estás con Vite, simplemente, buena suerte. Creo que eso es un obstáculo, algunos de ustedes se están riendo, pero es cierto. Y luego el otro lado de esto es, es bastante difícil de desplegar, especialmente con acciones de servidor. ¿Cómo razonas, dentro de mi componente React, onClick equals useServer dentro del cierre, cómo extraes esa función y la despliegas como una función serverless? Aquí es donde, Vercel tiene una ventaja tremenda, sin juego de palabras, y, sí, así que creo que el mayor obstáculo para llevarlo a producción es razonar sobre las acciones del servidor y su extracción más la migración incremental a RSE son algunos de los mayores obstáculos allí. Entonces, lo que estás diciendo es, hay algunos obstáculos, ¿crees que se resolverán a corto plazo, o crees que va a llevar un tiempo? Creo que definitivamente hay un impulso allí, pero por supuesto, la menor fricción es simplemente usar Vercel. Y me encantaría ver que eso no sea el caso, no porque tenga mala voluntad contra Vercel, pero quiero democratizar RSE. Sí, así que espero que se resuelva a corto plazo, pero no lo sé.

Bien, genial, tenemos tiempo para una pregunta más, pero recuerda, incluso si no llegamos a tu pregunta ahora, podrás encontrar a Tejas en el lugar de discusión de preguntas y respuestas cerca de la, cerca de la... Pista de uso memo. No desinformación, no sé. No la pista de uso memo, cerca de la recepción. Eso es lo que quería decir, mi cerebro se quedó en blanco. Bien, la última de Mr. O, ¿cómo los debug? ¿Construyes y ejecutas el servidor una y otra vez? Bueno, no, quiero decir, esto fue solo porque es una demostración perezosa. Preparé esto ayer. Tú debug, ¿cómo debug los componentes de servidor React? Si es esto, ¿cómo lo debug? Sí, pero podrías usar v-node, que te da como recarga automática al guardar, por ejemplo. Pero para debug RSCs, si estás usando un marco de trabajo, el marco de trabajo te ayudará. Como Next.js simplemente te dará advertencias, advertencias inteligentes en la consola, en el aire, etc. Sé que Remix está pensando en RSCs, los componentes de servidor React también, pero en este momento, Next.js es el único marco de trabajo y te ayudará. Así que de nuevo, si no fui claro al principio, no crees tus propios componentes de servidor React todavía. Esto fue solo para enseñarte mecanismo, usa un marco de trabajo. No, me encanta eso. Y creo que también es importante, a veces simplemente salir de las herramientas, para entender lo que las herramientas están haciendo por ti, luego volver a las herramientas para realmente hacer el trabajo también. Y pensar, ya entiendo, lo entiendo, puedo enseñarlo. Y si por alguna razón, alguien tiene un colapso nervioso y borra el código de fuente abierta, probablemente podría acercarme en mi propia implementación. Esa es una alta estimación de mis habilidades, pero no una alta estimación de las tuyas. Muchas gracias, Tejas. Demosle un aplauso también. ♪ Hey, hey, hey, hey, hey, hey, hey, hey, hey, hey, hey ♪ ♪ Hey, hey, hey, hey, hey, hey, hey, hey, hey, hey, hey, hey ♪