Escuchas que nunca se quitan y otras suscripciones huérfanas

Si tuvieras que apostar por una sola causa de fuga en una aplicación web sin saber nada más de ella, la apuesta correcta es un registro que sobrevivió a lo que registraba. Escuchas de eventos, observadores, suscripciones a un almacén, temporizadores, conexiones abiertas: cinco mecanismos distintos con la misma estructura y el mismo fallo. Esta lección es el catálogo de los cinco, la auditoría que los encuentra, y el error de sintaxis que hace que muchas limpiezas escritas de buena fe no limpien nada.

Por qué un escucha retiene tanto

Registrar un escucha crea una referencia desde el objetivo hacia la función manejadora. Si el objetivo es el documento o la ventana —que viven toda la sesión— esa función vive toda la sesión.

Y una función mantiene vivo todo su ámbito capturado. Si el manejador se definió dentro de un componente y usa cualquier variable de ese componente, mantiene vivo el objeto del contexto, que a su vez mantiene vivo todo lo que ese contexto contenía: la instancia, sus datos, sus nodos, las respuestas que guardó.

Un solo escucha olvidado en el documento puede por tanto retener un componente entero con sus megabytes. Y como se registra uno por cada vez que el componente se monta, en una sesión larga hay decenas.

Auditar lo registrado

La consola tiene una utilidad que enumera los escuchas de un elemento y se trató en inspeccionar eventos. Aquí interesa el uso agregado: contar cuántos hay en los objetivos de vida larga y ver si crecen.

// Auditoria de escuchas en los objetivos de vida larga
// getEventListeners solo existe en la consola de las DevTools
(() => {
  const objetivos = [window, document, document.body, document.documentElement];
  const filas = [];
  for (const o of objetivos) {
    let mapa;
    try { mapa = getEventListeners(o); } catch { console.warn('Ejecutalo en la consola de DevTools.'); return; }
    for (const [tipo, lista] of Object.entries(mapa)) {
      filas.push({
        objetivo: o === window ? 'window' : (o.nodeName || String(o)).toLowerCase(),
        evento: tipo,
        cuantos: lista.length,
        pasivos: lista.filter(l => l.passive).length,
        unaVez: lista.filter(l => l.once).length
      });
    }
  }
  filas.sort((a, b) => b.cuantos - a.cuantos);
  console.table(filas);
  const total = filas.reduce((s, f) => s + f.cuantos, 0);
  console.log('Total de escuchas en objetivos de vida larga:', total);
  console.log('Repite esta medida tras varios ciclos de tu aplicacion.');
  console.log('Si el numero crece, hay registros que no se estan quitando.');
})();

El uso correcto es diferencial: mide, ejecuta el ciclo diez veces, vuelve a medir. Un crecimiento de diez en algún evento concreto es un diagnóstico completo en treinta segundos, sin abrir el panel de memoria.

Para vigilancia continua durante el desarrollo, este interceptor cuenta registros y bajas y avisa del desequilibrio:

// Contabilidad de altas y bajas de escuchas, para desarrollo
(() => {
  const cuentas = new Map();
  const clave = (objetivo, tipo) =>
    (objetivo === window ? 'window' : objetivo?.nodeName || String(objetivo)) + ' :: ' + tipo;

  const alta = EventTarget.prototype.addEventListener;
  const baja = EventTarget.prototype.removeEventListener;

  EventTarget.prototype.addEventListener = function (tipo, fn, opts) {
    const k = clave(this, tipo);
    const c = cuentas.get(k) || { altas: 0, bajas: 0 };
    c.altas++; cuentas.set(k, c);
    return alta.call(this, tipo, fn, opts);
  };
  EventTarget.prototype.removeEventListener = function (tipo, fn, opts) {
    const k = clave(this, tipo);
    const c = cuentas.get(k) || { altas: 0, bajas: 0 };
    c.bajas++; cuentas.set(k, c);
    return baja.call(this, tipo, fn, opts);
  };

  window.balanceEscuchas = (soloDesequilibrados = true) => {
    const filas = [...cuentas].map(([k, c]) => ({
      objetivoYEvento: k, altas: c.altas, bajas: c.bajas, vivos: c.altas - c.bajas
    })).filter(f => !soloDesequilibrados || f.vivos > 0)
      .sort((a, b) => b.vivos - a.vivos);
    console.table(filas);
    return filas;
  };

  window.restaurarEscuchas = () => {
    EventTarget.prototype.addEventListener = alta;
    EventTarget.prototype.removeEventListener = baja;
    console.log('Interceptores retirados.');
  };

  console.log('Contabilizando. Ejecuta el ciclo y luego balanceEscuchas().');
})();

