Panel de Discusión: Dificultades de la Adopción de RSC Desde el Lado de Frameworks y Bibliotecas

Así que el tema para nosotros hoy es el título que se nos dio para reflexionar y meditar es Desafíos de la adopción de React Server Components como mantenedor o autor de una biblioteca o marco. Sabes, es un mensaje muy amplio y, ya sabes, creo que todos estamos muy interesados en el proceso que entra en la picadora. Sabes, creo que Daishi hoy, ya sabes, explicaste, mostraste, ya sabes, en la práctica lo que, ya sabes, como emprender es en realidad implementar todos los diferentes, ya sabes, tipos de casos necesarios para soportar los componentes del servidor. Así que vamos a saltar directamente a ello. Entonces, ya sabes, trabajas en un masterclass donde, ya sabes, tienes que esencialmente averiguar, ya sabes, todo esto, ya sabes, por ti mismo. ¿Cómo ha sido la experiencia? Bueno, ¿está encendido? Sí. Está bien. Así que desarrollar un marco de React es difícil. Una de las razones es que no está muy especificado. Así que pasé por todos los ejemplos y probé muchas, muchas cosas y vi, entendí el comportamiento, no desde el documento, no desde el código fuente y, sí, construí un modelo mental y creé un marco, lo cual sigue siendo una tarea difícil. Pero sí, lo he hecho. Lo has hecho. Sí. Sí. Un aplauso. Y entiendo que Tobi, estás en el proceso de hacerlo. Aún no lo has hecho del todo, pero estás cerca de haberlo hecho. ¿Es correcto? Estoy tratando de... decir que estoy cerca es difícil, pero sí. No, siento que finalmente estamos acercándonos a tener algo que podamos enviar para que los usuarios jueguen, por supuesto. Sí, correcto. Así que Redwood está haciendo la especie de migración, ya sabes, como antes, tú, ya sabes, como supongo que Redwood sería considerado como centrado alrededor de GraphQL y ahora en el futuro, la próxima versión de Redwood será...

Así que la próxima versión, volviendo a cuáles son nuestras versiones principales, intentamos, como estamos en la versión 8. Probablemente vamos a ser la versión 9, 10, tal vez antes de hacer el gran lanzamiento con React Serial Components. Así que nosotros intentamos hablar en épocas en su lugar, pero ya veremos. La mensajería es difícil alrededor de las versiones principales por supuesto porque la gente ha escuchado, espera cosas grandes, pero solo porque es una versión principal rompe. Pero sí, así que la próxima versión probablemente no, pero sí, la próxima época definitivamente será React Serial Components. Sí. Y Dominik, ya sabes, estás trabajando en React Query, que es como una biblioteca de cliente, ¿verdad? Pero, ¿te sorprende en absoluto que estés encontrando tu biblioteca en una posición muy fundamental en esta especie de, ya sabes, migración? Como, ya sabes, en mi trabajo usamos Next.js App Director y usamos componentes del servidor y usamos React Query, ya sabes, como el tipo de caché del lado del cliente.

