Experiencia de usuario asincrónica

Rate this content
Bookmark

"Por favor, no cierres ni abandones esta página" puede causar escalofríos, pero codificar el flujo de UX adecuado para lo asincrónico puede hacer que cuestiones tu trabajo diario. ¿Cómo podemos manejar correctamente la UX para el código asincrónico en aplicaciones altamente receptivas? Vamos a explorar cómo la introducción de código asincrónico crea un desafío para la UX.

21 min
25 Oct, 2021

Comments

Sign in or register to post your comment.

Video Summary and Transcription

La charla de hoy aborda la importancia de construir una experiencia de usuario asincrónica 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. Por último, se mencionan consideraciones para actualizaciones optimistas y el uso de CRDT u otras tecnologías para aplicaciones colaborativas.

Available in English

1. Introducción a la Experiencia de Usuario Asincrónica

Short description:

Hoy hablaré sobre la Experiencia de Usuario Asincrónica con React y aplicaciones de una sola página. Cubriré escenarios que encontrarás en tu trabajo diario y proporcionaré ejemplos de código y ejemplos de UX. El mensaje 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 Experiencia de Usuario Asincrónica con React y aplicaciones de una sola página. Cuando decimos que la web es asincrónica, nos referimos a la naturaleza subyacente de solicitud-respuesta de la web, donde una respuesta del servidor puede tardar en llegar. Tradicionalmente, las aplicaciones construidas teniendo en cuenta el renderizado del lado del servidor eran manejadas por el navegador. Cuando construimos la misma aplicación como una aplicación de una sola página, tenemos que crear nuevas funcionalidades para el usuario porque el navegador no puede manejarlas por nosotros. En la sesión de hoy, repasaré ciertos escenarios que encontrarás en tu trabajo diario y trataré de abordarlos con ejemplos de código 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 la Experiencia de Usuario

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, obtener datos puede llevar tiempo. Para mejorar la experiencia de usuario, podemos agregar una barra de progreso o utilizar una interfaz de usuario de esqueleto. Construir una experiencia de usuario más consistente puede ser complejo, especialmente cuando varios componentes tienen sus propios indicadores de proxy. 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 este tema en dos áreas diferentes. La primera área se ocupa de los parches de datos de solo lectura, y la segunda área son acciones iniciadas por el usuario que cambian el estado del servidor, básicamente realizando envíos de formularios mientras se realizan las consultas durante las navegaciones de página.

Hablemos de las consultas. Cada vez que navegas por la página, es posible que obtengas algunos datos. En este ejemplo ingenuo, cuando navegamos a una página, obtendremos los datos y luego los mostraremos al usuario. Este es un escenario ideal donde los datos llegan bastante rápido, pero dependiendo de la carga de la red, la carga del servidor o los datos del usuario, esperar a que lleguen los datos puede llevar tiempo. Mientras el usuario espera, queremos informarles que deben 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. Para mejorar esta experiencia de usuario, queremos agregar una barra de progreso simple. Este progreso es indeterminado porque no sabemos cuándo terminará, y el usuario puede querer esperar a que lleguen los datos. Para mejorar este indicador de progreso muy simple, es posible que deseemos utilizar una interfaz de usuario de esqueleto. Ahora, la interfaz de usuario de esqueleto parece que los datos se van a reemplazar. Básicamente, esto evita que ocurra el efecto de parpadeo, ya que los usuarios verán el contorno de los datos entrantes y luego, cuando lleguen los datos, se reemplazarán, con suerte, en su lugar. A diferencia del indicador de progreso, la interfaz de usuario de esqueleto es mucho más difícil de construir y puede desincronizarse rápidamente con los componentes que intenta 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 datos están ahí, es posible que desees tener actualizaciones parciales con la obtención de más datos. Es posible que desees tener diferentes formas de obtener datos que puedan producir diferentes tamaños de datos. En este caso, podemos ver que a veces obtienes pocos datos, a veces no obtienes datos y a veces obtienes un error. Y cuando tienes la obtención de datos, es posible que desees reutilizar esta experiencia de usuario. Como puedes ver, construir una experiencia de usuario más consistente requiere cierta explicación, y puedes imaginar lo complicado que puede ser el código. Cuando construimos componentes en nuestras aplicaciones, es posible que nos centremos demasiado en un solo componente, por lo que cada componente tiene su propia obtención de datos y su propio indicador de proxy. Lo que puede suceder es que rápidamente nos encontremos en una situación en la que varios componentes en la misma pantalla tienen sus propios indicadores de proxy, y luego tenemos este efecto de parpadeo a medida que los diferentes componentes tienen datos que llegan en un orden diferente. Además, cuando tenemos servidores muy rápidos, puede ser molesto debido al efecto de parpadeo, ya que los datos llegarán muy rápidamente y luego los usuarios verán el indicador de progreso solo por un breve tiempo. Entonces, para mejorar esa experiencia, es posible que deseemos introducir algún tipo de retraso antes de mostrar el indicador de progreso, de modo que solo se muestre el indicador de progreso cuando los datos tardan mucho tiempo en llegar.

