Category: Angular

Como hacer polling en Angular con Signals y rxResource. Buenas practicas

Tiempo estimado de lectura: 4 min

Resumen rápido (lectores con prisa)

Qué es: rxResource convierte Observables en señales gestionadas (valor, carga, error, reload).

Cuándo usar: dashboards y estados donde 2–30s de retraso son aceptables; no para latencia < 1s.

Por qué importa: limpieza automática, cancelación de peticiones y patrón más seguro que intervalos manuales.

Cómo: preferible encapsular polling dentro del loader con timer + switchMap, añadir retry/backoff y pausar con Page Visibility API.

¿Qué es rxResource y por qué importa para el polling?

rxResource (paquete: @angular/core/rxjs-interop) convierte un Observable en una señal gestionada: expone .value(), .isLoading(), .error() y .reload(). Maneja la limpieza de suscripciones automáticamente cuando el componente se destruye, lo que reduce significativamente el boilerplate y las fugas de memoria. Documentación.

Eso cambia las reglas del juego: el loader de un resource puede devolver un Observable que emita múltiples valores (ideal para polling). En lugar de gestionar intervalos manuales y ngOnDestroy, encapsulas la lógica reactiva en el resource.

Estrategias válidas: cuándo usar cada una

Hay dos patrones útiles: el imperativo (reload) y el declarativo (loader periódico). Usa el primero cuando el usuario debe controlar el ciclo (pausar/reanudar). Prefiere el segundo como opción por defecto: es más limpia y segura.

1) Polling imperativo con reload()

Útil si la UI ofrece control explícito (botón pausa).

// patrón simplificado
const dataResource = rxResource({ loader: () => http.get('/api/status') });

const id = window.setInterval(() => dataResource.reload(), 5000);
// clearInterval(id) al destruir/comportamiento de pausa

Ventaja: control directo. Desventaja: gestión manual del ciclo de vida y riesgo de olvidarte de limpiar el intervalo.

2) Polling reactivo dentro del loader (recomendado)

Encapsula todo en el loader. El resource escucha un Observable que emite periódicamente.

import { timer, EMPTY, merge, of, fromEvent } from 'rxjs';
import { switchMap, map, retry, catchError } from 'rxjs/operators';

dataResource = rxResource({
  request: () => ({ interval: pollIntervalSignal() }),
  loader: ({ request }) => {
    const visibility$ = merge(
      of(document.visibilityState === 'visible'),
      fromEvent(document, 'visibilitychange').pipe(map(() => document.visibilityState === 'visible'))
    );

    return visibility$.pipe(
      switchMap(visible =>
        visible
          ? timer(0, request.interval).pipe(
              switchMap(() => http.get('/api/metrics')),
              retry({ count: 3, delay: 1000 }),
              catchError(() => EMPTY) // mantiene vivo el stream ante errores transitorios
            )
          : EMPTY
      )
    );
  }
});

Beneficios prácticos: limpieza automática, cancelación de peticiones lentas gracias a switchMap, y pause automático con Page Visibility API.

Referencia útil sobre retry. Página sobre Page Visibility API (MDN).

Buenas prácticas obligatorias (no opcionales)

• Usa switchMap para evitar race conditions. Si una petición tarda más que el intervalo, cancelas la anterior.
• Implementa backoff para errores persistentes. No bombardees un servidor con 500s: retryWhen + delay exponencial.
• Pausa el polling cuando la pestaña está oculta (Page Visibility API) o cuando el dispositivo entra en modo bajo consumo.
• Evita polling agresivo en dispositivos móviles. Considera un throttle dinámico o reducir frecuencia en redes móviles.
• Agrupa requests cuando sea posible (batching/forkJoin) para reducir overhead.
• Usa cache + TTL (shareReplay(1) con invalidación) si la misma petición la hacen múltiples componentes.
• Supervisión: expón métricas de errores/latencia en logs para detectar piezas rotas del polling.

Testing y observabilidad

• Testea con fakeAsync y tick() para simular intervalos en unit tests.
• Mockea rxResource utilizando proveedores en TestBed para controlar emisiones.
• Registra fallos y frecuencia de reintentos; si ves un patrón de reintentos masivos, cambia a backoff más agresivo o al modo “degraded”.

Cuándo no usar polling

No uses polling si necesitas latencia < 1s o alta frecuencia. Para actualizaciones en tiempo real, usa WebSockets o SSE. Polling sigue siendo válido para dashboards, contadores y estados donde 2–30s de retraso son aceptables.

