Tanstack Start y Cómo Soporta React Server Components

¿Quién ha oído hablar de 10-Stack Dart antes de hoy? ¡Genial! ¿Y quién ha construido una aplicación usando 10-Stack Dart antes de hoy? Bien. Así que para los dos o tres de ustedes que no levantaron la mano, daré una breve introducción.

Entonces, 10-Stack Dart es nuestro framework full-stack para aplicaciones centradas en el cliente. Está construido sobre 10-Stack router, por lo que tiene rutas tipadas, estado de búsqueda, cargadores tipados, todo está tipado, tenemos un caché de enrutador y muchas más características. Además de eso, añadimos características de servidor cuando las necesitas, así que, por ejemplo, streaming SSR, funciones de servidor, middleware y seguridad de tipos de extremo a extremo. Start es compatible con Weed y RSBuild, y tenemos adaptadores para React y Solid.

Hoy, voy a hablar sobre los componentes de servidor de React, y solo se aplican a la versión de React de Start, pero generalmente tenemos un tema de diseño que es construir primitivas que se componen y verás que nuestro diseño de RSC también sigue la misma idea. Antes de hablar sobre cómo 10-Stack Dart maneja los componentes de React, quiero revelar un poco qué es realmente RSC. En muchos frameworks, el pipeline de RSC está oculto. Escribes archivos, añades directivas, y el framework decide cómo se renderizan los componentes de servidor, cómo se decodifica el resultado y, finalmente, cómo sale el HTML de eso.

Separemos el mecanismo de React de cualquier arquitectura de framework. A nivel de React, hay dos cooperaciones necesarias para RSC. Primero, renderizado a flujo legible se ejecuta en el entorno de renderizado de RSC. Los componentes de servidor se ejecutan allí, y los componentes de cliente se convierten en referencias. El resultado es un flujo de datos para React, y eso no es HTML. Ese protocolo propietario se llama flight internamente por React. El segundo paso es una función llamada create from readable stream, y eso se ejecuta en el consumidor de ese flujo, por lo que decodifica el flujo en un valor renderizable de React. Dos consumidores comunes de ese flujo son el navegador y el entorno SSR.

En el navegador, React decodifica el flujo RSC y reconcilia el resultado en el DOM existente durante la navegación del lado del cliente, y eso no involucra SSR en absoluto. Durante SSR, React decodifica el flujo nuevamente, pasa el resultado al servidor de React DOM y produce HTML para la respuesta del documento inicial. Solo para aclarar, RSC no es SSR, y RSC solo produce datos para React, y SSR es solo un posible consumidor. Una vez que vemos RSC como solo una carga útil, el resto de lo que sigue ahora seguirá naturalmente. Puedes buscarlo, almacenarlo en caché, invalidarlo, persistirlo y componerlo.

Así que, antes de profundizar ahora, quiero hacer explícito una cosa. Puede que no necesites componentes de servidor de React. Muchas personas asocian mucho con RSC, pero en realidad no los necesitan. No necesitas RSC para transmitir HTML. React SSR simple con suspense ya hace justo eso. No necesitas RSC para cargar datos en el servidor, y en 10 sec, start y load us. No necesitamos RSC para llamar al servidor o ejecutar mutaciones en el servidor. En 10 sec, start, tenemos funciones de servidor para eso. Así que, ya tenemos primitivas bastante buenas para esas preocupaciones, pero hay casos donde RSC es una primitiva realmente buena, y esa primitiva es la interfaz de usuario renderizada por el servidor, y realmente brilla cuando el código de renderizado de la interfaz de usuario es la parte costosa, tanto en tamaño de paquete como en potencia de cómputo.

Casos de uso comunes son el renderizado de markdown, el resaltado de sintaxis y, en general, solo UI estática pesada en contenido donde el navegador no necesita el renderizador pero quieres enviar el resultado renderizado.

Con eso fuera del camino, veamos cómo tratamos los componentes de servidor de React en 10 sec start. ¿Recuerdas el diagrama en la primera diapositiva? RSC tiene dos cooperaciones. Primero, el servidor renderiza RSC en un flujo de datos, y luego el consumidor lo decodifica. Así que, usualmente, esas dos funciones centrales de React son detalles de implementación ocultos, pero en 10 sec start, las exponemos en nuestra API de bajo nivel.

