Valores computados

Casi ningún estado interesante es primitivo; la mayoría es derivado. El total de un carrito es precio por cantidad; el nombre completo es nombre más apellido; la lista visible es la lista filtrada por el término de búsqueda. Un valor computado captura esa idea: un signal cuyo valor no lo escribes tú, sino que lo calcula una función de otros signals. Y lo hace con dos virtudes que lo separan de una simple función: se acuerda del resultado y no vuelve a calcularlo mientras sus fuentes no cambien. Es, a la vez, consumidor de signals y productor para otros.

Una derivación con memoria

Un computed envuelve una función de cálculo. La primera vez que lo lees, ejecuta esa función, guarda el resultado en una caché y lo devuelve. Mientras tanto, se comporta como un efecto: al ejecutar la función rastrea qué signals leyó y se vuelve dependiente de ellos. Y se comporta como un signal: otros pueden leerlo y volverse dependientes suyos. Esa doble naturaleza es la clave —un nodo intermedio en el grafo, con fuentes arriba y consumidores abajo.

function computado<T>(calcular: () => T) {
  let cache: T;
  let sucio = true;                 // hay que recalcular en la proxima lectura
  const dependientes = new Set<Efecto>();

  const leer = (): T => {
    if (activo) dependientes.add(activo);   // soy leido: registro a mi consumidor
    if (sucio) {
      cache = calcular();           // recomputo solo si estoy sucio
      sucio = false;
    }
    return cache;
  };

  // cuando una fuente cambia, me marco sucio y aviso hacia abajo
  const invalidar: Efecto = () => {
    if (sucio) return;              // ya estaba sucio: no repito el aviso
    sucio = true;
    for (const d of dependientes) d();
  };

  return { leer, invalidar };
}

Este esbozo omite el cableado que conecta invalidar a las fuentes —ese es el rastreo de la lección anterior—, pero muestra lo esencial: un flag sucio, una caché y la regla de recomputar solo cuando de verdad hace falta.

Y como un computed es a la vez lector y fuente, se encadena: un computed puede depender de otro, que depende de otro, formando un grafo de derivaciones de cualquier profundidad. El cambio en la raíz se propaga por toda la cadena, y cada eslabón cachea su propio resultado:

const [nombre, ponerNombre] = signal("Ada");
const [apellido, ponerApellido] = signal("Lovelace");
const completo = computado(() => `${nombre()} ${apellido()}`);
const saludo = computado(() => `Hola, ${completo.leer()}`);  // un computed de otro computed

Pereza: no calcula hasta que lo miras

La palabra clave es pereza. Cuando una fuente cambia, el computed no se recalcula de inmediato; solo se marca sucio. El cálculo real se pospone hasta que alguien lee el computed. Si nadie lo lee, no se paga nada, por muchas veces que cambien sus fuentes. Esta demora tiene una consecuencia práctica enorme: puedes definir cientos de derivaciones sin coste, porque solo las que de verdad se observan llegan a ejecutarse.

const [precio, ponerPrecio] = signal(100);
const [cantidad, ponerCantidad] = signal(2);
const total = computado(() => precio() * cantidad());

total.leer();          // primera lectura: calcula 200 y lo cachea
total.leer();          // segunda lectura: devuelve 200 de cache, no recalcula
ponerCantidad(3);      // marca total sucio, pero NO recalcula todavia
total.leer();          // ahora si: recalcula 300 bajo demanda

Push-pull: empujar el aviso, tirar del valor

El modelo moderno de computed es un híbrido de dos estrategias clásicas. La invalidación se empuja: cuando una fuente cambia, recorre el grafo hacia abajo marcando sucios a sus dependientes —un push barato que solo propaga un bit, no valores—. El recálculo se tira: ocurre cuando alguien lee, subiendo por el grafo para pedir los valores que necesita —un pull que solo se paga si de verdad se observa—. Push del aviso, pull del valor: lo mejor de ambos mundos.

flowchart TD
P[precio cambia] -->|push marca sucio| T[total queda sucio]
Q[cantidad cambia] -->|push marca sucio| T
V[la vista lee total] -->|pull pide el valor| T
T --> R[recomputa una vez y cachea]
style T fill:#cba6f7,color:#11111b
style R fill:#a6e3a1,color:#11111b
style V fill:#89b4fa,color:#11111b

El problema del diamante y los glitches

Considera un grafo en rombo: un signal a, dos computados b y c que dependen de a, y un cuarto nodo d que depende de b y de c. Si cambias a y propagas de forma ingenua y ávida, d podría recalcularse dos veces —una por b y otra por c— y, peor aún, ejecutarse un instante con un b nuevo y un c todavía viejo. Ese estado intermedio incoherente que nunca debió observarse tiene nombre: glitch.

flowchart TD
A[signal a] --> B[computed b]
A --> C[computed c]
B --> D[computed d lee b y c]
C --> D
style A fill:#89b4fa,color:#11111b
style D fill:#a6e3a1,color:#11111b

const [a, ponerA] = signal(1);
const b = computado(() => a() + 1);
const c = computado(() => a() * 2);
const d = computado(() => b.leer() + c.leer());  // depende de dos caminos desde a

ponerA(5);        // un push ingenuo recalcularia d dos veces y lo veria incoherente
d.leer();         // el modelo perezoso lo calcula UNA vez, con b y c ya frescos