UX Asincrónico

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

"Por favor, no cierre ni abandone esta página" puede enviar escalofríos por tu espalda, pero codificar el flujo UX adecuado para async podría hacerte cuestionar tu trabajo diario. ¿Cómo podemos manejar adecuadamente el UX para el código asincrónico en aplicaciones altamente responsivas? Vamos a explorar cómo la introducción de código asincrónico crea un desafío para el UX.

This talk has been presented at React Advanced 2021, check out the latest edition of this React Conference.

FAQ

La UX asíncrona en React se refiere a cómo se maneja la experiencia de usuario en circunstancias donde las operaciones, como la carga de datos, no ocurren de manera instantánea. Este enfoque es crucial en aplicaciones de una sola página donde el manejo de estados y la carga de datos pueden no sincronizarse inmediatamente con la UI, requiriendo técnicas como indicadores de progreso y UIs esqueleto para mejorar la experiencia del usuario mientras espera.

Para mejorar la experiencia de usuario durante cargas lentas se pueden utilizar indicadores de progreso que informen al usuario que la operación está en curso. Además, utilizar una UI esqueleto puede ayudar a mantener una sensación de actividad al mostrar la estructura básica de los datos que se cargarán, reduciendo el efecto de parpadeo y proporcionando una transición más suave una vez que los datos se cargan completamente.

En una aplicación de una sola página, manejar estados asíncronos puede llevar a condiciones de carrera, donde múltiples solicitudes pueden interferir entre sí, y problemas de memoria si los componentes se desmontan antes de que las operaciones asíncronas concluyan. También pueden surgir inconsistencias si las respuestas del servidor no se manejan adecuadamente durante o después de la navegación entre diferentes vistas o componentes.

Los estados de UI esqueleto son un método de diseño para mejorar la experiencia de usuario mostrando una versión preliminar de la página mientras los datos se están cargando. Esta técnica implica mostrar la estructura básica de la página, como encabezados y cajas de contenido vacías, que eventualmente se llenarán con los datos reales. Sin embargo, su implementación puede ser compleja y debe sincronizarse cuidadosamente con los datos reales para evitar desincronizaciones.

Manejar errores de backend en aplicaciones asíncronas requiere una buena gestión de errores que informe al usuario sobre qué falló y qué acciones puede tomar. Para estados vacíos, es importante comunicar claramente que no hay datos disponibles y ofrecer acciones relevantes que el usuario pueda realizar, como reintentar la carga o realizar diferentes búsquedas.

Una clave de idempotencia es un identificador único utilizado para prevenir la repetición de una operación en el servidor en caso de solicitudes duplicadas. Esta práctica es especialmente útil en transacciones importantes como pagos o reservaciones, donde enviar la misma operación más de una vez podría tener efectos indeseados. La clave asegura que, sin importar cuántas veces se envíe la solicitud, la operación solo se ejecutará una vez.

Toni Petrina
Toni Petrina
21 min
25 Oct, 2021

Comments

Sign in or register to post your comment.
Video Summary and Transcription
La charla de hoy cubre la importancia de construir UX Asincrónico con React y aplicaciones de una sola página, proporcionando ejemplos de código y UX. Explora la obtención de datos, la adición de indicadores de progreso, el manejo de errores y las acciones iniciadas por el usuario. La charla también discute el manejo de desmontajes de componentes, múltiples acciones, idempotencia y pérdida de contexto. Finalmente, toca las consideraciones para las actualizaciones optimistas y el uso de CRDT u otras tecnologías para aplicaciones colaborativas.
Available in English: Asynchronous UX

1. Introducción a la UX asíncrona

Short description:

Hoy, hablaré sobre la UX asíncrona con React y las aplicaciones de una sola página. Cubriré los escenarios que encontrarás en tu trabajo diario y proporcionaré ejemplos de código y ejemplos de UX. La clave es la importancia de construir este tipo de UX para los usuarios y el costo de desarrollo.

Hola, gracias por unirte a la sesión de hoy. Mi nombre es Tony y hoy te hablaré sobre la UX asíncrona con React y las aplicaciones de una sola página. Cuando decimos que la web es asíncrona, nos referimos a la naturaleza subyacente de solicitud-respuesta de la web, donde una respuesta del servidor puede tardar un tiempo en llegar. Tradicionalmente, las aplicaciones construidas con la renderización del lado del servidor en mente eran manejadas por el navegador. Cuando construimos la misma aplicación como una aplicación de una sola página, tenemos que construir nuevas asequibilidades para el usuario porque el navegador no puede manejarlas por nosotros. En la sesión de hoy, voy a repasar ciertos escenarios que encontrarás en tu trabajo diario y trataré de abordarlos con ejemplos de code y ejemplos de UX. Al final de la charla, espero que te lleves la idea de que es muy importante construir este tipo de UX para los usuarios y cuánto costará en términos de desarrollo.

2. Explorando la Obtención de Datos y UX

Short description:

