De observer manual a reactividad automática: el fin del cableado

Has recorrido el átomo (Observer), su versión mediada (pub/sub), su talón de Aquiles (la baja manual) y su eje profundo (push vs pull). Queda el salto que ordena todo lo anterior: pasar del cableado explícito de suscripciones a la reactividad automática. Los signals no inventan un mecanismo nuevo —siguen siendo sujeto y observador— sino que automatizan su administración: deducen las dependencias al leerlas y limpian el grafo solos. Este es el destino al que apuntaba el nivel entero.

El coste del cableado manual

Con el Observer clásico, las dependencias las declaras tú. Si un total depende de un precio y una cantidad, tienes que suscribir el recálculo a ambos a mano, y —esto es lo grave— recordar re-cablearlo cada vez que aparece un factor nuevo.

El cableado manual falla en las dos direcciones que ya conoces del nivel: si olvidas una suscripción, el valor queda obsoleto y la interfaz miente; si olvidas una baja, filtras memoria y ejecutas trabajo fantasma. Ambos fallos son silenciosos, y a ninguno lo atrapa el compilador.

// Manual: hay que suscribir a mano y acordarse de limpiar
function recalcular() {
  total.set(precio.get() * cantidad.get());
}
precio.subscribe({ update: recalcular });
cantidad.subscribe({ update: recalcular });
// si mañana el total pasa a depender de un descuento,
// DEBES acordarte de suscribir recalcular también a ese tercer signal

El problema no es que sea difícil, es que es frágil y no compone: la correspondencia entre “de qué depende este cálculo” y “a qué está suscrito” la mantienes tú, y basta una distracción para que ambas se desincronicen sin que nada avise.

Y el coste crece con el tamaño. Diez valores derivados que dependen unos de otros forman una maraña de suscripciones que hay que tejer y destejer a mano en el orden correcto. Es la misma contabilidad de la lección anterior, ahora elevada a la enésima potencia por la composición: cada dependencia nueva multiplica los lugares donde puedes equivocarte, y la corrección entera descansa en tu memoria.

Este es el punto de dolor máximo del nivel, y por eso llega al final: has visto el átomo, lo has desacoplado con pub/sub, has sufrido su limpieza manual y has diseccionado su control del tiempo. Todo apuntaba a la misma pregunta incómoda —¿de verdad tengo que cablear yo cada dependencia, una por una?— y los signals son la respuesta.

El seguimiento automático de dependencias

Los signals eliminan ese cableado con una idea tan simple como potente: leer un signal dentro de un cómputo crea la dependencia automáticamente. No declaras nada; el mero acto de leer suscribe.

const precio = signal(10);
const cantidad = signal(2);

const total = computed(() => precio() * cantidad()); // deps detectadas al leer
effect(() => console.log("total", total()));         // se re-ejecuta si total cambia

precio.set(12); // total se recalcula y el effect corre, sin cablear nada

Compara este código con la versión manual del principio: han desaparecido las llamadas a subscribe, la función recalcular con nombre propio y la obligación de re-cablear al añadir un factor. La dependencia entre total y sus signals no se declara en ninguna parte; se descubre en el instante en que computed ejecuta su función y lee precio y cantidad. Añadir un descuento sería tan simple como leerlo dentro del cálculo: la suscripción nacería sola.

El truco que lo hace posible cabe en un párrafo. Existe una variable global que apunta al observador actual —el cómputo o efecto que se está ejecutando ahora mismo—. Cuando un effect o un computed empieza a correr, se instala como observador actual. Cada vez que se lee un signal, este mira quién es el observador actual, se apunta a sí mismo en la lista de dependencias de ese observador y añade al observador a su propia lista de suscriptores. Al escribir en el signal, notifica a esos suscriptores. Alta y baja dejan de ser llamadas que tú escribes: son un efecto colateral de leer y de ejecutar.

En esqueleto, el mecanismo cabe en unas pocas líneas: un puntero global al observador en curso, una lectura que se registra, una ejecución que reinicia las dependencias.

let observadorActual = null;

function leer(sig) {
  if (observadorActual) {
    observadorActual.deps.add(sig);          // el observador depende de este signal
    sig.observadores.add(observadorActual);  // y el signal lo recordará
  }
  return sig.valor;
}

function ejecutar(observador) {
  observador.deps.clear();     // olvida las dependencias del turno anterior
  observadorActual = observador;
  try { observador.fn(); }     // al correr, cada lectura vuelve a registrarse
  finally { observadorActual = null; }
}

