El Camino Rocoso de las Bibliotecas de Obtención de Datos en el Nuevo SSR de Transmisión de React

Rate this content
Bookmark

Si usas el directorio de aplicaciones Next.js, es posible que ni siquiera lo hayas notado, pero no solo estás usando Componentes de Servidor de React, sino que también estás usando la nueva característica de SSR de transmisión de React.

Eso significa que en la primera carga de página, tus Componentes de Cliente ahora serán renderizados en el lado del servidor, límite de suspense por límite de suspense, y constantemente transmitidos al cliente, donde son rehidratados pieza por pieza.


Si combinas eso con suspense para la obtención de datos en tus componentes de cliente, de repente te enfrentarás a desajustes de rehidratación - ya que tus componentes de cliente comenzarán a buscar datos en el servidor, pero los datos no serán transportados al cliente.


En esta charla, repasaré el camino rocoso que tuvimos que atravesar para soportar suspense para la obtención de datos en SSR de transmisión con Apollo Client, mirando todos los curiosos problemas de tiempo que surgen con estas tecnologías, y cómo intentamos resolverlos lo mejor que podemos - siempre con la mejor experiencia posible para el usuario y el desarrollador en mente.

28 min
20 Oct, 2023

AI Generated Video Summary

Esta charla discute el viaje de las bibliotecas de obtención de datos en el nuevo SSL de transmisión de React, centrándose en el uso de suspense para la obtención de datos. Cubre la historia de suspense y la obtención de datos, el plan y la luz verde para su implementación, los desafíos con el enrutador de aplicaciones Next.js y SSR, el transporte de datos y el tiempo de vaciado, la importancia del tiempo y el transporte de datos, la rehidratación retrasada y el cierre de la transmisión, la necesidad de datos restantes y funcionalidades requeridas, los desafíos que enfrentan los usuarios de React vainilla, y las preguntas del público sobre los componentes del servidor de React.

1. Introducción

Short description:

Hoy voy a hablar sobre el accidentado viaje de las bibliotecas de obtención de datos en el nuevo SSL de transmisión de React. Es un tema frustrante, pero también muy interesante. Soy Lancey Bertronick, un ingeniero senior en Apollo GraphQL, trabajando en el cliente Apollo TypeScript y co-manteniendo el kit de herramientas Redux. Encuéntrame en Twitter como Fry o en GitHub como Frynias.

Hoy voy a hablar sobre—y tengo que leer esto—el accidentado viaje de las bibliotecas de obtención de data en el nuevo SSL de transmisión de React, y lamento mucho el título Y lamento mucho la charla. Desearía no tener que hacerlo, pero aquí estamos. Y es un tema frustrante, pero también es muy interesante. Ya me presentaron. Soy Lancey Bertronick. Soy un ingeniero senior en Apollo GraphQL, y estoy trabajando a tiempo completo en el cliente TypeScript Apollo. También soy co-mantenedor del kit de herramientas Redux y hago mucho otro código abierto. Tengo un TDAH. Tengo más hobbies de los que puedes contar. Puedes encontrarme en Twitter como Fry o en GitHub y en internet en general como Frynias.

2. La Historia de Suspense y la Obtención de Datos

Short description:

Vamos a sumergirnos en la historia de cómo comenzó el suspense para la obtención de datos en el cliente Apollo. En octubre de 2018, se introdujo React Lazy, permitiendo la importación perezosa de archivos y la división de paquetes. Unos meses después, se lanzaron las APIs de hooks. En marzo de 2022, React 18 trajo el modo concurrente y más características, incluyendo el cambio de nombre de Suspense. Sin embargo, el uso de Suspense para la obtención de datos todavía no se recomendaba. En la línea de tiempo del cliente Apollo, se lanzó React Apollo hooks con soporte de suspense en octubre de 2018. En septiembre de 2019, los hooks se fusionaron en el paquete del cliente Apollo, marcando la primera mención oficial de suspense para la obtención de datos.

Como dije, este es un tema frustrante para mí. Siempre hay una historia detrás. Así que vamos a ver la historia de un villano aquí. ¿Cómo empezó todo esto? Comenzó cuando quisimos añadir suspense para la obtención de data en el cliente Apollo. Y casualmente, en la última charla ya viste que eso funciona. Así que en este punto podría dejar el escenario y todo estaría bien. Pero no siempre fue así.

