DevHive

1) ¿Qué es una condicional y por qué es la base de la “automatización” en la web?

Cuando empecé a construir interfaces que “reaccionaran” a lo que hacía la gente, descubrí que todo empieza con una pregunta binaria: ¿se cumple esta condición? Si sí → haz esto; si no → haz lo otro. En mis proyectos lo vivo como un sí/no encadenado que empuja el flujo hasta un resultado concreto. Por eso, si ya dominaste variables, tipos y manipulación del DOM, aquí es donde “se enciende” la lógica de negocio y la página pasa de estática a dinámica.

Una condicional evalúa una expresión booleana. Si es true, ejecuta un bloque de código; si es false, lo salta. Eso puede significar mostrar/ocultar elementos, validar formularios, decidir a qué ruta navegar o aplicar un precio según el rol del usuario. En mi caso, lo veo como la base de la automatización: pequeñas decisiones que, juntas, mueven al usuario por el proceso correcto.

Ejemplo mínimo:

const estaLogueado = Boolean(localStorage.getItem('token'));

if (estaLogueado) {
  mostrarPanel();
} else {
  redirigirALogin();
}

Ideas clave para interiorizar:

Lectura antes que código: escribe condiciones que se lean como frases (“si el carrito está vacío, desactiva el botón”).
Bloques {} siempre: incluso en una sola línea; evita sustos de legibilidad.
Predica con nombres: tieneDescuento, esMayorDeEdad → expresan intención.

Cuando quiero que una página reaccione a lo que hace el cliente, las condicionales son la base de esa “automatización”. Son esenciales porque convierten eventos (clicks, cambios, peticiones) en decisiones que acercan al objetivo del usuario.

2) if, else if, else: sintaxis, ejemplos y buenas prácticas

La forma más común de una condicional es:

if (condicion) {
  // rama verdadera
} else if (otraCondicion) {
  // segunda opción
} else {
  // caso por defecto
}

Buenas prácticas que aplico a diario

Condiciones positivas: prefiero if (esValido) a if (!invalido).
Evitar condiciones con efectos: nada de if (x = obtenerValor()) por accidente.
“Guard clauses” para salir antes y aplanar anidaciones:

function procesarPedido(pedido) {
  if (!pedido) return;                 // guard clause
  if (pedido.items.length === 0) return;

  if (pedido.total > 100) {
    aplicarEnvioGratis(pedido);
  }
  confirmar(pedido);
}

Rango de valores con else if

Cuando la decisión depende de rangos, else if brilla:

function clasificarIMC(imc) {
  if (imc < 18.5) return 'bajo';
  else if (imc < 25) return 'normal';
  else if (imc < 30) return 'sobrepeso';
  return 'obesidad';
}

Truthy y falsy (sin mitos)

En JavaScript son falsy: false, 0, -0, 0n, "" (string vacío), null, undefined, NaN. No son falsy: [], {}, "0", "false". Así que:

if ([]) console.log('Se ejecuta');     // [] es truthy
if ({}) console.log('También se ejecuta');

En mi cabeza siempre repito esta lista para evitar bugs sutiles al validar datos.

3) switch: cuándo usarlo y cómo evitar errores con break

switch es ideal cuando comparas el mismo valor contra múltiples opciones discretas. Gana legibilidad frente a cadenas largas de else if.

function mensajeSegunDia(dia) {
  switch (dia) {
    case 'lun': return 'Arrancamos';
    case 'mar': return 'Seguimos';
    case 'mie': return 'Mitad de semana';
    case 'jue': return 'Casi';
    case 'vie': return '¡Viernes!';
    default:    return 'Fin de semana';
  }
}

Consejos prácticos

Siempre contempla default: evita estados sin cubrir.
Evita el fallthrough involuntario: usa return como arriba, o break en cada case:

let nivel = 'pro';

switch (nivel) {
  case 'basico':
    mostrarTips();
    break;
  case 'intermedio':
    mostrarRetos();
    break;
  case 'pro':
    mostrarAtajos();
    break;
  default:
    mostrarOnboarding();
}

Mapeos con objetos: a veces reemplazan switch con menos ruido:

const mensajes = {
  lun: 'Arrancamos',
  mar: 'Seguimos',
  mie: 'Mitad de semana',
  jue: 'Casi',
  vie: '¡Viernes!',
};
const texto = mensajes[dia] ?? 'Fin de semana';

En mis flujos de UI, cuando tengo muchos valores conocidos (estados de un pedido, roles, tipos de notificación), switch o un objeto de mapeo me da una lectura más limpia que varios else if. Pienso en if/else como un sí/no encadenado y en switch como tabla de decisiones.

4) Elegir entre if/else, switch y operador ternario: criterios prácticos

Usa if/else cuando evalúas condiciones complejas o rangos y el orden importa.
Usa switch cuando comparas un único campo contra muchos valores exactos y quieres una visión “vertical” clara.
Usa ternario (cond ? a : b) solo para expresiones simples (asignar/retornar), nunca para efectos con muchas líneas.

Ejemplos de decisión:

// 1) Ternario correcto (simple y expresivo)
const estado = isOnline ? 'conectado' : 'desconectado';

