Por qué Todos Necesitan un Marco de Trabajo

¡Hola! ¿Cómo estamos? Bueno, trabajaré con eso. Es la última charla del día. Sabes, dato curioso, tengo 25 minutos. Está en 16 minutos. Tengo 20 minutos, ¿verdad? Pero es la última charla, así que técnicamente, tengo todos los minutos. Porque la fiesta después de aquí es a las 7. Pero de todos modos, intentaré respetar tu tiempo. El organizador me está mirando aquí como, hey, hey, ahora.

Soy Tejas. Se pronuncia, como, contagioso. Puedo decir eso ahora porque las cuarentenas, en su mayoría, han terminado. Y he tenido el privilegio de trabajar en alguna capacidad, ya sea como consultor o como empleado en varias empresas de tecnología a lo largo de mi carrera. Y es una oportunidad por la que estoy realmente agradecido. Y a través de ella, llego a experimentar un montón de cosas diferentes, ¿verdad? Hoy, dirijo una pequeña pero efectiva agencia de relaciones con desarrolladores donde apoyamos herramientas para desarrolladores, empresas orientadas a desarrolladores, comunicamos, transmitimos su mensaje y realmente refinamos esa experiencia de desarrollador, ¿vale? Pero eso no es de lo que estamos aquí para hablar hoy. Hoy estamos aquí para hablar de por qué todos necesitan usar un framework. Y podrías estar leyendo esto y preguntándote, ¿qué significa eso? ¿Todos necesitan usar un framework? Idealmente, aclaramos algunas de esas cosas hoy. Solo necesito hacer una aclaración. No soy... No trabajo en React. He estado trabajando con React desde 2013, 2014, y lo amo profundamente. Tengo el privilegio de conocer a algunos del equipo. Y el trabajo que hacen es inspirador e intelectual y resuelve problemas del mundo real con abstracciones altas que simplemente hacen el trabajo y te hacen a ti, chicos, los héroes. Así que si podemos escucharlo por el equipo. Realmente lo agradecería... Sí. Sí. Ha... Creo que es quedarse corto decir que React ha revolucionado la forma en que construimos en la web. Y creo que vale la pena reconocerlo.

Entonces, ¿por qué todos necesitan usar un framework? ¿De dónde viene esto? Anteriormente en X, la plataforma anteriormente conocida como Twitter, Andrew Clark del equipo de React en Vercel publicó esto en enero. Dijo, si usas React, deberías estar usando un framework de React. Si tu aplicación existente no usa un framework, deberías migrar incrementalmente a uno. Si estás creando un nuevo proyecto de React, deberías usar un framework desde el principio. Algunos de ustedes podrían estar pensando, ¿pero no es React un framework? ¿Es React una biblioteca o un framework? No estamos haciendo eso hoy. Vamos a las redes sociales y peleamos. No. Pero por framework, a lo que Andrew se refiere es algo como Next.js o ReMix, etc. Y me encanta esto. Yo uso framework. ¿Alguno de ustedes está usando frameworks aquí en producción? Bueno, casi todos. Para aquellos de ustedes que no, hablemos de por qué. Y esto es lo que quiero hacer hoy. Esto es genial, pero quiero entender el mecanismo que nos lleva a llegar a esa conclusión. Como, ¿por qué uno dice esto? Y para entender el mecanismo, tienes que responder a la pregunta, ¿qué es un framework? Y un framework es esencialmente un conjunto de opiniones. Es un marco dentro del cual trabajas, literalmente. Te da opiniones sobre el enrutamiento, sobre la obtención de datos, sobre dónde renderizas el servidor o el cliente en algún lugar intermedio. Y estas opiniones se manejan por ti para que puedas, ¿qué puedes hacer? Puedes construir tu producto con velocidad. No tienes que resolver estos problemas individualmente. Así que son las opiniones las que te ayudan a acelerar tus flujos de trabajo de desarrollo, ¿vale? Si refinamos un poco, ¿qué hacen los frameworks? ¿Qué hacen los frameworks? Bueno, muchos de ellos se superponen. Esto puede que no sea cada framework, pero Next JS, Remix.

Realizarán la renderización en el lado del servidor. ¿Cuántos de ustedes hacen la renderización en el lado del servidor en producción? Vale. Casi todos los que usan un framework, genial. Resuelven el enrutamiento pero no solo en el lado del cliente. También en el lado del servidor. Enrutamiento isomórfico. Y esto es útil por varias razones porque anteriormente, cuando estábamos haciendo solo cosas del lado del cliente, solíamos enviar 404's. No sé si todos ustedes recuerdan esto. Solíamos enviar códigos de estado 404 desde el lado del servidor y luego una página 404 HTML se activaría en el lado del cliente y te daría una aplicación. Pero esto es fundamentalmente una mentira del cliente al servidor, ¿verdad? Y los frameworks resuelven eso.