Así que volvamos atrás en la historia primero y hablemos de suspense primero, porque esto es algo que en realidad no estuvo en React para siempre. ¿Por qué estamos hablando de esto, este año? ¿No debería haber sido esto algo de lo que dejamos de pensar o hablar? Así que hablemos primero de la historia de suspense. Y volvemos a octubre de 2018 cuando se introdujo la primera cosa suspensiva en React y eso fue React Lazy, que te dio una forma de importar perezosamente archivos, hacer la división de paquetes, cargarlos más tarde y tener a React de alguna manera buscando la carga, como hacer el estado de carga para eso como detrás de las escenas sin que tú tengas que hacerlo. Um, en la misma línea de tiempo, unos meses después, las APIs de hooks salieron en febrero de 2019. Y en marzo de 2022, hubo un gran salto. React 18 salió y esencialmente todo el asunto fue como que ahora tenemos el modo concurrente como Suspense fue renombrado a modo concurrente y obtuvo muchas más características en un punto y estábamos realmente felices y estábamos como, sí, podemos empezar a hacer esto ahora. Pero luego bajamos por las notas de la versión y en algún lugar de ese artículo del blog había una nota al pie. Uh, en React 18, puedes empezar a usar Suspense para la obtención de data y marcos de opinión como Relay, Next.js, Hydrogen y Remix. Y esa fue la parte deprimente de esto, la obtención ad hoc de data con Suspense es técnicamente posible, pero aún no se recomienda como una estrategia general. Y sí, todos nosotros, como cada palanca de obtención de data estaba experimentando con eso, pero somos una buena community y estamos escuchando a nuestros señores de React. Así que no lanzamos realmente nada, especialmente no a propósito. Creo que algunas bibliotecas tuvieron algo por un tiempo y luego vieron esa frase después y la borraron de nuevo. Um, así que esa es la línea de tiempo oficial de react, por supuesto, hay una segunda línea de tiempo y esa es la línea de tiempo del cliente Apollo y quiero recordar quiero que te enfoques en este octubre de 18 en que estamos, en los tiempos pre hooks los hooks aún no han salido, pero hubo una charla en una conferencia sobre hooks justo. Ahora mismo. Um, y volvemos a octubre de 18 y alguien realmente lanzó una biblioteca llamada React Apollo hooks y esa biblioteca tenía soporte de suspense usando ese truco de React lazy. Y, sinceramente, me quedé boquiabierto cuando lo busqué porque no estaba al tanto de eso preparándome para esto. Y solo quiero decir, no sé quién lo hizo, pero felicitaciones a esa persona. Eres increíble. Um, eso fue un experimento realmente, realmente lindo y genial. Um, y en septiembre de 2019, así como medio año después de que los hooks de react salieron, y un poco después de que los hooks de Apollo habían estado en beta por un tiempo, hubo un problema en el que fusionamos los hooks en el paquete real del cliente Apollo. Y esa fue la primera mención oficial de suspense que pude encontrar en nuestros problemas. Ese fue el problema 5,357. Y dice cuando el suspense de react y el enfoque de obtención de data se finaliza.

3. Destacando el Plan y la Luz Verde

Short description:

En los próximos meses de 2019, esperamos que el plan madurara. Teníamos demasiadas personas pidiéndolo, por lo que se esbozó una estrategia general RFC para el uso del hook de consulta de Spence. React 18 introdujo el SSR en streaming, y se lanzó Apollo client 3.8.0 alpha zero con ese hook. Tuvimos una reunión con el equipo de React, junto con 10 stack query y el equipo de R2K, y obtuvimos luz verde para proceder con suspense para la obtención de datos. Funcionó realmente bien.

Y ahora quiero destacar la siguiente parte, esperemos que en los próximos meses de 2019. Y luego esperamos, esperamos y esperamos. Y es bueno que haya tomado algún tiempo. Tenía que madurar. Um, y esencialmente, todavía estaríamos esperando si estuviéramos adhiriéndonos a esa nota al pie, pero en algún momento tuvimos demasiadas personas pidiendo eso y tuvimos que al menos empezar a hacer, a poner un plan en marcha, lo que queríamos hacer, así que un general que estaba en el escenario aquí hace un momento, uh, publicó como usted 10,231, así que unos 5,000 problemas más tarde. Uh, eso esbozó una estrategia general RFC para el uso del hook de consulta de Spence. Y lo que también quedó claro fue que react 18 obtuvo esta cosa de SSR en streaming. Así que probablemente también deberíamos añadir soporte para eso, pero no estábamos realmente seguros de cómo. Así que lo dejamos a un lado por un tiempo. Um, luego Apollo client 3.8.0 alpha zero se lanzó en diciembre del último año con ese hook por primera vez. Y dije, somos una buena community, así que empezamos a intentar conseguir una audiencia con el equipo de react. Y tuvimos eso en febrero de este año y esencialmente obtuvimos la luz verde. Así que esto no es algo de lo que no hablamos o algo que fue realmente una reunión donde también, uh, se unió 10 stack query y como el equipo de R2K. Así que como una biblioteca de obtención de data, toda la community obtuvo la luz verde para seguir adelante con suspense para la obtención de data ahora. Um, así que lo hicimos y funcionó realmente bien. Así que tu consulta de suspense funcionó bien.

