Utilizando useEffect de manera efectiva

Muy bien, hola a todos. Mi nombre es David Corschied, y mis diapositivas aparecerán en breve. Estoy seguro... Oh, sí, ahí está. David Corschied. Me encuentro como David K. Piano prácticamente en todas partes. Estoy muy emocionado de estar en Londres. Nuevamente, trabajo en stately.ai, donde pensamos mucho en el estado, la lógica y los efectos, pero basta de hablar de mí. Si sigo así, esta charla durará más que su próximo primer ministro, así que sigamos adelante.

De acuerdo. Entonces, por supuesto, trabajo en stately, y uno de nuestros ingenieros, Matice, tal vez lo hayan visto a él. Está en su NPM, en sus modules de node, te lo garantizo. Es uno de los desarrolladores más talentosos que conozco. Ayer creó una solicitud de extracción donde preguntó, ¿estoy 100% seguro de esta solución? Ni de broma, se basa en useEffect. Así que hoy vamos a hablar de eso, de nuestro hook favorito, useEffect. Pero empecemos desde el principio. ¿Quién recuerda los componentes de clase? ¿Verdad? Sí, algunas personas realmente los quieren de vuelta. Yo también.

Muy bien. Entonces, en este ejemplo, recuerdo que cuando react salió, estaba muy emocionado por ello. Pensé, wow, esto va a cambiar todo, y react cambió todo en cada renderizado. Así que aquí, estamos haciendo lo que la mayoría de los componentes hacen, o lo que la mayoría de los desarrolladores de React hacen, que es obtener data y mostrarlo en la pantalla. Admítelo. Eso es el 90% de tu trabajo. Pero teníamos un componente de ciclo de vida muy conveniente para hacer eso. Pero ahora las cosas son diferentes. Tenemos useEffect. Recuerdo que aprendí sobre useEffect en 2018, y estaba muy emocionado de usarlo porque pensé, wow, esto simplifica mucho las cosas. Así que en lugar de hacer estas clases grandes y voluminosas, tenemos estos hooks en los que podemos poner cosas.

Quería obtener data. Era 2018, así que quería usar la nueva sintaxis de JS. Y estaba en efecto. Así que lo puse en useEffect.

Intenté esto, React me gritó. Dijo, escucha, esta cosa de async await, es elegante, pero no puedes usarlo así. Tienes que, ya sabes, no lo infiere, hey, no sé qué hacer con esto porque promete que lo devuelves de useEffect. Así que tuvimos que hacer cosas como si estuviéramos en 2015 y usar .then.

Entonces, obtuve algunos data, luego lo establecí. Pensé, esto es simple. Solo lo puse en useEffect. Obtengo mis data. Estoy listo para continuar. ¿Verdad? Incorrecto. ¿Adivina qué le pasó a mi AWS al día siguiente? Sí. Así que esto, por cierto, seguirá buscando y buscando y buscando. Y realmente, React no te dirá, hey, esto ocurrirá como un bucle infinito.

De acuerdo. En este punto, pensé, tal vez debería leer un poco la documentación. Así que me desplacé hasta abajo. Y ahí estaba un consejo. Es solo un consejo. Sabes, esta información muy crucial es solo un consejo en la documentación actual de React. Documentos que optimizan el rendimiento al omitir efectos. Y así, aprendí que se supone que debes usar este pequeño array de dependencias. Y como esto realmente no tenía ninguna dependencia, simplemente lo pones vacío así. Si lo miras de lado, se parece un poco a un desarrollador de React angustiado gritando al vacío.

Entonces... Sí. De acuerdo.

Entonces, aprendí mi lección. Aprendí para qué sirve el array de dependencias. Y así, todo estaba bien. ¿Verdad? Bueno, ahora descubro que tenemos algo llamado una condición de carrera. Porque cuando obtengo algo con un ID, y luego decido, ya sabes qué, voy a obtener algo con un ID diferente, si ese ID se resuelve primero, mientras el primero todavía está en proceso, porque no lo cancelamos. Así que ahora tenemos que hacer el baile. Este es un baile que muchos de ustedes han hecho antes, y eso es tener esta bandera de cancelado en falso, o React lo llama ignorado en la documentación oficial, y luego tienes que asegurarte de que no hayamos cancelado esta promesa, que tienes que tener una limpieza allí, y tienes que hacer todo esto. Algunos de ustedes simplemente copian y pegan esto, algunos de ustedes lo ponen en un hook personalizado de promesa o async, lo cual está totalmente bien. Y esto funcionó bien por un tiempo.