Así que debes estar viendo muchos de los problemas y desafíos reales de los usuarios finales, ya sabes, de alguna manera. ¿Hay, ya sabes, algo como cuál ha sido tu experiencia como mantenedor de un proyecto, ya sabes, percibiendo a las personas adoptando componentes del servidor usando React Query? Sí, es un poco una posición incómoda porque, como dijiste, React Query es fundamentalmente una biblioteca del lado del cliente ¿verdad? Así que todos los hooks que exponemos no se pueden usar en el servidor. Así que a veces recibimos preguntas como, ¿podemos usar esto en componentes del servidor? Y la respuesta es, fundamentalmente, no, no puedes usarlo en un componente del servidor. No puedes usarlo en un marco que aproveche los componentes del servidor para renderizar si quieres algo de interactividad del lado del cliente o si quieres iniciar la obtención de datos en el servidor y luego enviar datos o incluso enviar la promesa al cliente y luego ponerlo en la caché del cliente y luego continuar con la interactividad del lado del cliente allí. Pero en los propios componentes del servidor, React Query en realidad no exporta ningún componente aparte del proveedor de contexto. Así que realmente no hay nada que puedas usar en un componente del servidor. Sí, pero aún así es una parte fundamental de ello y, de hecho, similar, tu esfuerzo anterior, eres bien conocido por ser un mantenedor de muchas bibliotecas de gestión de estado. Nuevamente, como las personas con las que has interactuado en el pasado, mantener estas bibliotecas ahora han enfrentado esta especie de replanteamiento monumental. ¿Estás viendo algún tipo de cambio allí? Sí, exactamente. Para las personas que han usado mi biblioteca de gestión de estado, quieren usar RSC del servidor, componente del servidor, pero no es posible porque es una biblioteca de gestión de estado del lado del cliente. Así que he tenido dificultades para explicar por qué esto no es posible o cómo deberíamos hacerlo. Así que esa es una de mis motivaciones para comenzar a desarrollar Waku para que eventualmente pueda apoyar esas bibliotecas de gestión de estado. Así que sí, eso es lo que pasa. Sí. Y creo que eso es algo así como, ayer estábamos hablando de esto y creo que un cambio de mentalidad es una gran cosa y probablemente pasaremos mucho tiempo hablando de ello. Así que antes de saltar a eso, Alexander, también quería preguntarte, acabas de dar una presentación donde mostraste una especie de línea de tiempo de las cosas en las que has trabajado en el contexto de los datos. Y fue muy interesante en el contexto de los componentes del servidor de React porque de alguna manera fuiste un pionero con Blitz, una especie de modelo temprano de poder importar código del servidor en código del cliente, aunque no se basara en RSC. Así que, ¿cómo ves esta transformación? Si estuvieras trabajando en ese proyecto o en tu próximo proyecto en ese espacio, ¿crees que RSC sería el camino a seguir para ti? Sí, creo que sí. Algo que intentamos hacer es minimizar esta capa de API para acercar el servidor al cliente, que también es algo que RSC permite. Y básicamente era este marco que te permitiría ejecutar código del servidor o acceder a tu base de datos directamente en tus componentes del cliente. Y sí, no usó RSC. Pasamos un tiempo pensando, como, bien, ¿cómo lidiamos con eso? ¿Cómo no copiamos el código? ¿Cómo no lo tenemos en dos lugares, en el servidor y en el cliente? ¿Cómo se comunica? Así que sí, definitivamente siento que los RSC son el camino. Es una pena que no los tuviéramos en ese entonces, pero es bueno que tuviéramos Blitz. Bueno, esa es siempre la pena del pionero. Tienes que resolver muchas cosas que las generaciones posteriores obtienen gratis, esencialmente. Así que saltemos a este tipo de cambio de mentalidad. Esto parece ser algo que, como, ¿fue ayer, tuvimos una pequeña conversación sobre de qué deberíamos hablar? Y Dominik dijo algo como, bueno, hay estos desarrolladores que simplemente no quieren actualizar su forma de pensar. Y yo estaba como, espera un minuto.

Soy uno de esos. Sí. Y me di cuenta de que soy uno de esos desarrolladores. He estado haciendo React desde prácticamente el principio. Y tengo un conjunto relativamente fijo de ideas sobre cómo quiero que funcione el marco porque es mi zona de confort. Y es un poco como el área donde no me di cuenta de que se me estaba pidiendo innovar, crecer o aprender. Yo pensaba que eso estaba más o menos establecido y que podía centrarme en otras cosas. Y ahora, de repente, ustedes me están pidiendo que salga de mis viejos hábitos y aprenda cosas nuevas. ¿Es correcto?

Creo que es un cambio de mentalidad aún mayor que el que tuvimos cuando pasamos de componentes de clase a hooks. Quiero decir, de alguna manera es similar porque tenías que dejar de pensar en ciclos de vida y tú deberías comenzar a pensar en la sincronización de datos con hooks. Y eso, de alguna manera, no fue fácil para muchos desarrolladores. Hubo muchas cosas que habías aprendido antes que necesitabas desaprender y luego continuar con lo nuevo. Y creo que con los componentes del servidor, es similar. Y es probablemente incluso más un cambio de mentalidad, porque de repente necesitas pensar en ¿dónde está el límite entre el servidor y el cliente? ¿Qué puedo hacer en el servidor? ¿Qué puedo hacer en el cliente? ¿Dónde pongo esos límites para el compilador? ¿Cómo obtengo un componente del servidor como hijo de un componente del cliente para que no tenga que tener todos los componentes del cliente comenzando desde un punto hacia abajo y así sucesivamente? Y hay mucho desaprendizaje que necesita hacerse y mucho aprendizaje de cosas nuevas.

