La arquitectura moderna de Angular en 2026: Cómo los Signals y Signal Forms cambiaron el juego
DominicodeHace un par de años revisé una aplicación empresarial desarrollada en Angular 14. Tenía más de 80 componentes. Para sincronizar dos campos de un formulario y calcular un total dinámico, el equipo había montado un laberinto de BehaviorSubject, combineLatest, operadores de RxJS como distinctUntilChanged y tuberías async por todas partes.
Cualquier cambio menor requería tocar 4 archivos distintos. Los desarrolladores pasaban más tiempo luchando contra fugas de memoria por suscripciones no canceladas que construyendo funcionalidades de negocio.
Cuando refactorizamos esa misma aplicación a las versiones modernas de Angular basándonos en Signals y Signal Forms, eliminamos el 45% del boilerplate y la velocidad de renderizado en el navegador se disparó.
Angular ha cambiado radicalmente. Si sigues programando en Angular como lo hacías en 2020, te estás perdiendo la mayor revolución de usabilidad en la historia del framework.
El problema histórico: RxJS en la capa de UI
RxJS es una librería extraordinaria para manejar eventos asíncronos complejos como websockets, streams de datos o cancelación de peticiones HTTP.
Sin embargo, usar RxJS para gestionar el estado reactivo simple dentro de un componente de UI era una mala decisión forzada por las limitaciones del framework anterior:
- Tenías que lidiar con la subscripción y desuscripción explícita (
takeUntilDestroyed,asyncpipe). - Zone.js tenía que comprobar el árbol completo de componentes ante cualquier evento, provocando ciclos de detección de cambios innecesarios.
- La sintaxis resultaba verbosa y confusa para desarrolladores que venían de otros ecosistemas.
Con el rápido ciclo de releases de Angular, el equipo del framework ha introducido un modelo reactivo síncrono, directo y ultrarrápido: los Signals.
El nuevo paradigma: Grafo Reactivo con Signals
En la arquitectura moderna de Angular, la reactividad síncrona dentro del componente se gestiona mediante tres primitivas fundamentales:
1. signal() (Estado primario)
Representa un valor reactivo mutable. Al modificar su valor, Angular sabe exactamente qué nodo del DOM depende de él y actualiza únicamente ese elemento.
const cantidad = signal<number>(1);
const precioUnitario = signal<number>(25);
2. computed() (Estado derivado)
Calcula automáticamente un nuevo valor en función de otros signals. Es perezoso (lazy) y memoriza su resultado (memoized), por lo que solo se reevalúa cuando uno de sus signals dependientes cambia.
const total = computed(() => cantidad() * precioUnitario());
3. effect() (Efectos secundarios)
Se ejecuta cuando los signals leídos en su interior cambian.
- Regla de oro de arquitectura: Jamás uses
effect()para modificar otro signal o para lógica de negocio. Reservalo exclusivamente para sincronización externa (ej. guardar enlocalStorage, emitir eventos a librerías de terceros o analytics).
Como recalcamos en nuestras guías de programación defensiva en TypeScript, tipar de forma estricta los valores de tus signals previene errores de estado en tiempo de ejecución.
Signal Forms y Zoneless: El salto definitivo
Dos de las piezas más esperadas en el ecosistema moderno son la integración de Signal Forms y el soporte nativo para aplicaciones Zoneless (sin Zone.js).
Zoneless Angular
Al basar la UI en Signals, Angular ya no necesita Zone.js para "mono-patrullar" los eventos del navegador (clicks, timers, peticiones HTTP). El framework sabe con precisión quirúrgica qué componente y qué nodo del DOM ha cambiado. El resultado es un consumo de memoria mínimo y un arranque instantáneo.
El rol actual de RxJS
RxJS no ha muerto ni va a desaparecer. La regla de arquitectura actual es sencilla:
- Estado de UI y componentes: Usa 100% Signals (
signal,computed,input,output). - Eventos asíncronos complejos y HTTP: Usa RxJS (
HttpClient,debounceTime,switchMap) y conviértelo a Signal en la frontera del componente mediantetoSignal().
// Integración perfecta: RxJS hacia la API, Signal hacia la plantilla
readonly usuarios = toSignal(this.userService.getUsuarios(), { initialValue: [] });
La arquitectura moderna de Angular es más limpia, más rápida de aprender y infinitamente más fácil de mantener que en versiones anteriores.
Si quieres dominar el desarrollo frontend moderno y la integración con herramientas de IA, descubre los Cursos de Dominicode. Y si quieres aplicar estas arquitecturas en proyectos reales de producción, te invitamos a sumarte a Dominicode Labs.
Preguntas frecuentes
¿Debo migrar todos mis BehaviorSubject a Signals inmediatamente?
No es necesario hacer una migración destructiva de golpe. Puedes mantener tu capa de servicios en RxJS e ir adoptando toSignal() y signal() en la capa de componentes de forma progresiva.
¿Cuándo debo usar RxJS en lugar de Signals?
Utiliza RxJS cuando necesites coordinar múltiples eventos asíncronos en el tiempo (por ejemplo, autocompletados con debounceTime, polling periódico, cancelación de peticiones anteriores con switchMap o gestión de WebSockets).
¿Cómo afecta el uso de Signals al SEO y SSR en Angular?
Los Signals mejoran el rendimiento de Server-Side Rendering (SSR) y Hydration ya que reducen la sobrecarga de evaluación de cambios en el servidor y permiten una hidratación parcial ultrarrápida en el cliente.
¿Qué versión de Angular se recomienda para trabajar con Signals de forma estable?
Signals se introdujo como developer preview en Angular 16 y alcanzó estabilidad en Angular 17/18. Para contar con APIs maduras como input(), output(), model() y Signal Forms se recomienda usar Angular 19/20+.
Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.