Antes de comenzar, dividamos este tema en dos áreas: parches de datos de solo lectura y acciones iniciadas por el usuario que cambian el estado del servidor. Al navegar por la página, la obtención de datos puede llevar algún tiempo. Para mejorar la UX, podemos agregar una barra de progreso o emplear UX esqueleto. Construir una UX más consistente puede ser complejo, especialmente cuando varios componentes tienen sus propios indicadores de progreso. Para evitar efectos de parpadeo, podemos introducir un retraso antes de mostrar el indicador de progreso. Veamos un ejemplo ingenuo de código para una página y exploremos cómo se puede mejorar.

Antes de comenzar, solo quiero dividir todo este tema en dos áreas diferentes. La primera área trata sobre parches de data de solo lectura, y la segunda área son acciones iniciadas por el usuario que cambian el estado del servidor, básicamente haciendo envíos de formularios mientras las consultas son navegaciones de página.

Hablemos de consultas. Entonces, cada vez que navegas por la página, podrías obtener algunos data. En este ejemplo ingenuo, cuando navegamos a una página, obtendremos los data y luego los mostraremos al usuario. Este es un escenario feliz donde los data llegan bastante rápido, pero dependiendo de la red carga, la carga del servidor, o los data del usuario, esperar a que lleguen los data podría llevar algún tiempo. Mientras el usuario está esperando, queremos informarles que tienen que esperar en caso de que no haya resultados. Queremos decirles que no hay resultados. Si hay un error, queremos decirles que hubo un error y qué pueden hacer al respecto. Entonces, para mejorar esta UX un poco, queremos agregar una simple barra de progreso. Este progreso es indeterminado porque no sabemos cuándo terminará, y el usuario podría querer quedarse y esperar a que lleguen los data. Para mejorar este indicador de progreso muy simple, podríamos querer emplear UX esqueleto. Ahora, UX esqueleto parece que los data van a reemplazar. Básicamente, esto detiene el efecto de parpadeo, porque los usuarios verán el contorno de los data entrantes, y luego cuando los data llegan, básicamente solo reemplazan esperemos que en su lugar. A diferencia del indicador de progreso, UX esqueleto es mucho, mucho más difícil de construir y puede rápidamente desincronizarse con los componentes que intentan imitar. Así que ten cuidado con las complejidades involucradas en su construcción.

Para una página un poco más complicada, puedes ver que cuando los data están ahí, podrías querer tener actualizaciones parciales con la obtención de más data. Podrías querer tener diferentes formas de obtener data que podrían producir diferentes tamaños de data. Entonces, en este caso, podemos ver que a veces obtienes poco data, a veces no obtienes data, a veces obtienes un error. Y cuando tienes obtención de data, quieres reutilizar esta UX. Como puedes ver, construir una UX más consistente requiere algo de explicación, y puedes imaginar cuánto más complicado podría ser el code. Cuando construimos componentes en nuestras aplicaciones, podríamos querer enfocarnos demasiado en un solo componente, por lo que cada componente tiene su propia obtención de data y su propio indicador de progreso. Lo que puede suceder es que podemos terminar rápidamente en una situación donde varios componentes en la misma pantalla tienen sus propios indicadores de progreso, y luego tenemos este efecto de parpadeo ya que diferentes componentes tienen data llegando en un orden diferente. Además, cuando tenemos servidores muy rápidos, puede ser molesto debido al efecto de parpadeo porque los data llegarán muy rápido y luego los usuarios verán el indicador de progreso solo por un breve tiempo. Entonces, para mejorar esa experiencia, podríamos querer introducir algún tipo de retraso antes de mostrar el indicador de progreso, por lo que solo mostramos el indicador de progreso cuando los data tardan mucho tiempo en llegar.

Echemos un vistazo a un ejemplo muy ingenuo de cómo se vería el code para una página. Independientemente de si usas React query o Apollo o algo similar, tu componente podría parecer algo así: obtienes data y lo muestras dentro de tu UI. Ahora, ¿podemos hacerlo mejor que esto? Por supuesto que podemos, pero requerirá trabajo adicional y requerirá un tipo diferente de trabajo. Entonces, veamos cuánto más complicado puede ser el code. En el lado izquierdo, podemos ver el ejemplo ingenuo de antes, y en el lado derecho seguiremos mejorándolo al manejar diferentes escenarios que hemos mostrado en las demostraciones anteriores.

3. Añadiendo Indicadores de Progreso y Manejando Errores

Short description:

Lo primero que debemos agregar es el indicador de progreso. Puede implementarse como un indicador de carga de nivel superior o en línea debajo del H1. Manejar errores, estados vacíos y cargadores de esqueleto puede mejorar enormemente la UX. Introducir un retraso y prevenir la visualización de múltiples indicadores de progreso son importantes. El manejo de errores de backend depende de la aplicación, incluyendo errores corregibles por el usuario, problemas de carga del servidor, fallos generales y problemas de conexión de red. Mejorar la UX para respuestas de larga duración también es crucial.

