Category: Blog

Revisé hace poco un componente de Angular que cargaba una lista de productos. Contaba los observables con los dedos: un BehaviorSubject para la categoría seleccionada, un switchMap hacia HttpClient, un catchError para los fallos, un takeUntilDestroyed para no dejar suscripciones vivas, y al final, un async pipe en el template.

Todo correcto. Todo necesario. Y todo código que explica exactamente lo mismo que cualquier otro componente de carga de datos en la aplicación. La Resource API de Angular 22 resuelve exactamente este problema.

Ese patrón tiene quince años. Angular 22 tiene la respuesta definitiva.

Qué es la Resource API y por qué existe

La Resource API es el mecanismo nativo de Angular para gestionar operaciones asíncronas dentro del sistema de Signals. No es una librería de terceros, no es un wrapper sobre RxJS: es la pieza que faltaba para que el modelo reactivo de Angular estuviera completo.

La idea central es sencilla: tienes un signal que representa un parámetro (un ID, un filtro, una página), y quieres que Angular haga automáticamente el fetch cuando ese parámetro cambia. Sin subscribe, sin pipe, sin gestión manual del ciclo de vida.

En Angular 22 el ecosistema completo se compone de tres APIs:

• resource() — fetch genérico con Promise. Estable en v22.
• rxResource() — puente para servicios basados en Observable. Estable en v22.
• httpResource() — wrapper declarativo sobre HttpClient. Experimental en v22.

El matiz de los estados de estabilidad importa. resource() y rxResource() ya son API pública con garantías de compatibilidad. httpResource() sigue marcado como experimental — la API puede cambiar. Para producción crítica, ten eso en cuenta.

resource(): el punto de entrada

Usa resource() cuando el origen de datos es una Promise o una función fetch directa. El parámetro reactivo se define en params, y la función que carga los datos en loader.

import { ChangeDetectionStrategy, Component, signal, resource } from '@angular/core';
interface Producto { id: number; nombre: string; }
@Component({   selector: 'app-catalogo',   changeDetection: ChangeDetectionStrategy.OnPush,   template: `     @switch (productos.status()) {       @case ('loading')   { <p>Cargando...</p> }       @case ('reloading') { <p>Actualizando...</p> }       @case ('error')     { <p>Error: {{ productos.error() }}</p> }       @default {         @if (productos.hasValue()) {           <ul>             @for (p of productos.value(); track p.id) {               <li>{{ p.nombre }}</li>             }           </ul>         }       }     }     <button (click)="categoria.set(categoria() + 1)">Siguiente</button>     <button (click)="productos.reload()">Recargar</button>   `, }) export class CatalogoComponent {   categoria = signal(1);
productos = resource<Producto[], { cat: number }>({     params: () => ({ cat: this.categoria() }),     loader: ({ params, abortSignal }) =>       fetch(/api/products?category=${params.cat}, { signal: abortSignal })         .then(r => r.json()),   }); } 

Dos errores que verás en código antiguo o en tutoriales desactualizados:

• El campo se llama params, no request. Eso era la API experimental anterior.
• Los estados son strings literales: 'loading', 'reloading', 'error'… ResourceStatus no es un enum TypeScript nativo — es un objeto de constantes (as const), así que se compara con strings literales, no con ResourceStatus.Loading.

Cuando categoria cambia, Angular cancela el fetch anterior (usando el abortSignal que recibe el loader) y lanza uno nuevo. El ciclo de vida completo, gestionado sin escribir una sola línea de cleanup.

rxResource(): para servicios que devuelven Observables

La mayoría de proyectos Angular tienen servicios basados en HttpClient que devuelven Observable. Migrar todo a fetch puro no es viable ni deseable.

rxResource() es el puente. En lugar de loader, usa stream, que devuelve un Observable.

import { ChangeDetectionStrategy, Component, signal, inject } from '@angular/core';
import { rxResource } from '@angular/core/rxjs-interop';
import { HttpClient } from '@angular/common/http';
interface Producto { id: number; nombre: string; }
@Component({   selector: 'app-catalogo-rx',   changeDetection: ChangeDetectionStrategy.OnPush,   template: `     @if (productos.isLoading()) { <p>Cargando...</p> }     @else if (productos.hasValue()) {       <ul>         @for (p of productos.value(); track p.id) {           <li>{{ p.nombre }}</li>         }       </ul>     }   `, }) export class CatalogoRxComponent {   private http = inject(HttpClient);   categoria = signal(1);
productos = rxResource({     params: () => ({ cat: this.categoria() }),     stream: ({ params }) =>       this.http.get<Producto[]>(/api/products?category=${params.cat}),   }); } 

Dos puntos que generan confusión frecuente:

• El import correcto es @angular/core/rxjs-interop, no @angular/core.
• El método se llama stream, no loader. Los ejemplos de versiones experimentales anteriores usaban loader, de ahí la confusión.

httpResource(): la opción declarativa

httpResource() va un paso más allá: elimina la necesidad de declarar un servicio intermedio para casos de fetching simple. Lo declaras directamente en el componente.

import { ChangeDetectionStrategy, Component, signal } from '@angular/core';
import { httpResource } from '@angular/common/http';
interface User { id: number; name: string; }
@Component({   selector: 'app-user-profile',   changeDetection: ChangeDetectionStrategy.OnPush,   template: `     @if (user.isLoading()) { <p>Cargando...</p> }     @else if (user.error()) { <p>Error al cargar el perfil</p> }     @else if (user.hasValue()) { <p>{{ user.value()?.name }}</p> }   `, }) export class UserProfileComponent {   userId = signal(1);
user = httpResource<User>(() => /api/user/${this.userId()}); } 

