Author: Dominicode

Tiempo estimado de lectura: 2 min

• Usa effects para interaccionar con el mundo exterior (analítica, localStorage, librerías imperativas).
• No uses effects para propagar estado dentro del grafo reactivo; usa computed() para relaciones derivadas.
• Para cancelación/debounce o flujos temporales complejos, usa RxJS y la interoperabilidad (toObservable / toSignal).
• Audita effects: la mayoría suele ser reemplazable por computed o RxJS para evitar bugs y renders extra.

total = signal(0);

constructor() {
  effect(() => {
    this.total.set(this.precio() * this.cantidad()); // antipatrón
  });
}

total = computed(() => precio() * cantidad);

const query$ = toObservable(querySignal);
const results$ = query$.pipe(
  debounceTime(300),
  switchMap(q => httpClient.get(`/search?q=${q}`))
);
const resultsSignal = toSignal(results$, { initialValue: [] });

FAQ

• ¿Puedo usar effect para sincronizar dos signals?
• ¿Por qué es mejor usar computed para valores derivados?
• ¿Cuándo debería introducir RxJS con signals?
• ¿Qué pasa si un effect escribe en otro signal?
• ¿Es acceptable resetear formularios con effects?
• ¿Cuándo usar afterRenderEffect en lugar de effect?

¿Puedo usar effect para sincronizar dos signals?

Técnicamente sí, pero es un antipatrón. Si B depende de A dentro de la app, define B como computed() en vez de escribirle desde un effect. Evitas flags especiales, renders adicionales y relaciones ocultas entre datos.

¿Por qué es mejor usar computed para valores derivados?

Porque es declarativo, lazy y memoizado. Definís la relación entre datos y solo se recalcula si alguien lee el valor, lo que reduce detecciones de cambio y hace el código más testeable.

¿Cuándo debería introducir RxJS con signals?

Cuando necesitas debounce, cancelación, switchMap o combinaciones temporales complejas. Convierte signals a observables con toObservable(), aplica operadores RxJS y, si hace falta, vuelve a signal con toSignal().

¿Qué pasa si un effect escribe en otro signal?

Genera código frágil: requiere flags especiales, oculta la relación entre datos y puede provocar re-ejecuciones innecesarias y bugs difíciles de rastrear. Mejor cambiar la fuente de la verdad o usar computed.

¿Es acceptable resetear formularios con effects?

Funciona en muchos casos, pero dispersa la lógica y dificulta testing. Puede introducir race conditions. Evalúa mover la lógica al flujo de datos principal o utilizar patrones que mantengan la fuente de la verdad clara.

¿Cuándo usar afterRenderEffect en lugar de effect?

Usa afterRenderEffect para actualizar widgets o librerías que requieren dimensiones reales del DOM después del commit. Evita layout thrashing y separa lectura/escritura del DOM imperativo.

Tiempo estimado de lectura: 4 min

• Standalone Components reducen complejidad y mejoran tree-shaking importando dependencias directamente en componentes.
• Signals aportan reactividad de grano fino: menos re-render y modelo más explícito.
• Control de flujo nativo y @defer mejoran rendimiento de templates y carga diferida por bloque.
• Migración por capas: standalone + control-flow primero; signals y zoneless después tras pruebas.

Introducción

¿Tu app Angular sigue anclada a NgModules y zone.js? De Angular 17 a Angular 21+ el framework cambió de piel: no es una serie de parches, es una reescritura de prioridades. Este artículo explica qué cambió de verdad, por qué importa a nivel de rendimiento y arquitectura, y qué debes migrar ya sin reinventar todo.

Resumen rápido (lectores con prisa)

Standalone Components: componentes sin NgModules, importas dependencias en el componente y se mejora tree-shaking.

Signals: reactividad de grano fino: signal(), computed(), effect().

Control de flujo nativo y @defer: mejor rendimiento en templates y carga diferida por bloque.

Zoneless: camino hacia detección de cambios sin zone.js, mejor SSR/hydration y menos overhead.

De Angular 17 a Angular 21+: cambios que importan (y por qué)

