Angular: httpResource & rxResource

Overview

Angular’s resource APIs are designed to make asynchronous work feel native in a signal-driven application. Instead of manually wiring together booleans for loading, separate values for data, and extra error state, a resource centralizes that lifecycle into one reactive abstraction.

In practice, this means your components can describe what data depends on what input, and Angular keeps the resource synchronized when those dependencies change.

The resource model

Before looking at the two APIs, it helps to understand the pattern they share. A resource generally ties together:

What is httpResource?

httpResource is Angular’s signal-based wrapper for HTTP fetching. It sits on top of HttpClient, which means it benefits from the same Angular HTTP stack: interceptors, request configuration, testing tools, and familiar request semantics.

It is especially appealing when your component already uses signals for local state and computed values. Instead of bridging between Observables and signals yourself, httpResource gives you a more direct path.

Typical mental model

• A signal determines the current URL or request config.
• The resource automatically refetches when that signal changes.
• Your template reads the resource’s status and current value reactively.

import { Component, computed, signal } from '@angular/core';
import { httpResource } from '@angular/common/http';

@Component({
  selector: 'app-user-profile',
  standalone: true,
  template: `
    <button (click)="userId.set(1)">User 1</button>
    <button (click)="userId.set(2)">User 2</button>

    @if (user.isLoading()) {
      <p>Loading user...</p>
    } @else if (user.error()) {
      <p>Could not load user.</p>
    } @else if (user.value()) {
      <h3>{{ user.value()?.name }}</h3>
      <p>{{ user.value()?.email }}</p>
    }
  `
})
export class UserProfileComponent {
  userId = signal(1);

  user = httpResource(() => `/api/users/${this.userId()}`);
}

That is the core appeal: the request itself becomes reactive.

What is rxResource?

rxResource follows the same broad resource pattern, but instead of wrapping Angular HTTP requests directly, it uses an RxJS-based stream loader. This makes it a strong fit when your data source already lives naturally in the Observable world.

For example, maybe your service already composes data with switchMap, combineLatest, retry logic, caching, or custom stream operators. In those cases, rxResource lets you keep that Observable-based design while still exposing the result through Angular’s resource abstraction.

import { Component, inject, signal } from '@angular/core';
import { rxResource } from '@angular/core/rxjs-interop';
import { UserService } from './user.service';

@Component({
  selector: 'app-user-details',
  standalone: true,
  template: `
    @if (userResource.isLoading()) {
      <p>Loading...</p>
    } @else if (userResource.error()) {
      <p>Request failed.</p>
    } @else {
      <pre>{{ userResource.value() | json }}</pre>
    }
  `
})
export class UserDetailsComponent {
  private userService = inject(UserService);

  userId = signal(42);

  userResource = rxResource({
    params: () => ({ id: this.userId() }),
    stream: ({ params }) => this.userService.getUser(params.id)
  });
}

Here, the service can continue returning an Observable, while the component consumes the result through resource semantics.

Key differences

Practical examples

Example: reactive search with httpResource

search = signal('');

results = httpResource(() => {
  const q = this.search().trim();
  return q ? `/api/search?q=${encodeURIComponent(q)}` : undefined;
});

Returning undefined can be a clean way to avoid making a request until the user has entered a valid query.

Example: debounced search with rxResource

results = rxResource({
  params: () => this.search(),
  stream: ({ params }) =>
    this.searchService.search(params).pipe(
      // custom RxJS behavior could be handled here
      // debounce, retry, mapping, fallback, etc.
    )
});

This version makes more sense when the service is already designed around RxJS operators and stream composition.

When to use each

Best practices