El bug no empezó en el error: sigue la conversión que JavaScript hizo por ti

Formulario bajo la lupa: cuatro valores problemáticos, un mismo embudo

En producción, un único formulario puede recibir representaciones de “vacío” que no son equivalentes entre sí. Un backend puede esperar null en una API REST, mientras que la UI, por medio del DOM, captura cadenas. En esa travesía aparecen, a menudo sin ser vistos, coerciones de tipo: al comparar con ==, al usar OR para default, o al convertir texto a número. Por ello, nuestro protocolo de análisis arranca con un pequeño laboratorio en el que fijamos la entrada exacta y medimos la salida con y sin coerciones.

<form id="f">
  <input name="cantidad" value="" />  <!-- el usuario podría enviar '', '0' o nada -->
</form>

<script>
// Captura cruda desde el DOM:
const vCrudo = document.querySelector('[name="cantidad"]').value; // siempre string

// Posibles equivalentes semánticos que llegan al backend:
const vCadena = vCrudo;                  // '', '0'
const vNumero = vCrudo === '' ? NaN : Number(vCrudo); // NaN o 0
const vNulo = vCrudo === '' ? null : vCrudo; // null o '0'
const vIndef = typeof vCrudo === 'undefined' ? undefined : vCrudo; // casi nunca undefined desde DOM

console.log({ vCadena, vNumero, vNulo, vIndef });
</script>

Cuando la fuente es el DOM, recibir undefined es poco común: los campos existen y devuelven al menos la cadena vacía. No obstante, undefined y null aparecen al cargar datos remotos, al leer desde un objeto incompleto o al omitir un parámetro al invocar una función. Por eso nuestro formulario “bajo la lupa” modela entradas que pueden venir tanto de la UI como de un objeto de datos, y las somete a igualdad laxa, estricta y a dos estrategias de valores por defecto (|| y ??). El encadenamiento opcional (?.) se emplea para indagar propiedades anidadas sin lanzar errores.

Lo que el operador laxo silencia: seguir el rastro de ==

La igualdad laxa aplica coerciones antes de decidir. Este rasgo explica una categoría entera de falsos positivos en validaciones. Los siguientes hechos son clave:

• ‘0’ == 0 es true, porque ‘0’ se convierte a número 0.
• » == 0 es true, porque » se convierte a 0 por coerción numérica.
• null == undefined es true, una regla especial del estándar.
• Sin embargo, ‘0’ == » es false; ambos se convierten a números diferentes (0 vs 0) ¿no? Atención: » se convierte a 0; entonces ‘0’ == » evalúa 0 == 0 y da true. Esta sutileza es peligrosa si no se controla la ruta de conversión. En general, comparar cadenas con == puede provocar resultados contraintuitivos si una de ellas es convertible a número.

La documentación de referencia describe con precisión estas normas; consúltala para el detalle formal de los pasos de coerción y las excepciones de null y undefined:
MDN: comparaciones de igualdad y nociones de “mismidad”.

// Tabla ilustrativa con == (laxo)
console.table([
  { a: "'0'", b: "0", expr: "'0' == 0", res: '0' == 0 },
  { a: "''", b: "0", expr: "'' == 0", res: '' == 0 },
  { a: "null", b: "undefined", expr: "null == undefined", res: null == undefined },
  { a: "'0'", b: "''", expr: "'0' == ''", res: '0' == '' },
  { a: "false", b: "''", expr: "false == ''", res: false == '' },
]);

Un patrón conservador de ingeniería en formularios es no usar == para validar intención del usuario. Si se busca “campo vacío”, conviene definirlo por contrato: “cadena vacía tras trim” o “nulo explícito” o “propiedad ausente”. Cualquier otra semántica debe declararse en código con conversión explícita.

El control médico del tipo: por qué === estabiliza el diagnóstico

La igualdad estricta no hace coerción; compara tipo y valor. Esto la vuelve un instrumento de diagnóstico fiable y la puerta de entrada a decisiones deterministas. En el contexto de nuestro formulario:

• ‘0’ === 0 es false (string vs number).
• » === 0 es false.
• null === undefined es false (tipos distintos).
• » === » es true; ‘0’ === ‘0’ es true.

