SPA to SSR and Everything in Between

Lo siento, no tengo camisetas esta vez, así que traje algo mucho mejor conmigo a Ámsterdam este año. Mi esposa y mis tres hijos están en la primera fila justo aquí. Así que cuanto más nos divirtamos, más se divertirán ellos. Así que mantengámoslo divertido.

Muy bien. No es ningún secreto que React está en auge. ¿Y está React en auge? Cuando comencé a usar React en 2014, no sabía que esto era lo que iba a parecer. Y pensé con certeza que después de una década empezaríamos a ver algunos cambios en esta línea. Pero solo está subiendo. Es una locura. Definitivamente es transformador. Ha transformado nuestra industria y ha transformado otras industrias también, aunque no lo creas.

Pero algo que creo que es realmente importante es que no creo que estaría en ningún lugar donde está hoy sin esta comunidad y este ecosistema que se ha unido a su alrededor. Quiero decir que estamos aquí porque elegimos React como nuestro framework todos los días. Creo que necesitamos celebrar eso. Así que React es genial. Hace diez años comencé a usarlo. Y desde que comencé a usarlo, se ha estado moviendo al servidor desde entonces.

He estado construyendo sitios web durante más de 15 años. No siempre con React. Así que cuando comencé a aprender React y vi que podía comenzar a usar capacidades del servidor, estaba realmente emocionado por eso porque realmente trae algunos buenos beneficios a la mesa, especialmente SEO. Pasé 10 años en la industria del SEO en esta última década y así que realmente aprecio eso. Obtenemos rendimiento. Obtenemos un montón de reutilización de código, un stack unificado. Y hoy es bastante fácil usar React en el servidor. Pero eso no siempre fue el caso.

En 2013, ni siquiera teníamos APIs del servidor. Fue una breve luna de miel de unos tres meses después de que lo lanzaron, obtuvimos la primera API para el servidor, renderizar a cadena. Y comparado con otros frameworks existentes en ese momento, aunque no lo creas, renderizar a cadena fue revolucionario. No sé si alguien intentó hacer SSR y Angular 1x, pero wow.

locura. Así que la idea de que puedes tomar tu aplicación y simplemente convertirla en HTML es realmente asombrosa. Y eso abrió este camino emocionante para los próximos 10 años. Desde 2016-17, vimos un gran crecimiento. Obtuvimos Next.js y Gatsby. Pero no obtuvimos el Next.js que estás pensando hoy. Estos eran frameworks de generadores de sitios estáticos, porque ni siquiera habíamos llegado al servidor todavía, al menos no todos nosotros.

También obtuvimos mejoras como React Fiber, actualizaciones centrales que comenzaron a allanar el camino para un impulso aún mayor hacia el servidor. En 2018 y 2019, obtuvimos Hooks y Suspense. Estos mejoraron enormemente toda nuestra ergonomía, y allanaron el camino para cosas como la transmisión y la hidratación progresiva. Y luego finalmente, comenzamos a obtener Next.js renderizado en el servidor, lo cual fue increíble. Esto fue el comienzo de la comoditización del renderizado del lado del servidor para los desarrolladores de React. Fue una gran victoria.

En 2020, obtuvimos COVID. No, solo estoy bromeando. Obtuvimos Remix. Obtuvimos otro framework clave para hacer que SSR sea más accesible para más desarrolladores de React. Y todos sabemos que en 2020, suprimimos mucho de 2020, admitámoslo. Pero lo recuerdo como uno de los momentos más emocionantes para ser un desarrollador de React, porque parecía que las cosas se estaban volviendo tan fáciles de participar. Lo que quisieras construir con React, podías hacerlo, y el servidor definitivamente era parte de eso. Fue increíble.

Pero todo el mundo estaba en internet en 2020, mucha gente. Y eso puso mucha presión sobre el servidor, el aspecto del lado del servidor de todo lo que hacíamos, incluyendo React. Y no creo que sea ninguna coincidencia que en diciembre de 2020, algo aún más grande y emocionante sucediera. Se anunciaron los componentes del servidor. Los componentes del servidor eran esta nueva y poderosa idea.

