El motor de grano fino por dentro

El modelo de grano fino invierte la apuesta. En vez de reconstruir una descripción para averiguar qué cambió, mantiene una arista permanente entre cada valor y el punto exacto del mundo que ese valor controla. No hay descripción intermedia, no hay comparación, no hay búsqueda: hay una lista de suscriptores y un salto directo. Esta lección lo implementa entero, sin framework, para que veas de dónde sale la ventaja y qué factura la acompaña.

Veinte líneas de motor

Todo lo que hace falta para el modelo fino cabe en muy poco código. Fuentes con lista de observadores, un observador actual, y efectos que se reejecutan.

let Observador = null;

function senal(inicial) {
  let valor = inicial;
  const observadores = new Set();
  const leer = () => {
    if (Observador) { observadores.add(Observador); Observador.fuentes.add(observadores); }
    return valor;
  };
  leer.set = (v) => {
    if (Object.is(valor, v)) return;
    valor = v;
    for (const o of [...observadores]) o.correr();
  };
  return leer;
}

function efecto(fn) {
  const nodo = {
    fuentes: new Set(),
    correr() {
      for (const s of nodo.fuentes) s.delete(nodo);   // desatar las aristas viejas
      nodo.fuentes.clear();
      const anterior = Observador;
      Observador = nodo;
      try { fn(); } finally { Observador = anterior; }
    },
  };
  nodo.correr();
  return nodo;
}

Está deliberadamente simplificado: sin memos, sin lotes, sin garantías de orden. Todo eso llega en los niveles siguientes. Lo que ya se ve aquí es lo esencial: una escritura recorre una lista de observadores y los ejecuta, y nada más.

La plantilla es un conjunto de efectos

Ahora la parte que hace la diferencia. En vez de una función que devuelve una descripción del árbol, construimos el DOM una sola vez y colocamos un efecto en cada punto que puede cambiar.

function listaDeTareas(tareas, filtro) {
  const ul = document.createElement('ul');
  const contador = document.createElement('p');

  // Un efecto por cada punto variable del DOM
  efecto(() => { contador.textContent = `${tareas().length} tareas`; });

  efecto(() => {
    const visibles = tareas().filter(t => filtro() === 'todas' || !t.hecha);
    ul.replaceChildren(...visibles.map(fila));
  });

  return [contador, ul];
}

function fila(tarea) {
  const li = document.createElement('li');
  li.textContent = tarea.texto;
  efecto(() => { li.className = tarea.hecha() ? 'hecha' : ''; });
  return li;
}

Fíjate en fila: tarea.hecha es una señal propia de esa tarea, y el efecto que lee esa señal escribe directamente en ese li. Cuando se marca una tarea como hecha, la escritura recorre una lista de un único observador y ejecuta una asignación a className. La lista de mil filas no se recorre. El ul no se toca. La función listaDeTareas no vuelve a ejecutarse jamás.

flowchart LR
S[senal hecha de la tarea 437] --> E[efecto de clase]
E --> N[el li numero 437]
style S fill:#89b4fa,color:#11111b
style E fill:#cba6f7,color:#11111b
style N fill:#a6e3a1,color:#11111b

Tres nodos. Ese es el grafo completo que participa en la actualización, con independencia de que la aplicación tenga diez mil elementos más. Esa es la propiedad que define el modelo: el coste de una actualización es independiente del tamaño de la aplicación.

El componente corre una vez

La consecuencia que más cuesta interiorizar al venir del otro modelo es que la función del componente es un constructor, no un renderizador. Corre una vez, crea los nodos y los efectos, y termina para siempre.

function contador() {
  const n = senal(0);
  console.log('esto se imprime UNA vez en toda la vida del componente');
  const boton = document.createElement('button');
  efecto(() => { boton.textContent = `Pulsado ${n()} veces`; });
  boton.onclick = () => n.set(n() + 1);
  return boton;
}

De aquí salen, en cadena, casi todas las diferencias de ergonomía entre las dos familias. No hace falta una lista de dependencias en los efectos, porque el efecto no se recrea. No existe el problema de la identidad de las funciones entre renders, porque no hay renders. No hace falta memoizar para evitar reconstrucciones, porque no hay reconstrucciones. Y, a cambio, desestructurar props rompe la reactividad, porque desestructurar lee el valor una vez en el único momento en que la función corre; ese es el asunto del nivel 9.

La factura

Contemos lo que cuesta el modelo, sin adornos.

Memoria por arista. Cada dependencia ocupa espacio en dos estructuras: la lista de observadores de la fuente y la lista de fuentes del observador. Una aplicación con cien mil aristas paga esa memoria de forma permanente, mientras que el modelo de reconciliación no paga nada entre ciclos, salvo el árbol anterior.

Contabilidad por ejecución. Cada vez que un efecto se reejecuta, desata todas sus aristas viejas y teje las nuevas. Para un efecto que lee veinte fuentes, son cuarenta operaciones sobre estructuras de datos por ejecución, además del trabajo real. Cuando el trabajo real es una asignación a textContent, la contabilidad puede ser la mitad del coste total.

Indirección en cada lectura. Leer una señal no es leer una variable: es llamar a una función que consulta el observador actual, posiblemente inserta en dos colecciones, y devuelve. En un bucle apretado eso importa, y es la razón por la que todos los motores ofrecen alguna forma de leer sin rastrear.

Coste de arranque. Crear el grafo cuesta. Una pantalla con cinco mil nodos reactivos paga cinco mil creaciones de objeto, cinco mil primeras ejecuciones y el tejido inicial de todas sus aristas antes de mostrar nada. La reconciliación paga un recorrido y unas asignaciones, sin estructuras persistentes. En arranque en frío, el grano fino no gana automáticamente.