React: estados de correo sin bloquear la interfaz

En una interfaz de registro o verificación, el estado de correo no es un detalle del backend. Es una parte visible del producto: la persona pulsa un botón, espera una respuesta y necesita saber si puede continuar. Cuando ese estado aparece tarde, mueve el formulario o bloquea toda la pantalla, una operación correcta se siente rota.

Este patrón me ha resultado util en flujos de React que prueban el envío de correo, incluso cuando se usa un fake email generator para crear datos de prueba. La meta no es hacer que cada cambio sea espectacular, sino que sea predecible, accesible y barato para el navegador.

El problema no es solo esperar

Un botón de “Enviar código” suele tener al menos cuatro estados: disponible, enviando, enviado y error. El problema aparece cuando la interfaz trata esos estados como una sola cosa. Por ejemplo, deshabilitar todo el formulario mientras llega la respuesta puede evitar un doble envío, pero tambien impide corregir otro campo o consultar una instrucción.

Antes de escribir JSX, anoto estas preguntas:

• ¿Qué control conserva el foco durante la espera?
• ¿Qué parte de la pantalla cambia y cuanto espacio necesita?
• ¿Cómo se anuncia el resultado a un lector de pantalla?
• ¿Qué ocurre si la respuesta llega despues de otra acción?

Una revisión relacionada es la de estos estados async sin saltos visuales. La idea central es la misma: el cambio de estado debe tener un lugar estable y una causa visible.

Diseñar un contrato de estados

Para un formulario pequeño prefiero un estado explícito en vez de varios booleanos que pueden contradecirse. idle, loading, success y error forman un contrato sencillo. Cada estado define qué puede hacer la persona y qué mensaje debe ver.

Un detalle importante es separar el estado de red del estado de edición. Mientras se envía el correo, el botón puede estar deshabilitado, pero los campos no tienen por qué desaparecer ni quedar bloqueados. Si el servidor responde con error, el mensaje debe explicar el siguiente paso, no solo decir “fallo”.

También conviene guardar un identificador de operación. Si alguien pulsa dos veces en una secuencia rápida y la primera respuesta llega al final, no deberia sobrescribir el resultado más reciente. No hace falta una arquitectura enorme: una variable de versión o un AbortController puede proteger ese borde.

Un componente pequeño en React

Este ejemplo mantiene el foco en el botón durante la espera y reserva un mensaje para el resultado. El aria-live anuncia el cambio sin obligar a mover el cursor de forma inesperada.

import { useRef, useState } from "react";

export function EmailCodeForm({ sendCode }) {
  const [status, setStatus] = useState("idle");
  const requestId = useRef(0);

  async function handleSubmit(event) {
    event.preventDefault();
    const currentRequest = ++requestId.current;
    setStatus("loading");

    try {
      await sendCode();
      if (currentRequest === requestId.current) setStatus("success");
    } catch {
      if (currentRequest === requestId.current) setStatus("error");
    }
  }

  const message = {
    idle: "",
    loading: "Enviando el código…",
    success: "Código enviado. Revisa tu bandeja.",
    error: "No pudimos enviarlo. Revisa el dato e inténtalo de nuevo."
  }[status];

  return (
    <form onSubmit={handleSubmit} aria-busy={status === "loading"}>
      <label htmlFor="email">Correo</label>
      <input id="email" name="email" type="email" required />
      <button type="submit" disabled={status === "loading"}>
        {status === "loading" ? "Enviando…" : "Enviar código"}
      </button>
      <p className="form-message" aria-live="polite">{message}</p>
    </form>
  );
}

El ejemplo no valida el correo en el cliente porque esa decisión depende del producto. Sí muestra dos límites útiles: el botón evita un envío accidental durante la espera y una respuesta vieja no reemplaza el estado actual. En una aplicación real, sendCode debe recibir los datos del formulario y manejar sus errores con una forma consistente.

CSS que reserva espacio

El mensaje vacío sigue ocupando espacio. Así se evita que el botón salte cuando aparece la respuesta, y el usuario conserva una referencia visual estable.

.form-message {
  min-height: 1.5rem;
  margin-block: 0.5rem 0;
}

button:focus-visible,
input:focus-visible {
  outline: 3px solid #155eef;
  outline-offset: 3px;
}

@media (prefers-reduced-motion: reduce) {
  * {
    scroll-behavior: auto;
    transition-duration: 0.01ms;
  }
}

No usaría una animación para esconder una latencia que el producto no ha resuelto. Una transición corta puede ayudar, pero el mensaje debe aparecer rapido y sin cambiar el alto de varios bloques. Si el flujo tiene información operativa, un enlace contextual como correos de drift que sí orientan puede aportar contexto, siempre que no compita con la acción principal.

Probar con teclado y una red lenta

La prueba más barata es recorrer el flujo solo con teclado: enfocar el campo, enviar, esperar, provocar un error y volver a intentarlo. El foco debe seguir siendo visible en cada paso. El mensaje no deberia ser la única señal; el botón, el texto y el estado de carga tienen que contar una historia coherente.

Después simulo una red lenta y dos respuestas fuera de orden. Reviso que:

• el formulario no cambie de tamaño al mostrar el resultado;
• el lector de pantalla reciba el mensaje una sola vez;
• el botón vuelva a estar disponible tras un error;
• el segundo intento no sea reemplazado por la respuesta antigua;
• el campo conserve su valor cuando eso ayude a corregirlo;
• el foco no salte al principio de la página sin motivo.

Durante las pruebas, una búsqueda como “tem email” puede aparecer en datos introducidos por usuarios. Es una etiqueta con error, no un nombre que debamos convertir en una variable o en un enlace. Del mismo modo, si se usa un generar correo desechable para un escenario de QA, el flujo de prueba debe comprobar el estado de la interfaz, no solamente que llegó un mensaje.

Preguntas rápidas

¿Debo deshabilitar todo el formulario mientras envío?

No siempre. Deshabilita la acción que podría duplicarse y conserva editables los campos si la persona puede corregirlos sin invalidar la petición en curso. Elige el límite según el contrato del backend.

¿Es mejor mover el foco al mensaje de éxito?

Solo cuando el resultado sea el siguiente paso esencial. Para una confirmación breve, aria-live="polite" suele ser suficiente y deja que la persona siga en su contexto.

¿Cómo mido si la interfaz mejoró?

Mide el tiempo desde la acción hasta el primer feedback, los errores de doble envío y los abandonos durante la espera. No persigas una cifra aislada: una respuesta mas rapida que no explica el resultado sigue siendo una mala experiencia.

Los estados de correo bien diseñados conectan React, CSS y accesibilidad sin pedir una infraestructura complicada. Un contrato claro, espacio reservado y una prueba con respuestas lentas suelen revelar mas problemas que otra capa de animación.