La Búsqueda del Suspense - Dentro de la Magia de React

Hola a todos. Soy Charlotte. Soy una líder técnica de React Native en VAM, y estoy muy emocionada de estar aquí con ustedes hoy.

Hoy vamos a hablar de un componente muy especial, suspense. ¿Sabes por qué suspense? ¿Sabes por qué es una herramienta tan poderosa? ¿Sabes por qué nos encanta? Pero ¿sabes cómo funciona suspense? ¿Cómo sabe suspense que se va a realizar una solicitud en mis hijos? Debería mostrar una carta en su lugar.

Hoy vamos a adentrarnos en el componente suspense, y a medida que lo hacemos, vamos a aprender más sobre React también. Así que esta no será una charla sobre concurrencia. Nos vamos a centrar únicamente en este componente. Pero antes de adentrarnos en el cómo de suspense, permítanme recordarles el por qué. ¿Por qué nos encanta tanto suspense?

Antes de suspense, nuestros componentes solían verse así. Obteníamos algunos datos, mostrábamos un cargador mientras se cargaban, un error si era necesario, y finalmente llegábamos a la parte que realmente es la más interesante de nuestros componentes, aquella en la que realmente aportamos valor al usuario. Con suspense, nuestros componentes ahora se ven así. Obtenemos algunos datos y podemos usarlos directamente. Ya no tenemos que preocuparnos por estos casos especiales de cargadores y errores. Se manejan arriba. Encima de nuestros componentes, definimos este límite de suspense que maneja el cargador, y este límite de error que maneja el error. De esta manera, en nuestros componentes, podemos usar directamente nuestros datos. Por eso nos encanta tanto suspense. No más cargadores, no más errores dispersos en todos nuestros componentes. Podemos acceder directamente a los datos.

Ahora vamos a adentrarnos en el cómo. Para el cómo, vamos a tener que adentrarnos en React. Pero antes, permítanme recordarles rápidamente cómo funciona React. React tiene algunos roles fundamentales. Uno de ellos es este. React llama a los componentes y hooks. Esto significa que React decide cuándo quiere renderizar tus componentes. Tú no. Cuando llamamos a nuestros componentes, lo hacemos de esta manera, con esta sintaxis JSX, pero llamar a un componente de esta manera no significa que se ejecutará de inmediato, al menos no de inmediato. Cuando instanciamos un componente de esta manera, con esta sintaxis JSX, JSX en realidad es solo azúcar sintáctica, y es equivalente a la llamada de esta función JSX.

Y esta función JSX, cuando se llama, instancia un nodo en el árbol virtual de fibras de nuestros elementos de React, y cada uno de estos nodos se llama fibra. Es un término que es posible que hayas escuchado antes. Cuando construimos nuestra aplicación por primera vez, React crea este árbol virtual con nuestros componentes y sus data, y a partir de este árbol, decide cuándo renderizar y volver a renderizar nuestros componentes.

Construyamos juntos este árbol de fibras. El primer componente que instanciamos con esta sintaxis JSX es la aplicación, por lo que creamos este nodo de la aplicación, esta fibra de la aplicación, pero no ejecutaremos esta función de la aplicación de inmediato. React agregará este puntero de trabajo en progreso a la fibra. El trabajo en progreso es un objetivo que apunta a la fibra en la que se está trabajando actualmente. React funciona de alguna manera como un bucle de juego. Mientras haya trabajo en progreso, mientras haya una fibra en la que trabajar, realizamos algún trabajo en esta fibra. Tal vez renderizarla. Tal vez volver a renderizarla. Luego pasamos a la siguiente. Así que React recorre nuestro árbol de esta manera hasta que llega al final del árbol o hasta que ocurre otro renderizado. Al principio, el trabajo en progreso apunta a la aplicación. Entonces React realizará algún trabajo en la aplicación. Va a renderizar la aplicación. Por lo tanto, ejecuta esta función. Aquí instanciamos los componentes A y B con esta sintaxis JSX, por lo que creamos las fibras A y B. Y hemos terminado con la aplicación, así que podemos pasar al siguiente.