Número tres, la obtención de data es tremendamente más fácil con los frameworks. Si te pregunto, ¿cuál es el mejor lugar y cuándo es el mejor momento para obtener data en tu aplicación React? ¿Qué me dirías? ¿Me dirías que uso el efecto y obtengo dentro del efecto y luego establezco el estado? Ese es un patrón muy común pero es un patrón problemático porque conduce a ¿qué? Conduce a, te veo, esto es React Advanced. No estamos en el jardín de infantes aquí, ¿verdad? Conduce a cascadas de red. Conduce a cosas lentas. Tienes que renderizar primero, eso lleva tiempo. Está limitado por la CPU y luego tienes que obtener y luego tienes que renderizar y no es rápido, no es eficiente y tu user experience sufre. Así que los frameworks resuelven muchos de estos problemas para nosotros y más. De hecho, resuelven todos los casos extremos que probablemente pasamos por alto porque están construidos por comunidades muy grandes que se encuentran con problemas que nosotros podemos tener el próximo año hoy. OK.

Así que esa es la teoría de ello pero ya estoy aburrido con mis diapositivas y supongo que simplemente haremos una pequeña demostración de eso. Esta es una demostración que resuelve esas cosas. Resuelve la renderización en el lado del servidor, resuelve la obtención de data, etc. Es algo interactivo y es el final del día, simplemente juguemos. Como estamos hablando de renderización en el servidor y obtención de data, necesitamos una aplicación de pila completa. Necesitamos un frontend, necesitamos un backend. Hay muchos backend listos para usar. Si necesitas una API rápida, está dog.ceo donde puedes consultar un montón de perros. Como estamos en Londres, estaba buscando un buen backend. Resulta que encontré una startup con base en Londres que ha estado muy callada pero ha estado construyendo algo realmente genial. Me sentí tan compelido, cené con los fundadores anoche. Me sentí tan compelido que simplemente lo puse en mi presentación y se lo mostré a todos. Tengo permiso para esto pero quiero completar toda la pila de la pila. Esta es la aplicación que tenemos, así que si vamos al navegador, si vamos al código, OK. Así que es una aplicación de chistes. Dice que no hay chistes. No sé si puedes leer eso, es intencionalmente pequeño pero esencialmente va a consultar una database donde viven los chistes y los renderizará. Primero en el lado del cliente, luego en el servidor y lo haremos juntos. Pero necesitamos llenar esta database de alguna manera. Permíteme guiarte un poco por el código y luego lo llenaremos de forma interactiva. OK. Es el final del día así que juguemos un poco. Si miramos el código, ¿qué tenemos? Tenemos una aplicación React aquí. ¿Ese tamaño de fuente está bien? ¿Puedes ver en la parte de atrás? ¿A nadie le importa? Genial. OK. Vamos... ¡Boom! Ahí vamos. Así que, una aplicación React muy básica. Estamos hidratando el documento con un diseño y si tenemos un ID de chiste, es una respuesta, de lo contrario es una pregunta. Es un tipo de chiste de pregunta y respuesta, ¿verdad? ¿Por qué cruzó el pollo la carretera? Porque había hidratación, no lo sé. Lo que sea.

Y esta es nuestra aplicación. Tenemos preguntas, que es un componente que efectivamente obtiene data, pero no hay data. Así que vamos a repasar un poco el backend. El backend, estoy usando este arranque sigiloso, se llama keel. Es un backend tremendo, francamente. Este es el sitio web. Y lo que me resultó convincente es que es un solo archivo. Escribe un archivo, haces git push y se convierte en infraestructura. Y luego abres una solicitud de extracción, cambias el... Es una locura. La infraestructura es código, pero no aportas nada propio. Está totalmente gestionado. Y me ayudó a preparar esta demostración muy rápido.

Entonces, el backend es esencialmente este esquema. Si vamos a aquí... ¿Qué tenemos? Esta es nuestra database. Tenemos un chiste, tiene estos campos, una pregunta, una respuesta y una fuente. Y estas son las cosas que puedo hacer desde mi API. Así que obtengo una API gratis. Puedo listar chistes, puedo obtener un chiste por ID. Incluso puedo validar un chiste. Escucha esto. Este es el momento. Puedo validar un chiste usando IA, de verdad. Y entonces, validar chiste, y está aquí. Y si miro la implementación del código, todo esto, por cierto, es código generado a partir de este archivo. Realmente no escribo ninguno de esos códigos. Y si voy a validar chiste, este es el código aquí. Entonces, obtengo la pregunta. Y me aseguro de que tenga al menos tres palabras. Y luego, hablamos con OpenAI, y decimos, para este chiste, ¿tiene sentido como un chiste? ¿Respondes con JSON, verdadero o falso? Ese es el backend completo, la API completa, funcionando en Keel solo con un documento. Y lo que quiero hacer en nuestro tiempo juntos es realmente hacer eso.