Así que, la función del servidor simplemente llama a render to readable stream, y esto devuelve un flujo de datos. Los elementos de React entran, y el flujo de flight sale. Luego aquí, una función de consulta llama a este create from readable stream para decodificar el flujo de flight de nuevo en un valor renderizable de React, y, después de eso, puedes simplemente usar esto y renderizar dentro de tu componente junto a cualquier otra cosa. Pero no solo estamos exponiendo estas APIs de bajo nivel, también hemos construido abstracciones sobre ellas. Eso significa que no todas las aplicaciones tienen que pasar flujos y necesitan decodificar nada, así que puedes usar las APIs de capa superior si lo deseas.

En ese caso, una de esas llamadas renderiza el componente de servidor, que nuevamente se llama aquí desde la función del servidor, devuelve el flujo pero no sabes que es un flujo, se maneja por ti. Ahora, simplemente puedes llamar a la función del servidor, no necesitas decodificarla, y al igual que antes, puedes simplemente renderizar el resultado, es un valor renderizable de React. Entonces, en 10 sec start, como ya hemos visto, las funciones del servidor son el límite para las solicitudes y respuestas de la UI renderizada por el servidor. El cliente envía la forma de entrada que el render necesita. En ese ejemplo, es solo un slug, pero puede ser cualquier cosa, así que no estás enviando todo el mundo al servidor, especificas lo que necesitas.

En el servidor, tienes un validador que valida que los datos que estás pasando son realmente lo que esperas, si no, se genera un error y no continúas, de lo contrario, se llama al manejador, y usará los datos de entrada validados, en ese caso, es solo un slug, y llamará a render server components para pasar el JSX que realmente quieres renderizar. Ahora, como dije antes, tenemos primitivas que se componen, así que, en ese caso, dado que esta es una función del servidor, puedes simplemente usar un middleware y aplicarlo y mover cosas comunes que típicamente tienes alrededor de una llamada HTTP. En ese caso, dado que esto es solo HTTP, realmente, puedes establecer encabezados de respuesta, en ese caso, establecemos control de caché y control de caché de CDN, y eso significa que la UI renderizada por el servidor será almacenada en caché tanto por el navegador como, aún más importante, a nivel de CDN, lo cual es bueno para cosas públicas.

Pero no significa que solo puedas devolver un único RSC desde una función del servidor. En realidad, puedes devolver lo que quieras, así que, como dice esta diapositiva, la forma de retorno es que puedes devolver tantos componentes de servidor desde una función del servidor como desees. También puedes combinar esto con datos simples como estás viendo aquí. Así que, en ese ejemplo, estamos iniciando la carga fuera de los componentes del servidor como también es posible, y, basado en eso, renderizamos tres componentes del servidor en paralelo, y luego devolvemos esto en combinación con datos simples. Y, en el servidor, es simplemente uniformemente los datos simples junto a los componentes del servidor, y todos los renderizas o los compones como desees. Y ese patrón es usualmente útil cuando tienes múltiples regiones renderizadas por el servidor que comparten la misma carga de datos, o quieres invalidarlas juntas y quieres almacenarlas en caché uniformemente.

Entonces, si esa respuesta de UI renderizada por el servidor es utilizada por una ruta, podemos simplemente usar el router cache que el router de Timestack tiene al igual que cualquier otro resultado de cargador, lo que llamamos caché basada en rutas. Entonces, si tienes UI renderizada por el servidor que pertenece específicamente a una sola ruta, simplemente colócala en el cargador de la ruta y devuélvela desde allí. Así que, en ese ejemplo, tenemos get post RLC, que es nuestra función del servidor que define qué componente del servidor será renderizado, y lo llamas desde un cargador en el cliente. Puedes especificar propiedades como tiempo de caducidad para especificar cuánto tiempo se considerará fresca esta información en el cliente hasta que el cargador se ejecute nuevamente. Entonces, en ese caso, decimos que queremos ejecutar el cargador cada vez que se exceda el tiempo de caducidad, o cuando se pase un nuevo valor de post-id, así que simplemente llamamos a la función del servidor con el parámetro post, y luego devolvemos el componente del servidor. Y nuevamente, simplemente accedemos a los datos en el cliente y el componente, y en ese caso, usamos el hook use loader data y puedes renderizar eso.