React recorre nuestro árbol de arriba a abajo, por lo que la siguiente fibra es A. React renderiza A, por lo que ejecutamos esta función. Creamos aquí la fibra del párrafo y del botón debido a esta sintaxis JSX, y así sucesivamente y así sucesivamente. Cuando se renderiza B, ejecutamos esta función B y también creamos este párrafo. Y este es nuestro árbol.

¿Qué sucede en el renderizado? ¿Qué sucede si hacemos clic en este botón aquí? Disparamos un cambio de estado. Vamos a renderizar. Entonces React va a agregar esta bandera de renderizado a la fibra que contiene el estado que fue cambiado recientemente. Una fibra es simplemente un objeto donde puedes almacenar algunos valores, por lo que puedes simplemente agregar esta propiedad de renderizado si quieres. Es solo un objeto. Luego, React va a recorrer nuestro árbol nuevamente y renderizar los componentes que desee. Comenzando desde la parte superior de nuestro árbol.

Un componente se renderiza por una de dos razones. Ya sea si contiene un estado que acaba de cambiar, lo que significa que fue marcado con esta bandera de renderizado, cuando llamamos a set state, React marca la fibra que contiene el estado con esta bandera de renderizado, luego cumple con este criterio. O un componente se renderiza si su padre se renderizó. Entonces, aquí la aplicación no pertenece a ninguno de estos casos. Por lo tanto, la aplicación no se renderiza.

Luego podemos pasar a la siguiente fibra. A se va a renderizar debido a esta bandera de renderizado. Cumple con este criterio. Y también el párrafo y el botón, porque su padre se renderizó. En cuanto a B y este párrafo, no tienen ningún estado que haya cambiado recientemente y su padre no se renderizó, por lo que tampoco se renderizan. Y esto es todo lo que necesitas saber para lo que viene a continuación.

Suspense. El trabajo de suspense es mostrar los hijos o un cargador si hay una solicitud dentro de los hijos. Pero cuando se renderiza suspense, ¿cómo sabe que va a haber una solicitud en los hijos? Debería mostrar el fallback en su lugar. Sabiendo que React renderiza los componentes de arriba a abajo, ¿cómo sabe que una consulta va a ocurrir más abajo en el árbol de antemano? ¿Cómo funciona suspense? Esa es la pregunta a la que intentaremos responder hoy.

Así que comencemos desde el principio. Digamos que es el primer renderizado. Suspense primero intentará renderizar los hijos. Así que agrega esta fibra de hijos y React la ejecutará. Ejecutamos esta función fetch data que simplemente lanza promesas libremente. Lanzamos una solicitud aquí. Entonces nos gustaría informar a suspense, oye, tenemos un cargador aquí. Tenemos una solicitud. Por favor, muestra un cargador. ¿Y cómo podemos, desde esta promesa, desde nuestro propio code, interactuar con suspense? Recuerda esta línea del code de React. Este árbol de fibra con este componente suspense con el que queremos interactuar se define en este nivel. Mientras que nuestro componente con nuestra promesa se ejecuta en algún lugar dentro de esta función de trabajo. Entonces, desde el alcance de mi code, no tengo acceso al code de React. No tengo acceso a suspense, ni quiero como usuario de esta API. No quiero preocuparme por ningún detalle de implementación. ¿Entonces cómo funciona esto? El truco que encontré realmente interesante es este. No solo ejecutamos una promesa. La lanzamos. Lanzamos esta promesa. Y esta función de trabajo que está en algún lugar debajo se encuentra anidada dentro de este try catch.

Entonces, cuando lanzamos esta promesa a tu suspense, sube hasta que llega a este catch. Y aquí estamos dentro del código de React. Entonces aquí, React puede decidir, puede hablar con suspense y pedirle que muestre un cargador. Entonces, varias cosas van a suceder en este catch. Primero, React va a subir por el árbol para encontrar el límite de suspense más cercano. Y le va a agregar a este la bandera didSuspense en verdadero. Nuevamente, solo una propiedad que se agrega a la fibra. Luego va a agregar un listener a la promesa para que sepa cuándo termina y pueda actuar sobre ella. Y por último, va a mover este puntero de trabajo en progreso hasta el límite de suspense y comenzar el proceso de renderizado desde allí.