Entonces, como puedes ver, en nuestra aplicación, no tenemos chistes. Hagamos chistes. Lo que quiero que hagas es crear un chiste. Entonces, ¿cómo vamos a hacer eso? Escanea este código QR. Te prometo que no es porno ni nada. Solo confía en mi palabra. Código de conducta, lo siento. No, pero escanéalo, y eso te llevará a WhatsApp, si tienes WhatsApp. Es una conferencia de Facebook, más o menos. Y lo que vas a hacer es enviar un chiste por texto. Entonces, primera parte, ¿por qué a los desarrolladores les gusta el modo oscuro? Envía eso. Y luego la segunda parte, porque atrae a los bugs, porque la luz atrae a los bugs, ¿verdad? Entonces, algo así, ¿vale? Entonces, envías una pregunta, y luego dirá, gran pregunta, y luego envías una respuesta. Experimenta. Lo intentaremos. Si no funciona, la gente de Keel está aquí. Simplemente lo arreglarán. De todos modos, entonces, estoy curioso. ¿Alguien tiene WhatsApp funcionando? ¿Sí? Al menos uno.

Gracias a Dios. Vale. Entonces, abrí algo a internet y estoy asustado porque sé de lo que eres capaz. Por favor, no seas grosero.

Vale. Echemos un vistazo a nuestra aplicación de chistes. Y si recargo, idealmente debería tener algo. Si no, ¿sabes qué? Simplemente iré a WhatsApp ahora mismo. Este es mi WhatsApp. Bienvenido. No puedes ver mis mensajes. Y enviaré un chiste aquí mismo. ¿Qué es... No, no, no. ¿Por qué a los desarrolladores les gusta el modo oscuro? Y ahora, dependiendo del internet de la conferencia, debería decir que le encanta. ¿Cuál es el remate? Ahí lo tienes. Porque la luz atrae a los bugs. Hilarante. Por favor, dime que es un buen chiste. Lo que pasa es que, porque es... Oh, genial. Se guardó. Vale. Oh, y hay un anuncio. Genial.

En fin, recarguemos. Y lo que deberíamos ver ahora es que estamos recuperando data. Genial. Mucha gente. Gracias. Apláudanse a ustedes mismos. Eso es increíble. Entonces... ¿Qué es marrón y pegajoso? ¿Por qué? Nunca puedes confiar en las personas en internet. Ni siquiera voy a hacer clic en... En fin. Entonces, por cierto, creo que todo eso marrón y pegajoso... ¿Yo? ¿Quién dijo eso? Dependiendo del juego al que estemos jugando. ¿Sabes a lo que me refiero? Entonces, todo eso proviene de un solo archivo. Ese back-end completo... Y creo que esto es realmente impresionante. Llegaremos al framework en un minuto, pero esta es la database que tenemos. Entonces, vamos aquí. Estos son tus chistes que ingresaste. Estoy arruinando los remates, pero no los veré. Pero mira esto. Inventaste todo esto. Increíble. En fin. Volvamos al framework.

Entonces, tenemos esto. ¿Por qué el Seis tenía miedo del Siete, etcétera? Ahora, veamos esto. Esto está completamente renderizado por el cliente. Y puedes ver eso por el flash de Unstyle. Mira esto. Dice, no hay chistes, y luego busca y usa el efecto. Esto es un poco molesto. Veamos el código de React que impulsa esto. Vamos a las páginas de preguntas, y vamos a las preguntas, y esto es lo que estamos haciendo. Entonces, estamos buscando desde aquí. Estamos haciendo listado de chistes. Estamos obteniendo los primeros 10, y luego establecemos el estado. Todo en el lado del cliente. Y realmente este no es el mejor método debido a las cascadas, etcétera. Y luego finalmente devolvemos un mapa. Básicamente iteramos sobre todas las preguntas. Si has escrito en React, esto no es nuevo para ti. El problema es que esto es completamente del lado del cliente. Tenemos este flash de nada al principio, mientras buscamos. Esa es la cascada. Pero aún peor, se podría argumentar, es que si vemos la fuente, el marcado está realmente vacío. No hay texto. No hay chistes. No hay nada. Entonces, en un entorno donde JavaScript no es compatible, los motores de búsqueda que tal vez no ejecutan JavaScript, no obtienes nada. Nada. No hay nada aquí. Queremos que el framework resuelva esto a través de qué? A través del renderizado del servidor. ¿Correcto? Así que implementemos eso.