Y no sé, tal vez las futuras generaciones de desarrolladores lo tengan un poco más fácil porque no están cargados con trabajar durante muchos años solo con estas cosas del lado del cliente y luego necesitar realmente repensar todo. Y probablemente nos superarán por mucho. No lo sé. Creo lo mismo. Es difícil para nosotros que estamos acostumbrados a trabajar todo en el cliente cambiar a trabajar en el servidor. Pero hablo con muchos desarrolladores que son desarrolladores de back-end o que trabajan con marcos como Django, por ejemplo, y piensan que estamos locos haciendo todo este uso de hooks en el cliente. Dicen que tenemos un modelo mucho más simple porque podemos centrarnos solo en el servidor. Y creo que con los Componentes del Servidor de React, podemos obtener un modelo más simple para React también. Así que creo que para las nuevas personas que comienzan con React, los Componentes del Servidor de React en realidad están haciendo las cosas más simples y fáciles. Sí, creo que definitivamente es más simple para los recién llegados. Pero si ya tienes aplicaciones existentes, tienes que migrar a la nueva.

Sí, pero también algo que Jani mencionó, como que hay personas que ya están acostumbradas al modelo actual y podría llevarles un tiempo aprender el nuevo. Como, aunque para los recién llegados, como aprender desde cero, como que hay una cosa de RSC, podría ser bueno. Pero creo que hay un montón que necesitarían pasar por una cierta fase de frustración sobre cómo cambiar a esos componentes o cómo aprender esas cosas, cómo escribir de manera diferente. Sí, quiero decir, la única palabra que escucho mucho en esta conversación es simplicidad, ¿verdad? Como que hace, sabes, como que estoy tratando de ir hacia la simplicidad desde la perspectiva del desarrollador. Y luego tienes a los autores de marcos o bibliotecas para llevar la complejidad. Y supongo que ese siempre es el trabajo del marco, sabes, como encontrar una abstracción que haga la mayor parte del trabajo de una manera que ayude al desarrollador. ¿Dónde crees que estamos en la experiencia del usuario final o del desarrollador final allí? Como si miras las implementaciones actuales de los componentes del servidor, creo que Next.js es el más utilizado en producción. Y luego Waku, por ejemplo, ¿ya hoy, como dirías que es más simple y habrá más oportunidades para la simplificación para construir aplicaciones en este nuevo modelo? Aún no he construido algo como grado de producción con componentes del servidor. Así que desde mi perspectiva, todavía estamos en el borde de las cosas. Como si miras las cosas que se discuten en Twitter o en conferencias, esto está todavía muy lejos de lo que realmente está sucediendo en la mayor parte de la larga cola de la industria. Así que todavía estamos en los primeros adoptantes, aunque los componentes del servidor existen desde, no sé, más de un año o algo así. Sí, todavía creo que va a llevar mucho más tiempo hasta que haya una adopción amplia de ellos. Sí. Y también creo que necesitamos más implementaciones que solo una para poder ver cuáles son realmente las buenas partes y qué partes se pueden mejorar. Es difícil saber, como, qué es fundamental para cómo los componentes de React tienen que funcionar y qué es solo una parte de la forma en que elegimos implementar el protocolo o el, sí, qué está haciendo el marco y qué es parte de React. Es difícil saber cuando hay solo una implementación. Así que cuando más personas comiencen a usar Waku, cuando Redroot finalmente pueda enviar algo con lo que la gente pueda jugar y tengamos como tres implementaciones diferentes, ahí es cuando creo que podemos comenzar a ver cuáles son los buenos patrones y qué deberíamos llevar adelante. Sí, si tengo que añadirlo, así que Waku se desarrolla porque quería tener RSC solo sin SSR, sin enrutador. Solo quería aprender cómo funciona RSC. Y no había tales cosas antes. Así que este es mi primero. Este debería ser el primero. Y puedes aprender RSC sin SSR y enrutador. Sí, eso es, sabes, como Redwood, por ejemplo, dijiste que necesitarías tres implementaciones. Y así tenemos Next.js, ahora tenemos Waku. Y luego suena como si Redwood pudiera ser como el tercero. ¿Qué estás aprendiendo de el arte previo? Miras, por ejemplo, la implementación de Next.js. Por supuesto, parte de ello está atada a las suposiciones que tienen sobre la infraestructura y la forma en que se alojan las aplicaciones. Pero ¿cuáles son las cosas que dices, oh, esas son buenas ideas? Y luego tal vez esas son algo sobre lo que queremos innovar? Sí.

