JavaScript: validación de datos

Validar datos es una de esas tareas que parecen pequeñas hasta que una interfaz empieza a recibir información real. Una persona puede dejar un campo vacío, escribir espacios, equivocarse en el correo, poner una nota fuera de rango o completar un teléfono con letras. La validación no existe para regañar al usuario, sino para proteger el flujo y ayudarle a corregir a tiempo.

En el capítulo anterior construimos formularios interactivos: escuchamos el evento submit, leímos datos con FormData y mostramos mensajes. Ahora daremos el paso siguiente: definir reglas claras, separar la validación del renderizado y mostrar errores útiles sin convertir la pantalla en una pelea.

Qué aprenderás hoy

• Diferenciar validación HTML5, validación con JavaScript y validación del servidor.
• Aplicar reglas para campos requeridos, longitudes, correos y rangos numéricos.
• Crear funciones de validación que devuelvan objetos fáciles de usar.
• Mostrar mensajes junto a cada campo usando el DOM.
• Evitar errores comunes como validar solo con color o confiar únicamente en el cliente.

Por qué importa la validación

En una aplicación real, los datos alimentan decisiones. Un correo puede servir para recuperar una cuenta. Una nota puede definir si una estudiante aprueba. Un precio puede afectar un total. Un campo mal validado puede generar errores visuales, cálculos incorrectos o registros inútiles.

También hay una dimensión de experiencia de usuario. Cuando un formulario dice simplemente “error”, obliga a la persona a adivinar. En cambio, si el mensaje dice “Ingresa un correo con @ y dominio”, la interfaz se vuelve más amable y eficiente.

Como regla de ingeniería, conviene validar en capas. El navegador puede ayudarnos con atributos HTML. JavaScript puede mejorar la respuesta inmediata. El servidor debe validar de nuevo antes de guardar datos. En este curso empezaremos por el cliente, pero sin olvidar esa arquitectura.

Primera capa: validación HTML5

HTML ya ofrece varias herramientas útiles. No resuelven todos los casos, pero reducen errores básicos y hacen que el formulario tenga más significado.

<form id="student-form">
  <label for="name">Nombre completo</label>
  <input id="name" name="name" type="text" required minlength="3">

  <label for="email">Correo institucional</label>
  <input id="email" name="email" type="email" required>

  <label for="grade">Nota final</label>
  <input id="grade" name="grade" type="number" min="0" max="20" required>

  <button type="submit">Guardar</button>
</form>

Con required, minlength, type="email", min y max, el navegador ya conoce algunas reglas. Esto no reemplaza nuestra lógica, pero sí establece una base semántica. Si el HTML puede expresar una regla sencilla, úsalo.

Leer los datos del formulario

Partiremos del mismo patrón del capítulo anterior. Una función lee los datos y devuelve un objeto. Así la validación no depende directamente del DOM.

function readStudentForm(formElement) {
  const formData = new FormData(formElement);

  return {
    name: String(formData.get("name")).trim(),
    email: String(formData.get("email")).trim(),
    grade: Number(formData.get("grade"))
  };
}

El detalle importante está en la conversión. Los formularios entregan texto. Si vamos a comparar una nota con números, primero debemos convertirla con Number(). Luego podremos validar si realmente es un número válido.

Ejemplo básico: validar campo por campo

Una forma clara de empezar es crear funciones pequeñas. Cada función se encarga de una regla y devuelve un resultado consistente.

function validateName(name) {
  if (name === "") {
    return { valid: false, message: "Escribe tu nombre completo." };
  }

  if (name.length < 3) {
    return { valid: false, message: "El nombre debe tener al menos 3 caracteres." };
  }

  return { valid: true, message: "" };
}

function validateEmail(email) {
  if (email === "") {
    return { valid: false, message: "Escribe tu correo institucional." };
  }

  if (!email.includes("@")) {
    return { valid: false, message: "El correo debe incluir @." };
  }

  return { valid: true, message: "" };
}

function validateGrade(grade) {
  if (!Number.isFinite(grade)) {
    return { valid: false, message: "La nota debe ser un número." };
  }

  if (grade < 0 || grade > 20) {
    return { valid: false, message: "La nota debe estar entre 0 y 20." };
  }

  return { valid: true, message: "" };
}

Este patrón se puede leer casi como una lista de reglas. Si algo falla, devolvemos valid: false y un mensaje. Si todo está bien, devolvemos valid: true.

Validar el formulario completo

Ahora necesitamos reunir las reglas. En vez de mostrar solo el primer error, podemos devolver un objeto con los errores de cada campo. Esto será muy útil cuando queramos pintar mensajes junto a cada input.

function validateStudent(student) {
  const errors = {
    name: validateName(student.name).message,
    email: validateEmail(student.email).message,
    grade: validateGrade(student.grade).message
  };

  const isValid = Object.values(errors).every(function (message) {
    return message === "";
  });

  return {
    valid: isValid,
    errors: errors
  };
}