Hasta React 18. Donde los efectos se ejecutan dos veces al montar. Así que cuando descubrí esto por primera vez, no sabía que era algo de React 18. ¿Estoy haciendo algo mal en mi código? ¿Qué hice? ¿Alguien cambió algo? ¿Fueron los Torys? No tengo idea.

Entonces, ¿qué está sucediendo aquí? Lo investigué y vi que montamos un efecto, y luego React está simulando un desmontaje y luego lo vuelve a montar, preguntándome por qué demonios estaba haciendo eso. Así que investigué mucho. Estaba mirando la segunda documentación oficial de React, que son hilos aleatorios de Twitter de los mantenedores principales, y me di cuenta de que, sabes, useEffect parecía ser algo defectuoso. Pensé que realmente, realmente no deberíamos estar usándolo, ya sabes, y cuanto más lo usamos, más nos sentimos así. ¿Verdad? Así que, por supuesto, me calmé un poco, investigué un poco más. Aprendí cómo funciona useEffect. Y la respuesta podría sorprenderte. No lo hace. No lo hace para muchos efectos. ¿De acuerdo? En realidad funciona. Pero hay muchas señales de advertencia donde puedes ver, vale, tal vez no debería estar usando useEffect. En primer lugar, la doble ejecución de React 18, esa cosa que hace solo en modo estricto y solo en entornos de desarrollo. Esto es básicamente un aviso de desalojo. Cuando esto sucede y parte de tu aplicación se rompe, básicamente React te está diciendo que no deberías estar usando este efecto dentro de useEffect. Además, hay otros síntomas como arrays de dependencias largos. Cuando tienes condicionales complejos dentro de tus efectos, si te faltan funciones de limpieza o si esas funciones de limpieza en sí mismas son condicionales, o si tienes llamadas de estado ad hoc dispersas por todas partes. Estos son todos signos bastante claros o efectos secundarios que podrían indicar que probablemente estás usando useEffect de manera incorrecta.

Entonces, ¿qué efectos deberíamos usar en useEffect? En la nueva documentación beta de React, a la que daré un enlace más adelante, dicen que realmente hay dos tipos de efectos. Los efectos que, con una E mayúscula, te permiten especificar efectos secundarios que son causados por el renderizado en lugar de por un evento en particular. Así que vamos a ver la diferencia ahora mismo. React se refiere a dos tipos de efectos, efectos con una E mayúscula y eventos. Los efectos que, ya sabes, se supone que deben ocurrir en los controladores de eventos, pero creo que esto es un poco confuso. Por lo tanto, durante esta charla los llamaré acciones de actividad o, lo siento, Activity Effects y Action Effects. Y los Activity Effects son algo que es un proceso continuo.