Así que cuando comenzamos, básicamente no había ejemplos por ahí y no había documentación. Y así comenzamos a mirar a Next. Pero como los componentes de React son en realidad bastante fáciles, o como el concepto es simple. Pero implementarlo en un marco es muy, muy difícil. Y tratar de seleccionar las partes que son fundamentales para los componentes de React al mirar el código fuente de Next es difícil, solo porque Next es un marco tan grande y hacen algunas cosas principales. Así que en realidad, o yo en realidad comencé copiando mucho código de Wacuu, porque ustedes, siempre han estado unos meses por delante de nosotros. Así que yo pude aprender mucho de lo que él estaba haciendo allí en Wacuu. Y eso fue mucho más simple porque anteriormente habíamos cambiado de Webpack a Vite. Y él también fue el primer autor en construir sobre Vite con componentes del servidor. Eso también nos facilitó aprender de su ejemplo. Ahora, es mucho más fácil. Ahora hay muchos más ejemplos por ahí. Así que si ahora, si quieres implementar algo desde cero con componentes de React, hay muchos otros YouTubes, hay publicaciones en blogs y muchos ejemplos por ahí que puedes consultar. Pero cuando comenzamos, no había nada como eso.

Sí, como dije, no hay docs. Pero hay algo llamado fixtures en el repositorio de React, de lo que puedes aprender. Y eso ejecuta RSE solamente. Así que eso fue uno de nuestros recursos. No miré el código de Next.js porque es complicado. Y combina todo. Así que sí, iba a decir, sí, esa imagen es un buen recurso. Y hice muchos, experimentos con cómo se comporta. Y de alguna manera, funcionó. Sí, casi me parece en cierto sentido que como los componentes del servidor de React son menos una implementación y más solo la especificación. Por supuesto, es especificación en código, y tiene como partes que usas en la implementación, pero deja a los autores de marcos para que sorteen un poco la forma de las cosas.

Así que, ¿ustedes hablan en el fondo? ¿Hay algún tipo de grupo de trabajo o intercambio? ¿Construyen algún tipo de conocimiento compartido, utilidades, entendimiento? ¿O todavía es muy como si todos estuvieran en su propio silo, resolviéndolo y la convergencia vendrá más tarde? Hay un poco de ambos.

Y eso ha sido muy útil. Como compartimos aprendizajes y preguntas allí. Y aprendo mucho al leer lo que otras personas, las preguntas de otras personas y cuáles son sus respuestas. Y especialmente para Vite, hay en realidad muchas personas que en este momento están experimentando con diferentes cosas, muchos desarrollos emocionantes sucediendo allí de los que aprender.

Bien, bueno, quería hacer una pregunta un poco picante. No sé. Siéntete libre de no responder esto si es algo que no está dentro de tu zona de confort. Pero sabes, como ahora mismo tenemos esta implementación de componentes del servidor que es realmente madura, madurando ahí afuera. Y también sucede que es hecha por la compañía que emplea al equipo central de React y les paga para, ya sabes, construir esto, ya sabes, una especie de tecnología es como, ¿cómo ves esa relación, ya sabes, a largo plazo para la comunidad como una especie de implementadores de terceros, como, obviamente, hay algunas partes buenas, pero ¿hay algunos desafíos también?

