React: warnings de correo sin robar el foco

En formularios de alta suelo ver un error muy repetido: el sistema detecta un dominio temporal, pero el aviso aparece como si fuera una alarma general. El campo pierde foco, el layout salta un poco y la persona no entiende si debe corregir algo o solo leer una advertencia. Tecnica y visualmente parece una cosa menor, pero desgasta bastante la confianza.

Para mi, el objetivo no es perseguir cada correo raro. Es explicar la consecuencia con calma. Si alguien usa un generador de direcciones de correo desechable o un generador de emails falsos para una demo, QA o una prueba corta, el frontend deberia orientar sin convertir el momento en castigo. Baymard lleva tiempo mostrando que la validacion inline funciona mejor cuando ayuda a avanzar y no solo a marcar errores (Baymard). En flujos reales eso se nota mucho, aun que a veces no se vea en una unica metrica.

El warning no debe competir con el campo

Cuando un warning roba foco pasan tres cosas a la vez:

• el teclado se siente menos predecible
• el lector de pantalla recibe un cambio con demasiado dramatismo
• la persona deja de mirar el valor escrito y empieza a pelearse con la interfaz

Ese ultimo punto es el mas molesto. En React he visto componentes que, al detectar un dominio temporal, montan un bloque nuevo arriba del input y desplazan todo. Google sigue recomendando reducir cambios inesperados de layout porque afectan tanto la percepcion de calidad como el CLS (web.dev). No hace falta obsesionarse con cada pixel, pero si con la estabilidad del paso.

Tambien conviene separar formato invalido de riesgo contextual. "Correo invalido" no significa lo mismo que "correo que podria expirar antes de la verificacion". Nielsen Norman Group insiste en que los mensajes utiles deben ser especificos y accionables (NN/g). Si el frontend mezcla ambas cosas, soporte y producto terminan leyendo la misma señal de formas muy distintas.

Un patron de React para avisar sin romper el foco

Lo que mejor me funciona es mantener el input quieto y cambiar solo una pista persistente debajo del campo. Nada de modales, nada de banners grandotes. Solo una region estable con severidad clara.

import { useId, useState } from "react";

type EmailHint =
  | { kind: "idle"; message: string }
  | { kind: "info"; message: string }
  | { kind: "warning"; message: string }
  | { kind: "error"; message: string };

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

function getEmailHint(email: string): EmailHint {
  if (!email) {
    return {
      kind: "idle",
      message: "Usa un correo que puedas abrir hoy si vas a terminar el registro."
    };
  }

  if (!email.includes("@") || !email.includes(".")) {
    return {
      kind: "error",
      message: "Revisa el formato del correo antes de continuar."
    };
  }

  const domain = email.split("@")[1]?.toLowerCase() ?? "";

  if (TEMP_DOMAINS.has(domain)) {
    return {
      kind: "warning",
      message: "Este dominio puede expirar antes de recibir el enlace de acceso."
    };
  }

  return {
    kind: "info",
    message: "Te enviaremos un enlace de verificacion a este correo."
  };
}

export function SignupEmailField() {
  const hintId = useId();
  const [email, setEmail] = useState("");
  const hint = getEmailHint(email);

  return (
    <label className="email-field">
      <span>Correo</span>
      <input
        type="email"
        value={email}
        onChange={(event) => setEmail(event.target.value)}
        aria-describedby={hintId}
        aria-invalid={hint.kind === "error" || undefined}
      />
      <span
        id={hintId}
        className="email-hint"
        data-kind={hint.kind}
        aria-live="polite"
      >
        {hint.message}
      </span>
    </label>
  );
}

Lo importante aqui no es la lista de dominios. Eso puede venir de backend o de una regla remota. Lo importante es que el componente no inventa una penalizacion. Solo explica una condicion con bastante precision. Si tu equipo ya piensa las alertas operativas con ese cuidado, la idea se parece mucho a esto de validar correos de Alertmanager: la señal sirve cuando llega con contexto, no cuando solo mete ruido.

CSS y accesibilidad para mantener estabilidad visual

Una pista estable necesita poco CSS, pero ese poco importa:

.email-hint {
  display: block;
  min-height: 1.5rem;
  margin-top: 0.4rem;
  font-size: 0.92rem;
  line-height: 1.4;
}

.email-hint[data-kind="idle"],
.email-hint[data-kind="info"] {
  color: #5f6b76;
}

.email-hint[data-kind="warning"] {
  color: #9a4d00;
}

.email-hint[data-kind="error"] {
  color: #b42318;
}

Hay tres detalles que me parecen especialmente utiles:

• reservar altura para que el CTA no salte
• usar aria-live="polite" en vez de anunciar cada cambio como emergencia
• no mover el foco salvo que exista un error real al enviar

Con eso, la advertencia deja de competir con el input. La persona sigue escribiendo y entiende la consecuencia. Ese equilibrio parece pequeño, pero en formularios de signup evita mucha friccion medio tonta. Tambien hace mas facil analizar comportamiento despues, porque no mezclas una perdida visual de foco con una decision genuina de la persona.

Cuando conviene advertir y cuando no

No todo correo temporal necesita el mismo tratamiento. Para un trial corto, un entorno de pruebas o una demo comercial, una advertencia suele alcanzar. Para recuperacion de cuenta, billing o avisos criticos, probablemente necesitas una politica mas dura en servidor. El frontend no deberia fingir que decide eso solo.

Yo intentaria mostrar el warning cuando ya hay dominio suficiente para justificarlo. Antes de eso, el mensaje cambia demasiado y el campo queda algo nervioso. Tambien conviene registrar esos casos por separado. Si mezclas cosas como temp org mail con errores reales de sintaxis, el analisis posterior queda bastante feote y terminas discutiendo datos que no describen el problema de verdad.

En equipos donde frontend y plataforma colaboran bien, esta separacion ahorra tiempo. Un buen ejemplo lateral es el trabajo de alertas nocturnas por correo: cuando cada estado significa algo concreto, responder se vuelve bastante mas rapido.

Checklist corto para revisar antes de publicar

• diferencia formato invalido de riesgo contextual
• mantiene una region estable para el helper text
• explica la consecuencia con una frase corta y accionable
• conserva el foco en el input mientras la persona escribe
• deja la politica final y el bloqueo duro en backend

No es un patron revolucionario, claro. Pero si hace que el formulario se sienta mas confiable, mas accesible y bastante menos tosco.

Q&A

Debo bloquear siempre un dominio temporal?

No. Si el flujo acepta demos, QA o activaciones breves, una advertencia puede ser suficiente. El bloqueo duro tiene sentido cuando la recuperacion o la entrega futura son requisito del producto.

Conviene avisar en cada tecla?

Solo cuando ya tienes una señal clara, normalmente el dominio completo. Antes de eso el mensaje cambia demasiado y se siente inquieto de una forma poco util.

Esto mejora UX o performance?

Las dos cosas. Mejora comprension y tambien evita saltos visuales innecesarios. No siempre sube una metrica gigante de golpe, pero si reduce pequeñas fugas de confianza que luego cuestan mas de explicar.