UX Asincrónico

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.

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.

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.

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.

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.

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.

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.

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.

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.