Todo el mundo estaba emocionado por lo que desbloquearían, pero ni siquiera podíamos usarlos todavía. De hecho, muchos de nosotros ni siquiera sabíamos cómo funcionaban, qué eran. Solo sabíamos que lo que nos decían era que iban a desbloquear la próxima frontera. Estaba emocionadísimo, pero solo deseaba haber podido usarlos antes. Y nos rompieron la cabeza por un tiempo, y probablemente todavía confunden a muchas personas hoy en día, porque son un concepto difícil y avanzado de entender. Espero que podamos cambiar eso juntos como ecosistema en el futuro.

Pero lo genial es que obtuvimos soporte de Next.js. Next.

Next.js agregó soporte para los componentes del servidor de React, y pensé, genial. {{^}}Next.js los agregó. El futuro está aquí. Ahora se van a agregar en todas partes donde pueda empezar a usarlos. Ese futuro no era lo que esperaba, porque era un enrutador completamente nuevo. Era un framework completamente nuevo. Y fue reescrito para ser primero componente del servidor de React. Y aunque extremadamente genial, se sentía muy diferente a cualquier otra cosa que había usado antes. Y honestamente, me planteó muchas preguntas, y creo que lo hizo para muchas otras personas.

Preguntas como, ¿es esto solo una nueva herramienta? ¿O es esto una característica del empaquetador? Me dicen que es una característica del empaquetador. ¿Tiene que ser un nuevo framework? También me dicen personas muy inteligentes que esto es una arquitectura completamente nueva que va a cambiar todo. Y creo que después de cinco años, me he dado cuenta de que es todas estas cosas. Y eso no necesariamente lo hace mejor. Pero deberíamos explorar todas estas cosas. Y eso es lo que quiero hacer por un momento.

Así que podría ser todas estas cosas, o podría ser algunas de ellas. O podría no ser ninguna de ellas. Porque la realidad para muchos de nosotros hoy es que probablemente no las estamos usando a menos que estés usando el enrutador de aplicaciones de Next.js. Pero son muy ampliamente aplicables. Se pueden usar de muchas maneras diferentes. Resuelven desafíos muy reales. Resuelven desafíos como la precompilación de JSX en el servidor. Pueden hacer que nuestro paquete del cliente sea más pequeño. Y si se usan en cierto grado, pueden eliminar problemas de cascada con la obtención de componentes, lo cual hemos estado buscando... Quiero decir, incluso yo he estado buscando hacer eso con React query durante los últimos cinco años. Todo esto suena realmente genial. Y honestamente, tengo casos de uso ahora mismo en tansoc.com para los que me encantaría usar componentes del servidor de React. Todavía tengo que enviar un analizador de markdown al cliente para hidratar nuestra documentación. Debería ser solo HTML estático. Y es la cosa más ridícula de todas.

No puedo esperar para usarlos solo para ese caso de uso. Y entonces pienso, ¿qué no amar, verdad? Pero con cada tecnología, con cada característica que construimos, todo lo que agregamos, siempre hay compensaciones. Y he estado tratando de explorar estas compensaciones durante los últimos cinco años. Y ¿sabes qué? Incluso antes de que existieran los componentes del servidor, el servidor era complejo. Ya estábamos lidiando con muchos desafíos y problemas difíciles con el servidor. Sabes, esto no es nada nuevo. Esto no es solo hace cinco años. Hemos estado lidiando con estas cosas durante mucho tiempo.

Pero incluso en React, no sé, tenemos algunos frameworks que lo han hecho realmente fácil para nosotros. Ellos han logrado tomar estos desafíos y contener el radio de explosión a lugares que nos hacen productivos. Entonces, ¿qué tiene que ver eso con los componentes del servidor de React? Creo que una de las primeras compensaciones que estamos haciendo con los componentes del servidor es la multiplicidad. Estamos tomando esos desafíos que hemos aprendido a manejar durante muchos años, y los estamos multiplicando por toda nuestra aplicación, potencialmente en cualquier lugar donde queramos ponerlos. Necesitamos poder tejer dentro y fuera del servidor. Realmente está multiplicando estos problemas en todas partes donde lo usamos.