Echemos un vistazo a un ejemplo muy ingenuo de cómo se vería el código para una página. Independientemente de si usas React Query, Apollo o algo similar, tu componente podría verse así: obtienes los datos y los muestras dentro de tu interfaz de usuario. ¿Podemos hacerlo mejor que esto? Por supuesto que sí, pero requerirá trabajo adicional y requerirá un tipo diferente de trabajo. Veamos cuánto más complicado puede volverse el código. En el lado izquierdo, podemos ver el ejemplo ingenuo anterior, y en el lado derecho seguiremos mejorándolo al manejar diferentes escenarios que hemos mostrado en las demos anteriores.

3. Agregando 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. El manejo de errores, estados vacíos y cargadores de esqueleto puede mejorar en gran medida la experiencia de usuario. Introducir un retraso y evitar la visualización de múltiples indicadores de progreso es importante. El manejo de errores del backend depende de la aplicación, incluidos los errores corregibles por el usuario, problemas de carga del servidor, fallas generales y problemas de conexión de red. También es crucial mejorar la experiencia de usuario para respuestas de larga duración.

Lo primero que queremos agregar es el indicador de progreso. Ahora, eso es bastante sencillo, solo tenemos algún tipo de bandera que indica que se está realizando la carga, en cuyo caso mostramos la interfaz de usuario de carga. Ya puedes ver que esto se puede hacer de dos formas diferentes, ya sea como un indicador de carga de nivel superior o debajo del H1, lo que hace que el indicador de carga sea un poco más intrusivo. Tus opiniones influirán en la forma en que implementes esto. Si queremos manejar errores, debemos agregar código adicional, 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 dificulta extraer este patrón 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 experiencia de usuario tendrá un impacto diferente en tu código. A veces será difícil ver cómo podemos aislar esto en un componente de orden superior que se pueda reutilizar en toda la aplicación. Siempre hay más cosas que podemos agregar a la página para mejorar la experiencia de usuario. Los estados vacíos mejoran las situaciones en las que la aplicación es nueva para el usuario, básicamente no tienen datos o cuando están buscando algo que no existe. En este caso, queremos mostrar siempre los resultados al usuario o decirles que no hay resultados. Esto mejora enormemente la experiencia de usuario.

