← All guides

Angular resource(), measured — the untracked loader, the dropped race, and the value() that throws

resource() is Angular's general-purpose async primitive: params is a reactive function, loader is your async code — fetch, a gRPC client, IndexedDB, anything that returns a promise. That split is the whole design, and it's also where the sharp edges live: only params is tracked. A signal read inside the loader is silently invisible to reactivity, fetch's no-reject-on-500 behavior walks right in, and value() throws when the loader failed.

Everything below was reproduced and measured in a real Chrome on Angular 22.1 (stock ng new blueprint, resource is @publicApi 22.0 in the shipped types) with an instrumented window.fetch — two full runs, identical counts. The numbers are observed, not paraphrased from docs.

1. Try it in 10 seconds (no signup)

A shared, self-resetting demo project is live right now:

curl "https://mockbird.mockbird.workers.dev/m/demo/products?limit=3"

That URL is the API for every snippet below. CORS is open (Access-Control-Allow-Origin: *), so it works from localhost:4200, StackBlitz, CI, anywhere. When you want your own schema it's one curl or one click — see §12.

2. It fetches on construction — and undefined params is the off switch

resource() is eager: the loader runs when the class field initializes, not when the template first reads the resource. We declared three resources in one component and rendered exactly one section behind @if:

resA = resource({ params: () => ({}), loader: () => fetchProducts() });
resB = resource({ params: () => ({}), loader: () => fetchOrders() });   // hidden
resC = resource({ params: () => ({}), loader: () => fetchCustomers() }); // hidden

Measured: 3 network requests on page load — both hidden sections fetched. The escape hatch is a convention worth memorizing: if params returns undefined, the loader never runs.

q = signal<string | undefined>(undefined);
res = resource({
  params: () => this.q() ? { q: this.q()! } : undefined,   // idle until q is set
  loader: ({ params }) => searchProducts(params.q),
});

Measured: status() stayed 'idle' with 0 requests for as long as the signal was unset; one q.set('night') later — exactly 1 request, five rows. That's your "don't fetch until the user acts" pattern, no boolean flags.

3. The happy path: read signals in params, receive them in the loader

import { Component, signal, resource } from '@angular/core';

@Component({ /* ... */ })
export class ProductList {
  page = signal(1);
  res = resource({
    params: () => ({ page: this.page() }),          // tracked: reads the signal
    loader: async ({ params }) => {
      const r = await fetch(`https://mockbird.mockbird.workers.dev/m/demo/products?page=${params.page}&limit=5`);
      if (!r.ok) throw new Error('HTTP ' + r.status);
      return r.json() as Promise<Product[]>;
    },
  });
}
// template: @for (p of res.value() ?? []; track p.id) { 
{{ p.name }}
 }

Measured: exactly 1 request on load; page.set(2) produced exactly 1 refetch and the rows swapped. The loader receives the params value — it never needs to touch a signal.

4. The loader is untracked — a signal read inside it never refetches

The headline gotcha. It looks equivalent to §3. It is not:

// THE BUG: no params — "I'll just read the signal in the loader"
res = resource({
  loader: async () => {
    const r = await fetch(`${API}/products?page=${this.page()}&limit=5`); // untracked read
    return r.json();
  },
});

