En muchos formularios React, el campo de email falla no porque la expresion regular sea mala, sino porque la interfaz se pone nerviosa demasiado pronto. La persona escribe tres letras, aparece un error rojo, desaparece, vuelve a salir, y el input termina sintiendose mas reganon que util. Ese detalle baja bastante la calidad percibida del flujo, aunque la logica sea correcta.
Ultimamente intento separar tres momentos: escribir, comprobar y anunciar. Parece un cambio pequeño, pero mejora mucho la sensacion de control. Tambien reduce trabajo visual innecesario, que en moviles o equipos lentos se nota mas de lo que a veces admitimos.
Cuando validar demasiado pronto empeora el formulario
Validar en cada tecla suena moderno, pero muchas veces mete mas friccion que valor. Mientras alguien aun esta escribiendo maria@emp, no necesita una alerta dramatica. Necesita terminar la idea.
Ese error temprano rompe ritmo, ensucia el area visible y ademas hace que el usuario dude si el problema es suyo o del sistema. En productos con bastante onboarding, este tipo de micro-friccion se acumula rapido. La interfaz parece activa, si, pero no siempre parece lista.
Por eso me gusta pensar este campo igual que otros flujos donde la claridad manda primero, como estos runbooks de email que si escalan. Si el sistema distingue bien cada etapa, luego es mas facil leer el estado y corregir algo sin adivinar.
Tambien sirve cuando QA hace pruebas con un correo temporal gratis o con valores medio raros de tem email para revisar copy, foco y mensajes. Si el componente reacciona a todo como si fuera una emergencia, cuesta ver que bug era real y cual fue puro ruido, la verdad.
El patron: separa escritura, comprobacion y anuncio
La idea practica es esta:
- mientras la persona escribe, solo guardas valor y limpias ruido viejo
- cuando sale del campo o intenta enviar, validas de verdad
- solo anuncias error cuando ya hay una decision util que mostrar
Eso evita castigar cada tecla y mantiene el feedback ligado a una accion entendible. No es una regla rigida para todos los casos, pero en formularios de registro suele funcionar bastante bien.
Tambien ayuda a performance percibida. Si cada pulsacion dispara validacion compleja, analytics, estilos y mensajes, el campo parece pegajoso. No hablo siempre de un cuello de botella enorme; hablo de esa sensacion pequena de "algo no va fino". Y esa sensacion importa un monton en frontend.
Un ejemplo simple en React
Este es un enfoque bastante terrenal:
import { useState } from "react";
const emailLooksValid = (value) => /\S+@\S+\.\S+/.test(value);
export default function EmailField() {
const [value, setValue] = useState("");
const [touched, setTouched] = useState(false);
const showError = touched && value.length > 0 && !emailLooksValid(value);
const message = showError ? "Escribe un email valido" : " ";
return (
<label className="field">
<span className="label">Email</span>
<input
type="email"
value={value}
onChange={(event) => setValue(event.target.value)}
onBlur={() => setTouched(true)}
aria-invalid={showError}
aria-describedby="email-help"
/>
<span id="email-help" className={showError ? "note error" : "note"}>
{message}
</span>
</label>
);
}
El truco no esta en la regex. Esta en que el error aparece cuando el usuario ya termino un primer intento. Eso vuelve el mensaje mas justo. Tambien deja el campo visualmente mas estable, porque la ayuda existe desde el principio y no entra a empujones.
Si el formulario hace llamadas remotas, ya prefiero mover comprobaciones costosas fuera del onChange. Primero confirmo formato local y luego, si hace falta, reviso disponibilidad o reglas del backend. En interfaces con varios estados, esa separacion recuerda bastante a escribir correos claros en mantenimientos: cada señal llega cuando toca, no toda a la vez.
Que revisar para que tambien rinda mejor
Hay varias cosas pequeñas que suelo mirar:
- no recalcular validaciones pesadas en cada pulsacion
- reservar espacio para el helper o el error
- no pintar rojo un campo vacio nada mas cargar
- mantener mensajes cortos, especificos y faciles de leer
- probar en movil con teclado abierto, que ahi todo se vuelve mas sensible
Si usas autoguardado, telemetria o una comprobacion async, mejor aun si desacoplas eso del feedback inmediato. Una persona no deberia notar que internamente estas registrando eventos, consultando reglas o comparando dominios raros como temp org mail. Si lo nota, algo ya esta compitiendo con la tarea principal.
En accesibilidad, lo minimo para mi es:
-
aria-invalidsolo cuando el error es real -
aria-describedbyenlazando la ayuda - contraste suficiente
- texto que diga que corregir, no solo que algo "esta mal"
Ese ultimo punto parece obvio, pero no siempre pasa. "Email invalido" informa poco. "Escribe un email con formato nombre@dominio.com" guia bastante mejor, incluso si no es perfecto para todos los casos.
Preguntas que me hago antes de darlo por bueno
Q: ¿Valido al escribir alguna vez?
A: Si, pero solo en casos muy concretos, como sugerencias suaves o autocompletado. Para error formal, prefiero esperar a blur o submit.
Q: ¿Esto hace el formulario mas lento?
A: Normalmente al reves. Al quitar trabajo y cambios visuales por tecla, el flujo se siente bastante mas liviano, aunque el ahorro tecnico sea pequeño.
Q: ¿Y si necesito feedback instantaneo?
A: Intento que sea feedback neutral primero. Ayuda, pista o progreso. Error fuerte solo cuando ya hay contexto suficiente. Si no, el campo se vuelve un semaforo histérico, y eso cansa rapido.
Al final, validar email bien no es solo aceptar o rechazar una cadena. Es decidir cuando hablar y con que intensidad. En React, ese timing vale casi tanto como la validacion misma. Cuando lo ajustas bien, el formulario se siente mas claro, mas rapido y un poco mas humano, aunque tenga algun detallecito imperfecto por ahi.
Top comments (0)