Entonces, lo primero que queremos agregar es el indicador de progreso. Ahora, eso es bastante sencillo, simplemente tenemos algún tipo de indicador que dice que, sí, se está realizando la carga, en cuyo caso mostramos la UI de carga. Ahora, ya puedes ver que esto se puede hacer de dos maneras diferentes, ya sea como un indicador de carga de nivel superior o puedes ponerlo en línea debajo del H1 y así tener un indicador de carga un poco más intrusivo. Tus opiniones influirán en la forma en que implementes esto. Si queremos manejar errores, tenemos que agregar aún más code, y puedes ver que la visualización del error también puede cambiar de ubicación y ser un poco más intrusiva, lo que hace que este patrón sea más difícil de extraer en un componente de orden superior.

También puedes manejar, por ejemplo, el estado vacío, que, como puedes ver, se vuelve un poco más intrusivo en la estructura general de la página. Entonces, como puedes ver, agregar soporte para muchos escenarios de UX tendrá un impacto diferente en tu code. Y a veces será difícil entrecerrar los ojos y ver cómo podemos realmente aislar esto en un componente de orden superior que pueda ser reutilizable en toda la aplicación. Siempre hay más que podemos agregar a la página que puede mejorar la UX. Los estados vacíos generalmente mejoran las situaciones en las que la aplicación es completamente nueva para el usuario, básicamente no tienen data, o cuando están, por ejemplo, buscando cosas que no existen. Entonces, en este caso, queremos mostrar siempre los resultados al usuario, o decirles que no hay resultados. Eso mejora enormemente la UX.

Los cargadores de esqueleto son una UX mucho mejor que los simples indicadores de progreso, pero requieren un poco más de tiempo de desarrollo, pueden desincronizarse rápidamente con el objetivo UI que van a reemplazar. Así que ten especial cuidado al introducir UIs de esqueleto debido a las complejidades que traen. Los indicadores de progreso, de nuevo, solo un booleano ingenuo, no mostrar, puede no ser suficiente. Entonces, queremos introducir algún tipo de retraso para prevenir el efecto de parpadeo. Y también queremos prevenir este bosque de indicadores de progreso, y solo mantener los indicadores para algo que es realmente, realmente lento. Realmente no hemos hablado mucho sobre cómo manejar los errores de backend, porque depende de la aplicación. Hay diferentes tipos de errores. Están los errores corregibles por el usuario, básicamente pueden hacer algo más. Está el reintento más tarde porque el servidor tiene una carga tremenda. Entonces, realmente no podemos manejar la solicitud en este momento. O puede haber un fallo general donde redirigimos al usuario para que use el soporte, y básicamente nos pregunte qué salió mal. También hay un caso especial sobre problemas de conexión de red. Por ejemplo, si estás en una zona urbana de alta densidad o te estás alejando, como en un túnel o simplemente en una parte rural del país, podrías perder la conexión o tener esto problemas de conexión intermitentes. En ese caso, la UI debe o debería manejar estos casos mostrando al usuario que en este momento los data no se pueden obtener y deberían actualizar la página completa o mostrar un botón donde pueden reintentar la obtención ellos mismos cuando la conexión se recupere. También podrías querer mejorar la UX para las respuestas de larga duración. A veces, esperar más de cinco segundos simplemente se verá mal para el usuario. No sabrán qué hacer. Podrían querer actualizar toda la página.

4. Manejo de Acciones Iniciadas por el Usuario y Efectos Secundarios

Short description:

No saben qué salió mal. En el área con efectos secundarios, queremos manejar las acciones iniciadas por el usuario e informar al usuario sobre el progreso de la acción y cualquier problema. También necesitamos considerar los efectos secundarios en la aplicación. Veamos una demostración de una UI receptiva donde un clic de botón desencadena una acción y proporciona retroalimentación. Sin embargo, hacer doble clic puede causar problemas y necesitamos manejarlos correctamente.

No saben qué salió mal. Por lo tanto, es posible que desees cambiar el mensaje de texto después de un tiempo o hacer diferentes tipos de mejoras.

Si observamos la segunda área, el área con efectos secundarios, queremos ver cómo manejar las acciones iniciadas por el usuario. Ahora, porque el usuario inició una acción, a diferencia de la navegación, quieren saber que la acción está siendo manejada. Quieren saber si la acción ha terminado de ser manejada, ¿hay algún problema?. En caso de un problema, ¿hay algo que el usuario pueda hacer o es simplemente un fallo general?

También queremos ver si hay efectos secundarios en esa aplicación porque dependiendo de lo que hizo el usuario, puede cambiar. Así que volvamos a ver algunas demostraciones. En este caso, vamos a ver un intento muy simple de construir una UI receptiva. Entonces, cuando haces clic en un botón, después de un tiempo obtienes un mensaje de éxito que dice que la acción se ha completado y el usuario puede continuar haciendo lo que estaba haciendo. Sin embargo, puedes ver que esta es una experiencia realmente triste porque el usuario puede hacer doble clic y luego no sabemos qué puede hacer el servidor en ese caso. Podríamos crear entradas dobles o algo similar.