Aquí aparece Object.values(), que nos permite tomar los mensajes del objeto y revisarlos como una lista. En el siguiente capítulo trabajaremos con arreglos y objetos con más calma, pero este ejemplo ya muestra por qué son tan importantes.

Mostrar errores cerca de cada campo

Una validación útil debe decir dónde está el problema. Para eso podemos preparar pequeños espacios debajo de cada input.

<label for="name">Nombre completo</label>
<input id="name" name="name" type="text" aria-describedby="name-error">
<p id="name-error" class="field-error"></p>

<label for="email">Correo institucional</label>
<input id="email" name="email" type="email" aria-describedby="email-error">
<p id="email-error" class="field-error"></p>

<label for="grade">Nota final</label>
<input id="grade" name="grade" type="number" aria-describedby="grade-error">
<p id="grade-error" class="field-error"></p>

El atributo aria-describedby conecta el campo con su mensaje de ayuda o error. No es solamente detalle técnico: ayuda a que la interfaz comunique mejor el problema a tecnologías de asistencia.

function renderErrors(errors) {
  document.querySelector("#name-error").textContent = errors.name;
  document.querySelector("#email-error").textContent = errors.email;
  document.querySelector("#grade-error").textContent = errors.grade;
}

Más adelante podríamos optimizar esta función para no repetir selectores. Por ahora, la ventaja es que se entiende muy bien qué mensaje corresponde a cada campo.

Ejemplo mejorado: flujo completo

Juntando las piezas, el evento submit queda breve. Esa es una señal saludable: el evento coordina, pero no carga con toda la lógica.

const form = document.querySelector("#student-form");
const statusMessage = document.querySelector("#form-status");

form.addEventListener("submit", function (event) {
  event.preventDefault();

  const student = readStudentForm(form);
  const result = validateStudent(student);

  renderErrors(result.errors);

  if (!result.valid) {
    statusMessage.textContent = "Revisa los campos marcados antes de continuar.";
    statusMessage.className = "result result-error";
    return;
  }

  statusMessage.textContent = "Datos listos para guardar.";
  statusMessage.className = "result result-success";
});

Este código ya tiene una estructura profesional para proyectos pequeños: leer, validar, renderizar errores y decidir si se continúa. Cuando lleguemos a CRUD, este patrón será la antesala de guardar datos en memoria, en archivos JSON o en MySQL.

Validación en tiempo real sin molestar

Podemos validar mientras el usuario escribe, pero con cuidado. Si mostramos errores demasiado pronto, la interfaz puede sentirse ansiosa. Una estrategia sencilla es validar después de que el campo pierde foco con el evento blur.

const emailInput = document.querySelector("#email");
const emailError = document.querySelector("#email-error");

emailInput.addEventListener("blur", function () {
  const result = validateEmail(emailInput.value.trim());
  emailError.textContent = result.message;
});

Este enfoque ayuda sin interrumpir. El usuario termina de escribir, sale del campo y recién entonces recibe una señal. Para campos como contraseñas, puede tener sentido mostrar reglas en vivo; para otros, conviene ser más discreto.

Errores comunes

• Validar únicamente con email.includes("@") y asumir que todos los correos serán correctos.
• Olvidar convertir valores numéricos antes de compararlos.
• Mostrar errores solo con color, sin texto claro.
• Usar alert() para todos los errores y cortar la experiencia.
• Mezclar lectura, validación, estilos y guardado en una sola función enorme.
• Confiar en la validación del cliente como si fuera seguridad del sistema.

Buenas prácticas

• Escribe reglas simples y mensajes específicos.
• Valida espacios con trim() cuando corresponda.
• Convierte números antes de compararlos.
• Devuelve objetos de resultado como { valid, message } o { valid, errors }.
• Muestra los errores cerca del campo relacionado.
• Usa HTML semántico antes de agregar JavaScript.
• Vuelve a validar en el servidor en cualquier proyecto real.

Reto práctico

Variante extra: agrega una regla para que el correo termine en .edu.pe o pertenezca a un dominio institucional ficticio. Luego separa tus funciones en cuatro bloques: leer datos, validar datos, mostrar errores y mostrar estado general.

Conclusión

La validación de datos convierte un formulario en una conversación más clara. Ya no se trata solo de recibir valores, sino de revisar si esos valores tienen sentido y de explicar cómo corregirlos cuando algo falla.

Una interfaz madura no espera al último momento para decir “algo salió mal”. Acompaña al usuario, respeta su tiempo y protege la calidad de los datos. Esa mentalidad será clave cuando empecemos a trabajar con listas, objetos y operaciones CRUD.

En el siguiente capítulo entraremos justamente en arreglos y objetos, dos estructuras fundamentales para representar datos, recorrer colecciones y preparar nuestras primeras aplicaciones con registros en memoria.

Fuentes consultadas

• MDN Web Docs: Client-side form validation
• MDN Web Docs: HTMLFormElement checkValidity()
• MDN Web Docs: ValidityState
• MDN Web Docs: HTML attribute required
• W3C WAI: User notification in forms