Así que eso es realmente bueno si tienes datos que solo pertenecen a una sola ruta, pero a veces tienes componentes del servidor que quieres delimitar de manera diferente a una sola ruta, y entonces quieres una clave de caché para esa pieza específica de UI independiente de una ruta. Y aquí es donde TensorStack Query encaja muy bien. Así que una vez que el valor RLC es solo un recurso asíncrono, la caché de consulta no necesita saber que la carga es una UI renderizada por el servidor. Así que aquí ves, simplemente estarás usando una clave de consulta estándar, en ese caso son solo dos cadenas, RLC post preview, y luego los valores reales de post id y tab. Oh, veamos. Bien, continuaré aquí.

Así que nuevamente, puedes simplemente usar TensorFlow para obtener componentes del servidor como lo harías para cualquier otro dato cargado por el servidor, y TensorFlow no necesita saber que tienes UI renderizada por el servidor, simplemente la estás colocando en la caché de consulta como lo harías normalmente. Y en ese ejemplo, especificas una clave de consulta, especificas una función de consulta, puedes usar cada opción de consulta como tiempo de caducidad como usas para cualquier otra carga de datos, y simplemente funcionará. Y sí, puedes invalidar manualmente la consulta y luego se volverá a obtener, y luego se volverá a renderizar en el cliente. Ahora lo interesante es que puedes sumergirte en el ecosistema de React query, y puedes usar Query Persisters, lo cual es realmente bueno, así que construí un Query Persister donde persistes los bytes del flujo RLC en un indexed DB, lo que significa que puedes usar una UI renderizada por el servidor para aplicaciones offline, y eso es realmente genial. Bien, hasta ahora hemos visto RLC como algo que mueve un flujo a través del sistema, tienes funciones del servidor que devuelven flujos de UI renderizada por el servidor, tienes respuestas que son almacenadas en caché por el router o una consulta, pero hay otra dimensión de RLC que no se trata de transporte o caché, y eso es la composición. Así que típicamente, en el mundo RLC, el servidor posee el árbol, y en ese modelo, la directiva useClient marca los lugares donde necesitamos servidor, donde necesitamos código de navegador. Y ves aquí esa composición de árbol propiedad del servidor.

Entonces, en ese caso, el componente de página decide la composición en el servidor. Coloca el componente markdown, que es un componente de servidor, coloca el botón de like, y obtienen ClientTabs, que son componentes de cliente, y sus módulos de cliente se cargarán en el navegador e hidratarán. Así que ahora echemos un vistazo a la rama de ClientTabs. El servidor coloca los comentarios dentro de los ClientTabs, lo que parece que tenemos un componente de servidor como hijo de un componente de cliente, que es React, pero el servidor decide toda esa estructura, por lo que ClientTabs no decide lo que obtiene como hijo, simplemente está siendo mandado por el servidor.

Así que en la implementación, por supuesto, los ClientTabs pueden decir, quiero mostrar estos hijos, o no quiero, pero no puede seleccionar los hijos del servidor. Y ese modelo funciona bien, y Start lo soporta completamente si lo deseas, pero no es la única forma de componer UI finalizada por el servidor. Hemos construido algo que te permite invertir el control, porque a veces el cliente ya posee la composición circundante. Así que tienes rutas, diseños, UI interactiva circundante, y en lugar de que el servidor posea todo el árbol y marque agujeros de cliente, el cliente posee la composición y quiere colocar regiones renderizadas por el servidor en ella.

Así que esto es para lo que construimos componentes compuestos. En este ejemplo, el componente de ruta es la raíz de la composición y posee el diseño. Así que renderiza una barra de herramientas que es un componente interactivo, y junto a ella, renderiza una región de tarjeta postal que es una región renderizada por el servidor. Así que este componente, tarjeta postal, es un componente de servidor, se ejecutará dentro de una función de servidor, ejecutará load post que es una función solo de servidor, puede usar dependencias solo de servidor, y no se enviará como parte del paquete del lado del cliente. Ahora, la idea aquí es, si quieres colocar elementos interactivos dentro de esa región renderizada por el servidor, puedes declarar un slot, y en ese caso, ese slot se llama footer, y eso dice, en ese lugar en la UI, quiero tener un componente interactivo, se llama footer, y paso una prop de slot y en este caso, es un author ID, una cadena.