Este instrumento tiene un sesgo que hay que conocer: los escuchas dados de baja mediante una señal de aborto no pasan por el método de baja, así que aparecerán como desequilibrados aunque estén bien. No es un fallo grave —significa que el instrumento avisa de más, no de menos— pero conviene saberlo para no perseguir falsos positivos en código bien escrito.

Los cinco tipos de suscripción

Los tres primeros son los más conocidos. Los dos últimos son los que más veces se olvidan.

Las suscripciones a un almacén fugan de forma especialmente silenciosa porque su alta devuelve una función de baja que es fácil descartar: almacen.suscribir(fn) sin guardar el retorno es una fuga garantizada, y el código compila, funciona y no da ningún síntoma hasta que la sesión es larga.

Las conexiones persistentes retienen además recursos de red, y una aplicación que abre una conexión por vista sin cerrarlas acaba agotando el límite de conexiones simultáneas además de la memoria.

El error de la función distinta

Este merece sección propia porque es el fallo que hace que limpiezas escritas correctamente en apariencia no limpien nada.

Para dar de baja un escucha hay que pasar exactamente la misma referencia de función con la que se registró. Y hay tres formas de romper esa igualdad sin darse cuenta:

// Los tres errores que hacen que removeEventListener no quite nada
const el = document.createElement('div');

// Error 1: funcion flecha creada al vuelo en las dos llamadas.
// Son dos funciones distintas: la baja no encuentra nada que quitar.
el.addEventListener('click', () => manejar());
el.removeEventListener('click', () => manejar());   // no hace nada

// Error 2: enlace al vuelo. bind devuelve una funcion nueva cada vez.
class Componente {
  montar(el) { el.addEventListener('click', this.alPulsar.bind(this)); }
  desmontar(el) { el.removeEventListener('click', this.alPulsar.bind(this)); } // no hace nada
  alPulsar() {}
}

// Error 3: opciones distintas. La fase de captura forma parte de la identidad.
el.addEventListener('scroll', manejar, true);
el.removeEventListener('scroll', manejar);          // no hace nada: falta true

function manejar() {}

// Las tres formas correctas
const manejador = () => manejar();
el.addEventListener('click', manejador);
el.removeEventListener('click', manejador);          // si funciona

class ComponenteBien {
  alPulsar = () => {};                                // campo de clase: una sola funcion
  montar(el) { el.addEventListener('click', this.alPulsar); }
  desmontar(el) { el.removeEventListener('click', this.alPulsar); }
}

const control = new AbortController();
el.addEventListener('scroll', manejar, { capture: true, signal: control.signal });
control.abort();                                     // funciona sin repetir opciones

La última forma es la que conviene adoptar por defecto, porque elimina la posibilidad del error: no hay que guardar la referencia, no hay que repetir las opciones, y una sola llamada da de baja todos los registros asociados a la señal.

Lo peor de estos tres errores es que son silenciosos. No hay excepción, no hay aviso, no hay valor de retorno que comprobar. El código parece correcto en la revisión y en las pruebas, y la fuga solo se manifiesta en sesiones largas.