5. Manejo de Errores e Idempotencia

Short description:

En el caso de un error, nunca se sabe cuál es la acción del error. Un botón que se comporta bien se desactiva para evitar la doble presentación, muestra un indicador de progreso e informa al usuario cuando la acción se ha realizado. Para mejorar la experiencia del usuario, podemos implementar una clave de idempotencia para evitar acciones duplicadas. Las aplicaciones de una sola página pueden causar efectos secundarios si el usuario se aleja antes de que se complete una acción.

En el caso de un error, nunca se sabe cuál es la acción del error. ¿Hemos configurado mal el manejador de clics? ¿Hubo una caída de la red? ¿El servidor respondió con un 500? No lo sabemos. Y queremos informar a nuestros usuarios de que algo ha ido mal. Un botón que se comporta bien, en este caso, se desactiva para evitar la doble presentación. También muestra un indicador de progreso. Y también cuando ha terminado, nos informa de que algo ha sucedido. Este es el ejemplo al que queremos aspirar.

Algunas aplicaciones, cuando estás haciendo cosas muy advanced, podrían querer decirte que por favor no abandones esta página. Por favor, espera hasta que la operación esté terminada. Esto podría llevar algún tiempo. Nunca se sabe cuánto. En un escenario feliz, esto llevará un segundo y ya está. Sin embargo, si esta página se queda en marcha, el usuario podría estar confundido o preocupado. Y no están realmente seguros de si deberían abandonar la página, qué pasa si la refrescan. Y eso puede dar lugar a experiencias de usuario inferiores.

Ahora, porque este es un ejemplo de reserva de entradas conocido por todos, queremos ver qué podemos hacer para mejorar la user experience. Así que echemos un vistazo a este botón. Digamos que tarda mucho tiempo en ejecutarse y durante este tiempo algo está sucediendo en el servidor. Después de un tiempo, el resultado vuelve y lo reservamos. Ahora voy a hacer algo diferente. Voy a hacer clic en un botón y a refrescar la página. Esto es básicamente destruir el contexto. Cuando volvemos a la página y hacemos clic en el mismo botón, se hace casi inmediatamente porque la respuesta del servidor, sí, la operación que solicitaste fue realmente realizada antes y este es el resultado que habría enviado la vez anterior.

¿Cómo haríamos algo así? La idea es muy simple, un poco más difícil de ejecutar para acciones tan importantes que realmente no deberían suceder dos veces. Implementamos algo llamado clave de idempotencia. Básicamente, generamos una clave aleatoria, la asignamos a la acción y luego recordamos esta clave en el almacenamiento local y cuando enviamos la solicitud al servidor, enviamos la misma clave. En las solicitudes subsiguientes, el servidor duplicará la solicitud y responderá con la respuesta anterior, evitando así realizar la misma operación dos veces. Esto es muy importante si quieres manejar, por ejemplo, pagos o cualquier tipo de recursos limitados en el mundo real porque no quieres hacerlo dos veces. No quieres pedir dos cosas o pagar por la misma cosa dos veces.

Ahora, porque las aplicaciones de una sola página no están construidas de la misma manera que las renderizaciones del lado del servidor, lo que puede suceder es que cuando realizas una acción en una pantalla y si tarda demasiado el usuario puede abandonar e ir a otra página y luego cuando la acción se completa, la respuesta llegará y pueden suceder efectos secundarios que potencialmente causarán errores.

6. Manejo de Desmontajes de Componentes y Efectos Secundarios

Short description:

Cuando hacemos clic en un botón y luego nos vamos a una página diferente, todavía podemos ver la misma alerta. Sin embargo, si intentamos modificar la UI de React, obtendremos una advertencia sobre una fuga de memoria. Para manejar esto, necesitamos recordar cuándo se desmonta un componente y evitar realizar efectos secundarios.

Entonces, echemos un vistazo a este ejemplo. Cuando hacemos clic en este botón, se dirá que se ha completado una acción. Si hacemos clic y luego nos vamos a una página diferente porque nada nos impide irnos, todavía podemos ver que tenemos la misma alerta. Ahora, esto es solo ilustrativo. Si intentamos hacer algo como establecer un estado o intentar modificar la UI de React, en realidad obtendremos la advertencia en la console diciendo que tenemos una fuga de memoria. No deberíamos hacer nada porque el componente ha sido desmontado. Para manejar esto correctamente, necesitamos recordar que cuando se desmonta un componente, en realidad queremos saber que el componente fue desmontado y en realidad no realizar los efectos secundarios. Esto es solo ilustrativo diciendo que, sí, entendemos que este componente sabe que ha sido desmontado y, por lo tanto, en realidad no debería realizar los efectos secundarios.

7. Manejo de Múltiples Acciones y UX

Short description:

Una última cosa a considerar en las aplicaciones ricas del lado del cliente es el manejo de múltiples acciones en la misma pantalla. Es importante ignorar las solicitudes anteriores y solo tener en cuenta la última solicitud enviada. Agregar código para mejorar la experiencia del usuario puede volverse intrusivo, especialmente al manejar errores. La validación a nivel de campo, el bloqueo de la entrada mientras se espera, y el manejo de problemas de red son consideraciones importantes. Las acciones de bloqueo evitan que los usuarios se vayan, mientras que las acciones no bloqueantes muestran toasts cuando se completan. Tener un centro de notificaciones y prevenir dobles envíos también son buenas prácticas.

Una última cosa que puede suceder con aplicaciones muy ricas del lado del cliente es que cuando tienes una serie de acciones en la misma pantalla, que se renderizan en la misma UI pero pueden tomar un tiempo diferente para responder desde el servidor. Por ejemplo, filtrar data puede tener diferentes tiempos de respuesta dependiendo de cuánta data necesita ser procesada en el servidor. Si el usuario hace clic en muchos lugares diferentes, puedes ver que las respuestas salen de no mostramos el resultado de la última acción en la que se hizo clic, en realidad mostramos el último resultado que llegó, que podría ser el que se envió antes. Por lo tanto, se debe tener especial cuidado para básicamente ignorar todas las solicitudes anteriores y solo tener en cuenta la última solicitud enviada.

Echemos un vistazo a parte del code. Así que en el lado izquierdo voy a mantener la implementación muy simple, muy directa de un manejo de envío. Y en el lado derecho voy a agregar más code para mejorar la UX y veremos cuánto más grande se vuelve el code y cuánto más intrusiva se vuelve esta UX. Así que lo primero, vamos a agregar un estado para si estamos enviando o no. Como puedes ver, necesitamos una variable de estado, necesitamos manejarla correctamente cuando comienza, cuando se detiene. Necesitamos mostrar la UI que muestra que se está realizando la acción. Y luego también queremos deshabilitar el botón. Si queremos manejar errores se vuelve aún más intrusivo porque estamos tocando ya code tocado y puedes ver que la UI también está siendo cambiada de una manera muy en línea. Es realmente difícil aislar esto en un componente de nivel superior.

Y como antes, siempre hay más que podemos agregar. Podemos agregar validation a nivel de campo donde realmente le decimos al usuario que algunos campos estaban mal, pueden llenarlos. O podemos decirles que, no, hay algo que hiciste mal, es el error del lado del servidor. Podemos bloquear la entrada mientras esperamos porque queremos evitar que editen los campos. Queremos manejar problemas de red. Esto es muy importante en caso de que se haya hecho mucho trabajo. Y si de alguna manera perdieron el trabajo, será malo para el usuario. Podríamos guardar los valores. Si es un modelo, podríamos querer considerar mientras esperamos una respuesta, ¿permitimos irnos y muchas otras cosas? Generalmente queremos pensar en acciones de bloqueo versus acciones no bloqueantes. Los bloqueos son las acciones que te impiden irte. Porque tus acciones después de esta dependen de que esta tenga éxito. También hay acciones no bloqueantes, también llamadas de fuego y olvido. En esos casos, solo queremos mostrar toasts cuando la acción se completa. Siempre considera tener un centro de notificaciones o algo donde el usuario pueda buscar las acciones realizadas anteriormente. En general, queremos prevenir dobles envíos. La solución simple es simplemente deshabilitar los botones de acción.

8. Manejo de la Idempotencia y la Pérdida de Contexto

Short description:

Queremos usar la idempotencia para escenarios importantes como las reservas o los pagos. El manejo de los problemas de red implica reintentar las solicitudes fallidas e informar al usuario a través de correo electrónico o SMS. La idempotencia permite el reintentar de forma segura las acciones. La pérdida de contexto ocurre cuando se navega a través de la aplicación, y necesitamos manejar el desmontaje de componentes y las condiciones de carrera para prevenir un extraño renderizado de la UI.

Básicamente, queremos hacer clic dos veces. Sin embargo, eso no siempre es bueno. Si se actualiza la página, se puede hacer clic de nuevo en el botón. La solución advanced es usar la idempotencia. Realmente queremos usarla para escenarios realmente importantes, como las reservas o los pagos. Requieren un trabajo adicional en el lado del servidor, pero darán la mejor respuesta para el usuario y para la UX.

Los problemas de red, como mencionamos antes, queremos manejar los problemas de red de dos formas diferentes. Podría haber un problema de salida, básicamente, no pudimos enviar la solicitud al servidor, por lo que falló, así que pueden intentarlo de nuevo. O en realidad, enviamos la solicitud, sin embargo, mientras el servidor recibió la solicitud, mientras la respuesta estaba volviendo o mientras esperábamos, mientras tanto, la red tuvo algunos problemas. En ese caso, el servidor aún procesa nuestra solicitud, y el usuario puede volver a intentarlo y así entrar en un estado inconsistente, básicamente haciendo la misma acción dos veces. Queremos ver si podemos informar al usuario de alguna otra manera, como usando un centro de notificaciones por correo electrónico o SMS, que la acción se ha completado. Como antes, la idempotencia en las acciones permite un reintentar seguro, porque puedes enviar la misma solicitud dos veces, y el servidor no hará el mismo trabajo dos veces. Esto requiere idempotencia, no se puede hacer solo analizando la solicitud, porque a veces es válido hacer lo mismo con los mismos data.