¿Alguien ha implementado el renderizado del lado del servidor desde cero? ¿Alguna vez? ¡Sí! ¡Mi gente! ¡Tres de ustedes! ¡Fantástico! El resto de ustedes, vamos a hacerlo. No tenemos tiempo para codificar en vivo. Vamos a hacer algunas gimnasias de git, pero lo superaremos. ¿De acuerdo? Solo estoy... Un aplauso, porque les mostré mi WhatsApp y censuré mis chats privados. Creo que eso es brillante. Sí. Fantástico. Asombroso. No puedes... Algunas de estas cosas, no deberías ver, y no lo haces. Así que eso es genial. Muy bien. Así que vamos a ver cómo añadir el renderizado del servidor a esto. Lo que vamos a hacer es abrir el editor a tiempo completo, y aprendí un truco en git. Esto es... Creo que todos ustedes podrían aprender esto. Así que en git... ¿Verdad? Puedes revisar un commit por mensaje de commit. ¿Alguien sabe cómo hacer esto? Aprendí esto de la charla. ¡Nadie! ¡Ah! ¡Estás aprendiendo cosas! Así que para revisar un commit por mensaje... Mira esto. Tengo un... Este es mi registro de git. Whip, whip, whip. Tengo añadir permiso como mi mensaje de commit. Así que si voy a git checkout, y luego en un string colon slash mensaje de commit, boom, voy allí. Es fantástico. Gracias. Hoy, aprendiste, y si aprendiste, por favor publica en las redes sociales para que lo vea allí. Así que vamos a revisar la historia. Vamos al paso cero. Ese es mi commit aquí. Paso uno, más bien, lo siento. Y en el paso uno ahora, tenemos un servidor. Así que vamos a ver nuestro servidor, server.tsx. Esto es renderizado del servidor, pero en su forma más básica, ¿OK? Solo estamos entendiendo el mecanismo. No hagas esto en producción, ¿OK? Entonces, ¿qué estamos haciendo? Estamos importando React. Y esta función de renderizar a cadena no es realmente utilizable para la producción hoy en día, diría, porque es sincrónica. Bloquea. Idealmente, usas algo asíncrono, como renderizar a tubería de flujo o renderizar a nodo de flujo, que implementa la, o renderizar a flujo legible, que implementa la versión del navegador de flujos. Idealmente, usas algo basado en flujos. Por motivos de educación, estamos haciendo esto por razones que se harán evidentes eventualmente. Estamos utilizando Express para un servidor, pero podrías usar COA, podrías usar Fastify, podrías usar lo que quieras. Solo me gusta Express y algunas otras dependencias. Así que inicializamos un servidor. Decimos leer CSS y activos estáticos de dist. Y luego hacemos esto. Obtenemos un parámetro de ruta de página. Esto puede ser cualquier cosa.

Esto puede ser pregunta, respuesta. Importamos dinámicamente algo de las páginas dist, y luego lo que sea que esté aquí, ¿de acuerdo? Y esto es realmente por qué dentro de un marco tu página que exportas necesita ser la exportación por defecto porque module.default está estandarizado. Y si haces una exportación nombrada como esta, es imposible de predecir desde el marco. Por eso las opiniones del marco te ayudan a moverte más rápido, ¿de acuerdo?

Así que obtenemos el componente de la página. Lo envolvemos en un diseño. Y luego simplemente enviamos el HTML al cliente. Eso es todo. Tienes el renderizado del lado del servidor para ti. Finalmente, escuchamos, ¿verdad? Esto no es tan complejo como 25 líneas de código. Así que echemos un vistazo a esto ahora, funcionando en el navegador. Así que haremos NPM run build para agrupar todo y simplemente lo iniciaremos, ¿de acuerdo? Y ahora pasaremos del puerto 5173 que es VEET en el cliente al puerto 3000. Y tenemos el renderizado del lado del servidor pero dice no hay respuesta. ¿Qué está pasando?

Así que vamos a slash question y dice no hay chistes. Una cosa realmente importante a mencionar aquí es que estamos haciendo enrutamiento basado en el sistema de archivos, ¿verdad? Así que si simplemente miramos la ruta y luego importamos el módulo. Así que efectivamente tenemos páginas slash question y estamos en slash question aquí. Pero el problema es que no hay chistes. ¿Por qué no hay chistes? Es porque no estamos recuperando data. Literalmente estamos renderizando a cadena. Estamos recuperando en use effect pero use effect no se ejecuta en el lado del servidor. Así que ahora tenemos renderizado del servidor pero es una solución a medias. ¿Cuál es la otra mitad? Recuperación de data. Tenemos que recuperar data de alguna manera. Ahora hay varias formas de recuperar data. Hay get server-side props. Puedes imaginar cómo se hace, ¿verdad? Quiero decir, ya estamos importando, si echamos un vistazo aquí, ya estamos importando la exportación por defecto de este archivo. Literalmente podríamos importar dot get server-side props. Esto es literalmente lo que hace Next.js. Y llamamos a esta función, recuperamos la data aquí, la pasamos como props, OK. Es React avanzado. Supongo que puedes llegar allí porque no tenemos tiempo. Pero esto es esencialmente cómo lo hacen los frameworks bajo el capó. Quiero ver la novedad para la recuperación de data, que son los componentes del servidor. Los componentes del servidor son la respuesta a la recuperación de data. Es la respuesta, punto. Estaba hablando con Satya aquí quien mencionó que es como relay, pero para todos. No dijo exactamente eso, lo siento. Lo representé mal. Va a venir a verme después. Pero los componentes del servidor son el camino. Así que hablemos de los componentes del servidor implementando los componentes del servidor desde cero, en el tiempo que tengamos. Yo no hice esto. No soy un experto en React. Solo lo he usado durante mucho tiempo. Esto se deriva en gran medida del trabajo de Dan Abramov, quien escribió los componentes del servidor desde cero. Literalmente, esta es la página de GitHub que él escribió. Eres bienvenido a leerla. Es larga e informativa. Y la aprendí, la leí, y pensé, ¿sabes qué? Esto debería ser una charla. Y así que le pregunté a Dan, ¿te importaría si yo... Y él dijo, sí, hazlo.

