Angular Signals: Guía Completa para una Reactividad Optimizada y Gestión de Estado Eficiente

El panorama del desarrollo web está en constante evolución, y con él, la forma en que gestionamos la reactividad y el estado en nuestras aplicaciones. Durante años, Angular ha confiado en Zone.js para detectar cambios, un mecanismo potente pero que a veces podía resultar costoso en términos de rendimiento y difícil de depurar. Sin embargo, con la llegada de Angular Signals, el framework ha dado un salto cualitativo hacia un modelo de reactividad más granular, eficiente y explícito. Mayo de 2026 nos encuentra con Signals ya consolidados como un pilar fundamental en las aplicaciones modernas de Angular, ofreciendo una alternativa robusta y de alto rendimiento para la gestión del estado.

En este artículo, exploraremos en profundidad qué son los Angular Signals, cómo implementarlos para optimizar el rendimiento y simplificar la gestión de estado, y cómo se integran con el ecosistema actual de Angular. Si buscas dominar la reactividad de tus aplicaciones y llevarlas al siguiente nivel de eficiencia, esta guía completa es para ti.

¿Qué son los Angular Signals y por qué son el futuro?

Angular Signals son un nuevo sistema de reactividad que permite que los valores cambien y notifiquen a los consumidores suscritos sobre esos cambios. A diferencia de Zone.js, que parchea APIs del navegador y detecta cambios en todo el árbol de componentes de forma un tanto ‘mágica’, Signals ofrecen un modelo de reactividad basado en pull/push: los componentes ‘pull’ (obtienen) los valores cuando los necesitan, y los ‘signals’ ‘push’ (notifican) a sus consumidores cuando cambian. Esto permite una detección de cambios mucho más granular y eficiente.

Los elementos clave de Signals son:

• `signal()`: Una función que crea un valor reactivo que se puede leer y escribir.
• `computed()`: Una función que crea un signal de solo lectura cuyo valor se calcula a partir de otros signals. Su valor se recalcula solo cuando sus dependencias cambian, lo que lo hace muy eficiente.
• `effect()`: Una función que ejecuta un efecto secundario cada vez que cambian los signals de los que depende. Es ideal para sincronizar el estado con APIs externas o el DOM, pero debe usarse con precaución.

Ventajas clave de Signals:

• Rendimiento mejorado: Al ser un sistema de reactividad granular, se reducen las comprobaciones de cambios innecesarias, lo que se traduce en aplicaciones más rápidas.
• Mejor experiencia de desarrollo: El flujo de datos es más explícito y fácil de seguir, lo que facilita la depuración y el mantenimiento.
• Independencia de Zone.js: Abre la puerta a la posibilidad de ejecutar aplicaciones Angular sin Zone.js en el futuro, simplificando la pila de tecnología.
• Sintaxis concisa: Permite escribir código reactivo de manera más directa y legible.

Primeros Pasos con Signals: Crea tu Primer Estado Reactivo

Comencemos con un ejemplo básico para entender cómo funcionan los signals.

Creando un signal simple

Para crear un signal, simplemente importamos la función `signal` de `@angular/core` y la inicializamos con un valor.

import { Component, signal } from '@angular/core';@Component({  selector: 'app-contador',  standalone: true,  template: `    
Conteo: {{ contador() }}
    Incrementar    Decrementar  `,  styles: [`:host { display: block; padding: 20px; border: 1px solid #ccc; border-radius: 8px;}`]})export class ContadorComponent {  contador = signal(0);  incrementar() {    this.contador.update(value => value + 1);  }  decrementar() {    this.contador.update(value => value - 1);  }}

En este ejemplo:

• `contador = signal(0);` declara un signal con un valor inicial de 0.
• `contador()` se usa para leer el valor del signal en la plantilla o en el código.
• `this.contador.update(value => value + 1);` es la forma segura y recomendada de actualizar un signal, especialmente si el nuevo valor depende del anterior. También existe `this.contador.set(newValue);` para asignar directamente un valor.

