Recolectar dependencias durante la ejecución

Un motor con tracking automático no analiza tu código: lo ejecuta y anota lo que pasó. Las aristas del grafo no se deducen del texto del programa sino que se observan durante una ejecución concreta con unos valores concretos. Esa diferencia entre analizar y observar tiene consecuencias enormes, y explica a la vez la precisión asombrosa del modelo y su resistencia a cualquier análisis estático.

La secuencia exacta

Cuando una computación se reejecuta, el orden es rígido y cada paso tiene su razón.

function ejecutar(nodo) {
  desatar(nodo);                     // 1. borrar todas las aristas de la pasada anterior
  const anterior = Observador;
  Observador = nodo;                 // 2. abrir el ambito de recoleccion
  try {
    nodo.valor = nodo.fn();          // 3. ejecutar: cada lectura teje una arista
  } finally {
    Observador = anterior;           // 4. cerrar el ambito
    nodo.estado = LIMPIO;
  }
}

El paso 1 antes que el 3 es obligatorio y no negociable: si no se borran las aristas viejas, las de la pasada anterior conviven con las nuevas y el nodo acaba suscrito a fuentes que ya no lee. La lección siguiente va entera sobre ese paso.

El paso 3 es donde ocurre todo. Cada llamada a un getter reactivo dentro de nodo.fn() ejecuta el tejido. El motor no sabe cuántas habrá ni cuáles serán: se entera al pasar por ellas.

Las aristas son de la ejecución, no del código

Esta es la propiedad central y conviene verla con un ejemplo donde el texto y la ejecución divergen.

const modo = senal('resumen');
const a = senal(1), b = senal(2), c = senal(3);

const vista = memo(() => {
  if (modo() === 'resumen') return a();
  if (modo() === 'detalle') return a() + b();
  return a() + b() + c();
});

Textualmente, vista menciona cuatro fuentes. En la ejecución con modo igual a 'resumen', teje exactamente dos aristas: modo y a. Ni b ni c aparecen en el grafo. Escribir en b no reejecuta nada, y no porque el motor haya decidido ignorarlo, sino porque no existe la arista.

Un análisis estático del texto no puede llegar a esa conclusión: tendría que evaluar la condición, que depende de un valor de tiempo de ejecución. Un analizador conservador tendría que suponer que las cuatro fuentes son dependencias, y el nodo se reejecutaría ante cambios en b y c sin necesidad. La recolección durante la ejecución es más precisa que cualquier análisis estático posible, y esa precisión es gratuita.

flowchart LR
M[modo] --> V[memo vista]
A[a] --> V
B[b] -.no hay arista.-> V
C[c] -.no hay arista.-> V
style M fill:#89b4fa,color:#11111b
style A fill:#89b4fa,color:#11111b
style B fill:#f9e2af,color:#11111b
style C fill:#f9e2af,color:#11111b
style V fill:#cba6f7,color:#11111b

Atraviesa fronteras de función

La segunda propiedad, y la que hace que el modelo escale, es que la recolección no se detiene en los límites de una función. La variable de observador actual es de módulo, así que cualquier lectura ejecutada durante el ámbito —a la profundidad de llamadas que sea— se atribuye a la computación abierta.

function reglaDeDescuento() {
  if (esVip()) return 0.2;          // lee una senal, tres marcos de pila mas abajo
  if (unidades() > 10) return 0.1;
  return 0;
}

function precioFinal() {
  return base() * (1 - reglaDeDescuento());
}

const total = memo(() => precioFinal());   // teje aristas a base, esVip y quiza unidades

Ninguna de las dos funciones auxiliares sabe nada del sistema reactivo. No reciben el nodo, no declaran dependencias, no importan nada del motor. Y aun así sus lecturas quedan registradas correctamente en total.

Esto es lo que permite abstraer lógica de negocio en funciones normales y usarla desde cualquier contexto reactivo. Compáralo con la declaración manual del nivel 2, donde las dependencias de una función forman parte de su firma pública. Aquí no forman parte de nada: son un efecto secundario de llamarla.

Duplicados y el coste de la precisión

Duplicados y deduplicación

Un cuerpo puede leer la misma fuente varias veces.

const etiqueta = memo(() => {
  if (contador() === 0) return 'vacio';
  return `${contador()} elementos, el ultimo es el ${contador()}`;
});

Tres lecturas de contador en una ejecución. Si el motor teje tres aristas, la propagación notificará tres veces al mismo nodo y el trabajo se triplica en cada escritura.

Cada representación resuelve el duplicado a su manera. Con conjuntos hash, la deduplicación es automática porque add sobre un elemento existente no hace nada. Con arrays hay que comprobar explícitamente si la arista ya existe, y aquí aparece una optimización bonita: como es abrumadoramente probable que la lectura repetida sea la última tejida, basta con comparar contra el último elemento del array para atrapar el caso común en tiempo constante. Con listas enlazadas y reutilización, el propio mecanismo de recorrido detecta que la fuente ya está enlazada en esta pasada.

// Deduplicacion barata para la representacion de arrays
function seguir(fuente) {
  if (!Observador) return;
  const f = Observador.fuentes;
  if (f && f[f.length - 1] === fuente) return;   // atrapa el caso comun
  // ... tejer la arista completa
}

El coste de la precisión

Nada de esto es gratis. La recolección durante la ejecución significa que cada lectura de cada fuente en cada ejecución paga el tejido. Un cuerpo que lee veinte fuentes paga veinte comprobaciones y hasta cuarenta operaciones sobre estructuras de datos, además de su cómputo.

Por eso los motores optimizan tanto esta ruta: la comprobación de duplicado contra el último elemento, la reutilización de aristas de las listas enlazadas, la creación perezosa de las colecciones. Todo eso existe para abaratar el camino que se recorre millones de veces.

Y por eso, también, todos ofrecen una manera de leer sin rastrear. Cuando sabes que no quieres la dependencia, saltarse el tejido es una optimización legítima además de un cambio semántico.