Los cargadores de esqueleto son una mejor experiencia de usuario en comparación con los simples indicadores de progreso, pero requieren un poco más de tiempo de desarrollo y pueden desincronizarse rápidamente con la interfaz de usuario objetivo que reemplazarán. Así que ten cuidado al introducir interfaces de usuario de esqueleto debido a las complejidades que conllevan. Los indicadores de progreso, nuevamente, solo un booleano ingenuo que no se muestra, puede que no sea suficiente. Por lo tanto, queremos introducir algún tipo de retraso para evitar el efecto de parpadeo. Y también queremos evitar este bosque de indicadores de progreso y mantener los indicadores solo para algo que sea realmente, realmente lento. No hemos hablado mucho sobre cómo manejar los errores del backend, porque depende de la aplicación. Hay diferentes tipos de errores. Hay errores corregibles por el usuario, básicamente pueden hacer algo diferente. Está el caso de volver a intentarlo más tarde porque el servidor tiene una carga tremenda. Entonces no podemos manejar la solicitud en este momento. O puede haber una falla general donde redirigimos al usuario a usar el soporte y básicamente nos pregunta qué salió mal. También hay un caso especial sobre problemas de conexión de red. Por ejemplo, si te encuentras en un área urbana de alta densidad o te alejas, como en un túnel o en una zona rural del país, es posible que pierdas la conexión o tengas problemas de conexión intermitente. En ese caso, la interfaz de usuario debe o debería manejar estos casos mostrando al usuario que en este momento no se pueden obtener los datos y que deben actualizar la página completa o mostrar un botón donde puedan volver a intentar obtener los datos cuando se recupere la conexión. También es posible que desees mejorar la experiencia de usuario para 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. Es posible que deseen 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 de efectos secundarios, queremos manejar acciones iniciadas por el usuario e informar al usuario sobre el progreso de la acción y cualquier problema. También debemos considerar los efectos secundarios en la aplicación. Veamos una demostración de una interfaz de usuario receptiva donde hacer clic en un botón desencadena una acción y proporciona retroalimentación. Sin embargo, hacer doble clic puede causar problemas y debemos manejarlos correctamente.

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

Si echamos un vistazo a la segunda área, el área de efectos secundarios, queremos ver cómo manejar las acciones iniciadas por el usuario. Ahora, debido a que el usuario inició una acción, a diferencia de la navegación, quieren saber que la acción se está gestionando. Quieren saber si la acción se ha completado, si 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 interfaz de usuario 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 lado del servidor en ese caso. Podríamos crear entradas duplicadas o algo similar.

5. Manejo de Errores e Idempotencia

Short description:

En caso de un error, nunca sabes cuál es la acción de error. Un botón que se comporta correctamente se desactiva para evitar envíos duplicados, muestra un indicador de progreso e informa al usuario cuando se completa la acción. 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 navega antes de que se complete una acción.

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

Algunas aplicaciones, cuando estás haciendo cosas muy advanced , pueden querer decirte que por favor no abandones esta página. Por favor, espera hasta que se complete la operación. Esto puede llevar algún tiempo. Nunca sabes cuánto. En un escenario ideal, esto llevará un segundo y habrás terminado. Sin embargo, si esta página se queda y se queda, el usuario puede estar confundido o preocupado. Y no están seguros de si deben abandonar la página, qué sucede si actualizan. Y eso puede generar experiencias de usuario deficientes.

Ahora, debido a que este es un ejemplo de reserva de boletos conocido por todos, queremos ver qué podemos hacer para mejorar la experiencia del usuario. 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, llega el resultado y lo reservamos. Ahora voy a hacer algo diferente. Voy a hacer clic en un botón y actualizar la página. Básicamente, esto está destruyendo el contexto. Cuando volvemos a la página y hacemos clic en el mismo botón, se completa casi de inmediato porque la respuesta del lado del servidor, sí, la operación que solicitaste ya se realizó 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 ocurrir 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 al enviar la solicitud al servidor, enviamos la misma clave. En solicitudes posteriores, 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 deseas 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 lo mismo dos veces.

Ahora, debido a que las aplicaciones de una sola página no se construyen de la misma manera que las representaciones 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 irse a otra página y luego, cuando se completa la acción, la respuesta llegará y pueden ocurrir efectos secundarios que potencialmente causarán errores.

6. Manejo de Desmontaje de Componentes y Efectos Secundarios

Short description:

Cuando hacemos clic en un botón y luego nos vamos a una página diferente, es posible que sigamos viendo la misma alerta. Sin embargo, si intentamos modificar la interfaz de usuario de React, recibiremos una advertencia sobre una fuga de memoria. Para manejar esto, debemos recordar cuándo se desmonta un componente y evitar realizar efectos secundarios.