4. Router de la Aplicación Next.js y SSR

Short description:

En este punto, no había jugado con el router de la aplicación Next.js, pero decidí probarlo. Las diapositivas que estoy usando no son un video, sino la aplicación real. Me encontré con un problema en el que la misma solicitud se realizaba tanto en el servidor como en el navegador, y el componente se renderizaba en ambos lugares. Esto provocó que los datos no se transportaran del servidor al navegador, lo que resultó en solicitudes desperdiciadas. Tuvimos que abordar este problema y decidimos usar la renderización en el lado del servidor (SSR) como siempre lo hemos hecho.

Pero en ese momento también recibimos muchas solicitudes sobre esto, uh, extraño router de la aplicación Next.js y honestamente en este punto no había jugado con él. Y pensé, sí, está bien, probémoslo.

Y aquí llegamos al punto en el que tengo que decir algo sobre mis diapositivas. Estas diapositivas son una aplicación de router de Next.js. Todo lo que veremos aquí no es un video, sino la aplicación real y yo haciendo trucos super sucios para mostrarles lo que está pasando en el servidor y lo que está pasando en el cliente al mismo tiempo.

Así que vamos a nuestra siguiente diapositiva, esa diapositiva va a usar la consulta de usuarios de Ben y esperemos, uh, sí, esperemos que la red de la conferencia esté ahí y que la solicitud se complete en algún momento. Um, por supuesto que no, uh, no, no. Sí, perfecto. Perfecto. Uh, así que como teníamos una búsqueda en el navegador de eso está bien, ¿verdad? Uh, y estaba realmente feliz. Como que ya terminamos aquí. No tenemos que hacer nada extra para soportar, uh, para soportar la aplicación del router y luego refresqué la página.

Y después de que refrescamos la página, déjame volver a pantalla completa. De repente, esa misma solicitud ocurre en el servidor y en el navegador. Y esto es también algo que realmente me irrita. Uh, como, especialmente desde que redacté estas diapositivas, uh, se ejecutan al mismo tiempo, como todos los experimentos que hice en el pasado, se ejecutarían en el servidor, el servidor terminaría y luego se ejecutarían en el cliente. Pero aparentemente encontré el caso límite de reproducción aquí para tener un componente renderizando, ambos entornos a la vez. Voy a estar depurando eso durante semanas a partir de ahora.

Um, pero el problema principal es el mismo. El componente se ejecuta en ambos lugares y busca data en ambos lugares. Y en realidad esa data ni siquiera se transporta del servidor al navegador, por lo que el servidor hace una solicitud y la descarta y no sale nada bueno de ella. Así que obviamente eso no es algo bueno. Así que de repente estamos en territorio de SSR. Queríamos hacer eso en un momento posterior. No tenemos la oportunidad de hacer eso en un momento posterior. Tenemos que hacerlo ahora. Así que el primer pensamiento por supuesto es hagamos SSR como siempre hemos estado haciendo SSR. Déjame refrescar la página para que ese estado de carga en la parte inferior desaparezca porque ese es mi truco para hacer que esa data se transporte.

Um, así que SSR en el viejo mundo era como antes de que el árbol de React se renderizara realmente, así que en Xjs sería como en obtener props del lado del servidor o algo así que, nos enganchamos, ejecutamos nuestro propio código que significa que creamos una instancia de cliente Apollo ejecutamos obtener data del árbol, uh, que renderiza ese componente con un proveedor de Apollo fuera de él y pasa esa instancia de cliente, esa renderizaría todo el árbol, desencadenaría toda la búsqueda de data dentro de ese árbol, nos daría como una promesa que podemos esperar hasta que toda la carga en ella esté terminada. Y luego repetimos eso, eso realmente sucede internamente en obtener data del árbol.