Guías de alternativas: WebSockets / SSE.

Resumen práctico (lista rápida)

• Preferible: implementar polling dentro del loader de rxResource con timer + switchMap.
• Añadir: retry/backoff, Page Visibility API para pausar, shareReplay si es necesario.
• Imperativo (reload) sólo si la UX necesita control manual.
• Evitar: polling sin control de errores o sin pausa para pestañas ocultas.

Fuentes

• Angular rxResource
• RxJS retry
• Page Visibility API

FAQ

Inyección sobre inyección de constructor

Tiempo estimado de lectura: 4 min

Resumen rápido (para IA y lectores con prisa)

Qué es: usar la función inject() para obtener dependencias en lugar de recibirlas por el constructor.
Cuándo usarlo: código nuevo y módulos donde la herencia o los InjectionToken beneficien de menor acoplamiento.
Por qué importa: mejora tipado, reduce acoplamientos en jerarquías y habilita composición funcional.
Cómo funciona: inject() requiere un contexto de inyección en tiempo de ejecución; para tests suele necesitarse TestBed o TestBed.runInInjectionContext().

Inyección sobre inyección de constructor: qué cambia y por qué importa

Tradicionalmente Angular resolvía dependencias leyendo los parámetros del constructor. Hoy existe una alternativa explícita: la función inject(). Ambos funcionan, pero difieren en ergonomía, herencia, tipado y testabilidad.

Constructor (clásico):

export class UserCmp {
  constructor(private svc: UserService) {}
}

inject() (moderno):

import { inject } from '@angular/core';

export class UserCmp {
  private svc = inject(UserService);
}

A primera vista es cosética. Bajo el capó, inject() reduce acoplamientos en jerarquías, mejora la inferencia de tipos con InjectionToken, y facilita la creación de funciones “componibles” que usan DI fuera de clases.

Ventajas técnicas claras

1. Tipado más robusto con tokens

Con InjectionToken<T>, inject() infiere T sin @Inject(). Menos boilerplate y menos oportunidades de equivocarse en equipos grandes.

2. Herencia sin “infierno de super()”

Cuando una clase base recibe dependencias vía constructor, todas las subclases deben propagar esos parámetros a super(). Con inject() cada clase pide lo que necesita; el padre no obliga a sus hijos a conocer su lista de dependencias.

3. Composición y utilidades reutilizables

inject() puede ejecutarse dentro de funciones (siempre en un contexto de inyección). Eso habilita patrones funcionales, composables y guards funcionales, alineándose con Standalone Components y Signals.

4. Menos fragilidad ante cambios de compilador

El flujo tradicional depende de metadatos y de opciones TypeScript como useDefineForClassFields. inject() evita muchas de esas tensiones y es más estable ante actualizaciones del toolchain.

El coste real: testing y contexto de inyección

La pega práctica es la testabilidad fuera del ecosistema de Angular.

– Con constructor: instancias “puras” en tests son triviales.

const s = new MyService(mockHttp);

– Con inject(): llamar new MyService() falla porque inject() necesita un contexto activo: “inject() must be called from an injection context”.

Soluciones:

• Usar TestBed y configurar providers (recomendado): Guía de testing.
• Para utilidades: TestBed.runInInjectionContext() permite ejecutar funciones que usan inject() dentro del contexto adecuado:

TestBed.runInInjectionContext(() => {
  const result = useSomeComposable();
  // asserts...
});

Referencia: TestBed.runInInjectionContext()

Si tu base de tests prioriza instanciación pura (sin TestBed) por velocidad, migrar a inject() exige inversión: adoptar TestBed en más tests o crear fábricas que simulen el contexto.

Estrategia de migración práctica para equipos

– Código nuevo: usa inject() por defecto. Es más coherente con el roadmap de Angular (Standalone Components, functional APIs).

– Código legacy: no refactorices todo de golpe. Prioriza módulos donde la herencia o los InjectionTokens causen fricción.

– Tests: identifica tests que instancian clases manualmente. Para esos:

• Refactoriza a TestBed si la cobertura y la criticidad lo justifican.
• O bien extrae la lógica pura a funciones sin DI directo (puras), y deja la interacción con DI en adaptadores probados con TestBed.

Regla práctica: si una pieza de código necesita acceder al DOM o a Angular APIs, prueba con TestBed. Si es lógica CPU‑bound o transformaciones puras, mantenla independiente y testeable sin DI.