// 2) Ternario incorrecto (demasiado anidado → mejor if/else)
const etiqueta =
  puntos > 100 ? 'oro' :
  puntos > 50  ? 'plata' :
  puntos > 10  ? 'bronce' : 'nuevo';   // -> pásalo a if/else

Regla personal que me funciona: si el ternario no cabe mentalmente en una frase corta, cambio a if/else. Cuando probé a forzar ternarios complejos, la legibilidad se fue al piso.

5) Errores comunes y cómo evitarlos (coerción, truthy/falsy, bloques {})

Olvidar break en switch → fallthrough inesperado.
Solución: usa return por case o break disciplinado.
Confiar en checks “vacíos”:

const filtros = {};
if (filtros) { /* se ejecuta */ } // {} es truthy

Solución: valida propiedad/longitud: Object.keys(filtros).length === 0.
Anidar demasiado: if dentro de if dentro de if.
Solución: guard clauses, funciones pequeñas y early returns.
Asignación en lugar de comparación: if (x = 1).
Solución: usa linters y === por defecto.
Comparar con falsy sin querer:

const valor = 0;
if (!valor) { /* entra */ } // 0 es falsy, ¿querías eso?

Solución: valida explícito: valor === 0.
Olvidar llaves:

if (ok) hacerA(); hacerB(); // solo A está condicionado

Solución: siempre llaves aunque sea una línea.

En proyectos reales, estas decisiones controlan el flujo para alcanzar el objetivo sin desviarnos. Cuando empecé, subestimé cuánto claridad y disciplina ahorran bugs.

6) Casos reales: decisiones de usuario en el DOM (formularios, roles, rutas)

Validación de formularios

form.addEventListener('submit', (e) => {
  e.preventDefault();
  const email = emailInput.value.trim();
  const pass  = passInput.value;

  if (!email || !pass) {
    mostrarError('Completa todos los campos');
    return; // guard clause
  }

  if (!email.includes('@')) {
    mostrarError('Email no válido');
    return;
  }

  enviarFormulario();
});

Mostrar/ocultar según acción

toggleBtn.addEventListener('click', () => {
  const abierto = panel.classList.contains('open');
  if (abierto) panel.classList.remove('open');
  else panel.classList.add('open');
});

Permisos por rol (mapeo + if)

const permisosPorRol = {
  admin: ['leer', 'editar', 'borrar'],
  editor: ['leer', 'editar'],
  lector: ['leer']
};

function puede(rol, accion) {
  return (permisosPorRol[rol] ?? []).includes(accion);
}

if (puede(usuario.rol, 'borrar')) {
  mostrarBotonEliminar();
}

Rutas condicionales (client-side)

function irADashboard(usuario) {
  if (!usuario) return ir('/login');

  switch (usuario.rol) {
    case 'admin':  return ir('/admin');
    case 'editor': return ir('/editor');
    default:       return ir('/inicio');
  }
}

En mi práctica, encadeno estos sí/no para construir flujos claros que guían al cliente al resultado esperado.

7) Snippets reutilizables para tu día a día

1) “Require” con mensaje estándar

const requireValue = (val, msg = 'Dato requerido') => {
  if (val === null || val === undefined || val === '') throw new Error(msg);
  return val;
};

2) Normalizar truthy/falsy sin sustos

const isEmptyObject = (obj) => obj && Object.keys(obj).length === 0;
const isBlank = (s) => typeof s === 'string' && s.trim() === '';

3) Tabla de decisión compacta

const estadoAClase = {
  success: 'is-success',
  warning: 'is-warning',
  error:   'is-error',
};

element.className = estadoAClase[estado] ?? 'is-default';

4) Guard clause para precondiciones

function descargar(url) {
  if (!/^https?:\/\//.test(url)) throw new Error('URL inválida');
  // ...
}

5) Anti-anidación

function pagar(carrito) {
  if (!carrito) return;

  if (carrito.items.length === 0) {
    return mostrarMensaje('Carrito vacío');
  }

  if (carrito.total <= 0) {
    return mostrarMensaje('Total inválido');
  }

  confirmarPago(carrito);
}

8) FAQs rápidas sobre condicionales en JS

¿elseif existe en JavaScript?
No. Se escribe else if (dos palabras).

¿Cuándo prefiero switch?
Cuando comparo un mismo valor frente a muchas opciones exactas (estados, roles, códigos).

¿Ternario o if/else?
Ternario para expresiones simples (asignar/retornar). Si hay varios pasos o condiciones anidadas, usa if/else.

¿Cómo pruebo condicionales?
Cubre ambos caminos (verdadero/falso) y casos borde: 0, "", null, NaN, [], {}.

¿Qué valores son falsy?
false, 0, -0, 0n, "", null, undefined, NaN.

Conclusión

Las condicionales son el motor de decisiones de tu aplicación. En mi día a día, pienso en if/else como un sí/no encadenado y en switch como una tabla de decisiones para valores discretos. Con unas pocas reglas —llaves siempre, guard clauses, evitar ternarios complejos, conocer bien los falsy— tu código gana en claridad y tus interfaces en comportamiento inteligente. Al final, de eso va la “automatización”: decisiones pequeñas y bien escritas que llevan al usuario al lugar correcto.

Condicionales en JavaScript: if, else y switch explicados con ejemplos