Es algo que no olvidas mientras estás en el ciclo de vida de tu componente, lo estás observando atentamente. Esto podría ser una suscripción o ver una transmisión en vivo de A Head of Lettuce o algo así. Un Action Effect es algo que ejecutas explícitamente, es disparar y olvidar, no te importa cuál es el resultado final, como el Brexit. Entonces, ¿para qué sirven los Use Effects? Los Use Effects, el hook específicamente, se utilizan para la sincronización con los Activity Effects. No con los Action Effects, sino con los Activity Effects. Un ejemplo de esto es, por ejemplo, un listener, un cambio de tamaño, un movimiento del mouse, algo así, donde creas un controlador, agregas ese controlador y te aseguras de usar esa función de limpieza para decir: ya no quiero escuchar esto. Y debido a que las actividades son cosas continuas, es como ver televisión donde no importa cuántas veces enciendas y apagues la televisión, el canal seguirá funcionando. No estás imponiendo ningún efecto secundario al encenderlo y apagarlo, no es como si apagaras la televisión y la BBC dijera: bien, cortémoslo, esta persona dejó de ver, no funciona así. Entonces, ¿dónde van los action effects? Sabemos que realmente no podemos tener efectos secundarios en el renderizado, y en realidad sí podemos, pero no entraremos en eso aquí. Sabemos que ponerlo en useEffect es incómodo, porque David lo dijo, pero ¿qué pasa fuera del componente? Esa es una idea. Entonces, ¿dónde van los action effects? En realidad, van en los controladores de eventos, o algo así. En este ejemplo, tenemos un onSubmit, y estamos enviando los datos directamente dentro de ese onSubmit, y te mostraré la alternativa más adelante. Pero el modelo mental real es que quieres poner tus efectos de disparar y olvidar, tus action effects, lo más cerca posible del evento que habría causado el efecto. Y así es como esto ayuda con React 18. Sabemos que cuando algo cambia, nuestro componente se volverá a renderizar, y si vinculamos ese efecto al renderizado, entonces React, recuerda, tiene la capacidad de seguir volviendo a renderizar ese componente, y porque lo vinculaste al renderizado, seguirá ejecutando esos efectos, lo cual realmente no queremos. Pero si mueves el efecto más cerca del controlador de eventos, evitas completamente ese problema, porque no lo estás vinculando al renderizado, lo estás vinculando al evento real que causó ese efecto. Los action effects ocurren fuera del renderizado. Muy bien.

Aquí tienes un ejemplo que en realidad tiene varios problemas. Y lo he visto antes. Incluso lo he hecho. Hay una propiedad isFocused. Y esta propiedad isFocused se asegura de que cuando enfocamos un componente, isFocus es igual a true o está escuchando ese cambio de estado y cuando ese estado cambia, vamos a ejecutar ese useEffect que luego va a enfocar el evento. Así que hay mucha indirección aquí solo para, ya sabes, hacer que ese componente se enfoque y también hay una posibilidad de un estado imposible, como qué pasa si tienes múltiples isFocused como true. En resumen, isFocused realmente no debería ser una propiedad. Pero veamos cómo podemos refactorizar esto, al menos fuera de useEffect. En su lugar, podríamos usar un forward ref y simplemente consumirlo en los componentes donde tenemos este input ref igual a useRef. Y aunque este es un input elegante, podríamos usar forward ref para capturarlo. O si realmente quieres, usa imperative handle. No lo incluí en las diapositivas porque no quiero que la gente haga capturas de pantalla y diga que este tipo recomienda usar imperative handle.

Esto es demasiado picante para esta charla. De todos modos, échale un vistazo. Estamos realizando el efecto secundario directamente dentro del controlador de eventos. Como resultado, tenemos un componente muy limpio, no tenemos ningún useEffect a la vista, y esto es extremadamente simple. Sin embargo, cuando pensamos en esto, ejecutar un efecto directamente dentro del controlador de eventos se siente... O, perdón, ejecutar un efecto directamente dentro del controlador de eventos se siente imperativo. Se siente como cuando algo sucede, ejecuta este efecto, sabes, se siente un poco extraño, se siente un poco como un efecto secundario y no realmente funcional, ¿verdad? Pero echa un vistazo al enfoque declarativo donde decimos que cuando algo sucede, provoca un cambio de estado, y dependiendo de qué partes cambien, este efecto debe ejecutarse, pero solo si se cumple alguna condición. Y React puede ejecutarlo nuevamente por alguna razón futura, pero solo en modo estricto, que no deberías desactivar, por alguna razón futura. He intentado escuchar la explicación para esto, creo que tiene algo que ver con el modo fuera de pantalla o algo así, cada vez que lo escucho, simplemente pierdo la razón, pero simplemente no lo hagas.

De acuerdo, entonces. Ahora vamos a sumergirnos en la documentación Beta de React. Solo revisando la hora. Oh, no hay mucho tiempo. De acuerdo, entonces, la documentación Beta de React, estoy muy agradecido de que exista esta documentación, por cierto. Así que, por cierto, si vas a reactjs.org, hay un encabezado agradable aquí, y puedes ir directamente a la documentación Beta de React, que tuvimos hace tres años, pero es genial que lo tengamos ahora.