Entonces, veamos 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, aún podemos ver que tenemos la misma alerta. Ahora, esto es solo ilustrativo. Si intentamos hacer algo como establecer el estado o intentar modificar la interfaz de usuario de React, en realidad obtendremos la advertencia en la consola que dice que tenemos una fuga de memoria. No debemos hacer nada porque el componente se ha desmontado. Para manejar esto correctamente, debemos recordar que cuando se desmonta el componente, realmente queremos saber que el componente se ha desmontado y 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, no debería realizar los efectos secundarios.

7. Manejo de Múltiples Acciones y UX

Short description:

Una última cosa a considerar en 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, bloquear la entrada mientras se espera y manejar problemas de red son consideraciones importantes. Las acciones de bloqueo evitan que los usuarios se vayan, mientras que las acciones no bloqueantes muestran notificaciones cuando se completan. También es una buena práctica tener un centro de notificaciones y prevenir envíos duplicados.

Una última cosa que puede suceder en aplicaciones muy ricas del lado del cliente es que cuando tienes una serie de acciones en la misma pantalla, que se representan en la misma interfaz de usuario pero pueden tardar diferentes tiempos en responder desde el servidor. Por ejemplo, filtrar data puede tener diferentes tiempos de respuesta dependiendo de cuántos datos necesiten procesarse en el servidor. Si el usuario hace clic muchas veces en diferentes momentos, puedes ver que las respuestas salen de orden. No mostramos el resultado de la última acción clicada, 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 en ignorar todas las solicitudes anteriores y solo tener en cuenta la última solicitud enviada.

Echemos un vistazo a parte del código. En el lado izquierdo voy a mantener la implementación muy simple y directa de un manejo de envío. Y en el lado derecho voy a agregar más código para mejorar la experiencia del usuario y veremos cuánto más grande se vuelve el código y cuánto más intrusiva se vuelve esta experiencia del usuario. Lo primero que vamos a agregar es un estado para indicar si estamos enviando o no. Como puedes ver, necesitamos una variable de estado, necesitamos manejarla correctamente cuando comienza y cuando termina. Necesitamos mostrar la interfaz de usuario que indica que se está realizando la acción. Y también queremos desactivar el botón. Si queremos manejar errores, se vuelve aún más intrusivo porque estamos tocando código que ya ha sido modificado y puedes ver que la interfaz de usuario también se está cambiando de una manera muy directa. Es realmente difícil aislar esto en un componente de nivel superior.

Y como antes, siempre hay más cosas que podemos agregar. Podemos agregar validación a nivel de campo donde le decimos al usuario que algunos campos están incorrectos y pueden corregirlos. O podemos decirles que no, hay algo que hiciste mal, es un 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 realizado mucho trabajo y si pierden el trabajo, será malo para el usuario. Podemos guardar los valores. Si es un modelo, es posible que queramos considerar si permitimos salir mientras esperamos una respuesta y muchas otras cosas. En general, queremos pensar en acciones de bloqueo versus acciones no bloqueantes. Las acciones de bloqueo son aquellas que evitan que te vayas porque las acciones posteriores a esta dependen de que esta tenga éxito. También hay acciones no bloqueantes, también llamadas `fire and forget`. En esos casos, solo queremos mostrar notificaciones cuando la acción se haya completado. Siempre considera tener un centro de notificaciones o algo donde el usuario pueda consultar las acciones realizadas anteriormente. En general, queremos evitar envíos duplicados. La solución simple es simplemente desactivar los botones de acción.

8. Manejo de Idempotencia y Pérdida de Contexto

Short description:

Queremos utilizar la idempotencia para escenarios importantes como reservas o pagos. El manejo de problemas de red implica reintentar solicitudes fallidas e informar al usuario a través de correo electrónico o SMS. La idempotencia permite volver a intentar acciones de manera segura. La pérdida de contexto ocurre al navegar por la aplicación y debemos manejar el desmontaje de componentes y las condiciones de carrera para evitar una representación extraña de la interfaz de usuario.

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