5. Transporte de Datos y Tiempo de Descarga

Short description:

Necesitamos una forma de llevar los datos a través del cable a la aplicación en ejecución para agregar más cosas a la caché. Hubo un RFC llamado Eject-To-Stream, pero no está. El siguiente trabajo fue usar HTML insertado por el servidor, pero hay preguntas sobre la representación múltiple y el tiempo de descarga. La documentación de Next.js recomienda tener una cola global para descargar y borrar de forma independiente. El contexto de HTML insertado por el servidor permite la llamada condicional de hooks, pero el tiempo de descarga aún no está claro.

Entonces hacemos la cascada, renderizamos esa cosa tantas veces hasta que nada más comienza a cargar, y luego tomamos todos los data del cliente, los transportamos de alguna manera, y luego renderizamos el HTML y luego todos esos data transportados se rehidratan en el otro lado. Eso es SSR tradicional con Cliente Apollo o prácticamente cualquier otra biblioteca de obtención de data, y yo estaba como, okay, sí. Hagámoslo.

Así que la renderización comienza en el servidor. Comenzamos a recoger los data para enviar al navegador, pero los pros ya comenzaron a correr y no tomarán más data. Así que ese enfoque tradicional no era factible porque de repente nuestros componentes son como nuestra aplicación está corriendo en el cliente y en el servidor al mismo tiempo. Y eso vale para cada componente del cliente, cada componente del cliente. Si refrescas la página, así que si es la primera carga de la página, todos esos componentes se ejecutarán en ambos entornos al mismo tiempo o poco después de cada uno, con suerte. Así que necesitamos algo más. Necesitamos una forma de llevar esos data a través del cable a la aplicación en ejecución para agregar más cosas a la caché.

Y hubo un RFC que se llamaba Eject-To-Stream y parecía super prometedor, pero no está. Como, hubo una discusión si incluso quieren incluir eso en un reactor, si el marco debería manejarlo, pero toda esa situación no estaba realmente clara, así que eso es un callejón sin salida. Entonces el siguiente trabajo fue, usar HTML insertado por el servidor, que es una API específica de Next.js, dirigida a CSS y marcos de JS para obtener el CSS generado para rehidratar allí y todo eso. Esa cosa, todo se pasa a un componente, a algún tipo de cola global, y en algún momento esa cola se descargará. Tengo preguntas porque estoy suspendiendo mis componentes, así que será renderizado varias veces, como siempre comenzará desde el principio, y llamará al servidor insertado HTML varias veces. ¿Entonces envío los mismos data varias veces o qué está pasando aquí? Así que esa es una pregunta a tener en cuenta. Otra pregunta es como, ¿cuándo ocurre exactamente esta descarga? Porque como veremos en el futuro, todo esto es muy sensible al tiempo. Así que estas dos preguntas son las preguntas que queremos responder. Pregunta número uno, si un componente se suspende dos veces, ¿transportamos los mismos data como tres veces porque se suspende, se suspende y luego la renderización real? Sí. Así que la documentación de Next.js ahora muestra que deberías tener algún tipo de cola global propia con cosas que deberían descargarse y deberías borrar eso de forma independiente. Creo que no estaba en los documentos en ese momento, pero ahora sí. Así que eso es genial para todo lo que se hace hoy. Um, y también está este contexto de HTML insertado por el servidor, que es un detalle de implementación del hook, que permite llamarlo condicionalmente porque no podemos, o no deberíamos llamar a los hooks condicionalmente, pero aquí funciona. Así que llamamos a eso condicionalmente, pero todavía tenemos que mantener esa cola global por razones. Um, la otra pregunta era como, ¿cuándo ocurre la descarga? Y esto es como, tú, tú buscas el código durante horas o días o semanas en mi caso. Y en algún momento te tropiezas con esto, uh, crea una pantalla HTML insertada, uh, cosa de transmisión que también cambió de nombre tres veces hasta ahora. Uh, Oh no. Quería mostrarles el, el código fuente de GitHub, pero la wifi de la conferencia espero que pueda volver y volver a la última página. Okay. ¿Alguien necesita ahora la combinación de teclas para intentar llevar el navegador de vuelta a la última página.

6. La Importancia del Tiempo y el Transporte de Datos

Short description:

El tiempo es crucial porque la aplicación ya se está ejecutando en el servidor, pero el cliente puede mutar los datos antes de que se rendericen en el servidor. Esto puede resultar en datos desajustados y confusos. Nuestro objetivo es transportar los datos a través del cable de inmediato en lugar de esperar a que termine el siguiente límite de suspense. Para lograr esto, transportamos no solo el resultado sino también la información de que la consulta ha comenzado en el servidor. Luego, el navegador simula la solicitud, y el servidor se asegura de que los datos se envíen antes de que el navegador los recupere. Este enfoque ayuda a prevenir que el cliente reciba datos incorrectos.

Puedes, puedes comandar a la izquierda comandar a la izquierda. Atrás. Uh, nosotros, no vamos a profundizar demasiado en eso. Aparentemente atrás. Sí. Nosotros, simplemente vamos a quedarnos aquí y tú dijiste, si aquí hay una pegatina para ti, tengo más pegatinas para más tarde. Acércate a mí. Um, entonces, ¿por qué es tan importante el tiempo? Uh, como, uh, el problema es que la aplicación ya está en funcionamiento y el navegador la renderiza en el servidor. Entonces, somos una caché normalizada y. Eso significa que tenemos una aplicación interactiva. Que no está realmente llena con todos los data que vienen del servidor, pero el cliente ya puede mutar esos data en el cliente. Entonces el cliente podría tener data más nuevos que los que realmente se renderizan en el servidor. Todo eso es muy confuso. Uh, para eso, tengo este maravilloso, uh, diagrama confuso y totalmente no apto para un proyector, pero es imposible hacerlo más pequeño. Uh, al final de mi charla, habrá códigos QR para un RFC muy largo que explica todo esto en detalle. Lo importante aquí es, uh, esto está en el servidor. Esto está en el navegador. Uh, y estamos asumiendo que los componentes se renderizan primero en el servidor, luego no luego en el navegador, no al mismo tiempo. Entonces comenzamos a renderizar, hacemos una consulta, obtenemos un resultado. Uh, y luego algo más se suspende también, pero el navegador ya está activo y el usuario hace algo cambia la caché y el navegador. Uh, y luego enviamos los resultados y sobrescribimos los data más nuevos porque enviamos el resultado demasiado tarde. Uh, y obtenemos data extraños mezclados. Entonces para nosotros, sería importante obtener data a través del cable de inmediato y no cuando el siguiente límite de suspense, uh, termina, que es el punto en el que realmente quería hablar cuando la página no se cargó. Um, entonces el punto es que los data solo se transportan, uh, poco antes de que el siguiente límite de suspense haya terminado y eso puede tardar una eternidad, o puede ser inmediato, no tenemos control sobre eso. Um, entonces, ¿qué podemos hacer cuando la consulta comienza en el servidor? Intentamos no solo transportar el resultado. También transportamos la información de que la consulta ha comenzado en el servidor, porque tenemos más posibilidades de que al menos esa información llegue rápidamente a través del cable, y luego el navegador ya comienza a simular esa solicitud. Um, y porque un cliente Poli tiene deduplicación de consultas, si el navegador mientras tanto intentara recuperar esos mismos data, al menos esperaría a que el servidor realmente enviara esos data. Así que no obtenemos completamente data falsos mezclados en el cliente. Um, y cuando eso termina, resolvemos eso y esa consulta simulada ha hecho su trabajo. Um, esto es todo lo que podemos hacer, porque como dije, no tenemos control sobre cuándo los data serán realmente transportados.

7. Rehidratación Retrasada y Cierre de Flujo

Short description:

Esta rehidratación retrasada puede llevar a desajustes de hidratación. Hacemos una instantánea del resultado del servidor y lo transportamos individualmente. Si el flujo se cierra demasiado pronto, detectamos el escenario y reiniciamos las consultas en el cliente. El mayor problema es la necesidad de APIs específicas de la plataforma o del marco de trabajo. Necesitamos diferentes paquetes para cada marco de trabajo. Se transportan datos extra por el cable para la cosa desajustada de pre-hidratación.