De acuerdo, y hay una sección aquí llamada `es posible que no necesites un efecto`. Así que vamos a repasar algunas de las secciones. No todas, porque entonces esta sería una charla mucho más larga. Pero sí, vamos a repasarlas una por una, especialmente las que son más comunes para lo que veo que la gente utiliza Use Effect, donde no deberían.

El primero, no necesitas Use Effect para transformar data. Aquí tienes un ejemplo, donde calculamos el total de un número de elementos directamente en Use Effect, lo cual tiene sentido, ¿verdad? Cada vez que los elementos cambian, necesitamos establecer el total. ¿Adivina qué? Esa es una forma muy imperativa de pensar. En su lugar, podríamos ponerlo dentro de Use Memo. Porque el total es un valor derivado, y Use Memo es muy bueno para valores derivados. Pero adivina qué? Es posible que ni siquiera necesites Use Memo. Sinceramente, comienza sin él. Y solo si comienzas a notar problemas de rendimiento, deberías comenzar a usar Use Memo. Estoy diciendo `usar` mucho. Pero sí, mucho más simple. Deshazte de Use Effect.

Y por supuesto, sabemos que poner set state en Use Effect podría causar un montón de problemas de todos modos, llevando a la gente a pensar, nunca entenderé por qué el comportamiento predeterminado de Use Effect es un bucle infinito. Me ha pasado antes y la documentación de React te advierte. No deberías hacer esto. Por eso es. Porque esto va a desencadenar una nueva representación, lo cual va a desencadenar el efecto nuevamente, y así sucesivamente. No necesitas Use Effect para comunicarte con los padres. Este es un caso interesante que destaca la indirección que está ocurriendo. Tenemos onOpen y onClose como props. Cada vez que abrimos algo aquí, como digamos que esta es una vista de producto, cambiamos el estado, y luego dependiendo de si está abierto o cerrado, vamos a llamar a esas props.

Lo estamos haciendo al poner isOpen en una dependencia, lo cual va a desencadenar el Use Effect. Puedes ver aquí, estamos haciendo clic, el estado está cambiando, luego tenemos un efecto. Mucha indirección. Entonces, en su lugar, deshazte del Use Effect, ponlo directamente en el controlador de eventos y ahora se vuelve mucho más directo y fácil de entender. Entonces, ahora en su lugar, simplemente estamos calculando el próximo estado, porque sabemos que el próximo estado de eso es abierto, y dependiendo de ese estado, llamamos directamente a onOpen y onClose. Incluso podrías ponerlo dentro de un gancho. De acuerdo. No necesitas Use Effect para suscribirte a tiendas externas. Este es realmente interesante, porque va en contra de lo que acabo de mencionar. Es como si Use Effect fuera realmente bueno para las suscripciones, ¿verdad? Bueno, aquí me estoy suscribiendo a una API de tienda, y todo lo que estoy haciendo es obtener un valor específico, como si estoy conectado o no a la API de la tienda, y luego tengo un unsubscribe aquí. Todavía tenemos un poco de indirección aquí porque estamos estableciendo una variable de estado local. ¿Adivina qué? En realidad podrías deshacerte de esto y usar el gancho useSyncExternalStore, que tiene tres partes. Una parte de suscripción, donde le dices, aquí está cómo suscribirte, aquí hay una función que necesitas llamar para suscribirte, la parte de getSnapshot, que es, este es el valor que quiero obtener, y aquí está cómo leerlo de esa tienda, y una instantánea del servidor que es buena para SSR. Entonces, juntas esas tres cosas, se va a suscribir automáticamente y obtener el valor que necesitas, sin usar fecha, sin usar efecto. Es un gancho realmente brillante. Así que te recomiendo que al menos lo pruebes. Dicen que solo es para autores de bibliotecas, pero también dijeron, como, no uses, o serás despedido, solo es para los mantenedores de React, pero estamos viendo bibliotecas que lo usan por cualquier razón, como Preact Signal y cosas así. Así que adelante y úsalo. No ese. Pero usa useSyncExternalStore. De acuerdo. Este es un gran punto. No necesitas Use Effect para obtener data. Como hablamos al principio, esa fue una de las grandes razones por las que usamos Use Effect. Entonces, en lugar de todo esto que estábamos haciendo antes, simplemente usa el marco. Sea lo que sea que estés usando, es probable que estés usando un marco. Remix tiene un cargador realmente agradable aquí. obtener props del lado del servidor. Esto estará disponible directamente en el componente. Y luego hay una biblioteca que espero que la mayoría de ustedes estén usando para obtener data, que es React query.

