Cuando trabajamos con React y manejamos varios estados simultáneamente, como loading y error, es común encontrarnos con problemas visuales en la interfaz. ¿Qué sucede cuando un usuario ingresa un código incorrecto, recibe un mensaje de error y luego vuelve a intentar? Si no gestionamos bien la actualización de estados, el mensaje de error puede seguir visible mientras la aplicación está cargando. Lo interesante no es solo corregir ese problema, sino descubrir todas las formas posibles de resolverlo y evaluar cuál se adapta mejor a cada situación.
¿Cuál es el problema de interfaz al combinar estados de error y carga?
El escenario es el siguiente: el usuario escribe un código incorrecto, la aplicación pasa al estado de carga y luego muestra el estado de error [01:00]. Todo funciona. Pero cuando el usuario escribe un nuevo código y presiona comprobar, aparece el estado de carga sin que desaparezca el estado de error [02:30]. Ambos mensajes se muestran al mismo tiempo.
La pregunta clave es: ¿es correcto mostrar el error mientras estamos cargando? No hay una respuesta universal. Depende completamente de la aplicación y del problema que quieras resolver [03:07]. En este caso, se asume que no es correcto y que el error debe desaparecer cuando inicia una nueva carga.
¿Dónde actualizar el estado para ocultar el error durante la carga?
Existen al menos tres lugares donde podemos intervenir. Cada uno tiene implicaciones distintas.
¿Qué pasa si llamamos a setError junto con setLoading en el evento de clic?
La primera opción es ir al evento onClick del botón de comprobar [03:43]. Aquí ya estamos llamando a setLoading(true), y podemos agregar también setError(false). De esta forma, al presionar el botón:
- Se activa el estado de carga.
- Se desactiva el estado de error.
- El componente se re-renderiza sin mostrar ambos mensajes.
Al probar, si escribimos un código incorrecto y luego intentamos con otro, el error desaparece y solo se muestra la carga [04:36]. Funciona correctamente para este caso.
¿Es válido limpiar el error en el evento onChange del input?
Otra alternativa es llamar a setError(false) dentro del evento onChange del input [05:18]. Es decir, cada vez que el usuario escribe algo, eliminamos el mensaje de error.
- El error desaparece apenas el usuario comienza a escribir.
- No necesita presionar el botón de comprobar para que el error se oculte.
Sin embargo, hay una implicación negativa: el actualizador del estado se ejecuta con cada tecla que el usuario presiona [06:16]. Si el usuario se equivoca varias veces al escribir, estamos llamando a setError(false) repetidamente de forma innecesaria. No siempre es incorrecto, pero puede ser ineficiente según el contexto.
¿Se puede resolver sin cambiar el estado, solo con una validación en la interfaz?
Esta es la solución más elegante para el caso planteado [07:27]. En lugar de modificar cuándo se actualiza el estado, cambiamos la condición de renderizado del mensaje de error. La idea es que el párrafo de error solo se muestre cuando se cumplan dos condiciones:
- Que
error sea true.
- Que
loading sea false.
jsx
{(error && !loading) && (
<p>El código es incorrecto</p>
)}
Con esta validación, cuando el usuario presiona comprobar y loading pasa a ser true, el mensaje de error deja de renderizarse automáticamente sin necesidad de llamar a ningún actualizador de estado [08:26]. Es una solución puramente visual que no altera el flujo de datos.
¿Por qué importa conocer múltiples formas de resolver el mismo problema?
El concepto de renderizado condicional permite controlar qué se muestra en pantalla combinando múltiples estados en una sola expresión. No siempre la solución pasa por preguntarse dónde actualizar el estado. A veces basta con ajustar la lógica de presentación.
Cada enfoque tiene su lugar:
- Llamar a varios actualizadores de estado en un mismo bloque funciona cuando necesitas sincronizar cambios explícitamente.
- Limpiar el error en onChange es útil cuando quieres dar retroalimentación inmediata al usuario.
- La validación en la interfaz es ideal cuando el estado no necesita cambiar, solo su representación visual.
En la siguiente parte se explorará cómo manejar estas actualizaciones múltiples de estado usando un solo objeto, comparando el enfoque de hooks con el de componentes de clase usando React.Component [09:40]. ¿Cuál de estas soluciones usarías tú en tus proyectos? Comparte tu respuesta en los comentarios.