Angular dejó atrás la era donde los NgModules eran la única forma de estructurar una app. El objetivo ahora es reducir el bundle inicial, minimizar work wasted en render y dar al dev un modelo de reactividad más explícito.

Standalone Components

Qué: sustituyen a NgModules. Importas dependencias directamente en el componente y el compilador hace tree-shaking fino.

Por qué importa: reducción de complejidad, bundles más pequeños y lazy loading más sencillo.

Docs: guía de Standalone

Signals

Qué: reactividad de grano fino que reduce la necesidad de recorrer el árbol entero para detectar cambios. signal(), computed(), effect() son la base.

Por qué importa: menos re-render, estado más predecible y preparación para zoneless.

Docs: Signals

Control de flujo nativo en templates

Qué: @if, @for, @switch reemplazan a *ngIf/*ngFor, con mejor performance y type narrowing.

Por qué importa: rendimiento inmediato en renderizados y listas grandes; mejora la experiencia de desarrollo.

Docs: Control Flow

@defer

Qué: carga diferida a nivel de bloque en la plantilla.

Por qué importa: cargas sólo el JS cuando el usuario lo necesita, no por ruta completa; mejora Core Web Vitals.

Zoneless

Qué: camino hacia la detección de cambios sin zone.js, disponible experimentalmente y consolidándose en 20/21.

Por qué importa: menos overhead y SSR/hydration más limpio.

¿Qué migrar ya? Prioridad práctica y razones

No necesitas reescribir todo. Migrar con criterio minimiza riesgo y maximiza ganancia.

1) Migración a Standalone — Prioridad Alta

Por qué: reducción de complejidad, bundles más pequeños y lazy loading más sencillo.

Cómo: usa las schematics oficiales y migra componentes compartidos primero.

Guía: guía de Standalone

2) Control de flujo en plantillas — Prioridad Alta

Por qué: rendimiento inmediato en renderizados y listas grandes; casi siempre seguro migrar.

Cómo: ng generate @angular/core:control-flow. Beneficio inmediato en DX y perf.

Docs: Control Flow

3) Aplicar @defer en componentes pesados — Prioridad Media

Por qué: mejora Core Web Vitals (LCP/INP) sin reestructurar rutas.

Dónde: dashboards, charts, modales pesados.

Tip: combina con placeholders para UX fluida.

4) Adoptar Signals progresivamente — Prioridad Estratégica

Por qué: preparas tu codebase para zoneless; menor re-rendering y estados más previsibles.

Cómo: en nuevo código, usa signal() para estado local; usa toSignal() para bridge con RxJS cuando necesites streams.

Docs: Signals

5) Zoneless — Prioridad Condicional (Post-setup)

Por qué: mayor rendimiento y mejor SSR/hydration.

Cuándo: cuando tu app ya sea standalone y use signals; aplica tests E2E exhaustivos antes de cortar zone.js.

Ejemplo rápido: de BehaviorSubject a Signal

Antes (RxJS):

private items$ = new BehaviorSubject<Item[]>([]);

Después (Signals):

const items = signal<Item[]>([]);

No es un trámite estético: cambia cómo Angular calcula la actualización del DOM.

Señales de alarma: cuándo no usar nativamente Signals todavía

• Workflows complejos de RxJS (combinaciones, debounce, backpressure) siguen siendo RxJS.
• Librerías de terceros que dependen de zones o async pipe pueden requerir adaptación.
• Workflows gigantes en templates (30+ nodos lógicos) mejor refactorizar a código.

Herramientas y enlaces prácticos

• Guía oficial de migración
• Standalone components
• Signals
• Control flow

Hoja de ruta breve para equipos (4 pasos, pragmático)

1. Ejecuta migración a Standalone en módulos compartidos y rutas lazy.
2. Aplica control flow en las plantillas (schematic). Corre pruebas de UI.
3. Introduce @defer en componentes no críticos para mejorar LCP.
4. En nuevos componentes usa Signals; planifica migraciones en servicios críticos tras benchmarking.

Conclusión

Angular 21+ no es un “upgrade menor”. Es una plataforma más modular, más rápida y lista para SSR/Hydration moderno. No lo intentes todo de golpe: migra por capas. Empieza por standalone y control-flow —es el menor riesgo con mayor retorno— y luego adopta signals como estrategia para preparar tu app para un futuro zoneless.

FAQ

• ¿Debo migrar toda la app a Standalone de inmediato?
• ¿Signals reemplazan RxJS completamente?
• ¿Qué ventaja práctica aporta el control de flujo nativo?
• ¿Cuándo aplicar @defer en mi app?
• ¿Es seguro eliminar zone.js ahora mismo?

¿Debo migrar toda la app a Standalone de inmediato?

No. Migra por capas: empieza por módulos compartidos y rutas lazy donde el impacto es mayor y el riesgo contenido. Usa las schematics oficiales para automatizar el proceso y validar por partes.

¿Signals reemplazan RxJS completamente?

No. Signals son excelentes para estado local y reactividad fina. Sin embargo, workflows complejos de RxJS (combinaciones, debounce, backpressure) siguen siendo más apropiados con RxJS. Usa toSignal() para integrar ambos mundos.

¿Qué ventaja práctica aporta el control de flujo nativo?

Reduce trabajo innecesario al re-renderizar, mejora type narrowing en templates y ofrece mejor rendimiento en listas y vistas condicionadas. La migración suele ser segura y con mejoras inmediatas en render.

¿Cuándo aplicar @defer en mi app?

Aplica @defer en componentes pesados y no críticos para mejorar LCP: dashboards, gráficos y modales que no son necesarios en el primer pintado. Combínalo con placeholders para no romper la UX.

¿Es seguro eliminar zone.js ahora mismo?

Es condicional: sólo cuando tu app esté mayormente standalone y haya adoptado signals. Antes de eliminar zone.js, corre pruebas E2E completas y verifica compatibilidad con librerías de terceros.

Tiempo estimado de lectura: 4 min

• Mantén RxJS en los servicios y expón Signals al componente.
• Usa toSignal() o rxResource()/resource() (Angular 19+) para manejar lifecycle y estado de petición.
• Encapsula loading/data/error en un único State Object o utiliza rxResource() para menos boilerplate.
• Usa computed() para derivaciones y aplica ChangeDetectionStrategy.OnPush en componentes que consumen signals.

Las mejores prácticas para cargar datos asíncronos en componentes Angular empiezan y terminan hoy con signals. Si tu componente aún vive de .subscribe() en ngOnInit y takeUntil en ngOnDestroy, estás escribiendo código que obliga a humanos a recordar cosas que debería recordar la plataforma. Este artículo explica, con ejemplos y criterio claro, cómo mover la responsabilidad de la reactividad a la frontera (servicio → señal) y por qué eso mejora rendimiento, legibilidad y seguridad frente a memory leaks.

Resumen rápido (lectores con prisa)

Qué es: Signals son primitivos de reactividad que permiten lectura síncrona y re-evaluación eficiente.

Cuándo usarlo: Convierte Observables a Signals en la frontera (servicio → componente) y usa rxResource() en Angular 19+ para requests estándar.

Por qué importa: Evita suscripciones manuales, reduce riesgos de memory leaks y mejora detección de cambios con OnPush.

Cómo funciona: Transforma streams en signals con toSignal() o usa recursos de alto nivel (rxResource()) que exponen isLoading, error y value.

Principio: convierte streams en señales en la frontera

Regla simple y práctica: mantén RxJS en los servicios; expón Signals al componente. Usa toSignal() para transformar Observables en Signals y, si estás en Angular 19+, considera rxResource()/resource() para delegar el lifecycle y el estado de petición.

Ventajas:

• Suscripción/desuscripción automáticas.
• Lectura síncrona en templates: mySignal().
• Detección de cambios de grano fino con OnPush.

1) toSignal() — la base práctica

toSignal() convierte un Observable<T> en Signal<T> sin que el componente gestione suscripciones.

Ejemplo mínimo

import { toSignal } from '@angular/core/rxjs-interop';
@Component({ changeDetection: ChangeDetectionStrategy.OnPush })
export class UsersComponent {
  private svc = inject(UserService);
  users = toSignal(this.svc.getUsers(), { initialValue: [] });
}

Template: *ngFor="let u of users()" o {{ users().length }}. Inicializar con initialValue evita undefined y permite render inmediato.

2) Patrón recomendado: State Object (loading / data / error)

Un único signal que represente { loading, data?, error? } reduce el bricolaje en templates y evita estados inconsistentes.

Cómo mapearlo con RxJS antes de toSignal:

userState = toSignal(
  this.userService.getUser(id).pipe(
    map(user => ({ loading: false, data: user })),
    startWith({ loading: true }),
    catchError(err => of({ loading: false, error: err.message }))
  ),
  { requireSync: true }
);

En template: condicionales limpias y predecibles. Menos flags, más intención.

3) rxResource() / resource() — la API de alto nivel (Angular 19+)

Si tienes Angular 19 o superior, rxResource() cubre la mayoría de casos: estado nativo (isLoading, error, value) y cancelación automática de peticiones en carrera. Usa rxResource cuando quieras menos boilerplate y comportamiento estándar.

Ejemplo conceptual

product = rxResource({
  source: () => this.productService.getById(this.productId())
});
// product.isLoading(), product.error(), product.value()

Beneficio práctico: maneja races, reloads y status sin mapear manualmente streams.

4) computed() para datos derivados y filtros

Signals brillan cuando derivan estado de forma clara y eficiente. Reemplaza combineLatest y operadores RxJS en la capa de vista por computed().

products = toSignal(this.api.getProducts(), { initialValue: [] });
query = signal('');
filtered = computed(() => {
  const q = query().toLowerCase();
  return products().filter(p => p.name.toLowerCase().includes(q));
});

Resultado: sólo se recalculan las partes necesarias y la UI actualiza con mínimo coste.

5) Arquitectura: dónde mantener RxJS y dónde usar signals

– Servicios: RxJS sigue siendo la mejor herramienta para retry, switchMap, backoff, forkJoin, debounce. Mantén ahí los Observable<T>.

– Componentes: transforman esos Observable<T> a Signal<T> con toSignal() o usan rxResource().

– Efectos/side-effects: usa effect() para reacciones locales, pero evita poner lógica de negocio compleja en componentes.

Esta separación reduce la superficie de bugs y hace que las pruebas unitarias sean más claras.

Patrones avanzados y consideraciones prácticas

• Debounce en inputs: usa toObservable() si necesitas operadores de tiempo, y vuelve a toSignal() para consumo.
• Cancelación: confía en rxResource() o en switchMap en el servicio; no intentes gestionar cancelaciones en el componente.
• OnPush: define siempre ChangeDetectionStrategy.OnPush en componentes que consumen signals para evitar checks innecesarios.
• SSR/Universal: requireSync y initialValue ayudan a evitar inconsistencias en render server-side.

Checklist rápido (implementación inmediata)

• Mueve lógica RxJS compleja a servicios.
• Convierte Observables a Signals en la frontera con toSignal() o rxResource().
• Encapsula loading/error/data en un único State Object o usa rxResource.
• Usa computed() para estados derivados.
• Aplica OnPush y elimina AsyncPipe cuando uses signals.
• Usa effect() sólo para side-effects locales y no para lógica de negocio.

Cierre con criterio

Priorizar signals no es moda: es una corrección arquitectónica. Simplifica tus componentes, mejora la predictibilidad y evita leaks. Si quieres leer más, empieza por la guía oficial de Signals y la interoperabilidad RxJS: guía de Signals y RxJS interop. Si ya estás en Angular 19+, revisa la API de reactividad y recursos en reactividad para adoptar rxResource() donde aplique.

Haz el cambio: menos suscripciones manuales, más señales claras. Tu equipo y tu app lo agradecerán.

FAQ

• ¿Qué es la función toSignal() y para qué sirve?
• ¿Cuándo debería usar rxResource() en lugar de toSignal()?
• ¿Cómo evito memory leaks al manejar Observables en componentes?
• ¿Por qué usar un State Object con loading/data/error?
• ¿Debo eliminar AsyncPipe si uso signals?
• ¿Qué consideraciones hay para SSR/Universal con signals?