Pero fíjate aquí que estoy haciendo algo diferente. Estoy utilizando query clients.prefetch query. Porque la idea es comenzar a obtener datos lo antes posible, lo cual es tema de otra charla completa. Así que en lugar de usar efectos, realmente utiliza query. Next.js dice que uses SWR. O simplemente use. Esto ocurrirá en el futuro. Si no estás familiarizado con el gancho use, básicamente funciona de la misma manera. Creo que esta será la nueva forma de hacer suspense. Es un RFC. React podría eliminarlo. Les gusta hacer lo mismo que Google, donde eliminan cosas. Solo bromeo. Han lanzado muchas cosas realmente geniales. Pero lo importante es esta caché aquí. Esta caché significa que cada vez que intentemos leer esto, no vamos a seguir obteniendo los datos una y otra vez. Te garantizo que verás tutoriales de React donde se olvidan de esta parte de la caché o comienzan a obtener datos aquí. Volverás a tener efectos en cascada, así que asegúrate de obtener los datos lo antes posible y almacenarlos en caché.

Y Dan habla sobre muchos problemas con la obtención y el uso de efectos. En primer lugar, las condiciones de carrera de las que hablamos, no hay un botón de retroceso instantáneo. Verás indicadores de carga en todas partes cuando intentes retroceder porque los componentes intentarán cargar de nuevo. Sin contenido inicial HTML, así que tendrás aún más indicadores de carga, y estarás persiguiendo cascadas porque el padre se cargará y cuando se descargue, el hijo se cargará. Cuando eso se descargue, etcétera, etcétera. Y así que quieres evitar esas cosas.

De acuerdo. Otra cosa, no necesitas el efecto de uso para inicializar singletones globales. Así es lo que quiero decir. Digamos que hemos hecho esto muchas veces, donde ejecutamos algún tipo de efecto justo cuando nuestra aplicación comienza. Y así que pensamos que el efecto de uso es el lugar adecuado para los efectos. Así que estamos llamando a esta API de almacenamiento API.authenticate, pero sabemos que en React 18, esto se va a ejecutar dos veces. Así que en su lugar, usamos una referencia y decimos, eh, ¿esto ya se ejecutó? Tal vez no. Pero esto honestamente es una señal de advertencia. Así que te recomiendo que no lo hagas. En lugar de usar una referencia, podríamos simplemente sacarlo fuera. Pero adivina qué. ¿Por qué no simplemente sacamos todo fuera? Mira qué simple es. Muchos de ustedes podrían estar gritando internamente. Esto es algo que Dan recomendó en Twitter, así que me siento bien poniéndolo en la pantalla. Pero si estás usando Next, puedes verificar si el tipo de ventana es indefinido o no y llamarlo condicionalmente así, y si vas a gritar acerca de testing, simplemente envuélvelo en una función, ¿sabes? Incluso podrías inyectar esa API de almacenamiento, hacer lo que quieras hacer. Ya sabes, simplemente hazlo fuera del componente.

Y luego el más grande para mí, no necesitas efectos de uso para manejar eventos de usuario. Y así que esto se refiere a efectos de actividad versus efectos de acción. Ahora estamos hablando de efectos de acción. En este caso, estamos enviando un formulario y estableciendo todas estas variables, así que establecemos isLoading en verdadero. Establecemos los datos del formulario en el evento. Y eso va a ser indirecto y desencadenar un cambio. Esto está mal. Lo que debes hacer es moverlo dentro del controlador de eventos. Así que muévelo dentro de submit y luego, ya sabes, es posible que necesites agregar mucha lógica extra pero debido a que no estás usando el efecto de uso y lo estás aislando en ese controlador de eventos, puedes abstraerlo fácilmente a un gancho.