Así que eso es lo que es esto. Puedes ir a leer eso. Pero esto es lo interactivo, como, te mostraré lo que dice. Vale. Entonces, ¿cómo hacemos los componentes del servidor? Bueno, para empezar, necesitamos... ¿Qué es incluso un componente del servidor? Eso es un gran lugar para empezar. Un componente del servidor es un componente que se ejecuta exclusivamente en el servidor. Es un... Todos los componentes son funciones. Los componentes de función son funciones, los componentes incorporados no lo son. Los componentes de función que se ejecutan solo en el servidor se llaman componentes del servidor. Se ejecutan en el servidor. ¿Y qué devuelven los componentes de función de React? Esa es la pregunta. ¿Qué devuelven? Devuelven JSX. Pero devuelven objetos JavaScript. Cada componente de función de React devuelve algo. Como el tipo es ya sea un componente de función, como este. Y luego las propiedades, ¿verdad? Y luego las propiedades son... Ups. Las propiedades son como esto. Y luego un array de hijos. Como, esto es la mayoría de los componentes de React. A veces, con los componentes del servidor, este tipo puede ser asíncrono. Y luego te metes en, como, problemas. Como, porque React no puede renderizar promesas. Así que necesitas de alguna manera desempaquetar las promesas. Y aquí es donde los componentes del servidor se encuentran con la renderización del lado del servidor. Si esto no está claro, simplemente hagámoslo. Escribamos el código y exploremos esto juntos. ¿Vale? Entonces, ¿cómo tomamos, por ejemplo, nuestro componente de pregunta y lo convertimos en un componente del servidor? Vamos aquí. ¿Vale? Estamos haciendo algunas búsquedas aquí. Si quisiéramos convertir esto en un componente del servidor, ¿qué hacemos? Nos deshacemos del estado de uso, para empezar. Y básicamente, venimos aquí, y esperamos. Y sí, el componente con componentes del servidor es un componente asíncrono. ¡Oh! Fantástico. Nos deshacemos del array de dependencias. Nos deshacemos de... Mira esto. Mira. Mira. ¡Uf! Vale. Entonces, nosotros... Nos deshacemos de un montón de cosas. Y finalmente, el TypeScript no sabe muy bien que los componentes pueden ser asíncronos. Así que lo solucionamos como solucionamos todos los problemas de TypeScript. Haciendo eso. Así que, esto ahora... Gracias por reír. Es valioso. Entonces, esto es...

Matt Pocock no está aquí, así que estamos bien. Entonces, esto es ahora oficialmente un componente del servidor, conceptualmente. ¿Cuál es el problema? React no puede renderizar promesas. Y cualquier cosa asíncrona devuelve una promesa. Por lo tanto, necesitamos algún proceso para esperar todo, obtener todos los data, y convertir las funciones asíncronas en componentes de función regulares. Necesitamos que esa pieza exista.

¿Cómo funciona eso? Veámoslo revisando la siguiente parte. Así que guardaremos todo, y revisaremos el número 2. Entonces, algunas cosas han cambiado. Esto es ahora un componente completo del servidor, async await. Veamos qué pasó en el lado del servidor. Si vamos a server.tsx, un par de cosas. Tenemos esta nueva función llamada unwrapjsx. Unwrapjsx, y esto de nuevo es para fines de aprendizaje, es mucho más complicado, pero esto es de la cosa de Dan. Unwrapjsx es una función que mira tu gran árbol de objetos de React, ¿verdad? Cada aplicación de React, una vez más, llega a tipo es, digamos que el tipo es un div, y las propiedades son algo con hijos, y los hijos podrían ser literalmente como un conjunto de objetos de React profundamente anidados de objetos, ¿verdad? Así que esto es válido. De hecho, tal vez le demos algún valor. Bien, así que mira esto. Así que esta función unwrapjsx mirará esto y dirá, los hijos pueden ser una cadena o un número o un Booleano o un array de cosas. Esto es realmente legal. Incluso podría ser un componente de función asíncrona. Podría ser cualquier cosa. Además, en lugar de un componente incorporado que es una cadena, esto es válido. Y con los componentes del servidor, incluso esto es válido, ¿verdad? Así que un montón de cosas son válidas. Así que esta función de desempaquetado va a mirar todos estos casos y devolver un JSX ponderado. ¿Claro? Así que si nuestro JSX aquí que le estamos pasando es una cadena o un número o un Booleano, que es válido, ¿verdad? Podríamos hacer algo como, como los hijos podrían ser esto. Técnicamente incluso podría ser esto. En este caso, simplemente lo devolvemos tal como está. Si es un array, esperamos todas las promesas que existen en el fragmento del array. Si es un objeto, y luego si ese objeto es un elemento de react, esta propiedad, $$typeoff, indica que un objeto no es sólo un objeto, sino que es un elemento de react. Así que si es un elemento de react, ¿entonces qué? Hay dos tipos, ¿verdad? Hay funciones e incorporadas. Así que manejamos el caso incorporado por, si hay alguna propiedad asíncrona, que puede ser hijos, nosotros los esperamos. Para los componentes de función, similar. Esperamos las propiedades, luego llamamos a la función con sus propiedades. Esto es react, ¿verdad? Llamas a tu componente con sus propiedades, lo esperas, y luego lo desenvuelves. Así que simplemente pasamos por todo este largo árbol y esperamos todo. Y al final de ello, ¿qué tenemos? Tenemos un gran árbol con todas las dependencias de data resueltas. ¿Está claro? Simplemente tenemos un árbol con todo obtenido. ¿Entonces qué hacemos? Luego, entregamos ese árbol a renderToString, o renderToPyblestream, o algo que luego tome la salida de los componentes del servidor y la pase por la red. En este caso, el renderizador del lado del servidor, renderToString, renderToPylblestream, etc, se convierte en un cliente del renderizador de componentes del servidor. Así que el servidor es el cliente. Se complica un poco, pero eso es esencialmente lo que está pasando.