La otra cosa es, uh, esta rehidratación retrasada puede llevar a desajustes de hidratación y eso es lo otro. Uh, si todo va bien aquí y obtenemos los data pronto, pero luego el servidor sigue renderizando por alguna razón, porque suspense, um, y aquí ocurren actualizaciones de caché, entonces el servidor renderiza HTML, que está desactualizado, pero el navegador ya tiene un HTML más nuevo. Así que obtenemos el temido desajuste de rehidratación. Tenemos que sortear eso también, porque esas advertencias son muy irritantes para los desarrolladores, incluso si es como que está bien. Y quieres que todo se vuelva a renderizar. Entonces, lo que estamos haciendo es que, uh, hacemos una instantánea del resultado del servidor. Transportamos el resultado del hook individualmente, renderizamos una vez con ese hook, y luego volvemos a renderizar inmediatamente con los valores que son realmente correctos en el cliente. De esa manera no obtenemos un desajuste de hidratación, pero nosotros simplemente enviamos una tonelada de data. Uh, pero hace feliz a React. Y de eso se trata ser un mantenedor de bibliotecas, uh, sobre hacer esas compensaciones. Um, luego está ese último escenario cuando el flujo se cierra demasiado pronto. Ya habíamos adelantado esos hooks hermanos, uh, use background query y use read query, use background query es esencialmente prefetching, uh, en un componente padre para que use read query para usar esa solicitud en curso en un componente hijo, potencialmente múltiples suspende el componente, uh, límites hacia abajo. Um, eso es muy agradable. Pero si ese componente hijo se renderiza condicionalmente, entonces tal vez nada se suspenderá. Los data nunca se transportarán. Y nuestro flujo ya está cerrado. El servidor tiene data que puede enviar al cliente. Así que tenemos que detectar esos escenarios y luego reiniciar esas consultas en el cliente. Um, así que esencialmente podemos sortear todo aquí. Esto está bien. Uh, es trabajo, es genial. Preferiría no sortear todas esas cosas, me gustaría que hubiera como herramientas reales que pudiéramos usar proporcionadas por react. Um, así que los problemas actuales, solo para resumir esto muy rápidamente, el mayor problema es que necesitamos APIs específicas de la plataforma o del marco de trabajo. Uh, me estoy quedando sin tiempo. Así que voy a ser muy rápido aquí. Um, esto está funcionando en NextJS. Tendremos, necesitaremos otro paquete para Redwood chairs que solo cambia una línea en nuestro paquete porque la exportación tiene un nombre diferente. Y para cada marco de trabajo después de eso, necesitaremos otro paquete porque no es un interno de react. Es un interno del marco de trabajo que estamos usando el tiempo sub-óptimo que he mostrado, uh, y para esa cosa desajustada de pre-hidratación extra, tenemos que transportar muchos data extra por el cable, uh, y esas cosas de flujo que no podemos retrasar. No podemos decirle a react.

8. Datos Restantes y Funcionalidades Requeridas

Short description:

Necesitamos el método use three de React y un método de registro de limpieza para gestionar los procesos en curso y evitar el desperdicio de recursos del servidor. Estas funcionalidades deberían ser proporcionadas por React para evitar la necesidad de múltiples paquetes. Sin estos, sería un desafío para las bibliotecas de cliente funcionar de manera efectiva.

Oye, todavía tenemos data entrante. Uh, lo enviaremos en un momento porque chase excess terminó de renderizar chase excess terminó de renderizar. Uh, y no vamos a hablar de la historia de agrupación. Eso son dos horas más. Um, ¿qué necesitamos? Necesitamos ese método use three de react y no de cada marco de trabajo, necesitamos algo como un método de registro de limpieza donde podemos decir, Oye, todavía hay algo en marcha. Por favor, espera a esto, o al menos detén la solicitud que ya no va a ser transportada al cliente. Así no desperdiciamos recursos del servidor. Uh, ambos necesitan ser proporcionados por react porque no podemos mantener 200 paquetes alrededor para cada marco de trabajo. Eso no es factible. Y eso sería el fin del mundo para cada biblioteca de cliente.

9. Desafíos y Enlaces Prometidos

Short description:

En este momento, los usuarios de React que quieren usar streaming SSR se enfrentan a desafíos para implementar su propio marco de trabajo y construir un paquete alrededor de él. Los autores de marcos de trabajo fuera de Next.js no tienen una guía oficial y deben confiar en la lectura del código fuente de Next.js. Esta falta de comunicación y documentación obstaculiza el progreso de todo el ecosistema. A pesar de la naturaleza experimental del paquete, funciona bien y se puede usar hoy. Se proporcionan códigos QR para acceder al código fuente, al RFC de inject into stream y a recursos adicionales sobre los componentes del servidor de React.