Vamos a renderizar suspense aquí. Pero esta vez, con didSuspense en verdadero, sabe que el renderizado anterior se suspendió. Entonces sabe que tiene que mostrar el fallback. Así que va a eliminar esta fibra de hijos y en su lugar agregar este fallback. Antes de continuar, va a cambiar esta bandera didSuspense a falso porque ya manejó la suspensión. Y continuando, mostramos nuestro fallback. Bien. Tenemos nuestro fallback en la pantalla. Pero solo se ha completado la mitad del trabajo aquí porque pronto la consulta se resolverá. Cuando la promesa se completa, React lo sabe gracias al listener que se adjuntó a la promesa. Así que puede actuar sobre ella. Agregará esta bandera de renderizado al límite de suspense y comenzará un nuevo recorrido por el árbol, un nuevo bucle de renderizado que comienza con la aplicación que no se renderiza. Recuerda estos criterios. No mantiene el estado que acaba de cambiar. Su variante no se ha renderizado. Pero suspense sí, debido a esta bandera de renderizado. Suspense se renderiza con didSuspense en falso esta vez. Recuerda que suspense vuelve a cambiar la bandera didSuspense a falso cuando maneja la suspensión cuando muestra el fallback. Así que sabe que tiene que mostrar los hijos nuevamente. Así que vamos a ejecutar nuestra función de hijos y la promesa se resuelve, por lo que podemos ver directamente nuestros datos en la pantalla. Genial.

Ahora que hemos terminado, si ocurre otra consulta, esta vez suspense no eliminará por completo la fibra de hijos de la pantalla. Los hijos están realmente anidados dentro de esta fibra offscreen. El objetivo de offscreen es mostrar la porción del árbol que se encuentra debajo o ocultarla según esta propiedad visible. Si es verdadera, se muestra. Si es falsa, se bloquean los objetivos de trabajo en progreso. Entonces no se avanza y no se pueden ver los componentes ubicados debajo. Esto es muy importante porque si elimináramos por completo la fibra de hijos, perderíamos todos los data que contiene. El objetivo de la fibra no es solo saber qué componentes tenemos en nuestro árbol. También es saber qué tenemos en ellos. Si agregamos, entonces, sí, otra promesa sucede. Oh, lo siento, me confundí en mis diapositivas. Si ocurre otra promesa, suspense cambia la propiedad visible a falso y muestra el fallback. De acuerdo.

Entonces, si ocurre otra consulta, no queremos perder los data de los hijos. Si agregamos este data de conteo a los hijos, este estado se mantendrá dentro de esta fibra. Esto significa que cuando renderizas los hijos, tu estado leerá este valor desde aquí. Entonces, si eliminamos por completo los hijos, cuando tengamos otra promesa, cuando queramos mostrar nuevamente el fallback, perderíamos nuestros conteos y comenzaríamos desde el principio en la siguiente renderización. Este es el objetivo de offscreen. Según lo que he leído, offscreen aún está en desarrollo. Es posible que se utilice en otros casos más adelante, como siempre con el objetivo de suavizar transiciones y hacer que tu aplicación sea más rápida. Pero no es un componente que usarás tú mismo. Es un componente oculto. Entonces, en resumen, así es como funciona suspense.

Para resumir, primero suspense intenta mostrar los hijos. Luego, puede ocurrir una solicitud en los hijos, en cuyo caso suspense muestra el fallback. Y cuando se resuelve la consulta, suspense intenta renderizar los hijos nuevamente. Siguiendo esto, hay algunas cosas que quería discutir. Primero, digamos que actualmente estamos mostrando un fallback. Entonces aquí tenemos en R3 el fallback y la propiedad visible en falso. ¿Qué sucede si tenemos otra renderización por encima en R3? Eso no tiene nada que ver con la promesa resuelta.