Measured: we clicked "next page" twice — the template dutifully rendered "page: 3", and the network log showed 1 request, total. The list stayed frozen on page-1 rows. Zero console warnings, zero errors. Angular runs loaders in an untracked context on purpose (so reading other state mid-load can't cause accidental refetch loops), but the flip side is this silent freeze: every value the request depends on must flow through params. If the loader mentions this.someSignal(), that's the bug.

5. Stale responses are dropped even if you ignore abortSignal — cancellation is opt-in

We made the first request slow (?mock_delay=2500, returning page-1 rows) and switched params 500ms in to a fast request returning a different row. First, a loader that ignores abortSignal:

raceRes = resource({
  params: () => ({ q: this.q() }),
  loader: async ({ params }) => {           // no abortSignal in sight
    const r = await fetch(urlFor(params.q));
    return r.json();
  },
});

Measured: the fast row rendered; 2.5s later the slow response landed on the network (2 completed requests, 0 aborts) — and the UI didn't budge. resource() discards resolutions from outdated loader runs. Correctness is built in; what you waste is bandwidth and server work. Passing the signal fixes that too:

loader: async ({ params, abortSignal }) => {
  const r = await fetch(urlFor(params.q), { signal: abortSignal });  // real cancellation
  return r.json();
},

Measured: same scenario — the slow request was aborted at the network layer (we captured the abort event), 1 completed response, same correct UI. And the control group, effect() + fetch with no protection at all: the fast result rendered first, then the stale slow response landed and clobbered it back. That's the bug class resource() deletes — ?mock_delay makes it reproducible on demand instead of "sometimes, on hotel wifi".

6. fetch doesn't reject on a 500 — and your loader is now the error handler

With httpResource, HTTP errors become error states automatically. With resource(), you own that logic, and fetch's oldest trap applies: it only rejects on network failure, never on HTTP status. This loader has no r.ok check:

loader: async () => {
  const r = await fetch(`${API}/products?limit=3&mock_status=500`);
  return r.json();   // parses the ERROR BODY as data
},

Measured: status() → 'resolved'. value() → {"error": "simulated 500 error (mock_status)"}, rendered as if it were data. No error state, no throw — the only trace was the browser's own network-tab console line. Every custom loader needs the two-liner from §3: if (!r.ok) throw new Error('HTTP ' + r.status). Simulate it in one query param (?mock_status=500) and watch what your template does with an error object shaped nothing like Product[].

7. value() throws in the error state — and defaultValue won't save you there

Once the loader throws, the resource enters status() === 'error': error() returns your Error('HTTP 500'), hasValue() → false — and value() throws:

Error: Resource is currently in an error state (see Error.cause for details): HTTP 500

A template that reads res.value() unguarded doesn't render an empty list on failure — it throws during render. Guard with hasValue() (it narrows the type) or branch on status().

The defaultValue subtlety, measured: with resource({ defaultValue: [] }), value() mid-load returned [] instead of undefined — nice for templates. But in the error state, value() threw exactly the same message. defaultValue covers idle and loading; it does not make failures quiet. If you want "keep showing something on error", read hasValue() ? res.value() : fallback yourself.

8. reload() keeps your rows — a param change blanks them

Two loading states look identical in a spinner but behave differently under your data. Measured mid-flight (?mock_delay=1500 makes the gap visible):

A refresh button flickers nothing; a page change flashes empty unless you handle it (keep the previous rows in a signal, or branch on status()). Same asymmetry as httpResource — it's the resource contract, not the HTTP layer.

9. No .headers() here — surface X-Total-Count from the loader yourself

httpResource exposes response headers as a signal; resource() gives you whatever your loader returns — so return the header with the rows:

pagerRes = resource({
  params: () => ({ page: this.page() }),
  loader: async ({ params }) => {
    const r = await fetch(`${API}/products?page=${params.page}&limit=10`);
    const rows = await r.json() as Product[];
    return { rows, total: Number(r.headers.get('X-Total-Count') ?? 0) };
  },
});

Measured: a load-more accumulator went 10 → 20 → 30 rows in exactly 3 requests with 0 duplicate ids, with the total read from X-Total-Count (CORS-exposed on the demo — many real APIs forget Access-Control-Expose-Headers and this silently reads null; the mock behaves like the real thing so you catch it now).

10. set() is a free optimistic-update primitive — status becomes 'local'

resource() returns a writable resource. Write to it and the framework tracks that the value no longer came from the server:

renameFirst() {
  const cur = this.res.value();
  this.res.set([{ ...cur[0], name: 'Saving…' }, ...cur.slice(1)]);  // optimistic
}

Measured: after set(), the edited row rendered immediately, status() → 'local', and 0 network requests fired. One reload() later: server truth back on screen, 'resolved', exactly 1 request. Pair it with a real write — the demo's POST/PATCH actually persist, so set()-then-PATCH-then-reload() round-trips against reality instead of write theater.

11. Deterministic retry tests — reload() against a scripted outage

Retry logic tested against a healthy API is untested. ?mock_seq serves an exact status script:

curl -s -o /dev/null -w "%{http_code}\n" \
  "https://mockbird.mockbird.workers.dev/m/demo/products?limit=1&mock_seq=503,503,200&mock_seq_key=me1"

Measured: a resource() whose loader throws on !r.ok, pointed at that URL: initial load → 'error' with HTTP 503; reload() → 503 again; second reload() → 'resolved' with data. Exactly 3 requests. On the shared demo the sequence counter is scoped per client IP (and mock_seq_key isolates parallel specs), so the curl above starts fresh for you. Statuses ≥400 are simulated before processing, so a failed write is never half-applied.

12. Get your own API (10 seconds, no signup)

curl -X POST https://mockbird.mockbird.workers.dev/api/projects \
  -H "Content-Type: application/json" \
  -d '{"preset": "ecommerce"}'

The response contains your project URL and admin key. Presets: blog, ecommerce, saas, payments — or define your own resources and field types, import an OpenAPI spec / db.json / CSV / Postman collection / HAR, and swap the base URL in the snippets above. Ship day is one environment token change.

13. Beyond this guide

• httpResource is the URL-only shorthand — auto error states, .headers(), auto-abort. Its own measured sharp edges (including 81 fetches in 5s from one effect) are at Angular httpResource, measured.
• TypeScript: GET /m/<project>/types.ts generates interfaces from your live schema (?format=zod for Zod) — a typed loader return for free.
• Mock auth: POST /m/<project>/auth/login returns a real signed JWT for any email+password — test 401 flows in your loader without a backend (guide).
• Snapshots: save a named data state, restore it in beforeEach — deterministic Karma/Playwright runs (guide).
• Request inspector: see exactly what your loader sent and when — the fastest way to prove the §4 freeze is a missing request, not a rendering bug.
• Lazy-loading the component that fetches? @defer's @loading/@error/prefetch are about the JS chunk, not your data — the loading block that never shows and the error block that ignores a 500 are measured at Angular @defer and your data, measured.
• Old-school HttpClient? The service-class version is at Mock API for Angular; NgRx SignalStore has its own measured guide at NgRx SignalStore, measured.

14. Honest comparison

Bias disclosure: this comparison is written by the Mockbird side. The measurements above, though, are just measurements — rerun them in your own Chrome with the snippets as written.