Um, y en este momento tampoco podemos apoyar a los usuarios de react que están usando streaming SSR porque tendrían que implementar su propio marco de trabajo y luego construir su propio paquete alrededor de su marco de trabajo hecho por ellos mismos para que todo esto funcione. Um, también los autores de marcos de trabajo en este momento. Y como gritarías, he estado hablando con la gente de redwood recientemente. Están haciendo react componentes de servidor en este momento. Los autores de marcos de trabajo en este momento, si no están trabajando para next chairs, no tienen una guía real. Todo lo que pueden hacer es pasar por unos pocos canales de comunicación, uh, donde siempre parece que estás, estás presionando al otro equipo. No hay documentación oficial sobre esto. Todo lo que puedes hacer esencialmente es como leer el código fuente de next chess y hacer algo similar. Y el código fuente de next trace funciona en implementaciones de tiempo muy específicas. Como conocimiento sobre los internos de react que la mayoría de las otras personas no tienen porque no tienen al equipo de react sentado al lado. Entonces, este, este pecho necesita mucha más comunicación y documentación para que todo el ecosistema avance. Y no solo aquellos pocos que lograron conseguir esa llamada y resistir a Abramov y sin, sin esa llamada. Pero entonces Abramov que tuve en febrero del año pasado, estaría pensando en esto como el próximo año y todavía no lo habría descubierto. Um, a pesar de todo, esto funciona realmente bien. Puedes usarlo hoy. Um, el paquete todavía tiene experimental en el nombre porque no estoy contento con el tiempo y nadie debería estarlo, pero funciona realmente bien. Y si ignoramos el fuego ardiente a nuestro alrededor, entonces solo vamos a ser felices. Um, sí. Y te prometí enlaces. Uh, sé que los enlaces no siempre son agradables. Así que estos son códigos QR. Puedes revisar el código fuente de esta charla. Puedes revisar el RFC de inject into stream. Uh, si quieres ver esos gráficos super extraños que mostré en medio, hay como un paseo sin fin con todos los detalles y cosas que aprendí sobre react componentes de servidor. También hubo mucha discusión con Dan allí. Así que incluso solo leyendo esa discusión, cómo, cómo él me explica las cosas podría ayudarte a entender eso más. Y eso también es solo una publicación de blog super quejosa sobre los componentes del servidor de react en general. Los amo, pero puedo alquilar durante horas. Entonces sí, espero que hayas sacado algo de todo esto. Uh, y espero que tengamos algunas preguntas y si tienes preguntas, tengo pegatinas.

10. Preguntas del público y Componentes de Servidor de React

Short description:

No, hablo en serio. Pasemos a las preguntas del público. Matt pregunta si el enfoque se debió al diseño del cliente existente y sugiere cambiar completamente el cliente. Los componentes del servidor de React son elogiados por su increíble funcionalidad, pero se critica la falta de educación y documentación. A pesar de esto, se considera que los componentes del servidor de React valen la pena aprender y serán una herramienta increíble una vez que estén completamente documentados.

No, hablo en serio. Pasemos a las preguntas del público. Um, y la primera pregunta. La tengo de Matt. Matt pregunta, ¿terminaste con este enfoque debido al diseño existente del cliente / libro design y podría simplificarse si cambias completamente cómo funciona el cliente? Podría reescribir un cliente Polo, que es una biblioteca que existe desde hace ocho años, cambiar completamente todo. Y hacer una base de usuarios completa. Muy enfadada. Um, para tener algunas cosas internamente, como para cada pieza de data pongo un sello de tiempo cuando se recibió, así puedo hacer coincidir estos sellos de tiempo entre el cliente y el servidor y ver que data está desactualizado. Y luego tal vez quiera desechar esto. Y no eso, pero eso también significa que necesito sincronizar el tiempo entre el servidor y el navegador, lo cual es como un problema que probablemente no se ha resuelto en este pro en este mundo. Uh, así que probablemente también sea inútil intentarlo. Um, pero creo que es la mejor solución que podemos tener por ahora. Um, y tal vez otras bibliotecas surgirán con algo completamente nuevo, pero yo no creo que las bibliotecas existentes vengan con algo realmente diferente. Me encanta cómo dices por ahora, y eso es básicamente para muchas cosas que estamos haciendo bien en nuestra industria. Siempre es lo mejor que podemos hacer ahora, y no hay muchas cosas de las que estaba súper orgulloso hace seis años que todavía haría hoy. Entonces sí, buena adición a tu respuesta.