Creo que cuando la gente dice que solo aumenta la complejidad, esto es un poco de lo que están hablando. Definitivamente no ayuda a mi cerebro. He usado componentes del servidor en Next.js, y lleva mucho tiempo acostumbrarse. Tienes que estar constantemente vigilante sobre dónde estás tejiendo dentro y fuera del servidor. Y si es difícil para los humanos, es difícil para las personas hacerlo, no puedo imaginar que sea difícil para la IA hacerlo tampoco. Compensación número dos que me di cuenta es que los RSCs demandan cambios micro y macro en nuestro código. Creo que hay obvios como poner used client, used server en un montón de lugares. Hay muchas reglas nuevas sobre lo que puedes usar y lo que no puedes. Y también tenemos que asegurarnos de que muchas de las herramientas que usamos sean compatibles.

También hay nuevos conceptos como entrelazar el servidor y el cliente. ¿Cómo hacemos eso correctamente? ¿Cómo pasamos promesas? ¿Qué sucede cuando pasas props y callbacks al cliente? ¿Cómo funciona esa capa de serialización? Hay muchas cosas nuevas que aprender, mucho terreno nuevo que cubrir. E incluso va tan macro como la organización de archivos. Dividir nuestros archivos en versiones de servidor y cliente. Estos cambios fueron intensos, pero si lo logramos con React hooks, creo que podríamos lograrlo con esto.

Este es un pequeño saludo a mi última charla que di en Ámsterdam. Desearía haber tenido más regalos de Jurassic Park, pero no pasaron el corte. Así que si podemos, si podemos manejar una transición a través de hooks, que fue bastante grande, deberíamos poder manejar algo como esto. Pero eso me lleva a la siguiente pregunta interesante que he tenido sobre los RSCs, es este concepto que estoy llamando componentes del servidor de React canónicos. Es como la visión, el santo grial de cuál es la mejor manera en que podríamos usar los componentes del servidor de React para obtener lo máximo de ellos. Y eso es lo que muchas personas realmente inteligentes y lo que muchos frameworks y muchas herramientas están apuntando hoy.

Están apuntando a deshacerse de las cascadas de obtención de datos de componentes, ¿verdad? Es como el santo grial. Quieres poder co-ubicar tus datos con tus componentes y simplemente seguir adelante. Y los componentes del servidor pueden hacer esto. Y es realmente impresionante cómo lo hacen. Pero el objetivo es usarlo solo con React. Más o menos. Porque sin un enrutador server-first o un metaframework, solo puedes llegar hasta cierto punto con los componentes del servidor. No puedes llegar a este siguiente nivel de uso canónico de poder usarlos en su máxima capacidad. Y no estoy diciendo que necesitemos llegar allí incluso, o que necesites llegar allí. Pero cosas como necesitar obtener nuevos datos requieren volver al servidor nuevamente. Tienes que volver al servidor cada vez que necesitas invalidar tus datos del servidor. Server-first. Sí, te da este increíble patrón de obtención de componentes, sabes, donde puedes entrelazar y simplemente obtener los datos que necesitas. Y todo sucede en el servidor. Y es realmente hermoso y puro. Pero también renuncias a algunas cosas, y las cosas se vuelven un poco más difíciles de lo que podrías haber esperado. Hay compensaciones en todas partes. Y una de las últimas compensaciones, que espero sea temporal, es el soporte del empaquetador. El estado del soporte del empaquetador para los componentes del servidor ha estado en mi mente mucho.

Vite es una parte clave del ecosistema de React, y aún no tiene soporte. Se están haciendo progresos, pero simplemente no está listo. Y yo espero que esto se solucione pronto. Tengo muchas esperanzas de que así será.