Los problemas de red, como se mencionó anteriormente, queremos manejarlos de dos formas diferentes. Puede haber un problema saliente, básicamente, no pudimos enviar la solicitud al servidor, por lo que pueden volver a intentarlo. O en realidad, enviamos la solicitud, sin embargo, mientras el servidor recibía la solicitud, mientras la respuesta viajaba de regreso o mientras esperábamos, en ese momento, 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 realizando la misma acción dos veces. Queremos ver si podemos informar al usuario de alguna otra manera, como usar el centro de notificaciones por correo electrónico o SMS, que la acción se ha completado. Como antes, la idempotencia en las acciones permite volver a intentar de manera segura, porque realmente puedes enviar la misma solicitud dos veces y el servidor no realizará 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 por la aplicación y luego, cuando la operación tiene éxito, puede suceder algo malo. Tengo algunos enlaces aquí que debes 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 gancho muy simple que te dirá si el componente ha sido desmontado. Podemos usarlo de una manera muy sencilla simplemente verificando si el componente ha sido desmontado. Este es un controlador 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, nuevamente, el gancho isMounted para saber si el componente ha sido desmontado, básicamente regresar desde la función importando el procesamiento posterior. La tercera forma es usar algo llamado cancelación cooperativa, inspirado en C-sharp. Este código muestra cómo se crearía un token en el propio efecto y luego cancelarlo en la parte desuscripción. La función asíncrona después de cada llamada await debe verificar si se solicita la cancelación. Básicamente, después de la llamada await, el componente puede estar desmontado y no lo sabemos, por lo que tenemos que verificarlo. Otra cosa que queremos manejar son las condiciones de carrera, como se muestra en la demostración. Si reutilizamos la interfaz de usuario después de las acciones, dependiendo del orden en que lleguen, esto podría generar una interfaz de usuario muy extraña.

9. Consideraciones para Actualizaciones Optimistas

Short description:

Una cosa final a considerar son las actualizaciones optimistas, donde fingimos que una acción se realizó de inmediato para que la interfaz de usuario sea receptiva. Sin embargo, esto puede llevar a inconsistencias si las acciones posteriores encuentran errores. En esos casos, considera CRDT u otras tecnologías para aplicaciones colaborativas.

Una cosa final antes de concluir es 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, fingimos que la acción se realizó de inmediato para que la interfaz de usuario se vea muy receptiva y luego, más adelante, nos sincronizamos con el servidor. Ten en cuenta que esto puede llevar a situaciones muy malas si hay acciones posteriores que el usuario realiza, porque si hay errores de red u otros tipos de errores. Si no lo manejas correctamente en la interfaz de usuario, puede volverse bastante inconsistente rápidamente. En ese caso, considera CRDT u otras tecnologías si estás construyendo, por ejemplo, aplicaciones colaborativas. Entonces, para resumir, manejar código asíncrono requiere cambios no triviales en nuestra base de código. Es un poco intrusivo y a veces muy difícil de hacer en componentes más complejos. Sin embargo, si lo hacemos correctamente, los usuarios estarán encantados. La aplicación se verá pulida y la experiencia será increíble y los usuarios estarán muy satisfechos con la aplicación. Con esto, he dicho todo lo que quería decir. 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 encontrarme en el Spatial Chat. Si quieren hacer una breve sesión de preguntas y respuestas, disfruten del resto de la conferencia y ¡feliz codificación! Gracias.

Check out more articles and videos

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

