Pereza, caché y el memo que nadie lee

La pereza de un memo es su propiedad más útil y la que produce los comportamientos más desconcertantes. Un memo cuyo valor nadie pide no se evalúa jamás, con independencia de cuántas veces cambien sus entradas. Eso ahorra muchísimo trabajo y, a cambio, introduce tres cuestiones que hay que entender: cuándo se paga el trabajo acumulado, si las aristas siguen vivas mientras el nodo duerme, y qué pasa con los efectos secundarios que alguien haya metido en el cuerpo.

El memo que duerme

Sigue este caso con atención, porque es donde la pereza se ve mejor.

const datos = senal([]);
let evaluaciones = 0;
const resumen = memo(() => { evaluaciones++; return calcular(datos()); });

for (let i = 0; i < 1000; i++) datos.set(generar(i));
console.log(evaluaciones);   // 0

console.log(resumen());      // se evalua ahora
console.log(evaluaciones);   // 1

Mil escrituras, cero evaluaciones. Al leer, una sola, con el último valor. El trabajo diferido no se acumula: se colapsa.

Esta propiedad tiene un nombre útil: el coste de un memo dormido es O(1) en el número de cambios, no O(n). Es lo que permite tener un grafo enorme con la mayor parte dormida y despertarla al abrir un panel sin pagar el historial.

Qué mantiene vivo un memo dormido

La pregunta natural es si el memo dormido sigue costando algo. La respuesta tiene matices y son interesantes.

Sus aristas siguen existiendo. El memo está en la lista de observadores de sus fuentes, así que cada escritura en esas fuentes lo recorre para marcarlo. Ese coste es real: una asignación de entero por escritura, más el recorrido de la lista.

Pero el marcado se corta enseguida. Recuerda la guarda: si el nodo ya está marcado, no se vuelve a marcar ni se propaga hacia abajo. Así que el memo dormido cuesta una comprobación por escritura y nada más, con independencia de cuántos cambios haya.

Su valor cacheado sigue en memoria. Si el último valor que calculó era un array de cien mil elementos, ese array sigue retenido. Un panel cerrado puede estar reteniendo memoria significativa sin hacer nada. Es un coste que casi nadie contabiliza.

Sus fuentes lo mantienen vivo. Mientras esté en la lista de observadores de una fuente viva, no se puede recolectar. Solo desaparece cuando lo desecha su dueño, que es el nivel 7.

// El memo dormido cuesta esto por cada escritura en sus fuentes:
if (obs.estado >= estado) continue;   // una comparacion, y salimos

Cuándo la pereza sorprende

Tres situaciones donde el comportamiento perezoso choca con la expectativa.

El memo que nunca corre. Si nadie lee un memo, su cuerpo no se ejecuta nunca. Si alguien metió ahí una llamada a una API, un registro o una inicialización, no ocurre. Y no ocurre de forma silenciosa.

El memo que corre tarde. Al abrir un panel cerrado durante minutos, el memo se evalúa en ese instante. Si su cuerpo es caro, el coste aparece justo en el momento de la interacción, que es el peor momento posible desde el punto de vista de la latencia percibida. Un memo perezoso puede convertir un trabajo repartido en un pico concentrado.

El memo que corre menos veces de lo esperado. Con dos consumidores que lo leen en momentos distintos del mismo ciclo, el cuerpo corre una vez y los dos ven el mismo valor. Eso es lo correcto, y sorprende a quien esperaba una evaluación por lectura.

flowchart TB
E[mil escrituras en la fuente] --> M[memo marcado mil veces]
M --> C[coste una comparacion por escritura]
M --> L[primera lectura]
L --> U[una unica evaluacion con el ultimo valor]
M --> R[el valor cacheado anterior sigue en memoria]
style E fill:#89b4fa,color:#11111b
style M fill:#cba6f7,color:#11111b
style C fill:#a6e3a1,color:#11111b
style L fill:#f9e2af,color:#11111b
style U fill:#a6e3a1,color:#11111b
style R fill:#f9e2af,color:#11111b

Por qué un efecto secundario en un memo es un error

De todo lo anterior se deduce la regla más importante sobre memos, y conviene justificarla bien porque se incumple constantemente.

Un memo se evalúa un número impredecible de veces: cero si nadie lo lee, una si lo leen mil consumidores en el mismo ciclo, y en un momento arbitrario respecto a cualquier otra cosa. Por tanto, cualquier efecto secundario dentro de su cuerpo ocurrirá un número impredecible de veces en un momento impredecible.

// MAL: efecto secundario en un memo
const usuario = memo(() => {
  registrarAnalitica('usuario_calculado');   // cuantas veces? cuando?
  localStorage.setItem('ultimo', id());       // puede no ocurrir nunca
  return buscarUsuario(id());
});

// BIEN: el memo deriva, el efecto actua
const usuario = memo(() => buscarUsuario(id()));
efecto(() => {
  registrarAnalitica('usuario_calculado');
  localStorage.setItem('ultimo', id());
});

La separación no es una convención estética: es la consecuencia directa de que los memos sean perezosos y los efectos ansiosos. Un efecto está garantizado que corre cuando sus dependencias cambian; un memo no. Poner algo en el sitio equivocado significa aceptar la garantía equivocada.