Herramientas de Desarrollo de Última Generación para React Server Components

♪ Hola a todos. Muchas gracias por decidir pasar este tiempo conmigo aquí. Como escucharon, mi nombre es Toby, o Toby, que aparentemente significa bañera en holandés, lo aprendí ayer. ¿Es esto divertido? Sí, entonces Redwood, no creo que haya visto ninguna mano levantada cuando preguntaste, así que... Redwood es un marco de trabajo súper productivo para construir aplicaciones web full-stack en JavaScript y TypeScript. Este es Redwood Studio. Es una aplicación complementaria a la que tienes acceso con cada aplicación de Redwood que construyes. Es una colección de herramientas útiles que puedes usar como desarrollador.

Aquí, vemos el panel principal con algunos gráficos de rendimiento. Si miramos el menú de navegación, puedes ver qué más está disponible. Tenemos monitoreo de OpenTelemetry. Hay una sección para algunas herramientas de GraphQL. Tenemos la sección de base de datos donde puedes ver tu esquema de base de datos en un gráfico, como un diagrama ER, y usamos Prisma como nuestro ORM. Al ir aquí, puedes ver las declaraciones SQL reales que se envían a tu base de datos.

A continuación, tenemos la integración de mailer. Entonces, cuando ejecutas Studio, tienes tu propia bandeja de entrada de correo electrónico de tiempo de desarrollo, así que cuando trabajas en cualquier característica de Redwood donde envías correos electrónicos, nunca corres el riesgo de enviar correos de prueba a clientes reales, porque todos terminarán aquí en Studio. Y también puedes previsualizar tus plantillas de correo electrónico.

Luego tenemos la sección de RSC, que es de lo que vamos a hablar hoy. Pero finalmente, solo quiero mencionar SSR, donde obtienes una vista previa de cómo se verán tus diferentes páginas cuando las compartas en redes sociales. Y finalmente, hay solo alguna información de Studio en la parte inferior.

Antes de pasar a la sección de RSC, solo quiero asegurarme de que todos estemos en el mismo, como, tipo de nivel básico de conocimiento sobre componentes de React Server. Quiero decir, esto es React Advanced, y todos han decidido escuchar una charla sobre herramientas de desarrollo de componentes de React Server, así que supongo que tienen alguna idea de lo que son los componentes de React Server. Pero rápidamente, los componentes de React Server son una forma de ejecutar componentes de React en el servidor en un contexto de servidor. Como, hemos estado haciendo componentes de React en el servidor por un tiempo con SSG y SSR, pero eso siempre ha sido en un contexto de cliente o navegador. Y todos esos componentes también se envían al navegador y se ejecutan en el navegador también. Con los componentes de servidor, solo se ejecutan en el servidor en un contexto de servidor. Y luego el resultado de ejecutar esos componentes se envía al cliente con este nuevo formato conocido internamente como Flight, pero más comúnmente conocido como el payload de RSC. Es un nuevo formato alineado, delimitado, tipo JSON.

Así que ahora que sabes eso, si vamos al primer elemento allí en nuestro RSC, parte del menú, tenemos el caché. Y de inmediato aquí, puedes ver este formato de payload de RSC como los valores de caché. La clave de caché, no sé, es demasiado pequeña para que la veas, pero la clave de caché es la URL en la página que estás visitando, y el valor es, como dije, el payload de RSC. El almacenamiento en caché es difícil. El almacenamiento en caché en el servidor es difícil. El almacenamiento en caché en el cliente es un poco más difícil. La invalidación de caché en el cliente es súper difícil desde una perspectiva de marco de trabajo. Así que supe que tan pronto como comencé a implementar soporte de almacenamiento en caché en el cliente, necesitaba construir, o quería construir algunas herramientas de desarrollo alrededor de eso. Así que por eso añadí esto. Honestamente, sin embargo, esperamos poder enviar sin almacenamiento en caché del lado del cliente de RSC.

