UX Asincrónico

Rate this content
Bookmark

"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.

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

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.

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

Don't Solve Problems, Eliminate Them
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.
Jotai Atoms Are Just Functions
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
Debugging JS
React Summit 2023React Summit 2023
24 min
Debugging JS
Top Content
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.
Fighting Technical Debt With Continuous Refactoring
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.
AHA Programming
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.
The Epic Stack
React Summit US 2023React Summit US 2023
21 min
The Epic Stack
Top Content
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, TypeScript, and TDD
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
Paul Everitt
Paul Everitt
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.
Web3 Workshop - Building Your First Dapp
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Top Content
Featured WorkshopFree
Nader Dabit
Nader Dabit
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.
Remix Fundamentals
React Summit 2022React Summit 2022
136 min
Remix Fundamentals
Top Content
Featured WorkshopFree
Kent C. Dodds
Kent C. Dodds
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
Vue3: Modern Frontend App Development
Vue.js London Live 2021Vue.js London Live 2021
169 min
Vue3: Modern Frontend App Development
Top Content
Featured WorkshopFree
Mikhail Kuznetcov
Mikhail Kuznetcov
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
Developing Dynamic Blogs with SvelteKit & Storyblok: A Hands-on Workshop
JSNation 2023JSNation 2023
174 min
Developing Dynamic Blogs with SvelteKit & Storyblok: A Hands-on Workshop
Top Content
Featured WorkshopFree
Alba Silvente Fuentes
Roberto Butti
2 authors
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.
Back to the Roots With Remix
React Summit 2023React Summit 2023
106 min
Back to the Roots With Remix
Featured Workshop
Alex Korzhikov
Pavlik Kiselev
2 authors
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)