Mi tipo favorito de gancho se ve así, donde tienes un estado y un enviar. Y todo lo que tienes que hacer en tus componentes es enviar eventos. Esto es useReducer. Esto es X-Day. Es una biblioteca que mantengo. Esto es Redux. Zushan funciona de manera similar.

Sí, pero aquí hay un ejemplo más grande. Quería hacer este video genial donde es una miniatura, pero cuando haces clic en él, se pone en pantalla completa y luego hay muchas formas de cerrarlo. Puedes hacer clic fuera de él. Puedes presionar la tecla de escape o puedes esperar a que el video termine. Hay tres useEffects que manejan esto. Entonces, el primero que estamos comprobando es si se está reproduciendo. Y si se está reproduciendo, VideoRef es, ya sabes, tenemos que reproducirlo o pausarlo si no lo está. El segundo, estamos escuchando el final del video. Y si no está terminando, entonces tenemos que establecer que se está reproduciendo en falso. Y recuerda, esto va a desencadenar cierta indirección. Va a desencadenar el cambio de estado y luego el estado va a desencadenar el efecto anterior. Y lo mismo aquí. Cuando presionamos la tecla de escape, nuevamente establecemos que se está reproduciendo en falso y ahora tenemos un poco de limpieza también.

La forma en que me gusta pensar en esto en términos de efectos declarativos es mediante el uso de una Máquina de Estado. Y no, no voy a hablar de XSEED en esta charla, pero puedes hablar conmigo después al respecto. Con las Máquinas de Estado, declaras los efectos que se ejecutarán directamente en la transición. Y creo que esto es brillantemente simple. Por ejemplo, cuando estamos en Mini y hacemos la transición a Full, lo hacemos con un interruptor y reproducimos el video. Lo mismo ocurre cuando pasamos de Full a Mini. Pasamos de Toggle y pausamos el video, y luego hacemos la transición. Entonces, si no has usado Xstate, imagina esto como Redux o tu reducer estándar.