Creemos que como desarrollador, tienes mucho más control si puedes hacer el almacenamiento en caché en el servidor, especialmente en torno a la validación de caché. Tal vez lo hagamos opcional para rutas donde sabes que realmente marcaría la diferencia. Pero si lo hacemos, definitivamente también vamos a hacer la estrategia de validación de caché configurable para ti como desarrollador. Pero sí, con suerte podemos enviar solo con almacenamiento en caché del lado del servidor y luego simplemente hacer lógica de validación normal y general en el cliente. Y con suerte eso dará una experiencia de usuario lo suficientemente buena.

Sí, así que esto es almacenamiento en caché del lado del cliente, y más específicamente, almacenamiento en caché completo del lado del cliente. Así que la entrada de caché es en realidad mucho, mucho más larga de lo que puedes ver aquí. Es toda la carga útil de la página la que está en caché. Tengo algunas otras ideas sobre un almacenamiento en caché más enfocado, como más granular solo para la obtención de datos. En el Redwood actual, usamos GraphQL, y tenemos la caché de Apollo Client. Es súper poderosa. Y sería interesante ver si hay algún concepto de cómo funciona la caché de Apollo que podamos aplicar a la obtención de datos con Rack Server Components. Tal vez haya algo en el fondo de mi mente aquí sobre RcIslands, pero ahora solo estoy soñando principalmente. Así que bájalo un poco y sigue adelante con lo que es realmente posible y está disponible ahora mismo.

Esta es la tercera... Lo siento, esta es la última página. Tuvimos caché, luego tenemos RcPayloads. Vamos a omitir eso por ahora, porque esa es la parte jugosa, y hacer render routes. Esta es la función en la que tenemos más trabajo por hacer. Pero la idea es que tienes una lista de todas tus rutas. Cuando haces clic en una de las rutas, obtienes un gráfico de todos los componentes que son visibles en esa página. Y luego podemos resaltar qué componentes se renderizan como componentes de servidor y qué componentes se renderizan como componentes de cliente. Creemos que esto puede ser súper útil, especialmente desde un punto de vista educativo, porque nosotros, como framework, sentimos que necesitamos educar a nuestros usuarios, pero también para los desarrolladores de aplicaciones y los miembros del equipo en tu equipo para ver rápidamente qué componentes tienes en tu página y dónde se renderizan.

Esto en realidad comenzó como un simple gráfico de Excalidraw como este. Dibujé este gráfico hace mucho tiempo cuando comenzamos a explorar componentes Rackstar dentro de Redwood. Así que en la parte superior, tienes los componentes de la página, página de ejemplo. Y luego ese es un componente de servidor. Y todo lo que está debajo en naranja también son componentes de servidor. Y luego probablemente puedo adivinar que las partes azules son componentes de cliente. El momento aha aquí, o lo que puedes ver, es que tan pronto como cambiamos a componentes de cliente, todo lo que está debajo de eso son componentes de cliente. Pero hay una cosa importante aquí. Esto significa que los componentes azules se importan de otros componentes de cliente. Es la importación. Es donde se importa un componente lo que es importante. Tener un gráfico como este hace que sea fácil ver si tienes componentes que pensabas que solo se renderizaban en el servidor que ahora se están renderizando en el cliente. Como, si miramos number.txt aquí, por ejemplo, ese componente se renderiza en el servidor bajo data display. Pero también renderiza un componente de cliente en la parte inferior. Quiero decir, no hay nada malo con esto. Esto podría ser exactamente lo que querías. Pero si pensabas que solo se renderizaba en el servidor, tener un gráfico como este puede ser realmente revelador para ti. Así que si querías que fuera un componente de servidor solamente, solo renderizado en el servidor, definitivamente puedes hacerlo. Lo que tendrías que hacer es mover la importación, porque ahora mismo se importa desde td.tsx, pero si mueves esa importación hacia arriba donde el gráfico es naranja, así que, por ejemplo, en table data cell, tendrías un gráfico que se vería así en su lugar. Así que ahora es un componente de servidor que se pasa como props a td y luego se renderiza en la pantalla. Así que este es el tipo de gráfico que quiero tener en el medio aquí.