Ejemplos cortos que ilustran la diferencia

Herencia con constructor (fragilidad)

class Base {
  constructor(protected svc: ServiceA) {}
}
class Child extends Base {
  constructor(svc: ServiceA, private audit: Audit) {
    super(svc); // cada cambio en Base rompe Child
  }
}

Con inject() (estable)

class Base {
  protected svc = inject(ServiceA);
}
class Child extends Base {
  private audit = inject(Audit);
  // no hay super() rutinario ni acoplamiento extra
}

Composable fuera de clase

export function useAuth() {
  const auth = inject(AuthService);
  return () => auth.isLogged();
}

Conclusión técnica y criterio

“Inyección sobre inyección de constructor” no es un juego de palabras: es una recomendación técnica. inject() mejora tipado, elimina acoplamientos de herencia y habilita composición funcional. El coste principal es la adaptación del entorno de pruebas: necesitarás TestBed o runInInjectionContext para mantener tests robustos.

Recomendación de Dominicode para equipos técnicos:

• Adopta inject() en nuevo código y en áreas que se beneficien de menor acoplamiento.
• Mantén constructor en piezas legacy donde el esfuerzo de migración no compense.
• Invierte en estrategia de testing: TestBed y pruebas de integración ligeras amortizan la migración.

Para profundizar: Angular DI, API inject(), y guía de testing Testing. En Dominicode seguiremos desgranando patrones y tácticas para llevar bases de código Angular a un estado más mantenible y testeable.

FAQ

• ¿Qué es exactamente la función inject()?
• ¿Cuándo debería preferir inject() sobre el constructor?
• ¿Cómo afecta inject() a la herencia entre clases?
• ¿Qué impacto tiene en mis tests unitarios?
• ¿Puedo usar inject() en funciones fuera de clases?
• ¿Qué alternativas tengo si no quiero adoptar TestBed ampliamente?

Tiempo estimado de lectura: 4 min

Ideas clave

• Signals y primitivas reactivas reemplazan la mayoría de los lifecycle hooks clásicos.
• Convierte Inputs en señales y usa computed() para derivados; usa effect() para side-effects.
• Usa DestroyRef.onDestroy() para limpieza cerca del recurso, evitando ngOnDestroy globales.
• Reacciona al DOM con signal queries y afterNextRender() en lugar de los hooks after-view.

Tabla de contenidos

• Ideas clave
• Lifecycle hooks en Angular: qué dejar atrás y por qué
  • ngOnChanges → computed()
  • ngOnInit → constructor + effect() (o input())
  • ngDoCheck → casi siempre obsoleto
  • ngAfterViewInit / ngAfterContentInit → signal queries + afterNextRender
  • ngAfterViewChecked → afterRender
  • ngOnDestroy → DestroyRef
• Reglas prácticas de migración
• Por qué importa (y cuándo no cambiar)
• Lecturas recomendadas
• FAQ

price = input.required<number>();
tax   = input.required<number>();
total = computed(() => this.price() * (1 + this.tax()));

chartEl = viewChild<ElementRef>('chart');

constructor() {
  effect(() => {
    const el = this.chartEl();
    if (el) { /* setup chart */ }
  });

  afterNextRender(() => {
    // ejecutar una vez después del primer render en cliente
  });
}

const destroyRef = inject(DestroyRef);
const timer = setInterval(...);
destroyRef.onDestroy(() => clearInterval(timer));

FAQ

• ¿Por qué debería convertir mis Inputs a señales?
• ¿Cuándo sigue siendo válido usar ngOnInit?
• ¿Cómo reemplazo las suscripciones manuales?
• ¿Qué uso para inicializaciones que requieren el DOM?
• ¿Qué ventajas tiene DestroyRef frente a ngOnDestroy?

¿Por qué debería convertir mis Inputs a señales?

Convertir Inputs a señales permite expresar de forma declarativa los cálculos derivados con computed() y reaccionar con effect(). Esto elimina la necesidad de logic dispersa en ngOnChanges y reduce errores de sincronización.

¿Cuándo sigue siendo válido usar ngOnInit?

Usa ngOnInit cuando necesites un efecto que debe ejecutarse exactamente una vez y no depende de la reactividad de señales (por ejemplo, migraciones o integraciones legacy). Para lógica ligada a estado reactivo, prefiere effect().

¿Cómo reemplazo las suscripciones manuales?