// Tabla ilustrativa con === (estricto)
console.table([
  { a: "'0'", b: "0", expr: "'0' === 0", res: '0' === 0 },
  { a: "''", b: "0", expr: "'' === 0", res: '' === 0 },
  { a: "null", b: "undefined", expr: "null === undefined", res: null === undefined },
  { a: "'0'", b: "'0'", expr: "'0' === '0'", res: '0' === '0' },
  { a: "''", b: "''", expr: "'' === ''", res: '' === '' },
]);

La combinación “captura con ===, normaliza con funciones explícitas” reduce la magia y te obliga a pronunciarte sobre intenciones del usuario. Por ejemplo, si la intención “cero” es válida, conviertes con Number y validas contra 0, no contra » o ‘0’ directamente.

Valores por defecto sin sorpresas: elegir entre || y ?? con conocimiento

El operador OR (||) devuelve el primer operando que sea truthy. La cadena vacía » y el número 0 son falsy; la cadena ‘0’ es truthy. El operador de fusión nula (??) devuelve el lado derecho solo si el izquierdo es null o undefined, sin tratar » ni 0 como carencias. Para defaults en formularios, esta diferencia es decisiva.

const a = '0'  || 'def'; // '0'  (truthy)
const b = ''   || 'def'; // 'def' ('' es falsy)
const c = 0    ||  99;   // 99    (0 es falsy)
const d = null || 'def'; // 'def'
const e = undefined || 'def'; // 'def'

// Fusión nula:
const f = '0'  ?? 'def'; // '0'
const g = ''   ?? 'def'; // ''
const h = 0    ??  99;   // 0
const i = null ?? 'def'; // 'def'
const j = undefined ?? 'def'; // 'def'

Cuando una cadena vacía es una señal legítima del usuario (por ejemplo, “borrar nota”), || la pisará sin preguntar. En cambio, ?? la preserva. El estándar describe estas garantías en:
MDN: operador de fusión nula (??).

Exploración segura de datos: ?. para inspeccionar sin romper la sesión

El encadenamiento opcional permite acceder a propiedades profundas sin provocar TypeError cuando un eslabón es null o undefined. Esto convierte la exploración de un payload parcial en una lectura determinista que retorna undefined en vez de explotar. Para nuestra auditoría, lo usamos para distinguir “no vino el campo” de “vino, pero vacío”.

const payload = { filtros: { desde: '' } }; // ejemplo
const desde = payload.filtros?.desde;   // '' si existe; undefined si falta 'filtros' o 'desde'
const hasta = payload.filtros?.hasta;   // undefined: propiedad ausente

// Lectura robusta con default solo para null/undefined:
const desdeFinal = (payload.filtros?.desde) ?? 'N/A';
const hastaFinal = (payload.filtros?.hasta) ?? 'N/A';

console.log({ desde, hasta, desdeFinal, hastaFinal });

Consulta la semántica formal de cortocircuito y propagación en:
MDN: encadenamiento opcional (?.).

Bitácora del laboratorio: instrumentar el formulario con rastros finos

Para verificar hipótesis, montamos un harness que simula recepción del valor del formulario y de un payload externo. El foco es comparar qué pasa si aplicamos: trims, casts explícitos, igualdad laxa/estricta y selecciones de default con || y ??.

<script>
function normalizaEntrada(v) {
  // Simula reglas típicas: trim, vacío como null, números válidos
  const crudo = v;
  const recortado = typeof v === 'string' ? v.trim() : v;
  const vacioComoNull = recortado === '' ? null : recortado;
  const numero = (recortado === '' || recortado == null) ? NaN : Number(recortado);
  return { crudo, recortado, vacioComoNull, numero };
}

function decideCantidad(v) {
  // Criterio de negocio: aceptar 0 numérico, rechazar vacío, preservar '0' como intención de cero
  const n = (typeof v === 'string') ? Number(v) : v;
  const esVacio = (v === '' || v == null); // nota: v == null capta null o undefined deliberadamente
  if (esVacio) return { ok: false, razon: 'VACIO' };
  if (Number.isNaN(n)) return { ok: false, razon: 'NaN' };
  if (n === 0) return { ok: true, valor: 0 };
  return { ok: true, valor: n };
}