Todavía hay mucho que debemos resolver para hacer eso posible, pero ese es el objetivo aquí.

Y ahora la parte final de nuestras herramientas RSC, el RSC payload. Antes de sumergirme en esta sección, quiero hacer una pausa un poco y decir que como framework, escribimos mucho código, por supuesto, mucho código de enlace entre diferentes bibliotecas que integramos. Pero también dependemos de mucho código que otras personas han escrito, así que quiero aprovechar esta oportunidad para dar un agradecimiento especial a Alvar Lagerlöf, quien está aquí en la audiencia hoy. La parte de RSC payload de Studio no sería ni de cerca tan buena como es si no fuera por el increíble trabajo que Alvar ha hecho en su biblioteca RSC partial. Así que gracias, Alvar. Y de hecho, sí, ¿por qué no damos un gran aplauso? Un gran aplauso. No solo a Alvar, sino a todos los mantenedores de código abierto cuyo trabajo nos beneficia a todos diariamente. Gracias. Gracias a todos.

Así que volviendo a la página de RSC payloads. En la parte superior, ves una línea de tiempo de todas las respuestas RSC que la app ha recibido. Y luego abajo, hay una lista de todas esas mismas respuestas también. Me voy a centrar en la cuarta desde arriba. La clave es la barra, así que esto es para la página raíz o la página de inicio. Así que si hago clic en eso en nuestras herramientas de desarrollo aquí, me lleva a esta página. Comenzando en la esquina superior derecha, tenemos el RSC payload en bruto. Hay diez líneas de este nuevo formato delimitado por líneas JSON-ish allí, cada línea representa un fragmento de la página de inicio. En el otro lado, tienes un diagrama circular. Y en ese diagrama circular, tienes esos mismos diez fragmentos. Y podemos ver inmediatamente que hay un fragmento, el verde. Eso es como la mitad del tamaño del payload. Así que ese podría ser un fragmento en el que queramos profundizar un poco más. Abajo, debajo del diagrama circular, esos mismos fragmentos también están disponibles. Y puedes obtener un nombre para ellos. Así que el verde, probablemente no puedas ver, pero el verde se llama model zero. Volviendo al otro lado de nuevo, debajo del RSC payload en bruto, tenemos algunas estadísticas. Así que esto es útil si comparas diferentes payloads. Lo que vemos allí o lo que está disponible allí es la duración del renderizado. Así que puedes ver, bien, ¿cuánto tiempo le tomó al servidor renderizar este componente de servidor? Y también obtienes el tamaño del payload.

¿Qué tan grande es este payload en total? Y eso podría darte una idea de, está bien, wow, esto es realmente grande. ¿Por qué es tan grande este componente? Tal vez hay algunos datos allí que no necesitamos incluir en el payload inicial de RSC. Tal vez podamos cargarlos de manera diferida en el cliente más tarde para algunas mejoras de velocidad.

Muy bien, así que vamos a sumergirnos en el grande, el green model zero. Si hago clic en ese, me lleva más abajo en la misma página a esta vista. Lo que tenemos arriba es solo esa línea de fragmento único del payload en bruto. Es súper ancho y muy difícil de leer. Así que justo debajo, tenemos una versión impresa en 3D de él, el mismo payload. También sigue siendo un poco difícil de leer porque en lugar de ser súper ancho, ahora es simplemente súper largo en su lugar. Pero lo interesante de la versión impresa en 3D es que es interactiva. Puedes hacer clic aquí.