Siempre que sea posible, reemplaza suscripciones con effect() o convierte fuentes externas en señales. Para recursos que aún usan callbacks o timers, registra limpieza con DestroyRef.onDestroy() junto al recurso.

¿Qué uso para inicializaciones que requieren el DOM?

Usa signal queries (viewChild(), contentChild()) que devuelven señales y combínalas con effect(). Para inicializaciones que deben ocurrir solo en cliente después del primer render, utiliza afterNextRender().

¿Qué ventajas tiene DestroyRef frente a ngOnDestroy?

DestroyRef permite registrar callbacks de limpieza cerca del recurso, haciendo la limpieza composable y localizada. Evita la necesidad de implementar la interfaz OnDestroy en cada clase y mejora la trazabilidad de recursos.

Tiempo estimado de lectura: 3 min

Ideas clave:

• Organiza por dominios (slicing vertical) en lugar de por tipo de archivo.
• Divide librerías en feature / ui / data-access (domain) / util y aplica reglas de dependencia.
• Usa el patrón Facade para aislar la UI del estado y poder cambiar implementaciones.
• Automatiza límites con reglas (ESLint / depConstraints de Nx) y aprovecha caching y librerías en Nx.

Tabla de contenidos

• Título
• Resumen rápido (lectores con prisa)
• Cómo estructurar un proyecto Angular grande sin morir en el intento (resumen práctico)
• Slicing vertical por dominio
• Taxonomía de librerías que sí funcionan
  • Feature
  • UI
  • Data-access / Domain
  • Util
• Patrón Facade: amortiguador entre UI y estado
• Reglas de dependencia: automatiza la disciplina
• Estrategias prácticas para migración y crecimiento
• Criterio técnico final
• FAQ

Cómo estructurar un proyecto Angular grande sin morir en el intento empieza por admitir que el problema no es Angular: es tu arquitectura. Agrupar por tipo de archivo es cómodo al principio y mortal a los 6 meses. Aquí explico cómo organizar por dominios, qué librerías crear, qué patrones aplicar y qué reglas automatizar para que tu app crezca sin destrozar la productividad del equipo.

En las primeras líneas: si tu equipo supera los dos desarrolladores, deja de pensar en carpetas por tecnología y empieza a pensar en dominios de negocio. Usa Nx para orquestar librerías, aplica el patrón Facade y fuerza límites con ESLint. Enlaces útiles: Nx, Module Boundaries, Standalone Components.

Resumen rápido (lectores con prisa)

Slicing vertical = agrupar por dominio. Librerías: feature / ui / data-access (domain) / util. Facade = única API estable para UI. Reglas (ESLint / depConstraints) hacen cumplir límites. Nx facilita orquestación y caching.

Cómo estructurar un proyecto Angular grande sin morir en el intento (resumen práctico)

La estructura que realmente escala combina tres decisiones simples: 1) Slicing vertical por dominio, 2) Librerías tipadas (feature/ui/data-access/util), 3) Patrones que desacoplan (Facade, Barrels) y reglas automáticas (ESLint). No es exotismo; es disciplina.

Slicing vertical por dominio

Evita el antipatrón: /components, /services, /models. En su lugar, crea dominios verticales:

• /libs/booking → todo lo relacionado con reservas.
• /libs/payments → lógica de pagos.
• /libs/shared/ui-kit → componentes presentacionales.

Cada dominio contiene sub-librerías con responsabilidades claras. El resultado: para cambiar una feature solo tocas la librería del dominio pertinente.

Taxonomía de librerías que sí funcionan

Divide las librerías en cuatro tipos. Cada tipo tiene reglas claras de dependencia.

1. Feature (feature-*)

• Contiene smart components, rutas y orquestación UI.
• Puede depender de data-access, ui y util.
• Normalmente cargada lazy.

2. UI (ui-*)

• Componentes dumb, sin lógica de negocio.
• Solo depende de ui y util.
• Reutilizable y testeable.

3. Data-access / Domain (data-access-* o domain-*)

• Estado, API services, interfaces y Facades.
• No debe depender de feature ni ui.

4. Util (util-*)

• Funciones puras, helpers, form validators.
• Sin dependencias del resto del repo.

Ejemplo de estructura en Nx:

/apps
  /customer-portal
/libs
  /booking
    /feature-search
    /data-access
    /ui-seat-map
  /payments
    /feature-checkout
    /data-access
  /shared
    /ui-kit
    /util-formatters

Patrón Facade: amortiguador entre UI y estado

