El cheatsheet de Angular Signals que tienes que tener pegado al monitor

Qué incluye exactamente el cheatsheet

No es otro PDF genérico sobre Angular. Es una referencia rápida para tener al lado mientras escribes componentes con Signals: qué hace cada API, cuándo usarla y qué errores evitar.

• Tabla de primitivas: signal(), computed(), effect(), linkedSignal(), resource() y httpResource() con el caso de uso correcto de cada una.
• Mapa mental del grafo reactivo: Productores, consumidores, dependencias dinámicas, Push/Pull, memoización y ejecución glitch-free explicados sin academicismo.
• Reglas para no abusar de effect(): Cuándo usar effect(), cuándo mover la lógica a computed() y cuándo tirar de untracked() sin esconder un mal diseño.
• Criterio Signals vs RxJS: Una guía práctica para decidir cuándo Signals simplifica el código y cuándo RxJS sigue siendo la herramienta correcta.

¿Qué es una Signal?

Una Signal es un wrapper reactivo alrededor de un valor. Cuando ese valor cambia, Angular sabe exactamente qué nodos del DOM necesitan actualizarse — sin Zone.js, sin ChangeDetectorRef, sin magia. El modelo es completamente síncrono y explícito: lees con (), escribes con .set() o .update(), y Angular hace el resto.

const price = signal(100);
price();           // read → 100
price.set(120);    // write → notify consumers
price.update(p => p * 1.1); // transform

El grafo reactivo de Angular

El cambio importante no es la función signal(). Es el grafo que Angular construye cuando tu código lee signals. Cada signal es un productor. Cada template, computed(), effect(), linkedSignal() o resource() que lee esa signal se convierte en consumidor. Cuando el productor cambia, Angular sabe qué consumidores debe invalidar, marcar o recalcular.

const price = signal(100);
const quantity = signal(2);

const subtotal = computed(() => price() * quantity());
const tax = computed(() => subtotal() * 0.21);
const total = computed(() => subtotal() + tax());

• Productores y consumidores: La dependencia se crea al leer una signal dentro de un contexto reactivo. No tienes que registrar nada a mano: Angular observa la lectura y conecta los nodos.
• Dependencias dinámicas: Un computed solo depende de las signals que realmente lee en esa ejecución. Si una rama del if no se ejecuta, sus signals no entran en el grafo hasta que esa rama se use.
• Recalculo perezoso y memoizado: computed() no recalcula por deporte. Guarda el resultado y solo lo invalida cuando cambia una dependencia. El cálculo nuevo llega cuando alguien vuelve a leerlo.
• Templates como parte del grafo: Cuando una plantilla lee una signal, Angular registra esa lectura como dependencia del componente. Si la signal cambia, ese componente queda marcado para actualizarse.

Dynamic dependency tracking

Angular no te pide un array de dependencias como en otros frameworks. Las descubre ejecutando el código. Si un computed lee price() y quantity(), esas dos signals entran en el grafo. Si en la siguiente ejecución lee discountPrice() pero ya no lee quantity(), Angular actualiza el grafo y deja de escuchar lo que ya no importa.

const useDiscount = signal(false);
const basePrice = signal(100);
const discountPrice = signal(70);

const finalPrice = computed(() => {
  if (useDiscount()) {
    return discountPrice(); // depends on useDiscount + discountPrice
  }

  return basePrice(); // depends on useDiscount + basePrice
});

• Las dependencias se descubren al leer: La llamada basePrice() no solo devuelve un valor. Si ocurre dentro de un computed, effect, resource o template, Angular registra esa lectura como dependencia.
• El grafo cambia con cada ejecución: Si cambia useDiscount(), el computed vuelve a ejecutarse y Angular sustituye la rama activa. A partir de ahí, cambiar basePrice no invalida finalPrice mientras el descuento siga activo.
• No hay listas manuales que mantener: El mantenimiento desaparece: no hay que acordarse de añadir o quitar dependencias cuando cambias una condición, extraes una función o mueves lógica.

El modelo Push/Pull

Cuando haces .set(), Angular no recalcula todo inmediatamente. Primero empuja la suciedad por el grafo: marca como inválidos los consumidores afectados. Después, cuando alguien lee una signal derivada, tira del valor actualizado y recalcula solo lo necesario. Push para invalidar. Pull para calcular.

basePrice.set(120);

// Push: Angular marks finalPrice as stale.
// Pull: finalPrice() recalculates when someone reads it.
console.log(finalPrice());