Lo que me lleva a la pregunta final. ¿Valen la pena? Me hacen esta pregunta todo el tiempo, todos los días, en todas partes a donde voy. ¿Valen la pena los componentes del servidor de React? Y yo diría que si necesitas renderizado del lado del servidor, y realmente estás sufriendo por problemas de cascada del servidor, o algún gran problema de paquete del cliente, los componentes del servidor son para ti. Ahora, creo que es obvio que no estoy aquí para venderte los componentes del servidor. Y si lo hice, me encanta eso para ti. ¿De acuerdo?

Pero la verdad es que, desde donde estoy parado, desde mi realidad, estoy bien. La realidad para mí es diferente. Y todo lo que veo en las redes sociales, siempre le digo a mi esposa, no creas lo que ves en las redes sociales. Eso no es la realidad. La realidad que veo es muy diferente, aunque eso es de lo que parece que todos estamos hablando. AI y componentes del servidor.

Pero incluso con todo eso, el 85% de nosotros todavía trabajamos solo en aplicaciones React del lado del cliente. Y eso es de la última encuesta sobre el estado de React. Y eso significa que cuatro de cada cinco de nosotros estamos trabajando en aplicaciones que ni siquiera usan el servidor, a menos que sea como una llamada fetch a una API o algo así. Y eso me parece una locura. Y eso no significa que SSR sea malo. Y también significa que podrías estar trabajando en ambos tipos de aplicaciones. Una aplicación del lado del cliente y una aplicación SSR. Yo lo hago. Tengo TanStack.com y tengo todas mis aplicaciones. ¿Verdad?

Pero la cuestión es que estas aplicaciones están en todas partes. Son herramientas internas y productos B2B. Están en juegos, aplicaciones SaaS. Están en todas partes. Y muchos de nosotros trabajamos en estos proyectos todos los días. Pero simplemente no hablamos mucho de ello. Porque lo que es genial y moderno para hablar, es una aplicación React del lado del cliente. Creo que son geniales. Y quiero hablar de ellas. Las SPAs son críticas. Y están aquí para quedarse. No creo que vayan a ninguna parte. Si tú estás de acuerdo con eso, quiero escuchar un grito.

Entonces, ¿por qué estoy diciendo todo esto? Bueno, por un lado, amo las SPAs. Siempre las he amado. Siempre las amaré. Además, he construido algunas SPAs muy intensas. SPAs muy intensas en los últimos 10 años que han consumido mucho de mi tiempo y energía en tratar de hacer que esa experiencia sea increíble. Por eso construí muchas de estas herramientas, o ayudé a construir algunas de estas herramientas más nuevas, para hacer ese proceso más fácil. Y todas esas herramientas son lo que eventualmente se convirtió en TanStack. Y en TanStack, preguntas a cualquiera en el equipo de mantenedores principales, amamos el cliente y el servidor.

No discriminamos. Los amamos a ambos. Y realmente queremos construir herramientas que vayan a satisfacer a los desarrolladores donde se encuentran hoy. Al menos. Y mirar hacia el futuro. Lo cual también es importante.

Y creo que estamos construyendo herramientas hoy, especialmente dos herramientas de las que quiero hablar, que están satisfaciendo a los desarrolladores donde se encuentran, donde tal vez no están siendo satisfechos por otras herramientas. La primera es TanStack Router. El enrutamiento es el corazón de cualquier aplicación. Y ya sea cliente o servidor primero, la mayor parte de la gestión de estado de URL debería ocurrir en un enrutador.

Y creo que TanStack Router sería el enrutador más increíble que hayas usado. Es algo que tienes que sentir. Y estoy muy seguro de que sería un cambio de juego para ti. Especialmente si estás construyendo una SPA. Es 100% seguro en tipos. Es gestión de estado para la URL. Y tiene muchas otras cosas geniales integradas en él.