Para probar esto, podemos agregar este estado a la aplicación y desencadenar este cambio de estado aquí. Entonces, cuando hacemos clic en este botón, vamos a agregar esta bandera de renderizado a la fibra que contiene el estado que acaba de cambiar y desencadenar una nueva recorrida. La aplicación se renderiza debido a la bandera y también lo hace suspense porque su padre se ha renderizado. Entonces renderizamos suspense con esta bandera did suspense en falso. Recordamos que suspense cambió la bandera did suspense una vez que mostró el fallback. Entonces hemos renderizado este componente con did suspense en falso. Entonces decide mostrar los hijos nuevamente. Así que vamos a pasar por esta función. Nos encontraremos con la promesa nuevamente que lanzamos. Volveremos a suspense que mostrará el fallback nuevamente. Me parece fascinante que React sea tan rápido que ni siquiera nos damos cuenta de que todo esto está sucediendo justo debajo de nuestra atención.

Ahora pasemos a la segunda conclusión. Si tienes varias solicitudes, varias consultas dentro de un componente, estas dos consultas en realidad ocurrirán en serie. No se lanzarán juntas. No se lanzarán en paralelo. Suspense primero mostrará los hijos. Nos encontraremos con esta promesa, la lanzaremos. Nos suspendemos, mostramos otro. Y cuando se resuelva, suspense volverá a renderizar este componente de hijos y solo entonces llegaremos a esta línea. Pero eso es realmente malo para el performance, ¿verdad? De hecho, me sorprendió mucho ver que no vi un impacto tan grande. Intenté tener varias consultas pequeñas y realmente no vi muchas diferencias. Pero esto puede ser un problema. Si tienes muchas consultas grandes, es posible que desees lanzarlas juntas. Entonces puedes hacer esto. En lugar de lanzar múltiples promesas, puedes lanzarlas todas a la vez. Esto es lo que hace useSuspendQuery de react-query en lugar de useSuspendQuery. No hablaré de otros manejadores de consultas de estado porque react-query es realmente el único que conozco. Entonces, si quieres lanzar tus consultas en paralelo, es posible que desees usar este. Sin embargo, todavía se realizan algunas otras optimizaciones. Lo siento, es posible que tengas un problema si tus consultas están en diferentes componentes.

Si tengo un primer componente que lanza una consulta y luego maneja este otro componente que tiene esta otra consulta, estas dos consultas no se lanzarán en paralelo. Y useSuspendQuery no puede hacer nada por ti aquí. Pero no creo que sea algo tan malo para suspense porque antes de suspense, esto todavía era el caso. Antes de suspense, tenías este cargador que bloqueaba tu proceso de renderizado. Así que no cambia mucho. Pero es posible que desees precargar tus data antes en tu aplicación para lanzar tus consultas más rápido.

Todavía hay, como dije, algunas optimizaciones realizadas. Suspense lanzará las consultas de todos sus hijos directos, lo que significa que si hay una consulta en perfil, suspense aún intentará lanzar al menos las primeras consultas de ayuda y boletín de todos los hermanos. Ese es el comportamiento de React 18. En React 19, esto ya no será el caso porque el equipo de React se dio cuenta de que era mejor mostrar un cargador lo más rápido posible. Pero algún día podrían volver a una mezcla del comportamiento del 18 y 19. Puedes obtener más información al respecto aquí, pero algún día podrían lanzar lo más rápido posible para mostrar un cargador, y luego activar otra pasada de renderizado para los hermanos.

Y esto es todo lo que quería compartir hoy sobre suspense. Espero que hayas disfrutado explorando sus secretos más oscuros. Llevo 18 años desarrollando y no tengo ni idea de lo que estás haciendo. Así que me quito el sombrero. Muchas gracias. Wow. Ahora vamos a pasar a las preguntas del público. Tengo que decir que esta es mi primera sesión de preguntas y respuestas y estoy realmente estresado por esta. OK. Vamos a empezar suavemente. Por favor. Primera pregunta, entonces. Solo para tranquilizarte, ¿qué día es hoy? No tengo idea. Si no puedo responder eso, debería dejar el escenario. Viernes. Es viernes. OK. Sí, tienes razón.

