React
Explica cómo modelar validación, envío, errores, éxito y estados pendientes en formularios React sin mezclar reglas de dominio con detalles de interfaz.
Un formulario puede estar idle, submitting, success o error. Diseña transiciones claras.
async function handleSubmit(event: React.FormEvent<HTMLFormElement>) {
event.preventDefault();
setStatus("submitting");
try {
await saveUser(form);
setStatus("success");
} catch (error) {
setStatus("error");
}
}required, type, minLength.Nunca confíes únicamente en el cliente.
Mostrar errores desde el primer render suele ser ruidoso. Considera touched, intento de submit o validación al salir del campo.
Deshabilita el submit o utiliza el estado pending de Actions.
Relaciona el error con el campo usando aria-describedby y comunica errores globales con regiones apropiadas.
La validación mejora feedback; el servidor sigue siendo la fuente de verdad.
Evita booleanos independientes. Usa una unión que represente transiciones válidas:
type SubmitState =
| { status: "idle" }
| { status: "submitting" }
| { status: "success"; message: string }
| { status: "error"; formError: string; fieldErrors: Record<string, string> };idle → submitting → success
↘ error → submittingEsto hace explícito qué datos existen en cada fase.
<input type="email" required minlength="5">Aporta semántica, teclado móvil y validación básica.
Mejora feedback, reglas entre campos y experiencia. Puede alterarse y nunca es autoridad de seguridad.
Valida tipos, permisos, reglas de negocio, unicidad y estado actual de los datos. Debe ejecutarse incluso si el cliente ya mostró todo como válido.
Modela touched o submitAttempted solo si cambia la experiencia.
const result = {
fieldErrors: {
email: "Este correo ya está registrado",
},
formError: "No pudimos crear la cuenta",
};Un error de campo debe aparecer junto al control. Un fallo general de red o servidor pertenece a una región global. No reduzcas todo a “Algo salió mal” si puedes orientar al usuario sin exponer detalles internos.
function EmailField({ error }: { error?: string }) {
const id = useId();
const errorId = `${id}-error`;
return (
<div>
<label htmlFor={id}>Correo</label>
<input
id={id}
name="email"
type="email"
aria-invalid={Boolean(error)}
aria-describedby={error ? errorId : undefined}
/>
{error && <p id={errorId}>{error}</p>}
</div>
);
}Tras un submit fallido, mueve foco al resumen o primer campo inválido cuando ayude. No uses role="alert" en cada validación por tecla.
if (state.status === "submitting") return;También deshabilita el botón o usa pending de Actions. La protección cliente mejora UX, pero el servidor debe manejar reintentos y duplicados mediante idempotencia cuando la operación lo necesite.
No limpies el formulario al iniciar. Si falla, el usuario debería conservar lo escrito. Limpia únicamente tras confirmación de éxito o cuando el producto lo solicite claramente.
async function handleSubmit(event: React.FormEvent<HTMLFormElement>) {
event.preventDefault();
const form = event.currentTarget;
const formData = new FormData(form);
setState({ status: "submitting" });
try {
const result = await createUser(formData);
if (!result.ok) {
setState({
status: "error",
formError: result.formError,
fieldErrors: result.fieldErrors,
});
return;
}
setState({ status: "success", message: "Usuario creado" });
form.reset();
} catch {
setState({
status: "error",
formError: "No fue posible conectar con el servidor",
fieldErrors: {},
});
}
}Distingue errores esperados de validación, conflictos de negocio y fallos inesperados.
Comprobar disponibilidad mientras se escribe necesita debounce, cancelación y estados como checking, available o unavailable. No uses el resultado cliente como garantía: el valor puede cambiar antes del submit.
Decide:
Un reducer puede modelar transiciones complejas mejor que muchos booleanos.
No toda mutación necesita optimismo. Es adecuado cuando:
Para pagos, permisos o eliminaciones sensibles, espera confirmación o solicita una confirmación explícita.
Prueba:
Usa interacción realista con userEvent y mockea el límite de red.
FormData como no confiable.Actions y useActionState integra mutaciones y pending con el árbol del formulario.