Así que, bueno, cuando escucho con qué están luchando los otros autores de marcos, parece que hay un poco de ventaja injusta en toda esta situación donde se dijo la palabra que, ya sabes, aquí están los componentes del servidor de React, ahora están listos, puedes usarlos y Next.js los ha implementado y está listo y todos los demás como, ve a resolverlo tú mismo, tal vez, no lo sé. Pero no he tenido esta lucha yo mismo. Y creo que desde otra perspectiva, creo que en realidad es bueno que los mantenedores del equipo central de React ahora estén un poco más distribuidos entre diferentes compañías. Creo que eso no perjudica, en general.

Sí, y estoy de acuerdo. Y creo, creo que todos estamos de acuerdo. Y lo vemos con Next ahora mismo con la iniciativa OpenNext o algo así, donde puedes realmente comenzar a desplegar Next completamente funcional en otros ecosistemas, no solo con dentro de Resell. Y creo que es lo mismo con los componentes de React, necesita ser implementado en más de un lugar. Creo que es lo mejor para todos nosotros.

Hablando de la ventaja injusta, no estoy seguro de si esto está realmente relacionado con nuestro equipo central de React siendo empleado por Next por Versal. Pero también como el hecho de que el equipo de Next.js es bastante grande. Recuerdo que estábamos luchando con eso con Bleeds, como que no podíamos iterar tan rápido como ellos. Así que en un momento, como que ellos estaban, tú sabes, estaban añadiendo características, estaban lanzando nuevas versiones de Next.js, y no había forma de que nosotros pudiéramos ponernos al día con un equipo de dos personas. Así que eso puede ser también una razón. Sí, quiero decir, sentimos eso todo el tiempo.

Ellos tuvieron su Next.conf. Y obviamente, tienen muchas características increíbles, pero luego también tenemos que recordar que son un gran equipo. Y nosotros somos muy pequeños. Definitivamente somos los desvalidos aquí. Y estás prácticamente solo. Pero apuesto a que es aún peor para ti. Pero para la plena divulgación, Versal patrocinó Waku. Así que les importa la comunidad. Así que creo que es algo bueno.

Sí, creo que definitivamente no quiero como intentar forzar una narrativa de que haya como una competencia o como una ventaja injusta en el sentido de que hay una carrera hacia algún tipo de recompensa, ¿verdad? Como, ya sabes, estas diferentes entidades tienen motivaciones altamente diferentes sobre, ya sabes, como explorar este tipo de cosas. Creo que principalmente estoy pensando desde la perspectiva de un desarrollador que quiere, ya sabes, construir aplicaciones y quiere usar el tipo de mejor, ya sabes, herramienta para el trabajo. Y luego, ya sabes, algunas herramientas están como atadas a ciertos, por ejemplo, plataformas de infraestructura y, ya sabes, etcétera, está, ya sabes, hubo un término que se mencionó, ya sabes, hace unos años, algunas personas lo llamaron el complejo industrial de React. Ya sabes, esto es como una industria de empresas alrededor, ya sabes, esto es como, ¿está RSC haciendo que React, ya sabes, debido a la complejidad de implementación del marco, se esté convirtiendo más en un, ya sabes, como un campo de pocos jugadores dominantes? ¿O sientes que hay posibilidad de que los desarrolladores individuales contribuyan en un sentido de comunidad abierta de código abierto? Tanto como tal vez en los viejos tiempos del desarrollo solo del cliente? Creo que definitivamente todavía hay espacio para la experimentación y contribuciones individuales, definitivamente contribuciones, como en Redwood, siempre estamos felices de recibir más contribuciones. Y es fácil para, tal vez no fácil, pero damos la bienvenida a cualquiera y estamos felices de ayudar a cualquiera a comenzar a contribuir, por supuesto. Otra motivación por la que desarrollé Waku es para aceptar más como para hacer crecer el ecosistema. Así que proporciono algunos primitivos mínimos, que la gente puede usar para desarrollar una nueva biblioteca sobre eso. Así que ese es realmente mi objetivo. Sí, no, eso es increíble. Y creo que, ya sabes, como, dado que haces el trabajo duro, y de hecho, otras personas pueden innovar sobre eso. Eso es, ya sabes, creo, y también el equipo V está haciendo un gran trabajo facilitando que las personas construyan estas cosas, especialmente con V6 que se avecina con la API de entornos que va a hacer que mucho de esto sea mucho, mucho, mucho más simple de lo que era antes. Y también facilitando, por supuesto, que cualquiera construya algo con su propio giro a los componentes de React. Y es como dijiste, es más una especificación y la gente puede elegir qué partes de ella implementar. Así que creo que vamos a ver algunas cosas interesantes saliendo del equipo de Remix cuando con sus enfoques sobre ello. Y vemos con 10 stack, su enfoque sobre los componentes de React también es súper interesante. Así que creo que veremos más de eso.