¿Cómo se ve esto en la práctica? Bueno, si venimos aquí a nuestra página de router slash, estamos importando dinámicamente la exportación por defecto. Antes de renderToString, hemos añadido otro paso. Desenvolvemos el JSX. Desenvolver simplemente significa esperar todas las promesas. Así que pasamos nuestra aplicación. Decimos, hey, si hay algo asíncrono aquí, espera todo eso. Y luego dame un árbol JSX con todas las dependencias de data resueltas, renderiza eso a una cadena y envíalo. Veamos cómo funciona eso. Así que ten en cuenta, no estamos usando React en el lado del cliente en absoluto aquí.

Entonces vamos a ejecutar NPM run build, construir un servidor y ejecutarlo, y recargaremos. Y ahí vamos. Así que estamos obteniendo data en el servidor. Esto se renderiza completamente en el lado del servidor. Si abro las React DevTools, esta página, no sé si puedes ver eso, pero dice que esta página no parece estar usando React. Todo se renderiza en el servidor, incluyendo las dependencias de data que se obtienen en el servidor, y obtenemos una página completa. Y algunos de ustedes me están mirando como diciendo, vaya, acabas de inventar PHP. No es cierto. Y llegaremos a eso en un minuto. Esto es mucho más rico porque si vemos la fuente ahora, lo que vemos es una gran cadena de HTML con todos los chistes. ¿Por qué estaba... Dios, hagamos esto mucho más grande. Entonces, ¿por qué el seis tenía miedo del siete? Vemos el otro chiste. ¿Qué le dijo el ojo izquierdo al ojo derecho? Etcétera. Así que tenemos un marcado rico que otros clientes ahora pueden recoger y leer. Es absolutamente fenomenal. Y también, si estamos haciendo grandes importaciones de formateadores de fechas masivas y cosas así, todo eso sucede en el servidor, no enviamos nada de eso al cliente. De hecho, ni siquiera enviamos React al cliente. No hay JavaScript en el cliente. Es brillante, ¿verdad? Entonces, ahora podrías estar pensando, está bien, eso es genial, pero eso es exactamente donde empezamos.

Más o menos. ¿Qué podemos hacer ahora? Dado que el renderizador de React componentes del servidor te da un gran objeto JSX, ¿quién más habla este objeto JSX? React en el lado del cliente. Oh, está bien. Entonces, lo que podemos hacer ahora es recoger ese objeto JSX y hacer cosas con él en el lado del cliente. Así que déjame mostrarte un caso práctico. Debido a esto, debido al lado del servidor, el renderizado de componentes del servidor, ahora podemos hacer cosas como la navegación suave en el lado del cliente. Veamos eso.

Para empezar, vamos a recoger React en el lado del cliente. Como puedes ver, no estamos usando React en absoluto, así que vamos a añadir React y luego seguir desde allí. Así que vamos a revisar la siguiente rama, el número tres, y una vez más vamos a ejecutar todo. Pero lo que está pasando ahora es que estamos tomando el React del lado del servidor y se lo estamos dando al lado del cliente. Así que aquí, mira. Así que estamos en el servidor, enviando HTML. Cerramos esto, cerramos todo y volvemos a server.tsx. Está bien. Vamos a revisar el número cuatro. ¿Qué? En el... ¿Mi cosa no funcionó? Whoa. Uh, hola. Lo siento. Ya sabes cómo es, log. Git checkout 3. Está bien, genial. Así que lo que estamos haciendo ahora es, tenemos todo nuestro objeto JSX. Estamos añadiendo algunas etiquetas de script aquí para tomar el gran árbol JSX que creamos en el servidor y lo estamos adjuntando al objeto de la ventana, ¿de acuerdo? Y luego también estamos cargando React en el lado del cliente.