• Push: invalidación rápida: El cambio se propaga por el grafo para avisar a los consumidores vivos de que su valor anterior puede estar obsoleto. En esta fase no se ejecutan side effects ni cálculos caros.
• Pull: cálculo bajo demanda: El valor derivado se recalcula cuando el template, un computed o un effect lo vuelve a leer. Si nadie lo lee, no se gasta CPU en recalcularlo.
• La clave está en separar las fases: Invalidar y recalcular no ocurren mezclados. Esa separación es lo que evita estados intermedios raros y hace que el sistema sea predecible.

Las tres propiedades que salen de este diseño

El grafo no es una metáfora bonita. De él salen tres propiedades prácticas que notas escribiendo componentes reales: memoización, ejecución glitch-free y dependencias dinámicas.

• Memoización: computed() guarda el último resultado. Si sus dependencias no han cambiado semánticamente, devuelve el valor cacheado. No necesitas getters defensivos, useMemo ni variables auxiliares para evitar recalcular.
• Glitch-free: Un consumidor no ve estados intermedios inconsistentes. Si total depende de subtotal y tax, no deberías ver un render donde subtotal ya cambió pero tax sigue con el valor anterior.
• Dependencias dinámicas: El conjunto de dependencias puede cambiar en runtime. Un computed puede depender hoy de discountPrice y mañana de basePrice según una condición, y Angular mantiene el grafo actualizado.

Por qué esto reemplaza a Zone.js

Zone.js responde a una pregunta muy amplia: algo ha pasado en el navegador, ¿debería Angular revisar la UI? Signals responde a una pregunta mucho más útil: este valor concreto cambió, ¿qué partes exactas de la UI dependen de él? Esa diferencia es la razón por la que Angular puede funcionar sin Zone.js.

• Zone.js detecta actividad, no intención: Un click, un timer o una promesa pueden haber cambiado estado... o no. Zone.js no lo sabe. Por eso Angular acaba ejecutando detección de cambios aunque no haya nada real que sincronizar.
• Signals notifican cambios reales: Cuando actualizas una signal, Angular sabe qué nodo del grafo cambió y qué consumidores dependen de él. Ya no necesita parchear APIs del navegador para adivinar cuándo revisar.
• Menos barrido global: El modelo antiguo tiende a recorrer el árbol de componentes desde arriba. El modelo con signals puede marcar vistas concretas porque conoce las lecturas del template.
• Zoneless no significa sin notificaciones: Angular sigue necesitando saber cuándo sincronizar. La diferencia es que ahora lo sabe por señales explícitas: signals leídas en templates, eventos, AsyncPipe, markForCheck y otras APIs compatibles.

Ventajas de usar Signals

• Reactividad granular: Angular actualiza solo el nodo exacto del DOM que cambió, no todo el árbol del componente. Menos trabajo para el framework, apps más rápidas.
• Sin subscribe() ni async pipe en template: El template lee la signal directamente con (). El código queda más limpio y el ciclo de vida de la suscripción desaparece.
• computed() memoiza automáticamente: Si las signals de las que depende no han cambiado, computed() devuelve el valor cacheado sin recalcular. Gratis, sin useMemo ni trackBy.
• Compatible con zoneless: Puedes eliminar Zone.js del bundle. Son ~50 KB menos y arranque más rápido, especialmente relevante en mobile.
• resource() e httpResource() incluidos: Datos asíncronos reactivos sin un solo Observable ni subscribe. El estado de carga y el error vienen de serie.
• Debugging síncrono: El valor de una signal siempre está disponible sincrónicamente. Puedes inspeccionarlo en el debugger sin esperar a un tick.

Signals vs RxJS: cuándo usar cada uno

Signals no mata RxJS. Le quita trabajo donde RxJS era demasiado para el problema. La decisión sana no es migrarlo todo, sino elegir la herramienta por el tipo de estado que tienes delante.

• Estado local de UI: Usa signal(). Un contador, un modal abierto/cerrado, una pestaña activa o el valor temporal de un input no necesitan Observable.
• Estado derivado: Usa computed(). Si un valor sale de otros valores, pertenece al grafo reactivo y debe recalcularse solo cuando cambian sus dependencias.
• Side effects: Usa effect() para sincronizar con APIs externas: localStorage, analytics, DOM manual o librerías que no entienden Signals.
• HTTP reactivo simple: Usa resource() o httpResource() cuando el dato depende de parámetros reactivos y quieres loading/error/value sin montar un flujo RxJS completo.
• Streams complejos: Usa RxJS para WebSockets, polling, cancelación avanzada, debounce complejo, merge, retry o composición temporal. Luego expón el resultado al template con toSignal() si hace falta.

Limitaciones y cuándo no usarlas