// Casos: '0', '', undefined, null
['0', '', undefined, null].forEach(caso => {
  const norm = normalizaEntrada(caso);
  const dec = decideCantidad(caso);
  console.log(caso, { norm, dec,
    laxo_vacio: (caso == ''), // ojo con laxo
    estricto_vacio: (caso === ''),
    porDefecto_OR: (caso || 'DEF'),
    porDefecto_NN: (caso ?? 'DEF')
  });
});
</script>

Con esta instrumentación, podemos responder con evidencia a preguntas del tipo: “¿por qué » disparó el valor por defecto con || pero no con ??”, o “¿por qué null y undefined fueron tratados igual por == pero no por ===?”.

Hallazgos consolidados: mapa de decisiones confiable

De las pruebas, emergen reglas prácticas que pueden incorporarse como utilidades compartidas o middleware de validación.

• Definir por contrato qué significa “campo vacío”. Sugerencias:
  • Vacío UI: cadena cuya versión trim() es ».
  • Vacío API: null explícito o propiedad ausente (undefined).
• Evitar == en validadores. Prefiere:
  • Comparaciones directas con ===: v === » para vacío de UI; v === null para intención de nulo; v === undefined para ausencia.
  • Normalización explícita: Number, String, Boolean, o parseos específicos con manejo de NaN.
• Elegir el operador de default según semántica esperada:
  • Usa ?? cuando » o 0 son válidos y no deben sustituirse.
  • Usa || solo si quieres tratar cualquier falsy como “sin valor”.
• Usar ?. para exploración segura del payload antes de decidir defaults con ??. Esto permite distinguir “no llegó el campo” de “llegó vacío”.
• Escribir pruebas unitarias que cubran los cuatro valores en al menos dos rutas: desde el DOM (string) y desde un objeto de datos (posibles null/undefined). Incluye casos mixtos (‘ 0 ‘, ‘ ‘).

Para ampliar con fragmentos reutilizables y guías prácticas, puedes consultar recursos internos:
Conversión implícita en JavaScript: guía aplicada,
Validación robusta de formularios: patrones,
Snippets de operadores y coerción,
Servicio de auditoría de bugs y flujos.

Protocolo de validación: de la hipótesis al checklist operativo

Para trasladar la investigación a producción, sintetizamos un protocolo minimalista que puedes pegar en tu base utilitaria. El objetivo es decidir, con consistencia, qué almacenar o enviar al backend cuando llega uno de los cuatro valores estudiados.

function esAusente(v) {
  // Ausente: null o undefined, sin coerciones indebidas
  return v === null || v === undefined;
}

function esVacioUI(v) {
  // Vacio UI: cadena con solo espacios tras trim
  return typeof v === 'string' && v.trim() === '';
}

function aNumeroSeguro(v) {
  if (esAusente(v) || esVacioUI(v)) return null; // decisión: normalizar "no hay número" a null
  if (typeof v === 'number') return Number.isFinite(v) ? v : null;
  if (typeof v === 'string') {
    const n = Number(v);
    return Number.isFinite(n) ? n : null;
  }
  return null;
}

function defaultNullish(v, def) {
  // Preserva '', 0 y false; solo suple null/undefined
  return (v ?? def);
}

function decideCampoCantidad(v) {
  const n = aNumeroSeguro(v);
  if (n === null) return { estado: 'SIN_VALOR', almacenar: null };
  if (n === 0)   return { estado: 'CERO_VALIDO', almacenar: 0 };
  return { estado: 'OK', almacenar: n };
}

Este protocolo separa tres preocupaciones: ausencia (null/undefined), vacío de UI (» o ‘ ‘), y números válidos. Su combinación con ?? permite defaults útiles que no se “comen” acciones válidas del usuario. Si el negocio requiere tratar » como anulación explícita y null como ausencia, bastará con añadir una capa de mapeo en la frontera de la API.

Errores que cambian de cara: cómo los síntomas engañan al depurador

Un síntoma común es ver un “cero fantasma” o un “campo reseteado” tras guardar. La pista visual sugiere un bug de post-procesamiento; el rastro real, sin embargo, suele iniciarse en una comparación laxa o en un || que interpretó » como falsy y aplicó un default. Otro síntoma es un TypeError al acceder a propiedades profundas, que enmascara el hecho de que el payload era opcional.