Uh, la siguiente pregunta es de nuestro apreciado miembro de la audiencia anónimo. ¿Crees que React va en la dirección equivocada con los React server components? Parece que se han añadido muchas armas de comida. Los React server components son increíbles. Los amo absolutamente y usarlos se siente como, como esa cosa mágica. Que deseaba tener hace 10 años cuando todavía estaba haciendo.net ASP y podías como, como escribir esa, esa clase que tenía el controlador de clic y si tú hacías clic en el navegador, ejecutaría ese código en el servidor que no funcionaba del todo, pero era una promesa agradable. Um, y ahora todo eso de repente empieza a funcionar y es realmente, realmente genial. Lo que realmente no es genial es la forma en que la educación alrededor de esto sucedió porque no sucedió. Um, en algún momento simplemente estaba allí después de ser experimental probablemente durante unos cinco años o algo así. Como había una demo de una conferencia que podías probar y luego tenías una cosa de producción. No había nada en medio y todo lo que puedes leer es la documentation de NextJS y eso también está cambiando a medida que los componentes del servidor de React están cambiando. Um, no hay un curso que puedas leer. Uh, la documentation de React acaba de salir con hooks. Um, pero no con componentes de servidor y como la community habría necesitado una introducción lenta a todo esto y simplemente se golpeó en la cara, como esa es la parte con la que no estoy contento, pero los componentes del servidor de React una vez que estén completamente documentados, um, incluyendo los internos para los desarrolladores de marcos de trabajo, para los desarrolladores de bibliotecas serán una herramienta increíble en un kit de herramientas y vale totalmente la pena aprenderlos. Y vale totalmente la pena esa sobrecarga mental adicional.

Muy bien. De acuerdo. De acuerdo. Um, se nos acabó el tiempo para una sesión de preguntas y respuestas. Así que si quieres continuar la conversación, vamos, va a ser en el área de preguntas y respuestas del orador en la entrada, y ahora tenemos 10 minutos para cambiar de sala si quieres ver la otra charla, pero yo no iría allí porque tenemos a Daniel Alphonso que viene aquí después, ahora vamos a aplaudir a Lance todos.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2023React Advanced Conference 2023
27 min
Simplifying Server Components
Server Components are arguably the biggest change to React since its initial release but many of us in the community have struggled to get a handle on them. In this talk we'll try to break down the different moving parts so that you have a good understanding of what's going on under the hood, and explore the line between React and the frameworks that are built upon it.
React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar
JSNation 2022JSNation 2022
21 min
The Future of Performance Tooling
Our understanding of performance & user-experience has heavily evolved over the years. Web Developer Tooling needs to similarly evolve to make sure it is user-centric, actionable and contextual where modern experiences are concerned. In this talk, Addy will walk you through Chrome and others have been thinking about this problem and what updates they've been making to performance tools to lower the friction for building great experiences on the web.
TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt.In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
JSNation 2023JSNation 2023
174 min
Developing Dynamic Blogs with SvelteKit & Storyblok: A Hands-on Workshop
Featured WorkshopFree
This SvelteKit workshop explores the integration of 3rd party services, such as Storyblok, in a SvelteKit project. Participants will learn how to create a SvelteKit project, leverage Svelte components, and connect to external APIs. The workshop covers important concepts including SSR, CSR, static site generation, and deploying the application using adapters. By the end of the workshop, attendees will have a solid understanding of building SvelteKit applications with API integrations and be prepared for deployment.
JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
Featured WorkshopFree
Building instant-on web applications at scale have been elusive. Real-world sites need tracking, analytics, and complex user interfaces and interactions. We always start with the best intentions but end up with a less-than-ideal site.
QwikCity is a new meta-framework that allows you to build large-scale applications with constant startup-up performance. We will look at how to build a QwikCity application and what makes it unique. The workshop will show you how to set up a QwikCitp project. How routing works with layout. The demo application will fetch data and present it to the user in an editable form. And finally, how one can use authentication. All of the basic parts for any large-scale applications.
Along the way, we will also look at what makes Qwik unique, and how resumability enables constant startup performance no matter the application complexity.
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
WorkshopFree
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up
React Summit Remote Edition 2021React Summit Remote Edition 2021
87 min
Building a Shopify App with React & Node
WorkshopFree
Shopify merchants have a diverse set of needs, and developers have a unique opportunity to meet those needs building apps. Building an app can be tough work but Shopify has created a set of tools and resources to help you build out a seamless app experience as quickly as possible. Get hands on experience building an embedded Shopify app using the Shopify App CLI, Polaris and Shopify App Bridge.We’ll show you how to create an app that accesses information from a development store and can run in your local environment.
React Advanced Conference 2023React Advanced Conference 2023
148 min
React Performance Debugging
Workshop
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)