Raíces desacopladas y propiedad manual

El árbol de propiedad crece hacia abajo automáticamente, pero a veces hace falta romperlo: crear un ámbito que nadie posea, cuya vida controles tú. Y a veces hace falta lo contrario: recuperar un dueño que se perdió al cruzar una frontera asíncrona. Las dos operaciones son la salida de emergencia del sistema, y como toda salida de emergencia conviene saber exactamente cuándo se usa y qué se pierde al usarla.

La raíz

Una raíz es un ámbito sin padre. Se crea poniendo el dueño actual a un nodo nuevo cuyo campo de padre es nulo, y devolviendo una función que lo desecha.

function raiz(fn) {
  const nodo = { hijos: [], limpiezas: [], fuentes: null };
  const duennoAnterior = Duenno, obsAnterior = Observador;
  Duenno = nodo;
  Observador = null;              // una raiz no rastrea nada de fuera
  try {
    return fn(() => desechar(nodo));
  } finally {
    Duenno = duennoAnterior;
    Observador = obsAnterior;
  }
}

Dos detalles importan. El primero, que se devuelve la función de desecho al cuerpo: quien crea la raíz recibe el control de su vida. El segundo, que Observador se pone a null: dentro de una raíz, las lecturas no se atribuyen a la computación exterior. Sin eso, crear una raíz dentro de un efecto haría que el efecto se suscribiera a todo lo que la raíz lea, que es justo lo que no se quiere.

let tirar;
raiz((desechar) => {
  tirar = desechar;
  efecto(() => pintar(datos()));    // vive hasta que llamemos a tirar
});

// mucho despues
tirar();                             // todo lo creado dentro se destruye

Los tres casos donde hace falta

El punto de entrada de la aplicación. Tiene que haber una raíz en la cima: alguien que posea todo lo demás. En un framework, esa raíz la crea el propio arranque y no la ves.

Un ámbito de vida distinta a la de su creador. Un modal creado desde un componente pero que debe sobrevivir a él, una animación que continúa tras desmontar, un caché global inicializado desde un componente. Si se crearan en el ámbito del creador, morirían con él.

Aislar una parte que se destruye y se recrea a menudo. Una lista donde cada fila tiene su propio ámbito para poder desechar una fila sin tocar las demás. Es lo que hacen internamente las primitivas de listas de los frameworks de esta familia.

Capturar y restaurar el dueño

El segundo problema es el inverso. Al cruzar una frontera asíncrona, el dueño actual se pierde igual que el observador. Todo lo que se cree después no pertenece a nadie.

efecto(() => {
  setTimeout(() => {
    alLimpiar(() => console.log('esto no se registra en ningun sitio util'));
  }, 100);
});

La solución es capturar el dueño mientras está disponible y restaurarlo dentro del callback.

function duennoActual() { return Duenno; }

function conDuenno(duenno, fn) {
  const anterior = Duenno, obsAnterior = Observador;
  Duenno = duenno;
  Observador = null;                 // se restaura la propiedad, no el rastreo
  try { return fn(); } finally { Duenno = anterior; Observador = obsAnterior; }
}

// uso
efecto(() => {
  const d = duennoActual();
  setTimeout(() => {
    conDuenno(d, () => {
      const id = setInterval(tic, 1000);
      alLimpiar(() => clearInterval(id));   // ahora si se registra donde toca
    });
  }, 100);
});

Fíjate en que se restaura la propiedad pero no el rastreo. Es deliberado: restaurar el observador haría que las lecturas dentro del callback tejieran aristas hacia una computación que ya terminó su ejecución, y esas aristas serían basura. La propiedad sí tiene sentido restaurarla, porque la pregunta quién limpia esto sigue teniendo la misma respuesta aunque haya pasado tiempo.

flowchart TB
E[efecto en ejecucion] --> C[capturar el duenno actual]
C --> A[cruzar una frontera asincrona]
A --> P[el duenno global ya es otro]
P --> R[restaurar el duenno capturado]
R --> N[lo que se cree aqui pertenece al efecto original]
style E fill:#cba6f7,color:#11111b
style C fill:#89b4fa,color:#11111b
style A fill:#f9e2af,color:#11111b
style P fill:#f38ba8,color:#11111b
style R fill:#89b4fa,color:#11111b
style N fill:#a6e3a1,color:#11111b

Las primitivas en cada motor

Solid tiene createRoot, getOwner y runWithOwner, que son exactamente las tres funciones de esta lección. Vue tiene effectScope, que admite un argumento para crearlo desacoplado del ámbito padre, más getCurrentScope y onScopeDispose; el patrón de captura y restauración se consigue guardando el ámbito y llamando a su método de ejecución. Angular resuelve el mismo problema con el inyector: se captura un Injector o un DestroyRef y se usa al crear el efecto más tarde. Svelte tiene $effect.root, que devuelve una función de desecho igual que la raíz de esta lección.

Todos coinciden en el diseño porque el problema es el mismo, y merece señalarse que ninguno lo hace automático: la ruptura del árbol tiene que ser explícita, precisamente porque romper la propiedad es una decisión con consecuencias que el motor no puede tomar por ti.