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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.