El patrón Facade es la guardia de contención. Cualquier componente de feature consume una Facade, no la store o servicios HTTP directamente. Si cambias la implementación de estado, solo cambias la Facade.

import { Injectable } from '@angular/core';

@Injectable({ providedIn: 'root' })
export class BookingFacade {
  readonly bookings = this.store.selectSignal(selectBookings);
  readonly loading = this.store.selectSignal(selectLoading);

  loadBookings() { this.store.dispatch(BookingActions.load()); }
  createBooking(data: BookingInput) { this.store.dispatch(BookingActions.create({ data })); }
}

El componente usa solo la Facade. Cambias NgRx por Signals o por otra librería y el componente sigue igual.

Reglas de dependencia: automatiza la disciplina

No confíes en la buena voluntad. Usa reglas de ESLint para imponer límites. Con Nx configuras depConstraints para que una ui nunca importe data-access, o que feature solo dependa de ui, data-access y util.

{
  "depConstraints": [
    { "sourceTag": "type:ui", "onlyDependOnLibsWithTags": ["type:ui","type:util"] },
    { "sourceTag": "type:feature", "onlyDependOnLibsWithTags": ["type:ui","type:data-access","type:util"] }
  ]
}

Documentación: Module Boundaries

Estrategias prácticas para migración y crecimiento

• Start small: convierte primero librerías compartidas críticas a ui-* y data-access-*.
• Facades on day one: crea facades incluso si hoy solo usan simple HTTP; evitarás reescrituras.
• Tests per lib: cada librería con su suite de unit y e2e en CI. Nx hará caching de builds/tests.
• Standalone components: adopta standalone: true para mejorar tree-shaking y simplificar imports (Standalone Components).
• Evita SharedModule gigante: usa barrels (index.ts) y exportaciones controladas.

Criterio técnico final

Un proyecto Angular grande que no se descomponga se basa en tres cosas: límites explícitos, contratos estables (Facades/interfaces) y herramientas que refuerzan la arquitectura. Nx + Slicing vertical + Facades + ESLint = velocidad sostenible. No prometo milagros, pero sí reproducibilidad: equipos que crecen y siguen entregando sin que el repo se convierta en una fosa de hormigón.

La próxima decisión es cultural: implantar y hacer cumplir estas reglas. Hazlo y tu código dejará de pelearse consigo mismo; tu equipo ganará espacio para resolver problemas reales.

FAQ

• ¿Por qué agrupar por dominios en lugar de por tipo de archivo?
• ¿Qué tipos de librerías debo crear?
• ¿Qué es una Facade y cuándo usarla?
• ¿Cómo aplico reglas de dependencia con Nx?
• ¿Debería adoptar standalone components ahora?
• ¿Cómo migrar un repo monolítico a este enfoque por dominios?

¿Por qué agrupar por dominios en lugar de por tipo de archivo?

Agrupar por dominios (slicing vertical) reduce el acoplamiento entre features y evita que cambios en una área afecten todo el repo. Cuando el equipo supera los dos desarrolladores, la organización por tecnología se vuelve difícil de mantener y ralentiza la entrega.

¿Qué tipos de librerías debo crear?

Crea cuatro tipos: feature-* (orquestación UI y rutas), ui-* (componentes dumb), data-access-* o domain-* (estado, servicios API, facades) y util-* (helpers puros). Cada tipo tiene reglas claras de dependencia para mantener límites.

¿Qué es una Facade y cuándo usarla?

Una Facade es una capa que expone una API estable para la UI y oculta la implementación del estado (NgRx, Signals, etc.). Úsala desde el inicio: permite cambiar la implementación interna sin tocar componentes presentacionales.

¿Cómo aplico reglas de dependencia con Nx?

Configura depConstraints en la configuración de Nx para imponer qué tags pueden depender entre sí. Complementa con reglas de ESLint para bloquear importaciones directas no deseadas y automatizar la disciplina arquitectónica.

¿Debería adoptar standalone components ahora?

Adoptar standalone: true mejora tree-shaking y simplifica imports, por lo que es una buena práctica a considerar. Evalúa el impacto en tu flujo y migra de forma incremental donde aporte más valor.

¿Cómo migrar un repo monolítico a este enfoque por dominios?

Empieza por mover librerías compartidas críticas a ui-* y data-access-*. Crea Facades desde el primer día para encapsular dependencias. Añade pruebas por librería y configura depConstraints en Nx para evitar regresiones.

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.