El antídoto es triple:

• Trazas finas con logging de tipo y valor antes y después de cada bifurcación crítica (comparaciones, defaults, conversiones).
• Test de regresión que repitan los cuatro valores estudiados por cada campo crítico del formulario.
• Bloques de decisión que hagan explícitas las reglas del negocio y no dependan de coerciones del motor.

En términos de mantenimiento, documentar en comentarios por qué se elige ?? en vez de || y por qué se compara con === prepara al equipo para futuras refactorizaciones. El enlace técnico a la referencia de igualdad en
MDN
ahorra conjeturas cuando llegan contribuidores nuevos.

Aplicación práctica: plantilla mínima para campos numéricos y opcionales

Para cerrar el círculo, se ofrece una plantilla de controlador de formulario que orquesta las decisiones anteriores. Enfatiza los puntos donde podrían infiltrarse coerciones implícitas y dónde cada operador aporta garantías.

<script>
function procesaFormularioCantidad(getValor) {
  // getValor: función que retorna '0', '', null o undefined
  const recibido = getValor();
  // 1) Observación: log de tipo/valor antes de tocarlo
  console.log('Recibido', { valor: recibido, tipo: typeof recibido });

  // 2) Acceso opcional (?.) si viene de un objeto profundo
  const valorSeguro = (typeof recibido === 'object') ? (recibido?.valor) : recibido;

  // 3) Defaults bien escogidos: no sobrescribir '' ni 0 accidentalmente
  const valorConDefault = defaultNullish(valorSeguro, ''); // solo null/undefined pasan a ''

  // 4) Rama explícita: si es vacío UI -> null, si no -> numérico o error
  const salida = esVacioUI(valorConDefault)
    ? { ok: true, almacenar: null, motivo: 'VACIO_UI' }
    : (() => {
        const n = aNumeroSeguro(valorConDefault);
        if (n === null) return { ok: false, error: 'NUMERO_INVALIDO' };
        return { ok: true, almacenar: n, motivo: n === 0 ? 'CERO_VALIDO' : 'NUMERO_VALIDO' };
      })();

  // 5) Reporte final
  console.log('Salida', salida);
  return salida;
}

// Ejemplos de ejecución:
procesaFormularioCantidad(() => '0');
procesaFormularioCantidad(() => '');
procesaFormularioCantidad(() => null);
procesaFormularioCantidad(() => undefined);
</script>

Esta plantilla te pone en control explícito de cada bifurcación. Observa que el único uso deliberado de comparación laxa podría ser v == null cuando, a propósito, quieres agrupar null y undefined en la misma rama. En todos los demás casos, === y la normalización explícita transforman lo incierto en verificable.

Conclusión accionable: el hilo oculto de la conversión es la escena del crimen

Siguiendo la tesis inicial, el bug casi nunca empieza donde lo ves: empieza en la primera decisión que se dejó a la coerción implícita del lenguaje. Al investigar un formulario expuesto a ‘0’, », undefined y null, queda claro que la combinación correcta de herramientas —=== para comparar, ?? para defaults respetuosos, ?. para explorar sin romper, y conversión explícita para normalizar— no es un capricho teórico: reduce soporte, previene sorpresas y hace auditable cada línea que decide guardar o no guardar datos.

Si tu flujo enfrenta síntomas como “cero fantasma”, “campo que no se borra”, o “excepción intermitente de propiedad”, el procedimiento de este informe es reproducible: levanta el laboratorio, registra con tablas lo que hace == vs ===, observa || frente a ??, añade ?. donde antes confiabas en la existencia del objeto, y somete tus hipótesis a pruebas concretas como las incluidas en los asides. Documenta la semántica acordada con tu equipo, y consolida utilidades que obliguen al código a pronunciarse sobre lo que antes decidía el motor en silencio.

Para cerrar el circuito con formación y acompañamiento, recurre a las guías internas enlazadas en este texto y, si necesitas otra mirada sobre un flujo con síntomas esquivos, considera una
auditoría técnica de bugs
que contraste tus reglas con datos de producción.