La pérdida de contexto es la situación en la que podemos navegar a través de la aplicación, y luego cuando la operación tiene éxito, algo malo podría suceder. Tengo algunos enlaces aquí que querrás tener en cuenta al investigar este tema. Echemos un vistazo a una forma sencilla de manejar si el componente está montado o no. Este es un hook muy simple que te dirá si el componente ha sido desmontado. Podemos usarlo de una manera muy directa simplemente comprobando si el componente ha sido desmontado. Este es un manejador de clics. Si tenemos useEffect, se vuelve un poco más complicado porque podemos hacerlo de tres formas diferentes. Podemos dividir el trabajo en la parte disponible, y luego hacerlo cancelable, y luego manejarlo en caché, básicamente por separado. Como puedes ver, la lógica se divide y esta no es una solución realmente buena. Esto se puede hacer y usamos el método unsubscribed para detener la acción asíncrona. Otra forma es usar, de nuevo, el hook isMounted para saber si el componente ha sido desmontado, básicamente regresar de la función importa el procesamiento subsiguiente. La tercera forma es usar algo que se llama cancelación cooperativa, inspirada en C-sharp. Este code muestra cómo uno crearía un token en el efecto mismo y luego lo cancelaría en la parte unsubscribed. La función asíncrona después de cada llamada await debe verificar si se solicitó la cancelación. Básicamente después de la llamada await, el componente podría estar desmontado y no lo sabemos, así que tenemos que verificar. Otra cosa que queremos manejar son las condiciones de carrera como se muestra en la demo. Si reutilizamos la UI después de las acciones, dependiendo del orden en que lleguen, esto podría renderizar una UI muy extraña.

9. Consideraciones para Actualizaciones Optimistas

Short description:

Una última cosa a considerar son las actualizaciones optimistas, donde pretendemos que una acción tuvo éxito inmediatamente para hacer que la UI sea receptiva. Sin embargo, esto puede llevar a inconsistencias si las acciones posteriores encuentran errores. En tales casos, considere CRDT u otras tecnologías para aplicaciones colaborativas.

Una última cosa antes de terminar son las actualizaciones optimistas. Es muy común en estos días tener una caché del lado del cliente y básicamente al iniciar una acción, en realidad pretendemos que la acción tuvo éxito inmediatamente para que la UI parezca muy receptiva y luego básicamente nos sincronizamos con el servidor. Por favor, tenga en cuenta que esto podría llevar a situaciones muy malas si hay acciones posteriores que el usuario toma, porque si hay problemas de red o cualquier otro tipo de errores. Si no lo manejas correctamente en la UI, puede volverse bastante inconsistente bastante rápido. En ese caso, considere CRDT u otras tecnologías si está construyendo, por ejemplo, aplicaciones colaborativas. Entonces, para resumir, manejar el código asíncrono requiere cambios no triviales en nuestra base de código. Es algo intrusivo y a veces muy difícil de hacer componentes más difíciles. Sin embargo, si lo hacemos correctamente, los usuarios estarán encantados. La aplicación simplemente parecerá pulida y el aspecto y sensación serán increíbles y los usuarios estarán muy contentos con la aplicación. Entonces, con esto, he dicho todo lo que quería. Quiero agradecerles por su atención. Si quieren ver las diapositivas, este es el enlace donde pueden verlas. Si quieren contactarme, este es el lugar donde pueden encontrarme. Además, quédense para verme en el Spatial Chat. Si quieren tener una rápida Q&A, disfruten el resto de la conferencia y feliz codificación. Gracias.

Available in other languages:

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