Sí, ¿cuál es el enfoque de 10 stack sobre los componentes de React? De hecho, tengo varios componentes, de hecho no sé nada sobre esto. Sí, no soy un experto en el tema. No estoy realmente involucrado con 10 stack start tanto. Pero la forma en que lo entiendo es que Tanner está tratando de ver los componentes del servidor de React como si el payload de RSC fuera solo otra forma de datos que transfieres desde el servidor. Así que similar al enfoque de Remix donde básicamente tienes cargadores que pueden devolver componentes que luego serán enviados como payload de RSC al cliente. En 10 stack start, muy probablemente tendrás funciones de servidor que puedes declarar, y que pueden devolver datos, JSON, lo que sea, o flujos o payload de RSC. Y luego puedes crear componentes en el servidor y transmitirlos al cliente de esa manera. Así que un enfoque diferente al de Next.js y también Baku están teniendo. Pero sí, creo que cuantas más diferentes perspectivas haya, es experimentación en un nivel muy vanguardista. Y lanzaremos cosas a la pared y veremos qué se queda básicamente.

Genial. Así que una cosa de la que hemos hablado aquí es claramente esta necesidad de implementaciones, implementaciones adicionales, para aprender más sobre las cualidades de esta tecnología. Pero, ¿qué más se necesita? Sé que, Toby, estás trabajando en algunas herramientas para desarrolladores. Pero, ¿cuál es el estado de si la gente quiere involucrarse en explorar el espacio, cuáles son algunas de las áreas que claramente están gritando por atención pero que aún no han recibido atención? Sí, como dijiste, estoy terminando mi charla en unos minutos. Voy a hablar más sobre las herramientas desarrolladas, y creo que eso es algo que realmente se necesita. Y creo que el equipo de Next también se está dando cuenta de que se necesita, pero tienen otras cosas en las que enfocarse también. Así que definitivamente hay espacio para contribuciones allí si quieres involucrarte. Y también es una muy, muy buena manera de convertirte en un experto en los Componentes del Círculo de React, como construir herramientas sobre ellos o para ellos. Realmente te obliga a entender cómo funcionan.

¿Alguien más tiene alguna lista de deseos? Sí, no sé si eso ya se ha resuelto. Es como cómo probar todas estas configuraciones de componentes del servidor, aparte de las pruebas de extremo a extremo. Creo que esa fue la respuesta inicialmente, como tienes una aplicación con componentes del servidor y quieres probarla, necesitas pruebas de extremo a extremo en ella. Creo que Storybook luego intentó obtener algo de soporte para componentes del servidor también. No sé cuál es el estado actual, pero la última vez que verifiqué, era solo una prueba de extremo a extremo. Está bien, esto es bueno para algunas situaciones, pero no es lo que todos están haciendo todo el tiempo. Entonces, ¿cómo se aborda eso? No sé si esa es una pregunta respondida en el ínterin, pero esto era algo que me he estado preguntando.