Así que lo que puedo hacer es colapsar el elemento div superior, el primer elemento div allí, y ver que tenemos esto. Así que ahora, solo una advertencia justa aquí, estás profundizando. Esto está en un nivel técnico de internals de framework React, pero lo que tenemos aquí es en la versión impresa en 3D tenemos un objeto con una clave de __rwjs__routes. Eso es solo para asegurarme de que no estoy sobrescribiendo nada. Esto es único para Redwood. Y luego tenemos todo el fragmento. Puedes ver que este gran fragmento era solo un gran elemento div con un montón de elementos anidados dentro.

Así que para aquellos de ustedes que no están familiarizados con Redwood, tenemos un solo archivo de rutas. No hacemos enrutamiento de sistema de archivos. Tenemos un solo archivo de rutas que se llama routes.

Y recuerda que hice clic en el cuarto elemento desde arriba con solo una barra con una URL raíz, y eso se mapea a la homepage. Y eso es lo que posiblemente, al menos si estás en la primera fila, puedes ver en este archivo de ruta en la parte superior. Tienes una definición de ruta para la ruta de la barra, y luego eso se mapea a la homepage. También puedes ver en el archivo de ruta que en la parte superior hay un diseño de navegación que envuelve todas las páginas. Así que lo que el enrutador realmente renderizará aquí es el diseño de navegación y luego la única página que se mapeó a la URL en la que estamos actualmente. Y lo que podemos empezar a hacer ahora es mapear lo que tenemos en el payload con lo que realmente se renderiza. Así que en el payload, podemos ver... Aquí vamos. Así que en el payload podemos ver en verde, en la versión preimpresa, ves class name y luego navigation layout. Y si miras de cerca en la salida en bruto, puedes ver eso también en el medio. Así que eso corresponde entre sí. Y si miramos la implementación real del diseño de navegación, el código fuente, podemos ver que tiene el mismo class name justo allí. Y debajo de él, hay un elemento HTML nav estándar. Eso también está disponible en el payload. Eso es como al final de lo que podemos ver en la salida en bruto. Y luego también en la versión preimpresa. Así que ahora puedes empezar a tener una idea de cómo funciona el payload. Es básicamente solo una versión más compacta de tu JSX en bruto. Y luego hay algunos nodos azules allí. Me adentraré en ellos en un segundo. Pero primero quiero mostrarte una cosa más. Y para hacer eso, necesito volver a esta vista. Así que todos los payloads están mapeados a algo que parece una URL. Pero hay uno que destaca. En el medio, justo debajo del que tiene la marca, hay uno que es diferente. Si no puedes leerlo, dice RSA action 0.mjs y luego un hash y luego un identificador que es on send en este caso. Así que porque es diferente, por supuesto, necesitamos investigar eso. ¿Por qué es eso diferente? ¿Qué es eso? Así que hago clic en él y llego aquí. Y se ve prácticamente exactamente igual que para la homepage que acabamos de ver. Todavía está este gran verde para el modelo 0.

Así que voy a seguir adentrándome en el modelo 0. Sigue siendo lo mismo. Pero ahora, si colapso todos los elementos dentro del div, llegamos aquí. Y ahora podemos ver que en realidad hay uno más. Hay una nueva cosa aquí. Así que déjame acercar. Si miras la versión preimpresa aquí, ves que la clave sigue siendo para las rutas y el div con todos los elementos anidados. Pero debajo de él, tienes algo llamado RSA data, hello world, etcétera. Así es como he elegido implementar soporte para acciones de XServer. Cuando ejecutas la acción del servidor, obtienes el resultado de esa ejecución de acción. El valor de retorno de tu acción o tu función, obtienes eso devuelto.

Pero también obtienes toda la página nuevamente en la que estás actualmente. Así que si tu acción del servidor actualizó un valor que es parte de algunos de tus componentes del servidor, obtienes eso como parte del valor de retorno también. Y no solo obtienes el valor de retorno, sino que también obtienes toda la página renderizada con este valor ya actualizado en la página.