• No reemplazan RxJS para streams complejos: WebSockets, polling, merge, combineLatest, debounceTime... siguen siendo territorio de Observables. La solución es RxJS hasta el final + toSignal() para exponerlo al template.
• effect() mal usado genera ciclos: Si un effect escribe en una signal que también lee, o en otra signal que acaba volviendo al mismo effect, puedes crear un ciclo de invalidación. La regla: effect() es para side effects (logs, localStorage, llamadas externas), no para transformar estado.
• linkedSignal() y resource() pueden evolucionar: Son estables desde v19/v22 pero son APIs relativamente nuevas. Revisa el CHANGELOG antes de adoptarlas masivamente en una base de código grande.
• Curva de aprendizaje desde Observables: El modelo pull (lees cuando quieres) vs. push (recibes cuando hay datos) es diferente. Si vienes de RxJS puro, el click mental tarda un poco en llegar.

untracked() y el riesgo real de effect()

effect() existe para sincronizar Signals con el mundo exterior: analytics, localStorage, APIs del navegador, logs o librerías que no son reactivas. El error aparece cuando lo usas para derivar estado escribiendo otra signal dentro del effect. En v22 Angular te deja hacerlo, pero el riesgo real es crear un ciclo infinito si el effect lee algo que termina volviendo a escribir.

const price = signal(100);
const quantity = signal(2);
const totalState = signal(0);

// Bad: derived state written inside an effect.
effect(() => {
  totalState.set(price() * quantity());
});

// Better: derived state belongs in computed().
const total = computed(() => price() * quantity());

• Cuándo aparece el ciclo infinito: Si un effect lee una signal y, directa o indirectamente, escribe otra signal que provoca que el mismo effect vuelva a ejecutarse, entras en una cadena de invalidaciones. No siempre es obvio: a veces el ciclo pasa por un servicio, un setter o una función auxiliar.
• La regla práctica: Si estás calculando un valor a partir de otros valores, usa computed(). Si estás enviando un evento fuera del grafo reactivo, usa effect(). Esa separación evita la mayoría de bugs.
• Para qué sirve untracked(): untracked() permite leer una signal dentro de un effect sin registrarla como dependencia. Úsalo cuando necesitas consultar un valor auxiliar pero no quieres que ese valor vuelva a disparar el effect.
• No lo uses como parche automático: Si necesitas llenar el effect de untracked(), probablemente el diseño está mezclando derivación de estado con side effects. Primero intenta mover la lógica a computed() o separar el efecto externo.

Los seis conceptos que necesitas dominar

• signal(initialValue): El estado básico. Writable, síncrono. Úsalo para cualquier valor que cambia por interacción del usuario o respuesta de servidor.
• computed(() => derivation): Estado derivado memoizado. Se recalcula solo cuando sus dependencias cambian. Reemplaza la mayoría de los getters y los pipes puros.
• effect(() => sideEffect): Ejecuta código cuando las signals que lee cambian. Para sincronizar con sistemas externos (DOM, localStorage, analytics). No para transformar estado.
• linkedSignal() / resource(): linkedSignal crea estado derivado editable. resource gestiona datos asíncronos con estado de carga integrado.
• httpResource(): Peticiones HTTP expresadas como estado reactivo: parámetros que cambian, refetch automático y estados de carga/error sin subscribe manual.
• untracked(): Herramienta de escape para leer una signal sin convertirla en dependencia. Útil, pero peligrosa si la usas para tapar un diseño reactivo confuso.

Errores comunes al empezar con Signals

La sintaxis de Signals es pequeña, pero el modelo mental cambia bastante. Estos son los fallos que más rápido ensucian una migración.

• Usar effect() para derivar estado: Si calculas un valor a partir de otros, usa computed(). Guardarlo en otra signal desde un effect abre la puerta a ciclos y estados duplicados.
• Meter untracked() para silenciar dependencias: untracked() es para lecturas auxiliares, no para esconder que tu effect está haciendo demasiado. Si aparece mucho, revisa el diseño.
• Migrar todo RxJS sin criterio: RxJS sigue siendo mejor para streams temporales complejos. Signals brilla en estado síncrono, derivado y leído por el template.
• Montar un store global con signals sin arquitectura: Un servicio con signals puede estar bien, pero si el estado cruza rutas, equipos y flujos de negocio, necesitas reglas claras o NgRx.
• Pensar que zoneless significa sin notificaciones: Angular sigue necesitando saber cuándo actualizar. La diferencia es que ahora puede enterarse por cambios explícitos del grafo, no por Zone.js adivinando actividad del navegador.