httpResource() expone dos signals exclusivos que no tienen resource() ni rxResource():

• .statusCode() — el código HTTP de la respuesta (200, 404, 500…)
• .headers() — las cabeceras de la respuesta

Ambas son señales independientes de .status(), que sigue siendo el estado del ciclo de vida del recurso. Confundir .status() con .statusCode() es el error más frecuente al empezar con esta API.

Para respuestas que no son JSON:

// Texto plano
const readme = httpResource.text(() => /docs/readme.md);
// Binario const avatar = httpResource.blob(() => /api/user/${this.userId()}/avatar); 

Requiere provideHttpClient() en el bootstrap. Usa HttpClient e interceptores por debajo, así que tus interceptores de autenticación siguen funcionando sin cambiar nada.

Recuerda que httpResource() sigue marcado como experimental en v22. Para proyectos con requisitos estrictos de estabilidad de API, usa rxResource() con tu servicio HttpClient habitual hasta que se estabilice.

Cuándo usar cada uno

No es una decisión complicada si tienes claros los criterios:

| Situación | API recomendada | |—|—| | Fetch puro o API externa directa | resource() | | Tienes servicios con Observable existentes | rxResource() | | Fetching simple sin servicio intermedio (experimental) | httpResource() | | Necesitas el status code HTTP como signal | httpResource() |

Las tres APIs comparten la misma superficie de lectura: .value(), .isLoading(), .error(), .hasValue(), .status(), .reload(). Cambiar de una a otra es mínimamente invasivo.

Validación del dato en runtime

El genérico de TypeScript solo existe en tiempo de compilación. Si el backend devuelve algo inesperado, httpResource() no lanzará ningún error — simplemente tendrás un objeto mal tipado en runtime.

La opción parse existe exactamente para este caso:

import { z } from 'zod';
const UserSchema = z.object({   id: z.number(),   name: z.string(), });
user = httpResource(   () => /api/user/${this.userId()},   { parse: UserSchema.parse } ); 

Si el dato del backend no cumple el schema, el resource entra en estado 'error' automáticamente. Sin try/catch manual, sin runtime silencioso. Si quieres profundizar en cómo construir schemas robustos con Zod para este tipo de validación, el curso de Zod para TypeScript cubre exactamente estos patrones de producción.

Lo que cambia en tu arquitectura

La Resource API no elimina los servicios Angular — los reorganiza. Sigues necesitando servicios para encapsular lógica de negocio compleja, componer múltiples endpoints, o compartir estado entre componentes. Lo que elimina es el boilerplate de gestión de ciclo de vida en los componentes que simplemente cargan y muestran datos.

Un componente que antes necesitaba un servicio, tres operadores RxJS y un takeUntilDestroyed ahora expresa la misma intención en diez líneas. La lógica no desaparece — se mueve al lugar correcto.

Si quieres el cuadro completo — Signals, Resource API, Signal Forms, Zoneless y todo lo que llegó en v22 — el curso Angular Moderno tiene el módulo M10 dedicado íntegramente a Resource API con ejemplos sobre el proyecto ShopFlow.

Qué hacer hoy

Identifica en tu proyecto los componentes que tienen este patrón: signal o BehaviorSubject como parámetro, switchMap hacia HttpClient, y async pipe en el template.

Esos son tus candidatos para migrar a rxResource(). No necesitas reescribir los servicios. Solo cambias la forma en que el componente consume el Observable.

Empieza por un componente de solo lectura — uno que carga datos y no tiene formularios complejos. Comprueba que .status() en el template te da todo lo que necesitabas del loading$ que tenías antes.

Si funciona ahí, tienes el patrón. El resto de la migración es repetirlo.

Preguntas frecuentes

¿Cuál es la diferencia entre resource() y httpResource() en Angular 22? resource() acepta cualquier función que devuelva una Promise — puedes usarlo con fetch, con SDKs externos, o con cualquier operación asíncrona. httpResource() es un wrapper declarativo sobre HttpClient que además expone el status code HTTP y las cabeceras como signals independientes. La diferencia clave: httpResource() sigue siendo experimental en v22; resource() es API estable.

¿Puedo usar rxResource() si tengo servicios que devuelven Observables? Sí. rxResource() está diseñado exactamente para ese caso. En lugar de loader, defines un stream que devuelve un Observable. Tus servicios existentes no cambian — solo cambia cómo el componente los consume.

¿La Resource API reemplaza completamente RxJS en Angular? No. RxJS sigue siendo útil para transformaciones complejas de streams, operadores avanzados y casos donde necesitas combinar múltiples fuentes. La Resource API reemplaza el patrón subscribe/unsubscribe para carga de datos HTTP en componentes — no todos los casos de uso reactivo.

¿Qué ocurre con los datos en caché cuando cambia el signal de parámetros? Cuando el signal de params cambia, el resource entra en estado 'reloading' (no 'loading'). El valor anterior sigue disponible en .value() durante la recarga. Esto permite mostrar datos obsoletos mientras llegan los nuevos, en lugar de mostrar un spinner que vacía la UI. Es el comportamiento por defecto — no necesitas configurarlo.

¿Funciona la Resource API con Angular SSR? Sí. httpResource() usa HttpClient internamente, que ya tiene soporte de transferencia de estado para SSR. Con resource() y rxResource() necesitas gestionar tú mismo la transferencia de estado si el servidor precarga datos. La integración más limpia con SSR actualmente es a través de httpResource() o rxResource() con un servicio que use TransferState.

Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode. Ha migrado proyectos Angular en producción desde v2 hasta v22.

Sources:

• Async reactivity with resources — Angular
• Reactive data fetching with httpResource — Angular
• rxResource — Angular API
• Angular 22: Stability and Asynchronous Power — Angular Academy