El diamante de dependencias

En la lección anterior vimos que un glitch solo aparece cuando un cambio alcanza a un nodo por más de un camino. Esa condición tiene una forma geométrica precisa, y es tan común que merece nombre propio: el diamante. Un valor depende de otros dos, y esos dos comparten una fuente. Cuando la fuente se mueve, el cambio se bifurca por dos ramas y vuelve a juntarse en el vértice inferior. Ahí, en la reconvergencia, es donde la propagación ingenua tropieza —y no una vez, sino dos: recalcula de más y recalcula mal—. Entender el diamante es entender la raíz estructural de todo el nivel.

La forma del diamante

Un diamante tiene cuatro papeles: una fuente arriba, dos derivados intermedios que la leen, y un derivado inferior que combina a los dos. El ejemplo más cotidiano es un cálculo de precio.

const precio = signal(100)
const subtotal = computed(() => precio() * cantidad())  // rama izquierda
const iva = computed(() => precio() * 0.21)             // rama derecha
const total = computed(() => subtotal() + iva())        // reconvergencia

flowchart TD
A[precio fuente] --> B[subtotal rama izquierda]
A --> C[iva rama derecha]
B --> D[total reconvergencia]
C --> D
style A fill:#cba6f7,color:#11111b
style D fill:#f9e2af,color:#11111b

La señal precio está arriba; subtotal e iva cuelgan de ella; total cuelga de ambos. Dibujado, el grafo es un rombo: de ahí el nombre. La propiedad clave no es el número de nodos, sino la topología: hay dos rutas distintas de precio a total, y ambas deben resolverse antes de que total tenga derecho a un valor consistente. El diamante no es un caso rebuscado: aparece en cuanto un selector deriva de otros dos selectores que comparten un dato, o un total agrega dos parciales de la misma raíz. Es el patrón más frecuente de cualquier grafo real.

Falla número uno: recalcular de más

Sigue el empuje ingenuo cuando precio cambia. La señal notifica a sus dos dependientes, subtotal e iva. El nodo subtotal se recalcula y, acto seguido, notifica a total, que se recalcula por primera vez. Después le toca a iva: se recalcula y también notifica a total, que se recalcula por segunda vez. Un solo cambio en precio ha provocado DOS recálculos de total.

// empuje ansioso: cada dependiente se recalcula y propaga al instante
function notificar(nodo) {
  for (const dep of nodo.dependientes) {
    dep.recalcular()   // usa los valores que haya AHORA, viejos o nuevos
    notificar(dep)     // y sigue en profundidad
  }
}
// precio.dependientes = [subtotal, iva]
// subtotal propaga a total ANTES de que iva se toque: total corre dos veces

El desperdicio parece menor con un diamante suelto, pero la forma se apila. Si la salida de un diamante es la fuente de otro, cada nivel duplica el número de recálculos del vértice final: dos diamantes en cascada dan cuatro, tres dan ocho. El coste del último nodo crece como dos elevado a la profundidad, cuando lo correcto sería exactamente uno. Un grafo con reconvergencias anchas y profundas puede pasar de miles de recomputaciones donde bastaba una.

flowchart TD
A[fuente] --> B[b]
A --> C[c]
B --> D[d]
C --> D
D --> E[e]
D --> F[f]
E --> G[g final]
F --> G
style A fill:#cba6f7,color:#11111b
style G fill:#f38ba8,color:#11111b

Falla número dos: recalcular mal

La redundancia solo cuesta tiempo; la segunda patología cuesta corrección. Vuelve al primer recálculo de total, el que dispara subtotal. En ese instante subtotal ya refleja el precio nuevo, pero iva todavía no se ha tocado: sigue con su valor viejo. Así que total se calcula con una rama nueva y otra vieja. El resultado es un glitch: un total que no corresponde a ningún precio, ni al viejo ni al nuevo.

Pongámosle números, con cantidad igual a 2 y precio pasando de 100 a 150.

1. Estado en reposo: subtotal vale 200, iva vale 21, total vale 221.
2. precio pasa a 150. Se recalcula subtotal, que ahora vale 300.
3. subtotal notifica a total, que se recalcula: 300 + 21 da 321. Este es el glitch.
4. Se recalcula iva, que ahora vale 31.5.
5. iva notifica a total, que se recalcula: 300 + 31.5 da 331.5. Ahora sí, correcto.

El 321 es imposible: para que subtotal valga 300 el precio ha de ser 150, pero para que iva valga 21 el precio ha de ser 100. Ningún precio produce ese par. El vértice del diamante exhibió un total que jamás fue real.

Las dos fallas comparten una raíz: el vértice inferior se recalcula tantas veces como aristas de entrada tiene, y cada recálculo intermedio ocurre antes de que todas sus entradas estén al día. Redundancia y glitch son las dos caras de la misma moneda: propagar por aristas sueltas.

Por qué el empuje ingenuo no puede evitarlo

La solución no puede ser local: ningún ajuste a la arista entre subtotal y total arregla el diamante, porque el problema es la relación entre DOS aristas que el empuje mira por separado. Hace falta una propiedad global del grafo —saber que total debe esperar a sus dos ramas— y esa propiedad tiene nombre matemático: el orden topológico, tema de la próxima lección.

Antes de ver esa cura en la próxima lección, conviene aterrizar el diamante en la práctica, porque aparece muchísimo más de lo que su aire teórico sugiere. Suena abstracto hasta que reconoces cuántas veces lo has creado sin querer: aparece siempre que dos derivados comparten una raíz y un tercero los combina, y ese patrón está por todo el ecosistema.

En todos, el motor de reactividad decide si sufres las dos patologías o no. Con un sistema glitch-free ni te enteras; con uno ingenuo, verás el vértice recalcularse de más y, de vez en cuando, un parpadeo inexplicable que resulta ser el glitch del diamante. Y ojo con el falso alivio de las pruebas: la redundancia se paga siempre —dos recálculos, ocurra lo que ocurra—, pero el glitch visible solo aparece si algo observa el vértice entre el primer recálculo y el segundo. Un diamante puede parecer inofensivo en tests, donde nadie miró en el microsegundo malo, y fallar en producción, donde un efecto sí escuchaba.

La moraleja invierte la intuición: el diamante no es un patrón a evitar diseñando grafos en árbol. Los grafos reales reconvergen por todas partes, y está bien que lo hagan —expresan que varios resultados comparten un origen—. Lo que no puede fallar es el motor que los recorre.