No resuelvas problemas, elimínalos
React Advanced 2021React Advanced 2021
39 min
No resuelvas problemas, elimínalos
Top Content
Kent C. Dodds discusses the concept of problem elimination rather than just problem-solving. He introduces the idea of a problem tree and the importance of avoiding creating solutions prematurely. Kent uses examples like Tesla's electric engine and Remix framework to illustrate the benefits of problem elimination. He emphasizes the value of trade-offs and taking the easier path, as well as the need to constantly re-evaluate and change approaches to eliminate problems.
Los Átomos de Jotai Son Simplemente Funciones
React Day Berlin 2022React Day Berlin 2022
22 min
Los Átomos de Jotai Son Simplemente Funciones
Top Content
State management in React is a highly discussed topic with many libraries and solutions. Jotai is a new library based on atoms, which represent pieces of state. Atoms in Jotai are used to define state without holding values and can be used for global, semi-global, or local states. Jotai atoms are reusable definitions that are independent from React and can be used without React in an experimental library called Jotajsx.
Depuración de JS
React Summit 2023React Summit 2023
24 min
Depuración de JS
Top Content
Debugging JavaScript is a crucial skill that is often overlooked in the industry. It is important to understand the problem, reproduce the issue, and identify the root cause. Having a variety of debugging tools and techniques, such as console methods and graphical debuggers, is beneficial. Replay is a time-traveling debugger for JavaScript that allows users to record and inspect bugs. It works with Redux, plain React, and even minified code with the help of source maps.
El Epic Stack
React Summit US 2023React Summit US 2023
21 min
El Epic Stack
Top Content
This Talk introduces the Epic Stack, a project starter and reference for modern web development. It emphasizes that the choice of tools is not as important as we think and that any tool can be fine. The Epic Stack aims to provide a limited set of services and common use cases, with a focus on adaptability and ease of swapping out tools. It incorporates technologies like Remix, React, Fly to I.O, Grafana, and Sentry. The Epic Web Dev offers free materials and workshops to gain a solid understanding of the Epic Stack.
Una Mirada al Futuro del Desarrollo Web en 2025
JSNation US 2024JSNation US 2024
32 min
Una Mirada al Futuro del Desarrollo Web en 2025
Top Content
Today, Wes Boss introduces the new features of the web, including customizable select and temporal, a standardized API for working with dates, time, and duration. The current date API in JavaScript has some problems related to time zones and date manipulation. With the temporal API, you can create dates without a time zone, specify dates without a year, and create durations without being attached to a specific date. The API also provides features for finding the difference between two dates. Invokers is a declarative click handlers API that eliminates the need for JavaScript. Speculation API enables pre-rendering and pre-loading of pages, improving performance. The CSS Anchor API allows positioning elements based on another element's location. Web components are encapsulated, framework-agnostic, and easy to use, offering a standardized approach for building reusable UI components. Building media UI components, like video players, is made easier with web components like Shoelace. Transformers JS allows running AI models in JavaScript for tasks like emotion detection and background removal. Python doesn't run in the browser, but JavaScript does. Small AI models can be loaded and executed faster in the browser using technologies like WebGPU. Animate height auto transition using calc size. Apply starting styles to elements for smooth animations. Use Vue transition for CSS and JavaScript animations. Syntax website with Vue transition for smooth page transitions. CSS relative colors allow for lighter or darker shades. Scope CSS ensures styles only apply to specified div containers. Web primitives facilitate modern JavaScript code. You can create web requests and receive web responses using the same primitives on both the client and server. There are many new web standards that work everywhere and frameworks like Hano and Nitro are built upon them. The select and Popover elements are accessible by default. Most of the discussed features will be available in all browsers by 2025. The future of web development with AI is uncertain, but web developers should embrace AI tools to improve efficiency. Implicit CSS lazy loading depends on whether it's prefetching or pre-rendering. Wes Boss discusses the specific features he is excited about in web development, including starting style, calc auto, and allowed discrete. He shares his preferred way of staying informed on new web development discoveries, emphasizing the importance of being part of the community and keeping up with industry discussions. Wes also mentions reading W3C meeting notes and recommends following the Twitter account Intent2Ship to stay updated on upcoming CSS features. Lastly, he discusses the potential impact of the new Scope CSS feature on developers' management of styles.
Luchando contra la Deuda Técnica con la Refactorización Continua
React Day Berlin 2022React Day Berlin 2022
29 min
Luchando contra la Deuda Técnica con la Refactorización Continua
Top Content
This Talk discusses the importance of refactoring in software development and engineering. It introduces a framework called the three pillars of refactoring: practices, inventory, and process. The Talk emphasizes the need for clear practices, understanding of technical debt, and a well-defined process for successful refactoring. It also highlights the importance of visibility, reward, and resilience in the refactoring process. The Talk concludes by discussing the role of ownership, management, and prioritization in managing technical debt and refactoring efforts.

Workshops on related topic

React, TypeScript y TDD
React Advanced 2021React Advanced 2021
174 min
React, TypeScript y TDD
Top Content
Featured Workshop
Paul Everitt
Paul Everitt
ReactJS es extremadamente popular y, por lo tanto, ampliamente soportado. TypeScript está ganando popularidad y, por lo tanto, cada vez más soportado.

¿Los dos juntos? No tanto. Dado que ambos cambian rápidamente, es difícil encontrar materiales de aprendizaje precisos.