Pero lo que está pasando en el lado del cliente, y esto es interesante. Así que esto es totalmente del lado del cliente aquí. Estamos hidratando el documento, no con algún componente de diseño como este, sino que en cambio nosotros estamos leyendo window.initialjsx. ¿De dónde viene eso? Eso viene del servidor, literalmente lo entregamos aquí. El cliente recoge eso y simplemente hidrata basándose en el árbol JSX generado por el servidor, ¿de acuerdo? ¿Cómo se ve eso en la práctica? Vamos a ejecutar npm y ver. Así que haremos esto. Recargar. Está bien. Así que si vemos la fuente de eso, lo que podemos ver es que window.initialjsx es nuestro gran árbol JSX que generamos en el lado del servidor. Literalmente desde el HTML, los hijos aquí son head, etc. Es todo el objeto del documento, ¿de acuerdo? Dado que ahora tanto el cliente como el servidor hablan ese objeto de documento, podemos hacer algunas cosas realmente geniales, y terminaremos con esto. Y espero que esto te dé una buena introducción a los componentes del servidor. Así que iremos a la pregunta. Y nota que el problema que todavía enfrentamos es que no tenemos navegación suave. Así que si hago clic en uno de estos chistes para ver la respuesta, por ejemplo, ¿cómo haces una fiesta en el espacio? Así que si hago clic en esto, observa la posición de desplazamiento. ¿De acuerdo? Hago clic en esto, y se reinicia. Todo comienza desde el lado otra vez. Tú planeta. ¿Cómo haces una fiesta en el espacio? Tú planeta. Me gusta eso. Pero observa lo que está pasando. La navegación no es suave, lo que significa que pierdo el estado cuando navego. Así que de nuevo, hago clic en este enlace, y lo que pasa es que simplemente se reinicia toda la página. Odio eso. Quiero que sea fluido, quiero mantener la animación en marcha.

¿Verdad? Obtienes renderizado del lado del servidor de serie. Y se hace mejor de lo que yo podría hacer aquí. Obtienes data fetching que obtiene en el momento adecuado, que es lo más temprano posible a nivel de servidor-router. No obtienes datos como un efecto de noticias. Y debido a eso, envías un marcado útil a tus usuarios y tus aplicaciones son más fluidas. Obtienes navegación suave, por ejemplo. Todo esto es manejado por ti. Entonces, ¿todos necesitan usar un framework? Y sabes, creo, realmente, no estoy calificado para responder a esta pregunta. Depende, creo, de tu caso de uso. Porque conozco a un montón de gente, Kiel. Ellos usan solo una aplicación del lado del cliente Vite, y funciona para ellos. Así que no lo sé, pero espero que en nuestro tiempo juntos, te haya mostrado el valor de un framework y por qué deberías estar usando uno.

Para resumir, hemos examinado el renderizado del servidor, la obtención de data, los componentes del servidor. Esto es parte de una conversación mucho más larga. Y tengo un canal de YouTube que si quieres ver el completo, esto es como una masterclass de 45 minutos. Esa es la versión completa. Además, estoy escribiendo un libro sobre React donde profundizamos en detalles como este. Y si estás interesado, te recomendaría que lo revisaras. No estoy aquí para venderte nada. Te lo juro por Dios, si no compras esto, no me importa. Pero si estás interesado en los detalles, siéntete libre. Y finalmente, realmente aprecio a Kiel que hizo posible esta presentación. Las personas están aquí si levantarías la mano. Si tienes preguntas sobre backends instantáneos, esas son tus personas. Sí. Como, se trata de lo local. Sabes, estamos en Londres. Es una startup delta con sede en Londres. Me gusta lo local. De todos modos, con eso, quiero decir muchas gracias por tu tiempo y atención. Ha sido un placer absoluto estar aquí. React Advance London. Gracias.

Y tenemos un par de preguntas para ti. ¿Es esto realmente un podcast? Creo que debería serlo ahora. ¿Debería mostrarnos el ruido si esto debería ser un podcast real? No, no es interesante. No está despegando. Está bien. Pasemos a la primera pregunta. Ahora, lo que me gusta del hecho de que obtenemos estos votos a favor es que siempre hay una pregunta picante. Cuidado. Siempre hay una pregunta picante ahí. Tan emocionado. Y tenemos una pregunta. Entonces dijiste, como, deberíamos usar frameworks. Muchas veces las personas inteligentes hacen las cosas mucho más fáciles para que no necesitemos pensar en todos estos casos extremos. Y la primera pregunta es, ¿cuál es tu opinión sobre Angular? Eso también es un framework. Primero que nada, ¿por qué? Hay un nombre. Denis Kruknit. Hombre, eliges la violencia hoy, hombre. ¿Por qué? Mi opinión sobre Angular es que es genial. Es una navaja suiza. Te da una serie de cosas. Y honestamente para grandes aplicaciones enterprise, lo he visto ser extremadamente exitoso. Eso no quiere decir que React no tenga lugar. Ahora la gente va a las redes sociales, le dice a todos que dije que React no es bueno para enterprise. ¿Eso es lo que harás, verdad? ¿Parezco cínico? No, pero sí digo que Angular es fantástico. Creo que es realmente bueno. Creo que para la gran mayoría de las aplicaciones pequeñas a medianas te da mucho poder, quizás demasiado. Así que depende. Siempre depende. Depende, tengo un contador de depende en mi cabeza. ¿Qué esperabas? Creo que estoy en un cinco o seis cuando se trata de preguntas y respuestas, depende. Pero, está bien. ¿Esperaba Dennis que dijera que Angular es malo y que React es el único evangelio verdadero? ¿Eso fue? Bueno, vamos a pasar de las preguntas picantes.