Usando `computed()` para valores derivados

Los signals son aún más potentes cuando creamos valores derivados a partir de ellos usando `computed()`. Estos valores son de solo lectura y se recalculan automáticamente solo cuando sus dependencias cambian.

import { Component, signal, computed } from '@angular/core';@Component({  selector: 'app-estado-tarea',  standalone: true,  template: `    
Tarea: {{ tareaTitulo() }}
    
Estado: {{ estadoTarea() }}
    Cambiar Estado  `,  styles: [`:host { display: block; padding: 20px; border: 1px solid #ccc; border-radius: 8px; margin-top: 10px;}`]})export class EstadoTareaComponent {  tareaTitulo = signal('Aprender Angular Signals');  completada = signal(false);  estadoTarea = computed(() =>    this.completada() ? 'Completada' : 'Pendiente'  );  toggleCompletada() {    this.completada.update(value => !value);  }}

Aquí, `estadoTarea` es un signal `computed` que depende del signal `completada`. Cada vez que `completada` cambia, `estadoTarea` se recalcula y la plantilla se actualiza automáticamente.

Gestión de Estado Complejo con Angular Signals

Si bien los ejemplos anteriores son sencillos, Signals brilla en la gestión de estado más complejo, como objetos o arrays. Es crucial entender cómo manejar la inmutabilidad para evitar sorpresas.

Manejo de objetos y arrays con Signals

Al trabajar con objetos o arrays, a menudo queremos actualizar propiedades específicas o elementos sin reemplazar todo el objeto/array. La inmutabilidad es clave para asegurar que los signals detecten los cambios correctamente.