Esa seguridad de tipos es una gran característica. No puedo subestimar lo genial que es. Y no me refiero solo a que fue escrito con TypeScript. Está escrito para TypeScript. Es a prueba de balas. Tipos inferidos en todas partes. De hecho, mucho del código que escribes con TanStack Router ni siquiera tiene sintaxis de TypeScript. Porque está tan completamente inferido que parece JavaScript simple. Pero todo es seguro en tipos. Es increíble.

Y puedes dejar de dispararte en el pie con enlaces malos y un estado defectuoso que probablemente romperá a tus usuarios y romperá tus URLs. Y vamos más allá. No solo más allá de la seguridad de tipos, sino que hay middleware seguro en tipos. Hay validación de parámetros de búsqueda anidados. No tengo suficiente tiempo para hablar de todo. Pero podemos manejar mucho. Miles de rutas. Sin ralentización.

La gestión del estado de URL en él es increíble. Son todas URLs compartibles, marcables, lo cual es como deshacer y rehacer incorporado en tu historial, lo cual es bastante genial. Validación de parámetros de búsqueda. Lanza Zod allí. Lanza lo que quieras allí. Validamos los parámetros de búsqueda para que no tengas que pensar en ellos nunca más. Solo piensas en ellos como estado. Así que puedes hacer cosas como esta, o esta. Y puedes incluso hacer cosas locas como esta. Todo en transacciones únicas a la URL. Incluso puedes reemplazar. Así que es como usar estado para la URL.

¿Quién no quiere eso? Es increíble. Gracias. Tiene todos los problemas que vienen con la gestión de estado. Los hemos resuelto todos. Tiene suscripciones de grano fino, que ni siquiera puedes obtener con muchas otras herramientas en el ecosistema de React. Hemos hecho grandes esfuerzos para asegurarnos de que sea muy eficiente. Y todo esto es solo del lado del cliente. Eso es lo que estoy tratando de decir.

Puedes usar esto hoy. Si estás construyendo un SPA, puedes empezar a usar esto hoy. Y nos encontraremos donde estés. Tengo un minuto para hablar sobre el servidor. El servidor es muy importante para nosotros también. Tenemos colaboradores aquí de React Query. Frederick, TK Dodo. Estos chicos se preocupan profundamente por el servidor y por React Query y cómo podemos usar React Query con cosas del lado del servidor. La pregunta siempre es, ¿qué pasa con el framework? ¿Qué va a hacer NANDstack sobre este framework? Bueno, resulta que la mayor parte del framework es solo enrutamiento. Y luego agregas alguna capacidad de SSR y algunas rutas de servidor. Y luego solo necesitas poder empaquetarlo y enviarlo.

Bueno, TanSec Start es exactamente eso. Lo emparejamos con VEET, que ahora es solo un plugin de VEET. Así que si has usado TanSec Start, ahora es solo un plugin de VEET. Muy genial. Me encanta esa animación. VEET es increíble. Obtienes capacidad de servidor y SSR. Pero es incremental. Es opcional. Realmente quiero decir que solo lo agregas al enrutador.

Es puramente aditivo y opcional. Y es una mejora a una experiencia ya excelente. Obtienes muchas otras cosas de las que ahora no voy a tener tiempo de hablar. Las funciones de servidor son increíbles. Y tenemos muchas características geniales que estamos lanzando. Incluso en solo V1, va a ser increíble. Y hay mucho más por venir. Ni siquiera hemos realmente abierto las compuertas para lo que queremos hacer. Se me acaba el tiempo, pero tengo que responder la pregunta, ¿qué pasa con los componentes de servidor de React? Pronto. Al igual que React Router, al igual que muchos otros, estamos esperando algo de estabilidad upstream. Necesitamos poder usar VEET y necesitamos poder dárselo a todos, no solo a las personas que usan algo como Next.js. Queremos que sea ampliamente accesible. Los RSEs son increíbles. Solo pensamos que son flujos de texto y vamos a hacer que puedas usarlos en todas partes, en todo. Incluso en nuevos proyectos que estamos construyendo de los que puedes venir a preguntarme más tarde. Y una cosa más, hemos incorporado algunas cosas realmente geniales, así que ahora se llama el lanzamiento DaVinci, pero todavía está en beta, así que no me preguntes sobre eso. Y por último, pero no menos importante, tengo muchos patrocinadores y socios geniales que han hecho esto posible. Pude dedicarme a tiempo completo a TAN stack hace un año gracias a estas empresas que también están apoyando a muchos de nuestros colaboradores y mantenedores principales ahora también, y merecen un aplauso.