Así que ahora podemos simplemente pedirle a React que tome el payload actualizado y haga un diff del DOM virtual con lo que está renderizando actualmente en el navegador del usuario y simplemente actualice el valor que fue actualizado por tu acción. Esto nos ahorra de hacer otro viaje al servidor solo para obtener el valor actualizado.

Bien. Ahora sigamos adelante, expandiendo el div allí. Ahora, profundizando más en los objetos anidados, vemos estos nodos azules nuevamente que prometí que volvería a ellos. Tenemos dos. Eso dice LazyNode, y así es como React sabe cargar de manera perezosa uno de tus componentes del cliente. Así que recuerda que el RcPayload se trata de los componentes del servidor. Y necesitas una manera de decirle a React que cargue componentes del cliente también, y así es como funciona. Hay una cosa llamada LazyNode en el payload. En el medio, tenemos una referencia del servidor. Y estos nodos azules son todos clicables, así que puedo hacer clic en uno de ellos. Hago clic en la referencia del servidor, y me llevaría a esa parte del payload.

Si miras la versión preimpresa aquí, puedes ver que es un nombre de archivo largo. Y al final del nombre del archivo, ves rcActions0, mgs, hash, y luego el ID onSend. Y ahora realmente cerramos el círculo, porque eso es exactamente en lo que hice clic aquí. Así es como puedes navegar y explorar tu RcPayload dentro de Redwood Studio. Y todas las herramientas que te he mostrado aquí hoy han sido inmensamente útiles internamente en el equipo para que podamos entender mejor cómo funcionan los componentes del servidor de React. Y han sido especialmente útiles y especialmente educativas para nosotros que hemos sido parte de la implementación de esto. Eso ha sido principalmente yo y otro chico en el equipo llamado David Cyruson. Redwood es de código abierto, y siempre estamos buscando contribuyentes. Así que si también quieres ser un experto común en Rc, realmente puedo recomendarte que nos ayudes a desarrollar las características que faltan aquí. Y personalmente te ayudaré a obtener un PR merch para Studio, si estás interesado.

Eso es todo lo que tenía que decir. Muchas gracias por escuchar. Gracias. Vamos a pasar a las preguntas de la audiencia.

La primera pregunta es de Lazlo. ¿Estas herramientas de componentes de servidor de React están disponibles fuera de Redwood JS Studio? Sí y no. Así que la biblioteca que usé, que Alva escribió, está disponible para cualquiera. De hecho, está disponible como un plugin que puedes habilitar en Chrome. Así que puedes inspeccionar el payload de cualquier página que use componentes de servidor. El resto es solo para Redwood Studio. Pero, ¿quién usaría eso fuera de Redwood Studio? Exactamente. Y dado que Redwood está respaldado por Preston, quien estuvo en GitHub, uno de los fundadores, ¿verdad? Sí, él fundó GitHub y lo vendió a Microsoft. Y ha estado alrededor por como cuatro o cinco años ahora, pero no está ganando la tracción que esperaría que tuviera con ese respaldo. Pero, ¿cuáles son algunos de los usuarios que conoces que piensas, bueno, no puedo imaginar que el usuario x empresa x esté usando el producto en el que estoy trabajando?

Entonces, ¿cuál es la pregunta de nuevo? Básicamente, publicita a tus usuarios de los que estás orgulloso. Así que creo que Redwood es definitivamente el mejor framework que existe si quieres comenzar con una aplicación completa como un equipo pequeño o incluso un solo desarrollador. Puedo ver que es difícil de adoptar si ya tienes un backend existente porque somos un framework full stack adecuado. Tenemos una base de datos, un backend adecuado, actualmente un GraphQL. Pero también un framework frontend. Realmente no tiene sentido usar solo la parte frontend de Redwood. Necesitas comprometerte al menos con el backend, pero idealmente ese backend más el frontend. Y noté que ahora dijiste que actualmente tenemos GraphQL. Y también mencionaste eso mientras aún hablabas. ¿Eso implica que estás investigando algo más o estoy?