Imagina si pudieras ejecutar efectos directamente dentro de tu reducer. Es básicamente la misma idea. Realmente me gusta esto porque te brinda una forma visual y declarativa de pensar en todos tus efectos sin tener que enredar tu mente y pensar, `ok, ¿cuándo se ejecutará este efecto? No tengo ni idea. Así que sí, esta es mi forma de decirte que comiences a investigar, supongo, las máquinas de estado porque las máquinas de estado están diseñadas específicamente para expresar de forma declarativa todos estos tipos de efectos.

Entonces, en resumen, ¿dónde van los efectos de acción? No realmente en los controladores de eventos, pero técnicamente van en las transiciones de estado, que ocurren aproximadamente al mismo tiempo que los controladores de eventos. Ahora no tengo mucho tiempo, así que vamos a concluir con un resumen. El useEffect se utiliza para la sincronización, los efectos de actividad se colocan en useEffect, los efectos de acción se colocan en los controladores de eventos, debes renderizar mientras obtienes datos y, por último, las transiciones de estado desencadenan efectos.

Así que con eso dicho, quiero agradecerles a todos mucho. ¡Increíble! Por favor, pasen a mi oficina. Muchas gracias, David. Fue fascinante y también muy divertido, lo cual aprecio. Recuerden que pueden hacer preguntas en Sli.do. El código es 2124. Como de costumbre, la gente quiere saber qué software de presentación estás usando. Porque es hermoso. Esto es slides.com porque soy demasiado perezoso para aprender keynote. Además, slides.com es súper fácil, y además puedes personalizarlo con CSS. También tienen esa función de movimiento mágico, es realmente agradable. Y presentar sin conexión. Eso es lo que uso.

Oh, sí. Hablemos de efectos. Me encanta el concepto de You Might Not Need. Porque soy una persona sencilla, no me gusta complicar las cosas. Pero si quisiera llevar todo esto al mundo real, un equipo, un trabajo, ¿hay alguna herramienta que podríamos usar? Algunas reglas de linting, algunas notas, una publicación de blog, algún tipo de recurso para asegurarnos de que estamos conscientes de estas cosas. Buena pregunta. Quiero decir, supongo que podrías ver mis charlas, pero luego dirán, oh, esto es solo David hablando sobre useEffect. Así que escribiré una publicación de blog al respecto. La documentación oficial de React, la documentación beta. Honestamente, deja de leer la documentación antigua, lee la documentación beta. Esa será la fuente de recursos para básicamente todo lo que hablé durante esta charla. Y también tienen algunos ejemplos más de cuándo no debes usar useEffect.

Definitivamente, lee eso. En cuanto a las reglas de linting, simplemente deja que React 18 haga que tu aplicación se bloquee en desarrollo. Y piensa, oh, ¿por qué sucedió eso? Probablemente sea un useEffect. Siento que sé la respuesta a esto, pero ¿qué opinas sobre esa regla de linting que dice que no debes poner funciones en tus controladores de eventos? No pongas... ¿Qué tal si no agregas reglas de linting hasta que realmente se conviertan en un problema? ¿Qué te parece eso? Eso es genial. Gracias por eso.

Bien, tenemos algunas preguntas. Está bien. `Fetch as you render` suena bien hasta que dependes de argumentos para tu solicitud. ¿Cuál es el mejor enfoque entonces? Bueno, piensa en cuándo ocurren esos argumentos. Probablemente el usuario lo inicie o provenga de una fuente externa. Por ejemplo, el usuario puede presionar un botón, completar un formulario y luego, cuando envíen el formulario, ese es el momento en que debes iniciar la solicitud. Lo que muchos desarrolladores de React hacen es enviar un formulario, que se establece en el estado o se pasa como una propiedad a un componente, y luego el componente dice, oh, hola, tengo una propiedad, ahora puedo leer esa propiedad y obtener datos basados en esa propiedad, pero hay mucha indirecta allí. Así que comienza a obtener los datos lo antes posible. Aprenderás que el renderizado de React no es un evento, o no son los eventos en los que debes preocuparte. Lo que debes enfocarte es en el usuario que realmente hace cosas o en alguna acción externa que hace cosas.

Hay muchas preguntas y las voy a agrupar sobre todas las alternativas. ¿No es useReducer bueno para obtener datos? ¿O crees que vamos a usar Redux nuevamente? ¿O cuándo usarías useEffect sin una matriz de dependencias? ¿Qué hay de useEvent? Todas las opciones. UseEvent está obsoleto. Ya sabes, a React le gusta matar cosas. Sí. ¿Cuáles eran las otras alternativas? Cosas como useReducer, Redux, etc. Estos son contenedores de estado. No son realmente formas de obtener efectos de obtención de datos. Pero como mencioné, con las máquinas de estado, debes pensar en cuando tu estado cambia, debes tener alguna forma de indicar... Este es un nuevo estado. Y estos son los efectos que deben ocurrir. Muchas veces, cuando lo pensamos, decimos, aquí hay un nuevo estado. Y luego tenemos algún middleware que se ejecuta donde decimos, bueno, tal vez obtendré los datos.

Pero creo que ambas cosas deberían ir juntas. Gracias, David. ¿Qué herramienta utilizaste para visualizar la máquina de estados en tu diapositiva? Buena pregunta. No es una pregunta plantada, lo prometo. Es un editor de stately.ai. Es gratuito de usar, juega con él. Es realmente bonito. Sí.

De acuerdo. Uno más. Oh, en realidad, tal vez dos más. ¿Alguna vez pensaste en contribuir a la documentación de React? Sí. Así que contribuí a la documentación de React una vez, porque habían usado timeout-ms. Eso fue para una API de suspense muy, muy antigua. Pero pensé, espera un minuto, solo dice usar timeouts en la documentación. Podría agregar ese pequeño ms al lado. Esa fue mi primera contribución a React, porque su código fuente real bien podría ser cerrado. Hay desplazamiento de bits y todas estas cosas extrañas de fibra. Y pienso, eso es muy inaccesible para cualquier desarrollador que no trabaje en Meta y probablemente la mayoría de los desarrolladores que trabajan en Meta. Es comprensible.

Y finalmente, excelente charla. ¿Se publicarán tus diapositivas en línea, ahora o más tarde? Sí. Genial. Sigue a David en Twitter en David K. Piano. David K. Piano. Gracias, David. Gracias. Por favor, un aplauso para David.