Tanner Stan está haciendo la primera pregunta, eso es increíble. ¿Tendrá TAN stack router soporte adicional de empaquetadores como RS pack y RS build? El router probablemente lo tendrá. No puedo decir para start aún, pero tenemos la esperanza de que start también lo tenga, pero el router probablemente lo tendrá. Algún día, algún día. De acuerdo, de hecho, podría incluso ya tenerlo. Router, start, tienes que ser específico.

La siguiente pregunta es de Sergei. ¿Cuáles son algunos casos de uso comunes para RSCs? Acabo de hablar sobre ellos, así que si quieres retroceder, mira mi charla de nuevo. De acuerdo, bueno, probablemente Sergei preguntó antes. Lo siento, solo estoy tratando de ser respetuoso con todas las preguntas. Y la siguiente pregunta es de Muxy. ¿Estás trabajando actualmente en alguna biblioteca o proyecto que dependa de las capacidades de componentes de servidor de React? Ciertamente estamos tratando de integrarnos con los patrones que tienen.

Si quieres aprender sobre algunas cosas complicadas que estamos haciendo con componentes de servidor de React alrededor de React query, TAN stack query, puedes encontrar a Dominic, TK Dodo o Frederick y ellos pueden contarte todo sobre las cosas complicadas y locas que estamos haciendo. Pero sí, estamos haciendo nuestro mejor esfuerzo para apoyarlos con todas nuestras herramientas. Genial. Una pregunta de Vinny. ¿Cómo es el soporte de TAN stack router con configuraciones de monorepo? Genial. Creo que hay algunos desafíos con compartir tipos a través de monorepos realmente grandes que pueden tener múltiples piezas de front-end. Todavía estamos resolviendo parte de eso, pero el futuro es brillante. De hecho, probablemente podrías venir a hablar con Dominic una vez más, quien de alguna manera ha logrado configurar una gran experiencia de monorepo con TAN stack router y start. ¿Deberíamos simplemente subir a Dominic al escenario? Sí, sí. Únete a nosotros. Pregunta de Anónimo. ¿Qué pasa con React router v6 o 7 entonces? ¿Qué puede ofrecer más TAN stack router y deberíamos cambiar a TAN stack? Sabes, las capacidades principales son muy similares. Usan el mismo enfoque para la hidratación y SSR.

Probablemente enviarán soporte para componentes de servidor de React antes que nosotros, lo cual está totalmente bien. Pero comparando manzanas con manzanas, mantengo lo que dije. Creo que TAN stack router, solo como router, es mucho más avanzado y simplemente mejor, más agradable, más fácil de usar. Y eso es lo que recomendaría. Sería raro si pensaras que algo más es mejor que en lo que estás trabajando.

Estoy de acuerdo. Pregunta de Marcus. ¿Hay planes para soportar la federación de módulos en TAN stack start? Oh sí. Zach Jackson me habla cada semana sobre eso. Nos encantaría soportarlo. Solo estamos esperando el momento adecuado para dedicarle esfuerzo, pero está en nuestro radar. Algún día.

Y tal vez Marcus pueda simplemente construirlo. Siguiente pregunta de nuestro querido visitante Anónimo. ¿El TAN stack router soporta cargadores de cliente? Sí. Fácil. Oh, sí. Entonces no hay más preguntas llegando. Genial. Genial. Entonces supongo que tu charla fue bastante clara. Así que si no hay más preguntas de nadie aquí, voy a darte 10, 9, 8, 7, 6, 5, 4. Oh, Anónimo. ¿Está planeado dar soporte completo a Angular para TAN stack query? Me encantaría verlo pronto. Oh, me encantaría eso. Como con los adaptadores de framework, nos gusta tener un fuerte soporte para adaptadores de framework. Y tenemos algunas personas realmente inteligentes de adaptadores de Angular trabajando ahora con TAN stack query. ¿Es Arnoud? Él está aquí. Arnoud está aquí.