Sí. Así que en el futuro, queremos que nuestros componentes de React sean el predeterminado, seguro, para la obtención de datos y para el backend. Pero personalmente, tampoco quiero dejar atrás a nuestros usuarios actuales de GraphQL. Pero el feedback que hemos recibido es que GraphQL es demasiado complicado, especialmente si solo quieres comenzar rápidamente. Así que estamos tratando de enfocarnos más en, como dije, un solo desarrollador o un equipo muy, muy pequeño o algunos usuarios de hackathon o algo en lo que trabajas los fines de semana y las noches. Así que queremos tener algo más simple. Y creo que con los componentes de React, definitivamente podemos hacer algo que sea mucho, mucho más simple para comenzar. Luego podemos ofrecer GraphQL como algo que puedes habilitar más tarde cuando lo necesites, si lo necesitas.

Entonces quieres reducir la barrera de entrada, pero no perder el poder que tienes. Exactamente. Así que, por ejemplo, si necesitas un cliente móvil, si necesitas una aplicación, probablemente necesites una API adecuada también. Y entonces pensamos, sí, GraphQL es perfecto para eso.

Genial. Otra pregunta de Laslo. ¿Cuál fue el mayor momento de revelación que aprendiste sobre los componentes de React Server al implementar estas herramientas? El formato de payload es realmente muy flexible. Y este momento de revelación llegó cuando necesitaba implementar acciones del servidor. No me di cuenta de que podía simplemente agregar otro elemento a mi... O en realidad, que podía enviar de vuelta un objeto completo y tener una clave para el payload y otra clave para el valor de retorno del servidor o valor de retorno. Pensé que solo podía ser como los componentes serializados. Pero ahora, cualquier cosa que pueda ser serializada puede ser enviada como el payload.

Sí. Es bastante poderoso. Sí. Afortunadamente. Una pregunta de Anónimo. ¿Fue difícil averiguar cómo implementar acciones del servidor? Sí. Así que si viste la charla anterior sobre Wacko, definitivamente tenemos el mismo desafío que él tiene. Mostró cinco formas diferentes en que las personas pueden definir acciones del servidor. Pero cuando realmente te metes en el análisis de los componentes para encontrarlos, hay al menos el doble. Porque al menos la forma en que lo hacemos, o que yo lo hago, es que analizo el AST. Y cuando tienes una función, puedes tener una función de error o una función normal a la antigua y necesitan ser manejadas. Porque son dos entidades diferentes en el AST. Así que necesitas manejar ambas. Así que para todos, siempre hay dos versiones diferentes para escribirlo. Así que sí. Al menos diez, si cuentas las diferentes formas en que las personas pueden escribirlo. Solo diez.

Sí. Hay múltiples maneras de vagar, pero eso es mucho.

La siguiente pregunta es de Amir. ¿Están tratando de ser el Laravel de JavaScript? Lo estamos. Sí. O Ruby on Rails, si quieres. Genial. Si hay más preguntas, por favor, háganlas llegar.

Entonces, si tienes una propuesta, porque nos queda un minuto, para usar Redwood en el próximo proyecto de alguien, ¿cuál sería? Creo que ya lo he mencionado. Pero comenzar y arrancar con un nuevo proyecto lo más rápido posible. Ahí es definitivamente donde Redwood brilla. No sé si han visto alguno de los videos de YouTube de Jason donde tuvo a personas venir y construir lo mismo con diferentes frameworks. Tuvimos a una de las miembros del equipo, Amy, que fue parte de ese programa hace un tiempo. Y sí, creo que lo hizo muy bien en el programa, gracias a usar Redwood. Definitivamente competimos con Laravel y los otros frameworks full stack adecuados en términos de productividad.

Muy bien. De acuerdo. Eso es todo lo que tenemos. Y eso es todo el tiempo que tenemos. Así que todos, por favor, den un cálido aplauso para Toby. Gracias.