La tarjeta postal renderizada por el servidor declara el slot, y en el lado del cliente, llenamos ese slot, así que en el lado del cliente, decimos post footer, lo ponemos en la prop del componente compuesto aquí abajo, y luego puedes renderizar todo, y se compone junto en el cliente. Así que el cliente tiene control total sobre qué elementos interactivos se colocan en las regiones renderizadas por el servidor. Así que esta es la clave aquí. Tienes un componente interactivo, y renderiza un enlace, puedes poner cualquier cosa dentro de aquí, y está conectado a través del componente compuesto que ofrecemos.

Como esperarías de 10-stack, es completamente seguro en cuanto a tipos, así que defines la forma de tu slot, que en ese caso, es un componente con props de un author ID, y si no logras proporcionar una prop de slot de la misma manera, entonces obtendrás un error de TypeScript. Te mostraré rápidamente cómo se ve esto, veamos si funciona, cómo se ve esto en tiempo de desarrollo, porque ahora puede ser un poco confuso. El modelo de composición, veamos si funciona.

Bien. No. No funciona. Genial. Bien, aquí ves uno de nuestros trajes de prueba de extremo a extremo, y ves aquí la cosa azul es una región renderizada por el servidor, y dentro de ella, tiene un componente de cliente que es interactivo, así que puedes hacer cosas aquí.

Si deseas inspeccionar los datos que obtuvimos del servidor, puedes mirar nuestras DevTools. Aquí tenemos nuestras DevTools del router de 10-stack, y dices que ahora estamos en esta ruta, así que puedes mirar qué contiene actualmente la caché de la ruta. Los datos cargados contienen una fuente compuesta. Tiene estos dos slots declarados, y pasará estos props a estos slots, y puedes luego verificar si cumples con eso o no.

Vamos a hacer... Sí. Muy bien. Oh, sí.

Oh, sí. Oh, sí. Oh, sí.

Oh, sí. {{^}}Oh, sí. Gracias. Genial. Bien, solo tengo una diapositiva más, así que hagamos zoom hacia atrás. Los componentes del servidor son poderosos, pero no tienen que convertirse en el centro de la aplicación. Como vimos a nivel de transporte, estos son solo flujos de datos, React renderizado en el servidor que puede moverse a través de todo el sistema. En 10-stack start, podemos reutilizar las primitivas existentes que tenemos, funciones del servidor, middleware, podemos almacenarlo en caché en el router, podemos almacenarlo en caché en la consulta. Porque puedes solicitar la salida de RSC de manera independiente, puedes elegir el modelo de composición que se adapte a tu caso de uso. Si deseas que el servidor lo posea, el modelo estándar de cliente funciona, y cuando el cliente lo posee, puedes usar componentes compuestos. Así que no necesitamos que RSC sea una arquitectura fija, porque desde nuestro punto de vista, RSC es una primitiva, no es la arquitectura. Gracias.

La primera pregunta que tengo para ti es si tengo una aplicación grande renderizada del lado del cliente construida con Vite y React router, ¿qué tan desafiante es migrar a 10-stack start? Bueno, depende de qué versión de React router estés usando, probablemente. Pero en general, si ya estás usando Vite, estás bastante en casa, así que dado que soportamos Vite, deberías estar bien. Y probablemente con la IA siendo capaz de traducir automáticamente entre las dos sintaxis, entre React router y 10-stack router, debería ser fácil, supongo.