import { Component, signal } from '@angular/core';interface Usuario {  id: number;  nombre: string;  email: string;}@Component({  selector: 'app-perfil-usuario',  standalone: true,  template: `    
      
Perfil de {{ usuario().nombre }}
      
ID: {{ usuario().id }}
      
Email: {{ usuario().email }}
      Actualizar Email    
  `,  styles: [`:host { display: block; padding: 20px; border: 1px solid #ccc; border-radius: 8px; margin-top: 10px;}`]})export class PerfilUsuarioComponent {  usuario = signal({    id: 1,    nombre: 'Juan Pérez',    email: '[email protected]'  });  actualizarEmail() {    // Uso de `update` para crear una nueva instancia del objeto    this.usuario.update(currentUsuario => {      if (!currentUsuario) return null;      return {        ...currentUsuario,        email: '[email protected]'      };    });  }}

En este ejemplo, usamos el operador spread (`…currentUsuario`) para crear una nueva instancia del objeto `Usuario` con el email actualizado. Esto asegura que el signal detecte el cambio y notifique a sus consumidores. Si hubiéramos mutado directamente el objeto (`currentUsuario.email = ‘…’`), el signal no detectaría el cambio ya que la referencia al objeto original sería la misma.

Creando un Store básico con Signals

Podemos encapsular la lógica de estado en un servicio para crear un ‘store’ básico, compartiendo el estado a través de la aplicación.

import { Injectable, signal, computed } from '@angular/core';interface CarritoItem {  id: number;  nombre: string;  precio: number;  cantidad: number;}@Injectable({ providedIn: 'root' })export class CarritoService {  private _items = signal([]);  readonly items = this._items.asReadonly();  readonly totalItems = computed(() =>    this._items().reduce((acc, item) => acc + item.cantidad, 0)  );  readonly precioTotal = computed(() =>    this._items().reduce((acc, item) => acc + item.precio * item.cantidad, 0)  );  agregarItem(item: Omit) {    this._items.update(currentItems => {      const existingItem = currentItems.find(i => i.id === item.id);      if (existingItem) {        return currentItems.map(i =>          i.id === item.id ? { ...i, cantidad: i.cantidad + 1 } : i        );      }      return [...currentItems, { ...item, cantidad: 1 }];    });  }  removerItem(itemId: number) {    this._items.update(currentItems =>      currentItems.filter(item => item.id !== itemId)    );  }  limpiarCarrito() {    this._items.set([]);  }}

Este servicio utiliza signals privados (`_items`) y expone versiones de solo lectura (`items.asReadonly()`) junto con `computed` para el total de ítems y el precio. Esto proporciona un patrón de gestión de estado simple pero robusto.

Integrando Signals con Componentes y Servicios

La integración de Signals con el resto de Angular es fluida, especialmente con la detección de cambios `OnPush`.

Uso en plantillas (templates)

Como vimos en ejemplos anteriores, simplemente llamamos al signal como una función para obtener su valor en la plantilla: `{{ miSignal() }}`. Angular se encarga automáticamente de suscribirse a los cambios y actualizar el DOM.

Signals en componentes con `Input` y `Output`

Mientras que los `@Input()` tradicionales no son signals, es una práctica común convertir un input a un signal dentro del componente si se necesita reactividad interna sobre él. Para Angular 17+, los inputs basados en signals (`signalInput`) son la norma.

import { Component, signal, input, output } from '@angular/core';@Component({  selector: 'app-producto-card',  standalone: true,  template: `    
      
{{ nombreProducto() }}
      
Precio: {{ precioProducto() | currency:'EUR' }}
      Agregar    
  `,  styles: [`    .card { border: 1px solid #eee; padding: 15px; border-radius: 8px; margin-bottom: 10px; }  `]})export class ProductoCardComponent {  idProducto = input.required();  nombreProducto = input.required();  precioProducto = input.required();  agregarACarrito = output();}

Aquí, `input()` crea un signal que se puede usar directamente en la plantilla o en `computed`s dentro del componente. El output sigue siendo un `EventEmitter` (o la nueva función `output()`).

Compartir estado entre componentes vía servicios

El `CarritoService` del ejemplo anterior demuestra cómo compartir estado. Un componente podría inyectar el servicio y acceder a `carritoService.items()` para mostrar los productos, y llamar a `carritoService.agregarItem()` para modificarlos. Esto centraliza la lógica de estado y la hace accesible.

Signals y `effect()`: Sincronizando Efectos Secundarios

La función `effect()` es poderosa para gestionar efectos secundarios que necesitan reaccionar a cambios en signals. Es importante entender su propósito y sus limitaciones.

Cuándo usar `effect()`

Un `effect` se ejecuta una vez inmediatamente, y luego cada vez que cualquiera de los signals que lee dentro de él cambia. Es ideal para:

• Sincronización con APIs del navegador (localStorage, cookies).
• Logging o analíticas.
• Manipulación directa del DOM (con precaución).
• Lógica de negocio compleja que debe ejecutarse como un efecto secundario (aunque a menudo `computed` es mejor para lógica pura).

import { Component, signal, effect } from '@angular/core';@Component({  selector: 'app-ajustes-usuario',  standalone: true,  template: `          Tema Oscuro:              
Mensaje: {{ mensaje() }}
  `,  styles: [`    :host { display: block; padding: 20px; border: 1px solid #ccc; border-radius: 8px; margin-top: 10px; }    .dark-mode { background-color: #333; color: white; }  `]})export class AjustesUsuarioComponent {  temaOscuro = signal(false);  mensaje = signal('');  constructor() {    // Leer el tema de localStorage al inicio    const savedTheme = localStorage.getItem('temaOscuro');    if (savedTheme === 'true') {      this.temaOscuro.set(true);    }    // Sincronizar tema con localStorage y clase CSS del body    effect(() => {      const isDark = this.temaOscuro();      localStorage.setItem('temaOscuro', String(isDark));      document.body.classList.toggle('dark-mode', isDark);      this.mensaje.set(isDark ? 'Modo oscuro activado.' : 'Modo claro activado.');    });  }  toggleTemaOscuro() {    this.temaOscuro.update(value => !value);  }}

En este ejemplo, el `effect` se encarga de:

• Guardar el estado de `temaOscuro` en `localStorage`.
• Añadir o remover la clase `dark-mode` del `document.body`.
• Actualizar un signal `mensaje` informativo.

Precauciones y antipatrones

• No usar `effect` para lógica de negocio pura: Si un valor puede ser un `computed`, úsalo. Los `effect`s son para efectos secundarios, no para derivar estado.
• Evitar mutar signals directamente dentro de `effect`s: Esto puede llevar a bucles infinitos si el signal mutado es también una dependencia del efecto. Es mejor mutar signals que no son dependencias del efecto, o usar efectos para disparar eventos.
• Limpieza: Los `effect`s se limpian automáticamente cuando el componente o el servicio en el que se crearon se destruye, pero en casos más complejos, puedes necesitar la función de limpieza que devuelve `effect()`.

Signals vs. RxJS: ¿Cuándo usar cada uno?

Una de las preguntas más frecuentes es si Signals reemplaza a RxJS. La respuesta corta es no. Signals y RxJS son herramientas complementarias, cada una sobresaliendo en diferentes escenarios.

• Angular Signals:
  • Ideal para gestión de estado síncrono y granular.
  • Simplifica la reactividad para datos que cambian con el tiempo de forma directa y síncrona.
  • Excelente para componentes, servicios con estado local y derivado.
  • Fácil de entender para desarrolladores nuevos en la reactividad.
• RxJS (Reactive Extensions for JavaScript):
  • Especializado en flujos de datos asíncronos complejos.
  • Potente para manejar eventos, llamadas HTTP, websockets, y cualquier secuencia de valores a lo largo del tiempo.
  • Ofrece un vasto ecosistema de operadores para transformar, combinar y manipular streams de datos.
  • Necesario para patrones reactivos avanzados y composición asíncrona.

¿Cuándo usar qué?

• Usa Signals para el estado interno de tus componentes o servicios que es principalmente síncrono o que representa el valor actual de una fuente asíncrona.
• Usa RxJS para gestionar operaciones asíncronas complejas (ej: llamadas HTTP encadenadas, debounce de inputs, eventos drag-and-drop), luego puedes convertir el resultado final de un observable a un signal si necesitas que ese valor sea reactivo en tu UI.

Interoperabilidad entre Signals y RxJS

Angular proporciona utilidades para facilitar la conversión entre ambos:

• `toSignal()`: Convierte un `Observable` de RxJS en un `Signal`. Esto es muy útil para transformar la respuesta de una llamada HTTP en un signal reactivo.
• `toObservable()`: Convierte un `Signal` en un `Observable` de RxJS, permitiendo que otros observables reaccionen a los cambios del signal.

import { Component, signal } from '@angular/core';import { toSignal } from '@angular/core/rxjs-interop';import { HttpClient } from '@angular/common/http';import { switchMap, of, delay } from 'rxjs';interface Post {  id: number;  title: string;  body: string;}@Component({  selector: 'app-data-fetcher',  standalone: true,  template: `    Cargar Posts    
      
Posts:
      
        
{{ post.title }}
        
{{ post.body.substring(0, 100) }}...
      
    
    
Cargando posts...
    
Error al cargar los posts: {{ posts.error.message }}
  `,  styles: [`    :host { display: block; padding: 20px; border: 1px solid #ccc; border-radius: 8px; margin-top: 10px; }    .card { border: 1px solid #eee; padding: 10px; margin-bottom: 5px; }  `]})export class DataFetcherComponent {  private _triggerLoad = signal(undefined);  posts = toSignal(    this._triggerLoad.pipe(      switchMap(() =>        this.http.get('https://jsonplaceholder.typicode.com/posts').pipe(          delay(1000) // Simular retardo de red        )      )    ),    { initialValue: [] }  );  constructor(private http: HttpClient) {}  cargarPosts() {    this._triggerLoad.set(undefined); // Dispara la carga de datos  }}

En este ejemplo, un `signal` (`_triggerLoad`) se usa para disparar la carga de datos. El `observable` de `HttpClient` se convierte a un `signal` (`posts`) usando `toSignal()`, permitiendo manejar la carga y los errores de forma reactiva en la plantilla.

Estrategias de Migración: Llevando tu Aplicación a Signals

Migrar una aplicación Angular existente a Signals puede ser un proceso gradual y muy beneficioso. No es necesario reescribir todo de golpe.

Identificar candidatos a migrar

• `BehaviorSubject` o `Subject` simples: Si tienes `BehaviorSubject`s que solo almacenan un valor y no requieren operadores RxJS complejos, son candidatos perfectos para ser reemplazados por `signal()`.
• Propiedades `@Input()` que se utilizan para derivar estado interno: Los inputs basados en signals (`input()`) simplifican esto.
• Lógica de detección de cambios compleja: Si tienes muchos componentes con `ChangeDetectionStrategy.OnPush` y aún experimentas problemas de rendimiento o tienes que usar `ChangeDetectorRef.detectChanges()`, Signals puede ayudar a simplificar y optimizar.

Pasos graduales para la migración

1. Comienza con nuevas características: Introduce Signals en nuevos componentes o funcionalidades que desarrolles.
2. Refactoriza pequeños `BehaviorSubject`s: Identifica los servicios o componentes que usan `BehaviorSubject` para un estado simple y migra a `signal()`.
3. Adopta `input()` basado en signals: Si estás en Angular 17+, usa los inputs basados en signals para nuevas propiedades o al refactorizar componentes.
4. Convierte Observables a Signals con `toSignal()`: Usa esta utilidad en servicios o componentes para manejar la salida de observables de forma más sencilla en la UI.

Consideraciones

• Pruebas: Asegúrate de que tus pruebas cubran el comportamiento de los signals. Los signals son fáciles de mockear en pruebas unitarias.
• Comprender el flujo de datos: Al principio, puede ser un cambio de mentalidad, pero el flujo explícito de signals es una gran ventaja a largo plazo.
• No te apresures: La migración es un maratón, no un sprint. Adopta Signals donde tenga más sentido y aporte el mayor valor.

Buenas Prácticas y Consejos Avanzados con Signals

• Inmutabilidad: Al actualizar objetos o arrays en signals, siempre crea nuevas instancias para asegurar que el signal detecte el cambio. Usa `update()` con cuidado.
• Minimiza `effect()`: Los `effect`s son poderosos, pero úsalos solo cuando no haya otra alternativa más declarativa (como `computed`). Demasiados `effect`s pueden complicar el flujo de datos.
• Encapsulación de estado: Encapsula tus signals y sus métodos de actualización dentro de servicios para crear stores reutilizables, como en el `CarritoService`. Expón solo interfaces de solo lectura (`asReadonly()`) cuando sea posible.
• Nombres descriptivos: Nombra tus signals de manera clara y coherente (ej: `productoActual`, `usuarioLogueado`).
• Tipado estricto: Aprovecha TypeScript para tipar tus signals (`signal`, `signal`), mejorando la seguridad y la legibilidad del código.
• Evita lecturas de signals en constructores o inicializadores fuera de `effect`/`computed`: Los signals solo garantizan la reactividad cuando se leen en un contexto reactivo (plantilla, `computed`, `effect`). Leerlos fuera de estos puede no reaccionar a cambios.
• Testing: Los signals son fáciles de testear. Puedes instanciar un signal directamente y llamar a sus métodos `set()` o `update()` para verificar el comportamiento.

El futuro de Angular con Signals es prometedor, abriendo las puertas a mejoras significativas en rendimiento y una experiencia de desarrollo más intuitiva. Al dominar esta potente característica, estarás equipando tus aplicaciones con un sistema de reactividad moderno y eficiente, listo para los desafíos del desarrollo web en 2026 y más allá.