Así que si quieres eso, ve a hablar con Arnoud y dile, vamos. Hagámoslo. Así que sí, vamos a añadirlo. Démosle un aplauso. Ahí está. Ya es experimental. Así que puedes probarlo hoy. Pero sí, queremos tener un soporte a prueba de balas. Supongo que es bastante difícil construir para tantos frameworks. Pero es bueno saberlo.

¿Qué tan grande es el equipo? Oh, el equipo es enorme. Probablemente tenemos 7 u 8 mantenedores principales, otros 15 mantenedores auxiliares, y luego un montón de colaboradores. Y la mayoría de ellos, mencionaste, como que tenías los patrocinadores del año pasado trabajando a tiempo completo. ¿Y estas personas ahora están trabajando gratis? ¿O todavía queda algo de dinero de patrocinio? Hay dinero de patrocinio que distribuimos a los mantenedores principales. Y con suerte eso solo va a crecer y mejorar pronto. Tal vez algún día podamos contratar a más que solo a mí a tiempo completo en TAN stack.

Sería bueno si hay personas tal vez en la audiencia que trabajan en una empresa millonaria que usa TAN stack que tal vez puedan, tal vez dar algo de dinero. ¿No sería algo? No estoy mendigando, pero sería agradable. Siguiente pregunta de nuestro querido visitante Anónimo nuevamente. Está haciendo muchas preguntas. Hubo una captura de pantalla donde envolvías servidor y cliente y servidor, cliente, servidor. Sí, no voy a pronunciar eso. ¿Puedes hablar un poco más sobre este enfoque? Sí, cuando usas componentes de servidor, puedes componer componentes de cliente dentro de componentes de servidor que componen otros componentes de servidor dentro de esos. Y hay un patrón para poder hacer eso, para componer los hijos de React juntos de una manera que te permita entrelazarlos. Sí, es solo parte de usar componentes de servidor de React. ¿Funciona de la misma manera con las mismas reglas que el router de la app de Next.js? Sí, eso no tiene nada que ver con Next. Eso es solo cómo los componentes de servidor de React... Quiero decir las mismas reglas. Oh, sí, mismas reglas.

como los componentes de servidor de React... Quiero decir, las mismas reglas. Oh, sí, mismas reglas. Sí. Bien. De acuerdo. Una pregunta más de Anónimo. Las actualizaciones entre versiones principales de React han sido dolorosas. ¿Cómo manejarás esto en el router de 10 stack? Solo vamos a intentar no cambiar las cosas tanto. Ser estables. Sí. Quiero decir, nadie es perfecto. Tendremos algunos cambios disruptivos. Pero creo que lo que intentamos hacer es no cambiar las filosofías centrales y cambiar las arquitecturas centrales y pedir a los usuarios que asuman grandes cambios. Así que, sí, creo que cada biblioteca tiene cambios disruptivos y es solo parte de que una biblioteca se mantenga relevante. Así que, no prometo que nunca tendremos cambios disruptivos, pero puedo prometer que si los tenemos, serán fáciles, elegantes y valdrán la pena. Es solo... Sí. Los cambios disruptivos usualmente en mi opinión también significan que has ganado nuevos conocimientos y las cosas están mejorando tanto que valió la pena. Es una decisión que tomaste conscientemente. Y, sí, no tomas tales decisiones a la ligera. Los cambios disruptivos que intentamos hacer en 10 stack son donde puedes eliminar más de tu código.

Vale la pena. Nos quedan diez segundos. Así que, eso será todo para nuestra sesión de preguntas y respuestas en vivo. Voy a decir gracias una vez más, Tanner. Fue genial tenerte de nuevo.