React Advanced Conference 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Top Content
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.
React Day Berlin 2022React Day Berlin 2022
22 min
Jotai Atoms Are Just Functions
Top Content
Jotai is a state management library. We have been developing it primarily for React, but it's conceptually not tied to React. It this talk, we will see how Jotai atoms work and learn about the mental model we should have. Atoms are framework-agnostic abstraction to represent states, and they are basically just functions. Understanding the atom abstraction will help designing and implementing states in your applications with Jotai
React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.
React Day Berlin 2022React Day Berlin 2022
29 min
Fighting Technical Debt With Continuous Refactoring
Top Content
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt. In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.
React Summit Remote Edition 2020React Summit Remote Edition 2020
32 min
AHA Programming
Top Content
Are you the kind of programmer who prefers to never see the same code in two places, or do you make liberal use of copy/paste? Many developers swear the Don't Repeat Yourself (DRY) philosophy while others prefer to Write Everything Twice (WET). But which of these produces more maintainable codebases? I've seen both of these approaches lay waste to codebases and I have a new ideology I would like to propose to you: Avoid Hasty Abstractions (AHA). In this keynote, we'll talk about abstraction and how you can improve a codebase applying and creating abstractions more thoughtfully as well as how to get yourself out of a mess of over or under-abstraction.
React Summit US 2023React Summit US 2023
21 min
The Epic Stack
Modern web development is fantastic. There are so many great tools available! Modern web development is exhausting. There are so many great tools available! Each of these sentiments is true. What's great is that most of the time, it's hard to make a choice that is wrong. Seriously. The trade-offs of most of the frameworks and tools you could use to build your application fit within the constraints of the vast majority of apps. Despite this, engineers consistently struggle with analysis paralysis.Let's talk about this, and a solution I am working on for it.

Workshops on related topic

React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Top Content
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
React Summit 2022React Summit 2022
136 min
Remix Fundamentals
Top Content
Featured WorkshopFree
Building modern web applications is riddled with complexity And that's only if you bother to deal with the problems
Tired of wiring up onSubmit to backend APIs and making sure your client-side cache stays up-to-date? Wouldn't it be cool to be able to use the global nature of CSS to your benefit, rather than find tools or conventions to avoid or work around it? And how would you like nested layouts with intelligent and performance optimized data management that just works™?
Remix solves some of these problems, and completely eliminates the rest. You don't even have to think about server cache management or global CSS namespace clashes. It's not that Remix has APIs to avoid these problems, they simply don't exist when you're using Remix. Oh, and you don't need that huge complex graphql client when you're using Remix. They've got you covered. Ready to build faster apps faster?
At the end of this workshop, you'll know how to:- Create Remix Routes- Style Remix applications- Load data in Remix loaders- Mutate data with forms and actions
Vue.js London Live 2021Vue.js London Live 2021
169 min
Vue3: Modern Frontend App Development
Top Content
Featured WorkshopFree
The Vue3 has been released in mid-2020. Besides many improvements and optimizations, the main feature of Vue3 brings is the Composition API – a new way to write and reuse reactive code. Let's learn more about how to use Composition API efficiently.

Besides core Vue3 features we'll explain examples of how to use popular libraries with Vue3.

Table of contents:
- Introduction to Vue3
- Composition API
- Core libraries
- Vue3 ecosystem

Prerequisites:
IDE of choice (Inellij or VSC) installed
Nodejs + NPM
JSNation 2023JSNation 2023
174 min
Developing Dynamic Blogs with SvelteKit & Storyblok: A Hands-on Workshop
Featured WorkshopFree
This SvelteKit workshop explores the integration of 3rd party services, such as Storyblok, in a SvelteKit project. Participants will learn how to create a SvelteKit project, leverage Svelte components, and connect to external APIs. The workshop covers important concepts including SSR, CSR, static site generation, and deploying the application using adapters. By the end of the workshop, attendees will have a solid understanding of building SvelteKit applications with API integrations and be prepared for deployment.
React Summit 2023React Summit 2023
106 min
Back to the Roots With Remix
Featured Workshop
The modern web would be different without rich client-side applications supported by powerful frameworks: React, Angular, Vue, Lit, and many others. These frameworks rely on client-side JavaScript, which is their core. However, there are other approaches to rendering. One of them (quite old, by the way) is server-side rendering entirely without JavaScript. Let's find out if this is a good idea and how Remix can help us with it?
Prerequisites- Good understanding of JavaScript or TypeScript- It would help to have experience with React, Redux, Node.js and writing FrontEnd and BackEnd applications- Preinstall Node.js, npm- We prefer to use VSCode, but also cloud IDEs such as codesandbox (other IDEs are also ok)