Volveré a la pregunta sobre el chiste, no te preocupes. No lo olvidaré. Pero por ahora, hablemos de algunas preguntas técnicas y volveremos a los chistes al final.

¿Sería posible RSC alguna vez sin un servidor node.js? Muchas empresas ya tienen backends en diferentes lenguajes. Esta es una gran pregunta. Acabo de tener el privilegio de estar en React Alicante, una tremenda conferencia con Daniel Alfonso, con Mateusz, un montón de gente. Somos como una familia o un circo ambulante, dependiendo de cómo veas a los oradores aquí. Pero se está haciendo mucho trabajo en ReasonML, OCaml, incluso Rust para agregar soporte para la renderización del lado del servidor en diferentes lenguajes. Así que no, absolutamente no. No necesitas un servidor node.js. Node.js es un runtime, ni siquiera un lenguaje, así que podrías hacer un servidor bun si quieres. Claro. Fundamentalmente, se trata de tomar un árbol y convertirlo en otro árbol. Puedes hacer eso en cualquier lenguaje de programación. Lo siento. Puede que haya simplificado demasiado eso para la gente de React aquí. Es muy complejo. Pero, sí. No, lo entiendo totalmente.

Muy bien. Haremos una pregunta más y luego pasaremos a las bromas. ¿Eso es justo? ¿Justo? Vale.

Muy bien. Entonces, esta es en realidad sobre Kiel. Y tal vez, si no conoces la respuesta, la gente de Kiel en la primera fila puede gritarla también. ¿Kiel soporta esquemas dinámicos que pueden ser actualizados al vuelo? Tal vez alguien quiera comprobarlo. Sí. Kiel.so.

No conozco la respuesta. Pero lo que sí sé es... Ha sido en gran medida sigiloso, así que no creo que nadie conozca la respuesta. Pero también... Sé que son muy... Están iterando realmente rápido. Y me dijeron... Tengo esto de buena autoridad que... Si necesitas un backend para una aplicación y aún no tienes nada y estás eligiendo, como, SuperBase, Firebase, lo que sea, te construirán tu backend. Gratis. Y así, si necesitas eso... No sé. Habla con ellos. Te encontrarán eso. Ve a comprobarlo. ¿La respuesta fue sí, no, o depende? Depende. Depende. Muy bien. Sí. Otro. Otro. Definitivamente. Vale. Así que, ahora, hay un montón de otras preguntas técnicas. Pero puedes venir y atrapar a Tejas al final, después de que hagamos la ceremonia de clausura. Pero creo que lo que realmente quieres escuchar son las bromas. ¿Quieres escuchar algunas bromas? Sí. Vale.

Muy bien. Aquí está lo que haremos. Iremos a buscar tu portátil, si simplemente lo abres de nuevo. Y veamos si podemos leer algunas de las bromas. Vamos a ponerlo en la pantalla. ¿Deberíamos ponerlo en la pantalla rápidamente? Y mientras hacemos esto, los MCs están simplemente... El resto de los MCs van a venir al lado, y vamos a prepararnos para cerrar esto. Estoy lanzando al equipo técnico uno aleatorio. Muy bien. Veamos cuáles fueron las últimas bromas. ¿Debería leer las bromas con acento británico o sería eso irrespetuoso? ¡Hazlo! ¡Hazlo! ¡Muy bien! ¡Hagámoslo, entonces! Tienes razón.

¿Te gustaría una taza de té? ¿Es eso ofensivo? Juro que no estoy tratando de ser ofensivo. Muy bien. Vamos desde... ¡Esto! La tercera en realidad leí la respuesta. No fue tan malo como esto. ¿Qué es marrón y pegajoso? ¿Vamos a averiguarlo, no? ¿Un palo? ¡Oh, por supuesto! ¿Hacia dónde iba tu mente? Oh, Dios.

Muy bien, ¿cuál es la siguiente? ¿Por qué... Se ha ido. Oh, se ha ido. Se ha ido. Volverá. Volverá... Muy bien, sé que alguien preguntó en el chat acerca de... ¿Por qué el siete tenía miedo de... Espera, ¿por qué el seis tenía miedo del siete? Esa sí la sé. Es porque siete, ocho, nueve. Vale, rápido, rápido. Las bromas han vuelto. La última. Elige una al azar. Vale, veamos. ¿Cuál es la golosina favorita de un desarrollador web? Oh, Dios. Tengo miedo. ¡Galletas! Las dejan por todo el navegador. Es fantástico. Aplaudan. Estoy realmente orgulloso. ¡Esa fue mi broma! ¡Esa fue literalmente mi broma! Gracias, Tejus, una vez más.