¿Tiene 10-stack archivos de agente o algún tipo de indicaciones preconfiguradas que podamos intentar usar para convertir aplicaciones? ¿Está eso en los documentos en alguna parte? No tenemos eso, pero sí tenemos 10-stack intent, que es nuestra forma de declarar habilidades específicas de la aplicación. Así que podríamos tener uno para migrar a React desde React router. Tenemos instrucciones para migrar desde Next. Así que eso podría ser una buena idea. ¿Y puedes hablar sobre los esfuerzos de documentación? ¿Se están haciendo esfuerzos para llevar la documentación a un nivel superior? Hay lugares que tienen próximamente en los documentos del router de 10-stack específicamente. Sí, quiero decir, los documentos siempre están rezagados con respecto a nuestros esfuerzos de implementación. Así que actualmente estamos realmente esforzándonos para llevar start a estable, lo cual realmente queremos hacer pronto. Y luego el esfuerzo de documentación también está avanzando bien. Está bien, eso tiene sentido. Muy bien. Y Robert pregunta, ¿qué tipo de soporte hay para micro-frontends? ¿Tiene 10-stack algo similar a las zonas de Next.js planeado? Así que no estoy muy familiarizado con el concepto de zonas, pero creo que en realidad son solo aplicaciones separadas de Next.js Creo que sí. Así que quiero decir, puedes hacer esto ahora mismo. Así que lo que no está realmente soportado ahora mismo es tener enrutamiento seguro por tipos a través de esas aplicaciones.

Así que tenemos algunas grandes empresas que quieren usar esto con equipos enormes, y necesitan ese tipo de separación de preocupaciones, así que estamos investigando eso, seguro. Eso tiene sentido.

Y tengo otra pregunta de Anónimo. ¿Cuándo comenzará 10-stack start v1? ¿Qué lo está retrasando? Lo mencionaste un poco, pero... Sí. Quiero decir, es solo que es un área de superficie enorme, un meta-framework. Solo hay tantos detalles y características que necesitas cuidar. Así que retrasarlo, probablemente solo sea cuestión de personal. No es, quiero decir, con la IA estamos acelerando bastante, pero sí, hay tantas cosas que hacer. Toma tiempo, y quieres hacerlo bien. Sí. Quiero decir, hemos estado madurando mucho y no se esperan muchos cambios importantes, tal vez solo uno o dos detalles menores. Así que ya es bastante estable. Y sí, la gente ya está apostando por ello. Y supongo que, ahora mismo es RC, así que eso significa que realmente no habrá cambios importantes. Solo quieres asegurarte de que todo lo que está ahí sea estable y funcione antes de que esté... Sí. Quiero decir, habrá como dos pequeños cambios importantes, pero luego, sí, nada grande. Es bueno saberlo.

Esta pregunta es, ¿estás usando RSCs en 10-stack.com, y si es así, ¿mejoraron el rendimiento? Sí, lo hacemos. Quiero decir, este fue nuestro primer campo de pruebas para verificar si tenía sentido hacerlo como lo hicimos. Y tuvo todo el sentido porque simplemente movimos todo el renderizado de markdown del cliente al servidor. Así que quiero decir, el tamaño del balance es mucho menor. Pero por supuesto, con RSC, también necesitas mirar los tamaños de carga útil que obtienes. Así que cuando navegas lo suficiente en la documentación, eventualmente obtendrás más RSC de lo que habrías tenido si ese renderizador hubiera estado en un cliente. Así que es un... Sí, realmente no hay una bala de plata. Pero si miras nuestra publicación de blog donde presentamos los Rake Server Components, verás las puntuaciones que mejoró. Así que puedes comprobarlo. Es bueno saberlo.

Muy bien. Esta es de Eddie, y la pregunta es, con la increíble implementación de RSC en 10-stack start, ¿preferirías usar RSC en nuevos proyectos hoy en día? Y como nota al margen, me encanta que no haya cadenas mágicas de no use client y no use server por todo el código. Sí. Así que en realidad, quiero decir, esa charla podría haber sido mucho, mucho más corta. Estamos tratando RSC simplemente como datos. No es nada especial. Y honestamente, solo úsalo si tiene sentido. Así que en nuestra visión arquitectónica, no deberías predeterminarlo. Quiero decir, solo usa lo que ya has estado usando y usa componentes del servidor cuando quieras por ejemplo, mejorar el rendimiento del renderizado del lado del cliente, el tamaño del paquete, pero no es el predeterminado, definitivamente. ¿Sería preciso decir que 10-stack start ya te ofrece renderizado del lado del servidor así que obtienes el beneficio de lo que la gente buscaba con los componentes del servidor de React directamente con 10-stack start? ¿Es preciso decir eso? Sí. Quiero decir, traté de explicar que RSC es tal vez un paso de pre-procesamiento para SSR, pero no es obligatorio uno. Así que puedes tener renderizado HTML completamente en streaming en 10-stack start desde el principio. Así que no necesitas RSC para eso. Puedes renderizar suspense, puedes hacer todo eso. No es necesario. Es bueno saberlo.

