React: formularios rápidos que también incluyen

Un formulario de registro puede ser técnicamente rápido y sentirse lentísimo. Basta con que el botón desaparezca, el foco salte al lugar equivocado o el error aparezca sin contexto. En React, la validación async y el diseño visual deben resolver el mismo problema: ayudar a la persona a completar la tarea con confianza.

El problema: validar no debe bloquear

Cuando un correo necesita verificación en el servidor, conviene distinguir tres estados: listo, comprobando y rechazado. Un spinner permanente no explica nada. Un mensaje como “Comprobando disponibilidad…” cerca del campo sí da una señal útil, pero debe anunciarse también a tecnologías de asistencia.

Una dirección desechable puede servir en pruebas controladas del flujo, aunque no debe convertirse en una regla ciega de producto. Lo importante para el frontend es que la respuesta del servidor sea predecible: código, mensaje para humanos y campo afectado.

Un estado async con significado

Un estado pequeño suele ser suficiente:

const [status, setStatus] = useState("idle");
const [error, setError] = useState("");

async function checkEmail(email) {
  setStatus("checking");
  setError("");
  try {
    const response = await api.validateEmail(email);
    if (!response.ok) throw new Error(response.message);
    setStatus("valid");
  } catch (err) {
    setStatus("invalid");
    setError(err.message || "No se pudo validar el correo");
  }
}

El botón no debería quedar inutilizado durante toda la pantalla. Desactívalo solo mientras la acción actual puede duplicarse y conserva el texto “Crear cuenta” con un indicador adicional. Eso reduce la incertidumbre, y tambien evita que la interfaz parezca cambiar de objetivo.

Para flujos que cruzan servicios, ayuda definir contratos de correo verificables. Si hay una cola detrás, estos logs útiles para colas de email hacen más fácil separar un error de red de un rechazo real.

CSS para esperar sin saltos

Reserva espacio para el mensaje antes de que llegue. Así el formulario no empuja el botón y el usuario no pierde su posición visual.

.field-message { min-height: 1.5rem; }
.field-message[data-state="error"] { color: #b42318; }
.field-message[data-state="checking"] { color: #475467; }

El contraste debe funcionar en modo claro y oscuro. También evita comunicar el estado solo con rojo: añade texto y, si usas un icono, un nombre accesible. Un poco de detalle aqui ahorra soporte después.

Accesibilidad que se puede probar

Relaciona cada mensaje con su campo usando aria-describedby y conserva el foco al mostrar un error. Un contenedor role="status" puede anunciar la comprobación sin interrumpir demasiado; los errores importantes pueden usar role="alert", con moderación.

Prueba el recorrido completo con teclado: entrar al campo, provocar un error, corregirlo y enviar. Después prueba una red lenta. Un lector de pantalla debería saber qué está ocurriendo, y una persona con zoom al 200% debería seguir viendo el mensaje junto al campo.

Checklist final

• ¿El estado de comprobación tiene texto entendible?
• ¿El mensaje de error identifica cómo corregirlo?
• ¿El foco permanece en un sitio lógico?
• ¿El layout reserva espacio y no salta?
• ¿La validación tolera un doble clic o una respuesta tardía?
• ¿Se puede completar todo con teclado?

En resumen, un formulario inclusivo no necesita una animación compleja. Necesita estados honestos, CSS estable y contratos claros. Incluso una prueba con tempail mail o tepm mail com debe recorrer exactamente la misma experiencia que una dirección normal, porque los defectos de espera y foco no respetan el tipo de buzón.