Pronto podremos. De acuerdo. ¿De qué color es el suelo? Diría que es gris. Espero que estemos de acuerdo. De acuerdo. Luego una pregunta real. Lanzar promesas como parte normal de la ejecución del code se siente un poco incorrecto. ¿Puede lanzar reservarse para excepciones? Oh. De acuerdo. Entonces esto... Lo siento. Tuve que leerlo tres veces. No te preocupes. Esto es muy cierto, pero estás anidado dentro de una API. Eso no es algo que debas hacer. Por lo general, se utiliza un controlador de solicitudes u otra biblioteca que lo hace, y sí, no parece correcto, pero está anidado, está oculto. Entonces, como te permite eliminar todos tus cargadores, todos tus errores, creo que tiene tantos beneficios que está bien. Entonces no lo hagas en tu code normal, pero a nivel de framework, lo permitiremos. O si quieres hacerlo en tu code, no sé por qué sería una buena opción, pero podrías hacerlo y simplemente ocultarlo en una función que solo... Con una advertencia, estamos haciendo esto aquí, no lo hagas en ningún otro lugar. Sé que esto es sucio, no me juzgues. Sí. Muy bien.

Siguiente pregunta. De Ensgar. Charlotte. ¿Entonces simplemente puedes lanzar cualquier promesa dentro de un componente y el componente se suspenderá? Sí. Según lo que he leído. Sí. En realidad, esto es prácticamente cómo funcionan los límites de error también.

Lanzas, y se propaga hasta el mismo tricatch, y React verifica los argumentos a los que estás presionando este error lanzado. Si tienes una promesa, supone que debe ser para suspense. Genial. Gracias.

Siguiente pregunta. ¿Los hijos de suspense necesitan ser componentes asíncronos, o solo necesitan ejecutar una promesa? Los hijos de suspense se han ido. ¿Los hijos de suspense necesitan ser componentes asíncronos, o solo necesitan ejecutar una promesa? Esa es una muy buena pregunta. Supongo que no... No estoy seguro, no lo he intentado. Pero supongo que no tiene que ser asíncrono. Simplemente lo hice asíncrono para obtener los resultados, pero supongo que si lanzas, lanzas. Así que esa es una buena pregunta, deberíamos probar esto. Cinco en la fuente.

Pregunta de Rob. Charlotte, ¿qué sucede si el árbol de fibra... ¿Qué sucede en el árbol de fibra si un respaldo también se suspende? Vaya, esta es una pregunta realmente buena. Supongo que tienes un error. Creo que definitivamente deberíamos probar esto. Pero supongo que podrías tener un bucle infinito. A todos les encantan los bucles infinitos, está bien.

¿Suspense también funciona con promise.all? No lo he probado, pero supongo que sí, sí. Realmente no lo sé. Esa es una respuesta válida. Quiero decir, si no lo hace, es solo unas pocas líneas de code que podrían agregarse a React y decidieron no hacerlo. De acuerdo. Muy bien, siguiente. ¿Cuándo recoge suspense la obtención de data dentro de useEffect con dependencias vacías? Cuando queremos obtener data solo una vez. Bueno, useEffect desaparecerá con React 19. Sí. Realmente no lo sé.

Lo siento. Supongo que no es necesario porque en React 19, ya no vamos a utilizar useEffect debido al nuevo compilador sofisticado del que todos estamos contentos.

De acuerdo. ¿Cómo se integra suspense con Redux, si lo sabes? No tengo idea. No lo he intentado. No sé por qué sería un problema. Probablemente. Sí. ¿Podrías decir la respuesta de un experto? Depende. Tal vez deberíamos intentar reunirnos con Mark Erickson aquí y preguntarle. Bueno, intentémoslo.

De acuerdo. React query aún afirma que el soporte de suspense es experimental. ¿Ya lo estás utilizando en producción? Sí, lo estamos utilizando. Sí. No lo sabía... Francamente, no sabía que todavía era experimental. Creo que es seguro, pero... Sí. Es lo suficientemente seguro. Aunque si ellos lo dicen, tal vez no deberíamos. La empresa todavía está en funcionamiento. Nadie se ha declarado en quiebra. Entonces, está bien. Nuestra aplicación aún no ha sido rechazada por la tienda.