Muy bien. ¿Cuáles son las ventajas y desventajas del RSC de 10-stack en comparación con la implementación de Next.js? Bueno, puedes usarlo o no tienes que hacerlo. Así que diría que poder elegir siempre es una ventaja. La desventaja es, por supuesto, que algunas personas podrían decir que necesitas aprender algunas nuevas APIs, necesitas usar render server component si quieres renderizar un componente del servidor. Pero diría que en la era actual de la codificación con IA, probablemente ni siquiera lo estés escribiendo tú mismo, así que la verbosidad probablemente esté bien. Así que sí, pero claro, es una API diferente que podrías necesitar aprender, y el concepto que necesitas entender. Pero decimos que vale la pena que no tengas que predeterminar toda tu aplicación al modelo RSC. Especialmente porque estamos apuntando a aplicaciones client-first, porque ahí es donde tiene sentido tener React e interactividad. Así que si solo estás haciendo sitios estáticos y cosas pre-renderizadas, tal vez no deberías estar usando React en absoluto.

Eso tiene sentido. Y supongo que leí la publicación del blog de lanzamiento de RSCs en 10-stack, y ustedes tomaron una postura en términos de ser unidireccional, ¿verdad? Como que los componentes del servidor se transmiten desde el servidor al cliente, y no es bidireccional como sería con Next.js. ¿Dirías que eso es una desventaja o una ventaja en términos de la implementación comparada con Next.js? Sí, quiero decir, el término RSC está nuevamente un poco sobrecargado. Así que decimos que RSC es el primitivo para la UI que se renderiza en el servidor. Pero de alguna manera se confunde con las acciones del servidor o una cosa de función que también tienen. Y dijimos que no estamos haciendo eso. Así que no estamos introduciendo nuevos servidores, por lo que no estamos apoyando funciones del servidor de React, acciones del servidor de React, como sea que se llamen hoy en día, porque el protocolo simplemente ha demostrado ser muy inseguro en el pasado, lo cual es decir que no estamos apoyando eso. Quiero decir, teóricamente, la gente podría usar un middleware y construir sobre eso si realmente, realmente quisieran. Pero eso es simplemente lo que no estamos haciendo. Así que sí, eso es una especie de desventaja. Pero creo que la idea de ese componente full stack donde simplemente instalas un paquete npm que tiene componentes del cliente y todo eso, y también acciones del servidor, no he visto que realmente suceda. Y también tal vez es un poco aterrador que algún paquete npm pueda simplemente activar un endpoint de servidor que no controlas. Cierto. Así que, sí. Sí, quiero decir, honestamente veo eso como una ventaja, porque hay menos superficie para cometer errores y tienes más control sobre dónde viven las cosas.

Muy bien. Tiempo para tal vez una o dos preguntas más. Esta siguiente. ¿Tienes algún consejo sobre cómo hacer pruebas de componentes cuando usas TanStack router? La documentación no es muy buena para esto. Sí. Quiero decir, pruebas de componentes, puedes... Depende de si... Cuando defines el componente en línea en nuestra cosa de crear archivo de ruta, acepto que la documentación no es muy buena para esto. Estamos trabajando en utilidades de prueba donde puedes activar un router simulado y simplemente configurarlo en un estado sin usar play write. Pero para pruebas unitarias... Entiendo. Sí. Pero si solo estás usando componentes exportados, puedes simplemente probar componentes como quieras. Quiero decir, necesitas simular el router, y estamos agregando utilidades para eso, pero vendrán más adelante. Bien. Bueno saberlo. Eso es todo el tiempo que tenemos, pero si tienes más preguntas para Manuel, él estará allí en la sección de preguntas y respuestas. Pero muchas gracias. Gracias.