Ese deps.clear de cada ejecución es la clave de la limpieza automática: como las dependencias se reconstruyen desde cero en cada corrida, las que dejan de leerse simplemente no vuelven a registrarse. No hay que darlas de baja porque nunca sobreviven a un turno en que no se usan.

Una nota práctica sobre sintaxis: la forma de leer y escribir un signal varía entre implementaciones —signal() y signal.set() en Angular y Solid, signal.value en Preact y en la propuesta de TC39, ref.value en Vue—, pero el mecanismo por debajo es idéntico en todas: leer registra la dependencia, escribir la invalida. Aprendes el concepto una vez y solo cambias de sintaxis al saltar de un framework a otro.

flowchart TD
A[signal precio] -->|leido dentro de| C[computed total]
B[signal cantidad] -->|leido dentro de| C
C -->|leido dentro de| E[effect pinta la UI]
style A fill:#89b4fa,color:#11111b
style B fill:#89b4fa,color:#11111b
style C fill:#cba6f7,color:#11111b
style E fill:#a6e3a1,color:#11111b

El grafo se reconstruye y se limpia solo

Como las dependencias se recolectan en cada ejecución, el grafo es siempre exacto. Si un cómputo tiene una rama condicional que este turno no lee cierto signal, deja de depender de él automáticamente —las dependencias son dinámicas, no una lista fija—. Y al destruir un efecto, todas sus suscripciones se sueltan de golpe, sin que tú recorras ninguna lista de bajas.

Fíjate en cuántos problemas del nivel se disuelven de una vez. La baja manual y el lapsed listener de la lección anterior desaparecen: no hay unsubscribe que olvidar porque el sistema lo hace por ti al re-rastrear o al destruir el efecto. El orden de limpieza deja de ser tu responsabilidad. Y el diseño es push-pull, como vimos: la escritura empuja una invalidación barata por el grafo y la lectura tira del valor recalculándolo perezosamente, sin cómputo inútil ni glitches. Los cuatro dolores del nivel —memoria, orden, cableado y control del tiempo— quedan resueltos por el mismo primitivo.

computed perezoso, effect ansioso

Una sutileza que conviene fijar: un computed es perezoso —no recalcula hasta que alguien lo lee— mientras que un effect es ansioso —corre en cuanto una de sus dependencias cambia, porque su razón de ser es producir un efecto en el mundo, como pintar la pantalla—. Ambos usan el mismo autoseguimiento y se diferencian solo en cuándo se ejecutan: un computed que nadie lee jamás se calcula, mientras que un effect corre siempre que su grafo se ensucia. Esa asimetría es push-pull otra vez, mirado desde arriba: el effect es el punto exacto donde el pull perezoso del grafo interior se convierte en el push ansioso hacia la interfaz.

Otra pieza que el autoseguimiento habilita es el batching: si escribes en varios signals seguidos, el sistema puede agrupar las invalidaciones y recalcular los efectos una sola vez al final, en lugar de una por escritura. Cambiar el precio y la cantidad en la misma operación no dispara dos repintados, sino uno. Es la respuesta automática al problema de la reentrada y las cascadas que vimos en el Observer crudo: donde antes encadenabas notificaciones a mano y arriesgabas estados intermedios, ahora el runtime fusiona los cambios en una transacción coherente.

La regla de oro: preferir computed a effect

Un consejo que atraviesa todo el ecosistema de 2026: la mayoría de lo que crees que es un effect es en realidad un computed. Si un valor se deriva de otros, decláralo computed y reserva el effect para los verdaderos efectos de frontera —pintar, registrar, sincronizar con algo externo—. Abusar de effect para copiar un signal en otro reintroduce a mano el cableado que los signals venían a eliminar, y con él vuelven los bugs de sincronización. El grafo debe ser sobre todo declarativo: los efectos son sus hojas, no su tejido.

El ecosistema de 2026

Lo notable de los signals es que la industria ha convergido en la forma del primitivo. Ya no es la apuesta de una librería, sino un consenso de diseño que se está estandarizando.

Que TC39, Solid, Angular, Vue, Preact y Svelte compartan el mismo modelo mental no es casualidad: es la señal de que el problema de la propagación de estado en el cliente ha encontrado, por fin, una respuesta canónica.

La convergencia tiene una consecuencia práctica enorme. Si el primitivo se estandariza en el propio motor de JavaScript, dejará de ser responsabilidad de cada framework reimplementarlo, y librerías hoy incompatibles podrán compartir un mismo grafo reactivo por debajo. Aprender signals en 2026 no es apostar por una herramienta concreta: es aprender el vocabulario común hacia el que se dirige toda la plataforma.