React: errores de email que no cansan

En muchos formularios el problema no es validar el email. El problema real es cuando decides hablarle a la persona. Si el mensaje aparece demasiado pronto, el campo se siente nervioso, el layout brinca y la experiencia se vuelve un poco hostil. En equipos frontend esto lo veo bastante seguido, sobretodo cuando alguien mezcla formato, disponibilidad y estados remotos en la misma linea roja.

Me funciona mejor pensar el input como una secuencia de ayuda, no como una alarma. Si ya vienes trabajando validacion de email sin castigar el foco, este ajuste es una continuacion natural. Y si tu flujo tambien toca APIs de onboarding, conviene separar muy bien la parte visual de la parte de red para no culpar al componente por retrasos que vienen de otro lado. La idea parece simple, pero cambia mucho como se siente el formulario.

El problema no es el error, es el momento

Un error de email no deberia competir con la escritura. Mientras alguien sigue tecleando, casi siempre falta contexto. Mostrar "correo invalido" despues de dos caracteres ayuda poco y castiga bastante. En mobile se nota mas, por que el teclado ocupa media pantalla y cualquier salto visual roba atencion.

Hay una razon practica para evitar eso. Segun NN/g, los mensajes funcionan mejor cuando son especificos y oportunos. Esa ultima palabra importa muchisimo. Oportuno no significa inmediato en cada tecla; significa que aparece cuando la persona ya puede usarlo.

Tambien hay una ventaja de rendimiento. Cuando el formulario dispara logica en cada cambio, aparecen renders extras, peticiones abortadas y mas trabajo para el navegador. web.dev explica por que reducir trabajo dentro de interacciones mejora la latencia percibida. No siempre ves el problema en una demo, pero en productos reales si se siente, y bastante.

En pruebas internas a veces aparecen datos raros como dummy e mail o direcciones cortadas a medias. Ese ruido suele exponer un fallo de UX antes que un fallo de negocio. El componente intenta corregir demasiado pronto y termina diciendo cosas utiles en el momento equivocado.

Tres estados visuales que ayudan de verdad

Para la mayoria de formularios me basta con tres estados:

• neutral mientras la persona escribe
• error de formato cuando sale del campo y el valor sigue mal
• comprobacion remota solo despues de tener una direccion plausible

Con eso el formulario deja de parpadear tanto. El texto de ayuda puede quedarse siempre en el mismo lugar, y solo cambia su contenido. Ese detalle evita saltos del layout y hace que la interfaz se sienta mas estable, casi mas tranquila.

Tambien ayuda a Accesibilidad. Si usas una region aria-live, conviene que no reciba mensajes nuevos cada segundo. Un anuncio corto, en el momento correcto, vale mas que cinco mensajes consecutivos que la persona ni alcanza a procesar. A veces este punto se olvida por completo, y luego toca arreglarlo a las apuradas.

Un patron de React que mantiene el ritmo

En React prefiero modelar el campo con una fase explicita. No hace falta una maquina de estados enorme, pero si ayuda nombrar bien lo que esta pasando:

type EmailPhase = "idle" | "format-error" | "checking" | "ok";

type EmailModel = {
  value: string;
  phase: EmailPhase;
  message?: string;
};

Luego reparto responsabilidades por evento. onChange solo guarda el valor. onBlur valida formato. Y el chequeo remoto corre solo si el formato ya paso:

const [email, setEmail] = useState<EmailModel>({
  value: "",
  phase: "idle",
});

function onChange(value: string) {
  setEmail({ value, phase: "idle" });
}

async function onBlur(value: string) {
  if (!/^[^\\s@]+@[^\\s@]+\\.[^\\s@]+$/.test(value)) {
    setEmail({ value, phase: "format-error", message: "Escribe un email valido." });
    return;
  }

  setEmail({ value, phase: "checking" });
  const result = await checkEmail(value);
  setEmail(result.ok ? { value, phase: "ok" } : { value, phase: "format-error", message: result.message });
}

Lo bueno de este patron es que cada fase tiene una sola tarea. El componente es mas facil de leer, de testear y de estilizar con CSS sin hacks raros. Tambien te deja medir mejor que esta pasando: sabes cuando hubo error local y cuando hubo espera de red. Parece una diferencia pequena, pero en depuracion ahorra mucho tiempo, posta.

Que revisar cuando el backend tambien participa

Si tu formulario pide verificar disponibilidad, enviar magic links o revisar dominios corporativos, el limite entre frontend y backend debe quedar clarito. El cliente decide formato basico y experiencia visual. El servidor decide reglas de negocio y estado remoto. Cuando ambas capas intentan hablar al mismo tiempo, el mensaje final sale confuso.

Por eso me gusta enlazar este patron con separar emails de signup por escenario. Ese tipo de division tambien mejora el trabajo de QA, por que ya no adivinas si el fallo vino del regex, del fetch o del servicio remoto. Cada capa tiene su pedazo y punto.

En la UI, dos detalles suman mucho:

• mantener reservada la altura del mensaje para evitar brincos
• ignorar respuestas viejas si la persona ya cambio el valor

No son trucos nuevos, pero siguen resolviendo problemas reales. Y cuando el formulario se siente predecible, la confianza sube aunque nadie lo diga en voz alta. Eso vale bastante mas de lo que parece.

Checklist corto antes de publicar

Antes de cerrar el componente, reviso esto:

• no aparece error mientras la persona aun esta escribiendo
• el mensaje vive en una zona estable del layout
• aria-invalid solo se activa con error real
• el estado de carga no roba foco
• las respuestas lentas no pisan el ultimo valor
• hay pruebas de teclado, lector de pantalla y red lenta

Es una lista corta, pero cubre bastnte. Cuando algo falla, normalmente el problema cae en uno de esos puntos y no en una "misteriosa sensacion de formulario raro".

Q&A

Debo validar solo al enviar?

No siempre. Validar solo al enviar baja el ruido, pero llega tarde en algunos casos. Para email, blur suele ser un punto muy sano entre ayuda y paciencia.

Y si necesito reglas de dominio o cuentas de empresa?

Haz primero el formato local y luego las reglas del negocio. Si mezclas todo en un solo mensaje, la persona recibe una explicacion medio torpe y cuesta mas corregirla.

Esto sirve fuera de React?

Si. React solo hace comoda la organizacion del estado. La idea central es separar fases, mantener mensajes estables y gastar menos trabajo por interaccion. Eso funciona casi en cualquier stack front.