React: autocompletar email sin ruido

Cuando un campo de email intenta ayudar demasiado pronto, termina molestando. Lo veo mucho en flujos de registro: la persona escribe tres letras, aparece una sugerencia agresiva, cambia el layout, se pinta el borde, y ya parece que hizo algo mal. No es un bug enorme, pero si desgasta bastante la sensacion del formulario.

En productos donde tambien importa detectar un correo de usar y tirar o separar pruebas de cuentas reales, la tentacion es meter toda la inteligencia dentro del input. Ahi es donde casi siempre se complica. El campo deja de ser una ayuda y pasa a ser una mini policia de negocio. Para mi, React funciona mejor cuando ese input solo resuelve una cosa a la vez: escribir bien, sugerir con calma y explicar claro.

Por que el autocompletado de email suele fallar

El fallo comun no es tecnico. Es de ritmo.

Muchas implementaciones mezclan al mismo tiempo:

1. sugerencias de dominios
2. validacion de formato
3. reglas de negocio sobre dominios
4. mensajes visuales que entran y salen

Ese combo hace que el input se sienta nervioso. Si alguien escribe [e-mail], por ejemplo, la interfaz deberia ayudar a corregir, no abrir tres estados distintos. Tambien he visto equipos meter notas de QA como temp mailid en tickets o dashboards y despues usar esa misma señal como si fuera evidencia suficiente en el cliente. No lo es, o no deberia serlo.

En vez de eso, me gusta pensar el campo como un pequeño asistente local: observa formato, ofrece una correccion obvia y deja las decisiones mas sensibles para submit o backend. Esa separacion baja ruido y hace mas facil medir si la UX de verdad mejora.

Un patron de React para sugerir sin distraer

Un enfoque simple es mantener tres piezas de estado:

1. value para el texto actual
2. suggestion para un dominio probable
3. active para saber si la lista esta visible

Con eso ya puedes construir algo bastante estable:

import { useId, useState } from "react";

const commonDomains = ["gmail.com", "outlook.com", "hotmail.com"];

function getSuggestion(value: string) {
  const [name, domain = ""] = value.split("@");

  if (!name || !domain) return "";

  return commonDomains.find((item) => item.startsWith(domain)) ?? "";
}

export function EmailInput() {
  const listId = useId();
  const [value, setValue] = useState("");
  const [open, setOpen] = useState(false);

  const suggestion = getSuggestion(value);

  return (
    <div className="email-field">
      <label htmlFor="email">Email</label>
      <input
        id="email"
        type="email"
        value={value}
        autoComplete="email"
        aria-expanded={open ? "true" : "false"}
        aria-controls={listId}
        onChange={(event) => {
          const nextValue = event.target.value;
          setValue(nextValue);
          setOpen(Boolean(getSuggestion(nextValue)));
        }}
        onBlur={() => setOpen(false)}
      />

      {open && suggestion && (
        <button
          type="button"
          id={listId}
          className="suggestion"
          onMouseDown={(event) => event.preventDefault()}
          onClick={() => {
            const [name] = value.split("@");
            setValue(`${name}@${suggestion}`);
            setOpen(false);
          }}
        >
          Quisiste decir {nameFromEmail(value)}@{suggestion}
        </button>
      )}
    </div>
  );
}

function nameFromEmail(value: string) {
  return value.split("@")[0] ?? "";
}

No es un combobox perfecto, pero ya evita un problema muy comun: la sugerencia aparece como accion opcional y no como correccion autoritaria. Eso importa mas de lo que parece, porqe las personas toleran ayuda, pero odian sentir que la UI les quita control.

Si tu equipo esta afinando eventos de activacion y seguimiento, conviene separar estas sugerencias de cualquier logica de negocio. Un buen paralelo esta en revisar emails de activacion sin perder contexto, donde el valor no esta solo en capturar el mensaje, sino en no mezclar señales distintas en el mismo punto del flujo.

Detalles de accesibilidad que cambian el resultado

Muchos campos "bonitos" fallan con teclado o lector de pantalla. Y ahi el coste no es solo etico: tambien empeora la tasa de finalizacion.

Algunas comprobaciones que suelo hacer:

1. la sugerencia debe poder ignorarse sin bloquear escritura
2. el foco no debe saltar cuando aparece ayuda
3. el texto de apoyo necesita una altura estable
4. el contraste del borde y la ayuda debe seguir siendo legible

En CSS, casi siempre reservo espacio para mensaje y lista ligera:

.email-field {
  display: grid;
  gap: 0.4rem;
}

.email-field input {
  border: 1px solid #b6beca;
  border-radius: 0.8rem;
  padding: 0.8rem 0.9rem;
}

.suggestion {
  justify-self: start;
  border: 0;
  background: #eef6ff;
  color: #12467b;
  border-radius: 999px;
  padding: 0.35rem 0.7rem;
}

Ese tipo de detalle reduce reflow y hace que el formulario se sienta mas sereno. Parece menor, pero hay datos decentes de usabilidad que apoyan esta idea: NN/g resume que errores tempranos, ambiguos o intrusivos elevan abandono y confusion en formularios. No hace falta convertir cada input en una ceremonia; solo evitar tropiezos evitables.

Tambien me gusta medir cuanto aparece una sugerencia y cuantas veces se acepta. Si el ratio de aceptacion es bajisimo, probablemente estas mostrando ayuda donde nadie la pidió. Esa es una de esas metricas pequeñas que dicen bastante, aunqe a veces nadie la mira.

Como tratar dominios temporales sin castigar al usuario

Si el producto necesita detectar correo temporal para Facebook u otros casos parecidos, yo no lo pondria dentro del autocompletado. Esa parte pertenece a otra capa. El input puede mostrar formato correcto y, como mucho, un aviso suave cuando el dominio sea poco comun. La decision real sobre bloqueo, advertencia o paso manual deberia vivir en API o en una regla posterior del flujo.

Esto tambien evita que un email legitimo pero raro termine tratado como sospechoso. En onboarding, esa confusion sale cara. Ya sea por QA, marketing o soporte, cada falso positivo añade friccion donde no hacia falta. Me parece mas util seguir el mismo espiritu de medir fallos de verificacion sin frenar producto: separar la observacion de la penalizacion.

Una pauta simple que me funciona:

1. el cliente corrige y explica
2. la API clasifica riesgo
3. el producto decide que hacer con ese riesgo

Eso suena menos brillante que meter todo en un hook, pero escala mejor y ensucia menos el componente. Y, siendo sinceros, deja el codigo bastante mas facil de revisar despues.

Checklist rapido antes de publicar

• La sugerencia se puede ignorar sin bloquear teclado.
• El mensaje de ayuda no mueve botones ni CTA.
• La validacion fuerte no corre en cada tecla.
• El input usa autoComplete="email" antes de inventar magia.
• Los eventos de analitica distinguen sugerencia, formato y regla de negocio.

No es un patron revolucionario. Pero cuando el campo de email deja de pelear con la persona, el resto del formulario respira mejor. En frontend, ese tipo de pulido suma mucho aunque desde fuera paresca pequeño.