Claro. Bueno, una cosa que he escuchado, una y otra vez, surgir en esta conversación es cómo no ha habido mucha documentación o no hay un recurso autoritativo sobre cómo comenzar. ¿Es ahora el momento de crearlo o todavía estamos resolviendo las cosas? Sí, supongo que sí. Pero nuestro equipo hizo un gran trabajo y tenemos un sitio web, un sitio web de trabajo, que explica todo desde el principio. Sin que sepas RSC, explica todo para acostumbrarte a ello. Pero ese es nuestro sitio web. Sería bueno si hubiera más sitios web con autoridad. Tengo que decir que el equipo de React ha hecho un gran trabajo en su documentación. Ahora hay en realidad mucha, mucha más documentación de la que solía haber. Incluso tienen algunas secciones en su documentación que dicen, esto es para autores de marcos. Así que así es como el marco debería implementar esto. Y luego tienen otra sección sobre cómo los usuarios deberían usarlo. Y eso ha sido súper útil. Ojalá hubiera existido cuando empecé.

Genial. Bueno, parece que estamos llegando al final de nuestro tiempo. Nos quedan aproximadamente cuatro minutos y tenemos cuatro panelistas aquí. Así que creo que hagamos un pequeño ronda rápida aquí. ¿Cuál es algo emocionante en lo que estás trabajando personalmente o esperando trabajar en el próximo año? ¿Hay algo en lo que realmente estés ansioso por profundizar? No preparé a estas personas para esta pregunta. Bueno, así que, sí, no está como ligeramente relacionado con los componentes del servidor, pero lo que estamos tratando de implementar actualmente es una integración de suspense en React query que se basa básicamente en pasar la promesa de use query de vuelta a los usuarios donde pueden luego pasarlo al operador use para básicamente activar el suspense en cualquier nivel que deseen. Y esto va de la mano con también crear la promesa en el servidor y luego transmitirla al cliente y básicamente consumirla, como activar la prefetching en el servidor y luego consumirla en el cliente. Todas estas son cosas que son algo experimentales, pero también muy interesantes para entender, como iniciar una promesa en el servidor y luego enviarla al cliente. Técnicamente no sé cómo funciona eso en realidad, pero creo que simplemente funciona al menos en Next. Así que eso es bastante genial. Personalmente, realmente espero comenzar a jugar más con la parte de obtención de datos. En Redwood, tenemos este concepto de una celda que utiliza GraphQL para obtener datos, y queremos que a nuestros usuarios les encante, a nosotros nos encanta, y queremos tener algo similar para los componentes de React. Así que esa es un área en la que quiero profundizar más cuando nuestra implementación general de RCE sea más estable. Algo que es emocionante para mí, y creo que puede ser posible con los componentes del servidor de React, es que me gustaría ver una solución de relay para los componentes del servidor de React. Ahora que no tenemos que tener la capa APA, podemos acceder a los datos directamente desde los componentes. Aún sería bueno tener un compilador encima de eso, algo relacionado con GraphQL. Y eso podría ser algo que comenzaremos a explorar en EdgeDB. Sí, ya lo insinuaste al final de tu charla. Sí. ¿Ya estás trabajando en eso, o es algo para el próximo año? Creo que es más como para el próximo año. Pero sí, se veía muy emocionante. Y es una pena que no tuviéramos tiempo para hablar más sobre GraphQL porque esto también es algunas de las cosas que siento que con cada revolución en la tecnología, parte del viejo bebé se queda en el agua sucia mientras avanzamos, por así decirlo. He sido un gran usuario de GraphQL a lo largo de los años. Así que espero que podamos hablar de eso en tu sesión de preguntas y respuestas en la sala de Q&A en un momento. ¿Daishi? Sí, esto es algo que sigo diciendo hoy, pero Waku se está preparando. Aún está en v0, pero estamos trabajando duro para hacerlo v1. Pero para hacerlo estable, necesitamos algunos colaboradores, o al menos personas que tengan que probarlo para hacerlo estable. Así que realmente te animo a que lo pruebes y nos des tu opinión. Genial. Gracias. Bueno, lo que espero es que, creo que este panel me ha convencido claramente ahora de que estoy atrasado para un cambio de mentalidad. Y tal vez el próximo año sea el momento de comenzar a jugar con esta nueva tecnología y ver cuáles son las oportunidades reales, porque en este momento soy solo ese viejo gruñón que siente que todo es arena movediza. Así que gracias a todos por trabajar en crear ese futuro. Y espero el próximo año estar más involucrado en ello. Así que gracias a nuestros panelistas. Démosles un aplauso.