De acuerdo. La documentación menciona que la visualización de cargadores en suspense solo funciona con frameworks habilitados para suspense. ¿Funciona el patrón que muestras sin ese framework? No lo creo. Debo haber seguido la documentación, así que supongo que lo agregué. Creo que mencionan que los frameworks habilitados para suspense son la única forma en que funciona en versiones anteriores a React 19.

Porque en el mundo de React 19, creo que ya funciona. Realmente no tengo idea. Necesitamos leer el código fuente.

Una pregunta de Lou. ¿Qué sucede si el componente secundario contiene algo como un tiempo de espera y luego lanza una promesa? No veo... No veo por qué el tiempo de espera afectaría la promesa. Sí. Probablemente si detiene el ciclo de renderizado. O si... Oh, si la promesa ocurre dentro del... Tiempo de espera. De acuerdo. Lo entiendo. Esa es realmente una buena pregunta. Tengo que recordar.

¿Cómo sabe suspense que este componente desencadenó la promesa? No recuerdo esta parte. Esa es una buena pregunta. ¿Cómo sabe suspense que este es el componente que lanzó esta promesa? Tengo que decirlo. No lo recuerdo. Lo siento. Le pediremos a Lou que te busque en Twitter y luego podrán descubrirlo juntos. Puedo verificar después. Lo siento. No estás aquí porque lo sabes todo. Sabes un poco y queremos tener ese conocimiento. Así que no te preocupes.

La siguiente pregunta es de Ren. ¿React MonkeyPatch promete hacerlo lanzable, o cómo funciona eso? Realmente no lo sé. Pero una promesa es lanzable. Sí, no conozco a React Monkey, lo siento.

No lo sabemos, Ren. Lo siento. Alex Pax pregunta, ¿quieres decir que con OffscreenComponent no necesitamos almacenar en caché la promesa para que funcione suspense? Y Alex todavía está en React 17. No sé por qué necesitamos almacenar en caché una promesa. Oh. Con Offscreen. De acuerdo. Entonces, el objetivo de Offscreen no es mantener las promesas en caché. Es mostrar u ocultar tus hijos, ya sea que quieras mostrar la carga de respaldo o los hijos. No estoy seguro de entender la pregunta.

De acuerdo. Bueno, es un poco difícil de responder ya que Alex todavía está en React 17. El consejo sería tal vez hacer una actualización de NPM. Siguiente pregunta. ¿Se considera una buena práctica usar suspense para renderizar páginas completas con una carga de respaldo? ¿Entonces si envuelves toda tu aplicación con un suspense para un cargador? ¿Para páginas completas? Bueno, no sé acerca de las mejores prácticas de diseño, pero supongo que quieres tener tanto como solo un cargador en lugar de tener varios cargadores y tener una cascada de cargadores. Así es como lo hacemos. Pero no estoy seguro de que sea la mejor práctica. Por un lado, quieres mostrar los pequeños fragmentos de datos. Si tienes como cinco fuentes de datos, quieres mostrar los datos que llegan. No quieres tener que esperar. Si hay una llamada que tarda dos segundos y la otra tarda 10, quieres mostrar los datos después de dos segundos, ¿verdad? No quieres hacer esperar al usuario. Pero por otro lado, mostrar también cinco cargadores, sí. Supongo que depende de tu aplicación. Si tienes esqueletos bonitos, entonces puede ser bueno tener proveedores de suspense solo para estas partes para que puedas, como dijiste, mostrar los datos de esta parte lo más rápido posible. Si solo tienes algunos cargadores, entonces tener grandes cargadores en todas partes no es bonito. Así que supongo que depende de cuánto tiempo tengas en tus decisiones de diseño. Eso es un final perfecto porque no tenemos más tiempo. Así que quiero agradecerles mucho por estar aquí hoy y por esta encantadora sesión de preguntas y respuestas. ¿Puedo tener un cálido aplauso para Charlotte? Así que tómense un momento para calificar la charla de Charlotte. Cualquier comentario es muy apreciado. Ahora vamos a tomar un descanso. No olviden conseguir algunos sellos y ganar esos increíbles auriculares de Apple. Y ahora tomen un refrigerio, tomen algo y nos vemos en 30 minutos.