Simplificando los Componentes del Servidor

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.

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