🎯 Why these two APIs matter right now
Angular's Signals story has been building for three years. With Angular 20, the final pieces clicked into place: linkedSignal() and resource() both graduated to stable, and together they solve two problems that every Angular developer hits repeatedly.
The first problem is dependent writable state — you need a signal whose initial value is derived from another signal, but the user can also change it directly. computed() is read-only, so it's no help. Before linkedSignal(), developers reached for awkward effect() workarounds or manual synchronization logic. 😩
The second problem is async data in a signals world — you have a reactive fetch that should re-run automatically when params change, surface loading/error states as signals, and cancel in-flight requests when the params change again. Previously this meant wiring up RxJS observables, managing subscriptions, and handling race conditions by hand. resource() handles all of that declaratively. 🙌
Let's look at each one in depth.
🔗 Part 1: linkedSignal()
🤔 The problem it solves
Suppose you have a shipping options component. The available options come from a server (or a parent component as an input), and you want to pre-select the first one. But the user can also pick a different option themselves.
Before linkedSignal(), the typical approach was to use a signal() for the selection and an effect() to reset it when the options changed. This works, but effect() is meant for side effects — using it for state derivation is a code smell that the Angular team actively warns against. 🚩
linkedSignal() is the right tool: it creates a writable signal whose value resets automatically when its reactive source changes. ✨
🚀 Basic usage
import { Component, Signal, linkedSignal } from '@angular/core';
@Component({ /* ... */ })
export class ShippingPickerComponent {
shippingOptions: Signal<string[]> = getShippingOptions();
// ✅ Automatically initializes to the first option.
// If shippingOptions changes (e.g., user switches region),
// selectedOption resets to the new first element.
selectedOption = linkedSignal(() => this.shippingOptions()[0]);
selectOption(index: number) {
this.selectedOption.set(this.shippingOptions()[index]);
}
}
The key difference from computed(): selectedOption is a WritableSignal. The user can call .set() on it, and that change holds — until shippingOptions changes, at which point the computation re-runs and resets it to the new first element. 🔄
Sometimes you don't want a full reset. Say the user has selected "Air" shipping ✈️, and then the available options refresh with a new list that still includes "Air". Resetting to the first item would be a bad UX — you should keep their selection if it's still valid.
The advanced linkedSignal() form gives you access to the previous value:
interface ShippingMethod {
id: number;
name: string;
}
selectedOption = linkedSignal<ShippingMethod[], ShippingMethod>({
source: () => this.shippingOptions(),
computation: (newOptions, previous) => {
// 🔍 If the user had a selection and it still exists in the new list, keep it
if (previous) {
const stillAvailable = newOptions.find(
opt => opt.id === previous.value.id
);
if (stillAvailable) return stillAvailable;
}
// Otherwise default to the first option
return newOptions[0];
}
});
The computation function receives:
source — the new value of the source signalprevious — an object with previous.source (old source value) and previous.value (the previous linkedSignal value)
📝 Note: When using the previous parameter, you must provide generic type arguments explicitly: linkedSignal<SourceType, ValueType>.
This is the most common real-world use case. You load data from the server, display it in a form, and let the user edit it. When the user saves, you send the edited copy. If the source data reloads (e.g., another user changed it), the form should refresh. 🔁
@Component({ /* ... */ })
export class UserProfileComponent {
loadedUser = this.store.user; // a Signal<User>
// ✏️ Editable local copies — reset if loadedUser changes
name = linkedSignal(() => this.loadedUser().name);
email = linkedSignal(() => this.loadedUser().email);
role = linkedSignal(() => this.loadedUser().role);
save() {
this.store.update({
...this.loadedUser(),
name: this.name(),
email: this.email(),
role: this.role(),
});
}
}
The template uses two-way binding directly on the linked signals:
<input [(ngModel)]="name" />
<input [(ngModel)]="email" />
<select [(ngModel)]="role"> ... </select>
<button (click)="save()">Save</button>
The user can freely edit the form. If the server pushes an update to loadedUser, all three fields reset to reflect the new data. Clean, and zero effect() calls. 💪
🚫 When not to use linkedSignal()
Use computed() when the derived value should be strictly read-only — for example, a total price derived from quantity and unit price. There's no scenario where you'd want the user to override that value directly. linkedSignal() is specifically for cases where manual overrides are part of the intended UX.
📡 Part 2: resource()
😩 The problem it solves
Before resource(), fetching data reactively in Angular typically meant:
- 💉 Injecting
HttpClient
- 🔀 Using
switchMap in an RxJS pipeline to react to param changes
- 📊 Manually tracking loading and error states
- 🧹 Unsubscribing on destroy
- 🏁 Handling race conditions manually (usually via
switchMap)
That's a lot of boilerplate for something as universal as "fetch data when this signal changes." resource() replaces the whole pattern. 🎉
⚙️ How resource() works
A resource has two parts:
params 🎛️ — a reactive function (like computed()) that returns the parameters for the async operation. When the params change, the resource automatically re-fetches.loader 🚚 — an async function that receives the current params and returns a Promise.
import { resource, signal } from '@angular/core';
userId = signal<string>('user-1');
userResource = resource({
params: () => ({ id: this.userId() }),
loader: ({ params }) => fetch(`/api/users/${params.id}`)
.then(res => res.json())
});
The resource automatically exposes the following signals:
| Signal |
Type |
Description |
.value() ✅ |
T | undefined |
The resolved data |
.isLoading() ⏳ |
boolean |
True while the loader is running |
.error() ❌ |
unknown |
The thrown error, if any |
.hasValue() 🔍 |
boolean |
True when data is available |
.status() 📊 |
ResourceStatus |
Full status string |
🖼️ Using resource signals in templates
@if (userResource.isLoading()) {
<p>⏳ Loading...</p>
} @else if (userResource.error()) {
<p>❌ Error: could not load user.</p>
} @else if (userResource.hasValue()) {
<user-profile [user]="userResource.value()" />
}
⚠️ Always guard .value() with hasValue() — reading .value() when the resource is in an error state throws at runtime.
🔄 rxResource() — the RxJS-friendly variant
If your data layer uses HttpClient (which returns Observable), use rxResource() from @angular/core/rxjs-interop. It's identical to resource() except the loader function returns an Observable instead of a Promise. As of Angular 20, the loader key is called stream in rxResource().
import { inject, signal } from '@angular/core';
import { rxResource } from '@angular/core/rxjs-interop';
import { HttpClient } from '@angular/common/http';
@Component({ /* ... */ })
export class ProductListComponent {
private http = inject(HttpClient);
page = signal(1);
productsResource = rxResource({
params: () => this.page(),
stream: ({ params: page }) =>
this.http.get<Product[]>(`/api/products?page=${page}`)
});
}
rxResource() automatically unsubscribes and cancels in-flight requests when params change — no switchMap, no takeUntilDestroyed. 🧘
⚡ httpResource() — the simplest option for plain HTTP GET
For the most common case — a reactive HTTP GET with a dynamic URL — httpResource() is the most concise API:
import { httpResource } from '@angular/core';
@Component({ /* ... */ })
export class UserComponent {
userId = input.required<string>();
// 🔁 Automatically re-fetches whenever userId changes
user = httpResource(() => `/api/users/${this.userId()}`);
}
httpResource() runs through Angular's HttpClient stack, including interceptors, and returns the response as signals. It also supports response type variants (.text(), .blob(), .arrayBuffer()) and schema validation via Zod or Valibot via a parse option.
🧪 Note: httpResource() is still experimental as of Angular 21. resource() and rxResource() are stable.
🤝 Combining resource() with linkedSignal()
This is where the two APIs shine together. ✨ Say you fetch a list of posts and want to track the selected post — defaulting to the first one, but letting the user pick:
@Component({ /* ... */ })
export class PostBrowserComponent {
private http = inject(HttpClient);
category = signal('angular');
postsResource = rxResource({
params: () => this.category(),
stream: ({ params: cat }) =>
this.http.get<Post[]>(`/api/posts?category=${cat}`)
});
// 🎯 Defaults to first post, resets when posts reload,
// but user can select any post manually
selectedPost = linkedSignal(
() => this.postsResource.value()?.[0] ?? null
);
selectPost(post: Post) {
this.selectedPost.set(post);
}
}
When category changes, postsResource re-fetches, and selectedPost automatically resets to the new first post. The user can select any post in between, and that selection holds until the next category change. 🔄
🛠️ Part 3: Common patterns and pitfalls
🏁 Race conditions are handled for you
One of the most important things resource() does behind the scenes: if params change while a load is already in flight, the previous request is aborted (for resource() via AbortSignal, and for rxResource() via automatic unsubscription). You never need to think about stale responses overwriting fresh ones. 🛡️
🔗 Chained resources
Resources can depend on other resources via computed():
userResource = resource({
params: () => ({ id: this.userId() }),
loader: ({ params }) => fetchUser(params)
});
// ⛓️ Only triggers when userResource has a value
profilePicResource = httpResource(
() => this.userResource.hasValue()
? `/api/images/${this.userResource.value()!.profilePicId}`
: undefined
);
When the params function returns undefined, the resource stays in idle state and doesn't fire a request. 😴
🔃 Manual reload
Resources expose a .reload() method for cases like "pull to refresh":
<button (click)="postsResource.reload()">🔄 Refresh</button>
🚫 Avoid using resource() for mutations
resource() is designed for read operations only. If params change while a POST or PUT is in flight, the request gets cancelled — meaning your mutation might never reach the server. ⚠️ Use HttpClient directly (or a dedicated mutations pattern) for writes.
📋 Summary: which API to reach for
| Scenario |
Use |
| Derive a value reactively, user can override it 🖊️ |
linkedSignal() |
| Editable form copy synced with server data 📝 |
linkedSignal() |
| Fetch data reactively using Promise 🤝 |
resource() |
| Fetch data reactively using HttpClient/Observable 🔄 |
rxResource() |
| Simple reactive HTTP GET, don't need full control ⚡ |
httpResource() |
| Strict read-only derived value 🔒 |
computed() |
| Side effects (logging, DOM, non-Angular APIs) ⚙️ |
effect() |
📚 Further reading