¿React+TypeScript, con los IDEs de JetBrains? Esa combinación de tres partes es el tema de esta serie. Mostraremos un poco sobre mucho. Es decir, los pasos clave para ser productivo, en el IDE, para proyectos de React utilizando TypeScript. En el camino, mostraremos el desarrollo guiado por pruebas y enfatizaremos consejos y trucos en el IDE.
Masterclass Web3 - Construyendo Tu Primer Dapp
React Advanced 2021React Advanced 2021
145 min
Masterclass Web3 - Construyendo Tu Primer Dapp
Top Content
Featured Workshop
Nader Dabit
Nader Dabit
En esta masterclass, aprenderás cómo construir tu primer dapp de pila completa en la blockchain de Ethereum, leyendo y escribiendo datos en la red, y conectando una aplicación de front end al contrato que has desplegado. Al final de la masterclass, entenderás cómo configurar un entorno de desarrollo de pila completa, ejecutar un nodo local e interactuar con cualquier contrato inteligente usando React, HardHat y Ethers.js.
Fundamentos de Remix
React Summit 2022React Summit 2022
136 min
Fundamentos de Remix
Top Content
Workshop
Kent C. Dodds
Kent C. Dodds
Construir aplicaciones web modernas está lleno de complejidad. Y eso solo si te molestas en lidiar con los problemas
¿Cansado de conectar onSubmit a las API del backend y asegurarte de que tu caché del lado del cliente se mantenga actualizada? ¿No sería genial poder utilizar la naturaleza global de CSS en tu beneficio, en lugar de buscar herramientas o convenciones para evitarla o trabajar alrededor de ella? ¿Y qué te parecería tener diseños anidados con una gestión de datos inteligente y optimizada para el rendimiento que simplemente funciona™?
Remix resuelve algunos de estos problemas y elimina completamente el resto. Ni siquiera tienes que pensar en la gestión de la caché del servidor o en los conflictos del espacio de nombres global de CSS. No es que Remix tenga APIs para evitar estos problemas, simplemente no existen cuando estás usando Remix. Ah, y no necesitas ese enorme y complejo cliente graphql cuando estás usando Remix. Ellos te tienen cubierto. ¿Listo para construir aplicaciones más rápidas de manera más rápida?
Al final de esta masterclass, sabrás cómo:- Crear Rutas de Remix- Estilizar aplicaciones de Remix- Cargar datos en los cargadores de Remix- Mutar datos con formularios y acciones
Vue3: Desarrollo Moderno de Aplicaciones Frontend
Vue.js London Live 2021Vue.js London Live 2021
169 min
Vue3: Desarrollo Moderno de Aplicaciones Frontend
Top Content
Workshop
Mikhail Kuznetsov
Mikhail Kuznetsov
Vue3 fue lanzado a mediados de 2020. Además de muchas mejoras y optimizaciones, la principal característica que trae Vue3 es la API de Composición, una nueva forma de escribir y reutilizar código reactivo. Aprendamos más sobre cómo usar la API de Composición de manera eficiente.

Además de las características principales de Vue3, explicaremos ejemplos de cómo usar bibliotecas populares con Vue3.

Tabla de contenidos:
- Introducción a Vue3
- API de Composición
- Bibliotecas principales
- Ecosistema Vue3

Requisitos previos:
IDE de elección (Inellij o VSC) instalado
Nodejs + NPM
Desarrollando Blogs Dinámicos con SvelteKit & Storyblok: Una Masterclass Práctica
JSNation 2023JSNation 2023
174 min
Desarrollando Blogs Dinámicos con SvelteKit & Storyblok: Una Masterclass Práctica
Top Content
WorkshopFree
Alba Silvente Fuentes
Roberto Butti
2 authors
Esta masterclass de SvelteKit explora la integración de servicios de terceros, como Storyblok, en un proyecto SvelteKit. Los participantes aprenderán cómo crear un proyecto SvelteKit, aprovechar los componentes de Svelte y conectarse a APIs externas. La masterclass cubre conceptos importantes incluyendo SSR, CSR, generación de sitios estáticos y despliegue de la aplicación usando adaptadores. Al final de la masterclass, los asistentes tendrán una sólida comprensión de la construcción de aplicaciones SvelteKit con integraciones de API y estarán preparados para el despliegue.
De 0 a Autenticación en una hora con ReactJS
React Summit 2023React Summit 2023
56 min
De 0 a Autenticación en una hora con ReactJS
WorkshopFree
Kevin Gao
Kevin Gao
La autenticación sin contraseña puede parecer compleja, pero es simple de agregar a cualquier aplicación utilizando la herramienta adecuada. Hay múltiples alternativas que son mucho mejores que las contraseñas para identificar y autenticar a tus usuarios, incluyendo SSO, SAML, OAuth, Magic Links, One-Time Passwords y Authenticator Apps.
Mientras abordamos los aspectos de seguridad y evitamos errores comunes, mejoraremos una aplicación JS de pila completa (backend Node.js + frontend React) para autenticar a los usuarios con OAuth (inicio de sesión social) y One Time Passwords (correo electrónico), incluyendo:- Autenticación de usuarios - Gestión de interacciones de usuarios, devolviendo JWTs de sesión / actualización- Gestión y validación de sesiones - Almacenamiento seguro de la sesión para solicitudes de cliente posteriores, validación / actualización de sesiones- Autorización básica - extracción y validación de reclamaciones del token JWT de sesión y manejo de autorización en flujos del backend
Al final del masterclass, también exploraremos otros enfoques de implementación de autenticación con Descope, utilizando SDKs de frontend o backend.