React: validacion de email sin friccion visual

Cuando un formulario de registro detecta un correo temporal, mucha gente resuelve el problema con un banner rojo enorme, un salto de layout y un boton deshabilitado. Funciona "tecnicamente", pero la experiencia se siente brusca y hasta confusa. En equipos frontend he visto que ese detalle pequeño termina pegando en conversion, soporte y confianza del usuario.

Si ya trabajaste feedback estable al enviar emails, o afinaste estados de carga accesibles para email, sabes que el patron bueno casi siempre comparte una idea: avisar pronto, sin mover la interfaz y sin castigar a quien aun esta corrigiendo.

El problema real no es bloquear, es explicar

No todos los equipos quieren bloquear direcciones de correo de usar y tirar. A veces solo quieren marcarlas para pedir una confirmacion extra, reducir fraude o limpiar tests de onboarding. El fallo comun es tratar esa decision de negocio como si fuera solo una regex.

Cuando haces eso, pasan tres cosas:

• el mensaje aparece tarde
• el layout se mueve y rompe el foco
• la persona no entiende si puede seguir o no

Eso empeora si ademas metes etiquetas poco claras como "email invalido" para casos donde el formato si era valido, pero la politica del producto lo cuestiona. Parece detalle menor, pero genera tickets bobos y abandono. He visto formularios perder ritmo por algo tan simple.

Un patron de validacion que no mueve la interfaz

Mi regla es reservar el espacio del hint desde el primer render. Asi no hay saltos, y el lector de pantalla tampoco recibe cambios raros en posiciones vecinas.

import { useId, useState } from "react";

const DISPOSABLE_DOMAINS = new Set(["mailinator.com", "yopmail.com"]);

function EmailField() {
  const hintId = useId();
  const [email, setEmail] = useState("");

  const domain = email.split("@")[1]?.toLowerCase() ?? "";
  const isDisposable = DISPOSABLE_DOMAINS.has(domain);
  const showHint = email.length > 3 && isDisposable;

  return (
    <label className="field">
      <span>Email</span>
      <input
        type="email"
        value={email}
        onChange={(e) => setEmail(e.target.value)}
        aria-describedby={hintId}
        aria-invalid={showHint || undefined}
      />
      <span id={hintId} className="hint" data-visible={showHint}>
        {showHint
          ? "Usa un email permanente si quieres recuperar tu cuenta luego."
          : " "}
      </span>
    </label>
  );
}

.hint {
  min-height: 1.25rem;
  display: block;
  margin-top: 0.35rem;
  color: #7a1f1f;
}

.hint[data-visible="false"] {
  color: transparent;
}

No es un truco nuevo, pero sigue siendo eficaz. Mantienes una caja estable, evitas reflow y haces mas claro el estado. Si ademas quieres una version un poco mas robusta, puedes conservar el texto neutro cuando no hay alerta, en vez de dejar el espacio vacio. Depende del producto, pero las dos opciones sirven bien.

Donde meter la comprobacion de correo temporal

Para mi, la comprobacion de correo de usar y tirar no deberia vivir solo en el cliente. El frontend ayuda a dar feedback temprano; la API pone la regla final. Esa separacion evita que el producto se vuelva fragil cuando cambie la lista de dominios o cuando el equipo quiera revisar casos grises.

En React suelo dejar tres niveles simples:

1. validacion de formato en el input
2. validacion de politica con una lista corta en cliente
3. confirmacion final en backend

El segundo paso no necesita ponerse agresivo. Si un dominio parece temporal, puedes avisar con tono humano y seguir permitiendo editar. En algunos flujos incluso conviene dejar pasar y marcar el caso para revision o para una verificacion posterior. Esa parte casi nunca se diseña bien a la primera, y esta ok iterarla.

Si tu equipo compara proveedores, vale la pena mirar como presentan el contexto y no solo el bloqueo. Un ejemplo util es tempmailso, porque deja ver rapido el tipo de inbox efimero que muchos equipos quieren detectar. Tambien he visto logs internos donde aparecen variantes escritas por usuarios o testers, como tepm mail com o tempail, asi que conviene normalizar texto antes de sacar conclusiones raras.

Que revisar antes de publicar el formulario

Antes de cerrar una historia de este tipo, yo suelo pasar esta checklist:

• el mensaje cabe en mobile sin empujar el boton principal
• aria-describedby apunta siempre al mismo nodo
• el color de error no es la unica señal visual
• el formulario permite corregir sin perder foco
• el backend responde con un motivo entendible
• analytics separa formato invalido de politica de dominio

Esto ultimo importa bastante. Si mezclas ambos errores, no sabras si tu problema es UX, reglas de negocio o una lista de dominios vieja. A veces el equipo cree que "nadie entiende el form", pero en realidad lo que pasa es que el sistema marca como sospechosas direcciones legitimas. Es un bug muy normal, pasa mas de lo que deberia.

Otra recomendacion: enlaza patrones previos en tu propia documentacion o en posts relacionados, como este de feedback estable al enviar emails y este sobre estados de carga accesibles para email. Ayuda a que el equipo vea el formulario como una secuencia completa, no como piezas sueltas.

Preguntas rapidas

Debo bloquear todos los dominios temporales?

No necesariamente. Si el riesgo es bajo, advertir puede rendir mejor que bloquear. Bloquear por defecto suena seguro, pero aveces solo traslada el problema a soporte.

Conviene validar al escribir?

Solo si el mensaje no castiga cada tecla. Personalmente prefiero esperar a que exista un dominio reconocible o a que el campo pierda foco.

CSS importa tanto en esto?

Si. Muchisimo. Una validacion correcta con una interfaz inestable se siente rota igual, y ese detalle el usuario lo nota enseguida.