DEV Community: Giorgio Galassi

validateHttp() Has No Async Machinery: A Trace From Signal Forms Down to fetch() 🔍🚀

Giorgio Galassi — Thu, 27 Aug 2026 09:45:47 +0000

Let's be honest: async validation is the part of any forms library where you brace yourself. Debouncing, cancelling the request the user just invalidated by typing another character, keeping a "checking..." spinner honest, not letting a slow response overwrite a fast one. Every library that has ever done this has grown a pile of bespoke machinery for it.

So when Signal Forms shipped validateHttp() and it just worked, I wanted to see the pile. I opened the source expecting a few hundred lines of async bookkeeping, and instead found a function whose entire body is a single call to something else.

That turned into a trace all the way down, from a form field to the line where bytes actually leave the browser. Six layers, and only two of them add anything you could call new async machinery.

✅ Availability: validateHttp() is @publicApi 22.0, stable. Every source reference in this article is pinned to the v22.1.1 tag, so the line numbers stay valid even as main moves.

🧩 The View From Outside

The usage is unremarkable, which is the point. You declare that a field validates against an endpoint, and you're done:

const schema = form(this.model, (path) => {
  validateHttp(path.username, {
    request: ({ value }) => `/api/username-available?u=${value()}`,
    debounce: 300,
    onError: () => ({ kind: 'server-unreachable' }),
    onSuccess: (res: { available: boolean }) =>
      res.available ? undefined : { kind: 'username-taken' },
  });
});

Sync validators run first, the request waits until they pass, field().pending() is true while it's in flight, and typing again cancels the previous call. If you've read Part 3 of my Signal Forms series, that's the behaviour contract you already know. The question here is who implements it.

🔍 Layer 1: validateHttp() Is a Delegation

Here is the whole function, from validate_http.ts:

export function validateHttp(path, opts) {
  validateAsync(path, {
    params: opts.request,
    debounce: opts.debounce,
    factory: (request) => httpResource(request, opts.options),
    onSuccess: opts.onSuccess,
    onError: opts.onError,
    when: opts.when,
  });
}

That's it. No await, no subscription, no cancellation logic. The URL function you wrote becomes the params of something, and httpResource() gets handed over as a factory. Out of the whole file, that factory is the only line that does anything HTTP-related; everything else naming HTTP is an import, a type or a doc comment.

So the async machinery is in validateAsync. Let's go there.

🧠 Layer 2: Three Behaviours, Zero New Mechanisms

validate_async.ts is where I expected the pile to be. It isn't there either. Three behaviours, each one built from something that already existed.

Sync-before-async gating is just returning undefined. The computation that feeds the resource's params does this:

if (validationState.shouldSkipValidation() || !validationState.syncValid()) {
  return undefined;
}

A resource() whose params computation returns undefined sits in idle and never calls its loader — loadEffect() returns early as soon as it sees extRequest.request === undefined. That's documented public behaviour, not a forms detail. The docs promise that async validation runs only after all synchronous validation passes. Nobody implemented that promise here. It falls out of a rule that was already there.

pending() is a resource status, read through a validator. The async error rule is a switch (lightly condensed here — the real one wraps each result in addDefaultField() to attach it to the field):

switch (res.status()) {
  case 'idle':                      return undefined;
  case 'loading': case 'reloading': return 'pending';
  case 'resolved': case 'local':
    return res.hasValue() ? opts.onSuccess(res.value()!, ctx) : undefined;
  case 'error':                     return opts.onError(res.error(), ctx);
}

Six resource statuses collapse into four form outcomes. field().pending() holds no state of its own, it's a projection of res.status().

Debounce composes two existing primitives instead of writing a timer:

if (opts.debounce !== undefined) {
  const debouncedResource = debounced(() => params(), opts.debounce);
  const wrappedParams = computed(() => ɵchain(debouncedResource));
  return opts.factory(wrappedParams);
}

debounced() is a public (still experimental) @angular/core primitive, and ɵchain is the internal side of ctx.chain(), the resource-composition helper you reach through a params context. The file does declare export function chain(), but it carries no @publicApi marker and is not surfaced on @angular/core's public entry point, which is why the forms code reaches it through the ɵ-prefixed alias rather than importing it by name. The forms team is chaining a debounced resource into a loader's params exactly the way you would chain any two resources in your own code. Worth noticing that they're dogfooding an experimental API in a stable feature.

⚙️ Layer 3: httpResource() Swaps the Loader

httpResource() extends ResourceImpl and doesn't override any of the loading logic. It passes in a loader that subscribes to HttpClient, and it adds three signals:

Signal	What it is	Resets on request change?
`progress`	`linkedSignal` sourced from `extRequest`	Yes, by the graph
`statusCode`	`linkedSignal` sourced from `extRequest`	Yes, by the graph
`headers`	`computed` over a `linkedSignal`, gated on status	Yes, plus stays `undefined` until `resolved`/`error`

So changing the request resets all three with no reset code involved — and the gate on headers means you never read half-populated headers mid-flight.

The one place a reset is written by hand is override set(), which clears all three when you write a value locally. The signal graph covers the request path; the local-write path doesn't go through it.

One line inside that loader is the bridge between the signal world and the HTTP world:

sub = this.client.request(request!).subscribe({ /* ... */ });

🔧 Layer 4: The Pipeline Everything Shares

ResourceImpl is the actual engine, and it's four reactive nodes. The one I'd single out is the state machine, because it explains a UI behaviour you've probably relied on without asking why:

// the branch taken when the resource already has previous state
status = request === undefined ? 'idle' : 'loading';

There are two of these, one per branch of an if/else inside that linkedSignal. The first covers initialisation and can also resolve straight from an initial stream; the second is the one above, taken when params change on a resource that already exists. Both send undefined to 'idle'. That expression runs inside a linkedSignal, which means it's not behind an await. linkedSignal is lazy, it recomputes on read rather than on write, but that recomputation is pure and synchronous: the first read of status() after your params change already returns 'loading', and pending() is already true, in the same tick, before any promise exists. Only the data is async. If you've ever wondered why Signal Forms' pending state doesn't flicker, that's the reason: the state transition doesn't live inside the async function.

The loader itself is called by exactly one effect whose only tracked dependency is the request. Nobody calls the loader imperatively. The graph decides that work should happen, and a single effect does it. It's the same lazy, pull-based model I traced in Internals #1, which is a good sign: you learn this machine once and it keeps showing up.

🔌 Layer 5: Where the Trace Goes Dark

Follow client.request(...) downward and you hit a wall. HttpClient hands off to HttpHandler, HttpHandler hands off to HttpBackend, and both of those are abstract classes with a single handle() method and no implementation. Grep as hard as you like, no import leads to the code that touches the network.

That's because the binding isn't an import, it's a provider. From provider.ts, reformatted here to fit the width (the real HttpBackend entry uses a block-bodied factory, and each object sits on its own lines):

const providers: Provider[] = [
  HttpClient,
  FetchBackend,
  HttpInterceptorHandler,
  {provide: HttpHandler, useExisting: HttpInterceptorHandler},
  {provide: HttpBackend, useFactory: () => inject(FetchBackend)},
  {provide: HTTP_INTERCEPTOR_FNS, useValue: xsrfInterceptorFn, multi: true},
];

provideHttpClient() is the only place in the framework where those two abstract tokens get a concrete answer. Two details are easy to get wrong here. First, HttpClient itself is @Injectable({providedIn: 'root'}) and FetchBackend is auto-provided too, so both classes are reachable from a bare injector. Forgetting provideHttpClient() doesn't fail on HttpClient, it fails with No provider for HttpHandler, because the class resolves and its dependency doesn't. Second, re-listing HttpClient and the backends in that array isn't redundant. It re-provides them at the environment injector where you called the function. That's what lets a lazy route have its own interceptors, instead of everything collapsing onto one root instance.

This is also why swapping the transport is a one-line change:

Feature	What it adds	Status at v22.1.1
`withFetch()`	`{provide: HttpBackend, useExisting: FetchBackend}`	Deprecated — "`FetchBackend` is the default `HttpBackend`"
`withXhr()`	`{provide: HttpBackend, useExisting: HttpXhrBackend}`	Supported — still needed for upload progress and JSONP

🌐 Layer 6: The Floor

FetchBackend is where Angular stops and the platform starts:

private readonly fetchImpl =
  inject(FetchFactory, {optional: true})?.fetch ?? ((...args) => globalThis.fetch(...args));

const fetchPromise = this.ngZone.runOutsideAngular(() =>
  this.fetchImpl(request.urlWithParams, {signal, ...init}),
);

Even the last hop is injectable. And notice handle() returns new Observable(...), so nothing was sent until layer 3 called .subscribe(). The cold Observable is the hinge the whole chain turns on: the resource's effect decides when, and the subscription is the trigger.

Cancellation runs back up the same path in reverse. Typing another character changes the params signal, so the effect aborts its AbortController, the httpResource loader unsubscribes, the RxJS teardown aborts a second AbortController inside FetchBackend, and that one is the signal handed to fetch. Four different cancellation idioms relayed in sequence, with a staleness check at the top that rejects a late response by object identity in case anything slips through.

✅ Closing Thoughts

Lined up, the whole stack is one pipeline with one part swapped at each level:

Layer	What it swaps	What it adds
`validateHttp()`	The params	Nothing at all — the body is one delegating call
`validateAsync()`	The params again, now gated and debounced	The translation from resource status into form errors
`httpResource()`	The loader	`headers()`, `statusCode()`, `progress()`
`ResourceImpl`	Nothing — it is the pipeline	Status, cancellation, staleness
`HttpClient`	The transport, through DI	Interceptors, XSRF, the transfer cache
`FetchBackend`	Nothing either — it's the floor	Chunked body reading, progress, timeouts, and finally `globalThis.fetch`

FetchBackend is the one row worth a caveat: there is real code down there, it just isn't async validation code. None of the debouncing, cancelling or pending-state logic we came looking for lives below ResourceImpl.

The reason this matters beyond trivia: there's no forms-specific async system to learn, work around, or wait on the team to extend. If you understand resource(), you already understand validateHttp(), and anything it does you can reproduce with public APIs. Gate a loader by returning undefined. Render pending state off status(). Debounce by chaining a debounced() resource into your params. That's the entire feature.

It's also a fair signal about the abstraction's honesty. A thin layer over primitives you can reach yourself is one you can debug at 6pm on a Friday, and one that inherits every improvement made underneath it for free.

If you want to walk it yourself, clone the repo at v22.1.1 and read in this order: validate_http.ts, validate_async.ts, common/http/src/resource.ts, then core/src/resource/resource.ts (the constructor, then loadEffect). A nice runtime check: provide a custom FetchFactory that logs, then type into a validateHttp field and watch one line appear at the bottom of a five-layer stack.

For the usage side of Signal Forms, Part 1 through Part 4 of the series cover the API from the outside. This one was the floor beneath it.

If you found this helpful, follow me here and on LinkedIn for more deep dives into Angular, web performance, and modern frontend development.

I also send the longer, more opinionated version of this kind of thing to a small list — reading the source, and what it changes about how you build. Subscribe here.

See you in the next one! 🤙🏻
— G.

Angular WebMCP — Your App is Now an AI Tool 🔥🚀

Giorgio Galassi — Sat, 08 Aug 2026 10:09:17 +0000

There's a pattern in Angular releases that I've come to appreciate: every major version picks one bet that's slightly ahead of its time. Signals were that bet in v16. Zoneless was that bet in v21. In v22, that bet is WebMCP, and it's a fundamentally different kind of feature — not a framework improvement, but an architectural shift in what an Angular app is.

Let me explain what I mean.

🧭 The Idea: Outside → In

Every Angular feature so far has been about what happens inside the app — how components detect changes, how services are injected, how forms manage state. WebMCP is different: it's about exposing your app's capabilities to the outside, specifically to AI agents running in the browser.

The mental model is simple. Today, an AI assistant browsing your app sees a DOM — pixels and HTML. It can read text and click buttons, but it has no understanding of what your app can do. WebMCP changes that. You declare a set of tools backed by your real Angular services, your real signals, your real DI graph, and any WebMCP-capable agent can discover and call them directly through a typed, described interface you control.

This is different from Agent Skills, which is your app calling out to AI. Two separate features, two directions: WebMCP is agents driving your app; Agent Skills is your app calling AI. Today we're only talking about WebMCP.

🔧 Browser Support

WebMCP is built on the W3C ModelContext API, a draft browser standard. Your tools register on navigator.modelContext and any agent that speaks this protocol can query that object and call them.

As of June 2026, Edge 147 ships it natively, Chrome 149 has an open Origin Trial, Firefox is committed for Q3 2026, and Safari for Q4. Mass adoption is realistically mid-2027, and Angular ships this as experimental — that flag is honest, but the integration is already surprisingly clean.

⚠️ Experimental: provideExperimentalWebMcpTools() is available in Angular 22 but carries no stability guarantees yet. The W3C spec is still evolving; expect API changes before general availability.

🛠️ Building Your First WebMCP Tool

Let's build something concrete. A dashboard shows a list of expenses and we want an AI assistant to ask "what expenses are currently visible?" and get real, live data back — not a DOM scrape or a static API response, but the actual signal state the component is rendering from.

Step 1: The service

// expense.service.ts
import { Service, signal } from '@angular/core';

export interface Expense {
  id: string;
  description: string;
  amount: number;
  currency: string;
  category: ExpenseCategory;
}

export const ExpenseCategory = {
  Accommodation: 'accommodation',
  Transport: 'transport',
  Meals: 'meals',
} as const;

export type ExpenseCategory = typeof ExpenseCategory[keyof typeof ExpenseCategory];

export const CATEGORY_VALUES = Object.values(ExpenseCategory).join(', ');

@Service()
export class ExpenseService {
  private expenses = signal<Expense[]>([
    { id: '1', description: 'Hotel',  amount: 250, currency: 'USD', category: ExpenseCategory.Accommodation },
    { id: '2', description: 'Taxi',   amount: 35,  currency: 'USD', category: ExpenseCategory.Transport },
    { id: '3', description: 'Dinner', amount: 80,  currency: 'USD', category: ExpenseCategory.Meals },
  ]);

  getVisible(): Expense[] {
    return this.expenses();
  }
}

@Service() is Angular 22's new shorthand for @Injectable({ providedIn: 'root' }) — if you want the full picture on that, I covered it in Angular 22 — @Service and injectAsync: Dependency Injection Finally Grows Up. Notice that CATEGORY_VALUES lives right here next to the ExpenseCategory object — we'll use it to keep the tool description in sync automatically.

Step 2: Declaring the tool

Parameters are described using JSON Schema syntax — the same format Angular uses internally and the same format the agent receives.

// expense-mcp.tool.ts
import { declareExperimentalWebMcpTool, inject } from '@angular/core';
import { ExpenseService, ExpenseCategory, CATEGORY_VALUES } from './expense.service';

export const expenseListTool = declareExperimentalWebMcpTool({
  name: 'getVisibleExpenses',
  description: 'Returns the list of expenses currently visible in the dashboard.',
  inputSchema: {
    type: 'object',
    properties: {
      category: {
        type: 'string',
        description: `Filter by expense category. Allowed values: ${CATEGORY_VALUES}.`,
      },
    },
    additionalProperties: false,
  },
  execute: ({ category }: { category?: ExpenseCategory }) => {
    const svc = inject(ExpenseService);
    const all = svc.getVisible();
    const filtered = category ? all.filter(e => e.category === category) : all;
    return { content: [{ type: 'text', text: JSON.stringify(filtered) }] };
  }
});

Four things to notice here.

The return value follows the MCP tool result format. { content: [{ type: 'text', text: '...' }] } is the wire format the agent expects, defined by the Model Context Protocol spec. You don't return a plain object or array directly — you serialise your data into that text field with JSON.stringify, and the agent parses it on its end. This is not Angular-specific; it's the protocol contract every MCP tool must honour.

name and description are instructions to the LLM, not documentation for humans. The agent reads them at runtime to decide whether and how to call the tool, so write them like an OpenAPI spec for an AI: precise, specific, unambiguous.

execute runs inside Angular's injection context, which means inject() works normally and your tool has full access to your DI graph.

CATEGORY_VALUES is derived from the object, not hardcoded. Add a value to ExpenseCategory and the agent description updates automatically, with no second place to maintain.

Step 3: Registering in the app

// app.config.ts
import { provideExperimentalWebMcpTools } from '@angular/core';
import { expenseListTool } from './expense-mcp.tool';

export const appConfig = {
  providers: [
    provideExperimentalWebMcpTools([expenseListTool]),
    // ... rest of your providers
  ]
};

One line in your app config and you're done. From here, any WebMCP-capable agent visiting your app will find getVisibleExpenses in document.modelContext.tools and can call it against the live session.

🔍 What the Agent Actually Sees

When a WebMCP-capable agent inspects the page, this is what it finds on document.modelContext:

{
  "tools": [
    {
      "name": "getVisibleExpenses",
      "description": "Returns the list of expenses currently visible in the dashboard.",
      "inputSchema": {
        "type": "object",
        "properties": {
          "category": {
            "type": "string",
            "description": "Filter by expense category. Allowed values: accommodation, transport, meals."
          }
        },
        "additionalProperties": false
      }
    }
  ]
}

The user says "show me only transport expenses." The agent reads the schema, resolves category: "transport", calls the tool. Angular runs the handler against the live signal state. The agent gets back exactly the filtered rows the dashboard is currently showing — no DOM scraping, no brittle selectors, no static mock data.

⚛️ Signal Forms as Agent Tools

If your app is form-heavy, Angular 22 also ships provideExperimentalWebMcpForms(), which automatically surfaces all your Signal Forms as agent-callable tools without you having to declare each one manually.

// app.config.ts
import { provideExperimentalWebMcpForms } from '@angular/forms/signals';

export const appConfig = {
  providers: [
    provideExperimentalWebMcpForms(),
  ]
};

⚠️ Experimental: provideExperimentalWebMcpForms() is double-experimental — both WebMCP itself and the forms integration are in preview. Treat it as a proof of concept for now.

Each Signal Form becomes a tool the agent can fill and submit. For internal tooling or admin dashboards this is already genuinely useful, and it shows where the Angular team is heading: if Signal Forms are the way to model user intent, they should also be the way to model agent intent.

💡 Beyond the Happy Path

The docs highlight forms as the easy entry point, but the more interesting territory is everything else — read queries, write actions, navigation triggers.

Let's be honest: a read + write pair is where agents become genuinely powerful. Expose getExpenseReports() alongside flagExpense(id, reason) and an agent can query, reason over the data, and act in a single turn. Add permission-awareness by injecting your AuthService inside the execute handler and the agent automatically gets a properly scoped view, seeing only what the current user is authorised to see. You could also expose derived data tools like getSummaryByCategory() — pre-computed aggregates cost fewer tokens and produce faster responses than handing the agent a raw list to process itself.

The general principle worth internalising: anywhere you'd write a hardcoded string describing your domain model, ask whether you can derive it from TypeScript instead. Your types are the single source of truth and the agent's schema should follow from them, not diverge from them.

🔒 One Thing Worth Getting Right Early: Trust

Because execute handlers run inside Angular's injection context with full access to your DI graph, a WebMCP tool is as powerful as the service method it wraps — which means a write tool is a real mutation, not a preview. Before shipping any tool that modifies state, there are three things worth understanding.

Prompt injection in your descriptions. The description and parameter description fields are read by the LLM as trusted context. A malicious site can embed instructions in its own tool descriptions that manipulate the agent's behaviour on other sites — and if your own tool returns user-generated content, that content is another vector. The W3C security considerations doc calls this out explicitly under "Metadata / Description Attacks" and "Output Injection Attacks": never echo unsanitised user content directly from an execute handler.

Angular does not validate inputs for you. The agent is supposed to match the inputSchema you define, but Angular makes no guarantee it does — the execute callback receives whatever the agent sends. The Angular docs are explicit on this: "Consider explicitly validating arguments to the execute function before using them." Treat every input as untrusted, the same way you would a form submission or a query parameter.

The session is the attack surface. The W3C spec's threat model notes that agents inherit the user's authentication context — session cookies, logged-in state, everything. The real risk isn't an anonymous external caller; same-origin constraints handle that. The risk is a legitimate, trusted agent that has been manipulated through prompt injection and then calls your write tools with the user's full permissions. Design accordingly: scope write tools tightly, and never expose an action you wouldn't want triggered automatically on behalf of a logged-in user.

⚠️ The Honest Caveat

The W3C spec is still early and has been changing frequently. Mid-2027 is the realistic mass-adoption target, when both browser default support and enough publisher adoption exist to make it meaningful at scale. For now it's great for internal tools and early experimentation, but it's not ready to ship to anonymous production users.

That said, the direction is set. Your app has always had one interface — the DOM, for humans. WebMCP adds a second one, for agents. How you design that second surface is a new skill worth starting to develop now, before the spec lands and everyone is catching up at once.

If you found this helpful, follow me here and on LinkedIn for more deep dives into Angular, signals, AI, and modern frontend development.

See you in the next one! 🤙🏻
— G.

linkedSignal() Writes Back: A Trace Through the Reactive Graph 🔍🚀

Giorgio Galassi — Fri, 07 Aug 2026 08:43:39 +0000

Let's be honest: linkedSignal() always had a bit of a split personality. It read beautifully from another signal, deriving a value that stayed in sync automatically. But the moment you needed to write back to that source, you were on your own, writing a separate method, converting the value by hand, and hoping you didn't forget to call it from every place that touched the field.

Angular 22.1 closes that gap. linkedSignal() can now take a custom set() option, and the linkedSignal becomes a genuine two-way field: read from a larger piece of state, write back to it, no disconnected duplicate copy of the data anywhere.

My first reaction when I saw this: if the linkedSignal reads a source signal, and writing to the linkedSignal updates that same source, doesn't that loop forever? It didn't feel obvious to me, so I went and traced through the actual reactive graph source to settle it, and that turned into a nice little tour of how Angular's signals actually work.

✅ Availability: the custom set() option shipped in Angular 22.1.0 (stable) and is documented in the official linkedSignal guide.

🧩 Before: Reading Was Clean, Writing Wasn't

Here's the classic shape. A profile signal holds the real state, and a linkedSignal exposes one field of it:

protected readonly profile = signal<UserProfile>({
  id: 1,
  name: 'Brian',
  email: 'brian@example.com',
  maxMarketingEmailsPerWeek: 2,
});

protected readonly maxMarketingEmailsPerWeek = linkedSignal(
  () => this.profile().maxMarketingEmailsPerWeek
);

Reading maxMarketingEmailsPerWeek() is effortless. Writing back to profile is not: you need a second method that does the profile.update() dance, and every button, every input handler, has to remember to call that method instead of the linkedSignal directly. The read side and the write side live in two different places for what is conceptually one piece of state.

🔧 After: A Custom set()

The fix is a set function passed alongside the computation:

protected readonly maxMarketingEmailsPerWeek = linkedSignal(
  () => this.profile().maxMarketingEmailsPerWeek,
  {
    set: (value) => {
      this.profile.update((profile) => ({
        ...profile,
        maxMarketingEmailsPerWeek: value,
      }));
    },
  }
);

Now maxMarketingEmailsPerWeek.set(5) and .update(v => v + 1) both flow through that setter and land on profile. The helper method is gone. The simplest version of this idea, straight from the Angular docs, is a temperature converter:

const tempC = signal(0);
const tempF = linkedSignal(() => (tempC() * 9) / 5 + 32, {
  set: (valF) => tempC.set(((valF - 32) * 5) / 9),
});

tempF.set(212);
console.log(tempC()); // 100
console.log(tempF()); // 212

🧠 Wait, Doesn't This Loop?

Here's where I got stuck. tempF reads tempC() inside its computation, so tempF is a genuine dependent of tempC in the reactive graph. When tempC.set(100) runs inside the custom setter, that dependency absolutely gets marked dirty and tempF absolutely does recompute. If it didn't, tempF() would show a stale value after the conversion, and the whole feature would be pointless.

So the question I actually needed answered was: does that recompute call the custom setter again? It doesn't, and the reason is architectural, not incidental.

🔍 Under the Hood: The Write Path

linkedSignal's public write API, defined in linked_signal.ts, looks like this once a custom setter is supplied:

const rawSet = (newValue: D) => linkedSignalSetFn(node, newValue);
upgradedGetter.set = (newValue: D) => customSet(newValue, rawSet);
upgradedGetter.update = (updateFn: (value: D) => D) =>
  customSet(updateFn(untracked(getter)), rawSet);

Calling tempF.set(212) invokes exactly one thing: your customSet function. It never touches tempF's own internal value directly, unless your function explicitly calls the rawSet escape hatch it's handed. In the temperature example, it doesn't, it only calls tempC.set(100).

The temperature example never reaches for that second parameter, but there are two situations where you would. One is performance: when computation is expensive and you already know the exact result, rerunning it is wasted work. The other is less obvious: not every linkedSignal has an invertible relationship with its source the way tempF/tempC do. Plenty of real computation functions, summarizing, rounding, picking one field out of several possible source states, can't be inverted into a single correct value to write back. rawSet covers both: it's a direct line to the exact primitive that backs the default .set() when there's no custom setter at all, letting you plant the value directly instead of inverting through the source:

} else {
  upgradedGetter.set = (newValue: D) => linkedSignalSetFn(node, newValue);
  upgradedGetter.update = (updateFn) => linkedSignalUpdateFn(node, updateFn);
}

rawSet is (newValue) => linkedSignalSetFn(node, newValue), the same call, just handed to you as an argument instead of wired up automatically. Here's what that function actually does, from the signal primitives:

export function linkedSignalSetFn<S, D>(node: LinkedSignalNode<S, D>, newValue: D) {
  producerUpdateValueVersion(node); // resolve any pending staleness first
  signalSetFn(node, newValue);      // plain field write: node.value = newValue, version++
  producerMarkClean(node);          // mark the node up to date
}

Three steps: settle any recompute that's already overdue, write node.value directly with the same primitive a plain signal() uses (never touching node.computation or node.sourceValue), then mark the node clean.

That first step is worth pausing on, because "settle any overdue recompute" is literal. If the linkedSignal is currently dirty, its source changed since anyone last read it, producerUpdateValueVersion runs producerRecomputeValue before your value ever gets written, which means computation fires once, and if it has any observable side effects, they happen. Your value always wins in the end, the freshly recomputed result gets overwritten immediately after, but "computation never runs" isn't quite true in that specific case. The mark-clean step is what matters for everything after this call: it tells the next read's staleness check that the node is current, so from then on producerRecomputeValue is skipped, regardless of what the source is doing in the meantime.

Line them up and there are three distinct write paths, not two:

`.set()`	What happens	`computation`
Default, no custom setter	Calls `linkedSignalSetFn(node, v)` directly.	Does not run. Exception: if the node was already `stale` due to an earlier unread source change, it runs once first to settle the pending recomputation.
Custom setter, setter writes to the source	Only the source's version is bumped. This node is marked dirty but is otherwise untouched.	Re-runs lazily, the next time the `linkedSignal` is read.
Custom setter, setter calls `rawSet(v)`	Identical to the default case: calls `linkedSignalSetFn(node, v)`.	Does not run, except when there is already a pending stale recomputation that must settle first.

Here's the performance case: a custom setter with independent knowledge of the right answer, where redoing the computation would be wasted work:

const items = signal<Item[]>(hugeInitialList);

const sortedItems = linkedSignal(
  () => expensiveSort(items()), // recomputes whenever items() changes
  {
    set: (value, rawSet) => {
      // We just got an already-sorted page back from the server —
      // no need to re-run expensiveSort() for a value we already know.
      rawSet(value);
    },
  },
);

sortedItems.set(pageFromServer); // writes directly, skipping a fresh expensiveSort() run

Compare that to the temperature example: there, the setter calls tempC.set(...) because it genuinely needs tempF to re-derive from the new tempC. Here, the setter already has the final value, so it bypasses the derivation instead of inverting it.

And here's the other case, where inverting through the source isn't just wasteful, it doesn't make sense at all:

const rawInput = signal('42.7');

const roundedValue = linkedSignal(
  () => Math.round(Number(rawInput())),
  {
    set: (value, rawSet) => {
      // Multiple rawInput strings round to the same integer, there's
      // no single correct string to write back, so just store the value.
      rawSet(value);
    },
  },
);

Rounding is lossy: many different rawInput values produce the same roundedValue, so there's no correct string for the setter to write back to rawInput. rawSet sidesteps the question entirely, it's the same direct write the default .set() would give you if there were no custom setter at all.

Both cases share the same shape: rawSet is for when inverting through the source is either wasteful or doesn't make sense, and you'd rather just set the value. It also keeps a single public method for callers: .set(x) works the same way from the outside whether this particular value is a normal edit that should flow through the source, or a precomputed result the setter recognizes and stores directly. The linkedSignal, not the caller, decides which applies.

That's the entire write path, everything .set() and .update() can reach, custom setter or not. rawSet can reach into the recompute machinery to settle a pending stale value, but never the other way around.

⚙️ Under the Hood: The Recompute Path

The recompute lives somewhere else entirely, in the signal primitives:

const linkedSignalGetter = () => {
  producerUpdateValueVersion(node); // check staleness, recompute if needed
  producerAccessed(node);
  return node.value;
};

Every signal getter, plain signal(), computed(), or linkedSignal(), is shaped this way. producerUpdateValueVersion checks whether any dependency's version changed since the last read, and if so, calls producerRecomputeValue, which reruns the computation and assigns straight to node.value as a plain field write:

newValue = node.computation(newSourceValue, prev);
node.sourceValue = newSourceValue;
// ...
node.value = newValue;
node.version++;

That's the whole answer. tempC.set(100) only flips a dirty flag and bumps a version counter, no computation runs at that moment. The actual recomputation is deferred until the next time something reads tempF(), and when it happens, it happens through producerRecomputeValue, a function that has never heard of customSet. Not directly, not indirectly. There's no code path in the primitives package that leads back to your setter. That direction is the one that would actually matter: if recomputation could call back into customSet, that's the loop you'd have to worry about, and it provably can't. The reverse isn't quite as absolute, rawSet can call into producerRecomputeValue to settle a pending stale value, as covered above, but even then it only ever reaches this same recompute logic, never back into your setter. That asymmetry, not a strict mutual isolation, is the whole reason a linkedSignal can safely both read from and write to the same piece of state.

One detail worth keeping in mind: this recompute isn't scheduled for later, it's synchronous and pull-based. If tempF() is read inside another computed(), the staleness check and recompute for tempF happen inline, in the same call stack, before that outer computed can finish. Angular's signals are lazy all the way down: nothing recalculates until someone actually asks for a value, but once something does ask, the whole stale chain resolves immediately, in dependency order.

✅ Closing Thoughts

So, back to the question that opened this piece: no, it doesn't loop, and now you know exactly why: producerRecomputeValue can't reach back into customSet, only rawSet reaches the other way. That one-way gap is what makes it safe.

The custom set() option is a small addition on paper, one new field in an options object, but it changes what linkedSignal() is for. Before, it was a read-only derivation with a writable escape hatch bolted on by convention (the default set/update, with no custom setter, just overwrites the linkedSignal's own value directly). Now it can be the field-level API for a slice of larger state, without ever creating a second source of truth. And it does that safely because Angular's signal graph keeps "someone wrote to me" and "one of my dependencies changed" as two structurally separate events, not because of anything defensive in the code you write.

If you haven't read my earlier piece comparing computed() and linkedSignal(), that's the conceptual "when to reach for which" companion to this one, this article is the deep end: the internals that explain why the two-way version is safe.

If you're touching linkedSignal() in a codebase that also uses Signal Forms or resource(), the same lazy, pull-based recompute model is running underneath all of them. Worth understanding once, pays off everywhere.

If you found this helpful, follow me here and on LinkedIn for more deep dives into Angular, web performance, and modern frontend development.

See you in the next one! 🤙🏻
— G.

Angular v19+ — Understanding @defer: Blocks, Triggers, and Deferrable Views (Part 2) 🔥🚀

Giorgio Galassi — Sun, 07 Dec 2025 10:12:11 +0000

One of the main goals in modern Angular apps is reducing hydration costs and improving user experience. With Angular v19, we finally get native tools to achieve this: Incremental Hydration and Event Replay.

In Part 1, we explored the fundamentals of @defer blocks and triggers. Now, let’s see how Angular extends that foundation to make hydration smarter and interactions smoother.

💧 Incremental Hydration

Hydration is the process of transforming a pre-rendered HTML page (generated by server-side rendering) into a fully interactive Angular app on the client side.

Incremental Hydration takes this a step further by letting you control when specific parts of your application should become interactive.

This means better Core Web Vitals, faster initial paints, and a smoother user experience overall.

Activate it like this:

export const appConfig: ApplicationConfig = {
  providers: [
    // other providers
    provideClientHydration(withIncrementalHydration())
  ]
};

Once configured, you can start deferring hydration for parts of your UI:

@defer (hydrate on idle) {
  <large-cmp />
} @placeholder {
  <div>Large component placeholder</div>
}

The hydrate syntax mirrors the classic @defer structure, supporting the same triggers and patterns. You can even combine behaviors:

@defer (on idle; hydrate on interaction) {
  <large-cmp />
} @placeholder {
  <div>Example Placeholder</div>
}

Note: The on interaction trigger behaves differently when used with hydrate. Classic @defer requires an element reference, while hydrate doesn’t—the interaction happens directly with the de-hydrated version of the component.

Example:

<!-- Classic @defer -->
<div #greeting>Hello!</div>

@defer (on interaction(greeting)) {
  <greetings-cmp />
}

<!-- @defer with hydrate -->
@defer (hydrate on interaction) {
  <greetings-cmp />
}

With hydrate, the component itself is the trigger, simplifying setup and making it easier to use in real-world hydration scenarios.

Why it matters

Incremental Hydration is especially valuable for large apps with multiple deferred views — dashboards, content-heavy pages, or e-commerce layouts. It helps you decide when to activate interactivity, improving both performance and responsiveness.

⚡ Event Replay

Server-Side Rendering (SSR) is key for performance and SEO, but it introduces a common problem: lost interactions.

When HTML is pre-rendered, users can start clicking before the JavaScript is fully hydrated. Without proper handling, those interactions are lost — leading to broken UX.

Event Replay fixes this by capturing events during hydration and replaying them in the same order they occurred.

This ensures every user action is processed, even if it happened before the app became interactive.

Activate it with:

export const appConfig: ApplicationConfig = {
  providers: [
    // other providers
    provideClientHydration(withEventReplay())
  ]
};

If you’re already using withIncrementalHydration(), you don’t need to add withEventReplay() separately—it’s included automatically.

Why it matters

Event Replay ensures that no user action is lost. It captures input events (like clicks, scrolls, or typing) and replays them after hydration. The result is a seamless, frustration-free experience for users.

🧩 Combined Example

Here’s how both features can work together:

export const appConfig: ApplicationConfig = {
  providers: [
    provideClientHydration(withIncrementalHydration())
  ]
};

@defer (hydrate on interaction) {
  <user-profile />
} @placeholder {
  <loading-spinner />
}

In this example, Angular hydrates the user-profile component only after the user interacts with its placeholder. Any clicks made before hydration are safely replayed, thanks to Event Replay.

🧠 Behind the Scenes

Under the hood:

Incremental Hydration reuses the server-generated DOM and attaches event listeners lazily.
Event Replay hooks into the browser’s event queue, caching early interactions and re-dispatching them once hydration is complete.

These optimizations work together to provide a faster, more resilient user experience especially in apps with complex, interactive UIs.

🪄 Key Takeaways

Incremental Hydration lets you decide when to make parts of your app interactive.
Event Replay ensures no interaction is lost during hydration.
Combined, they improve Core Web Vitals, reduce Time to Interactive, and simplify performance optimization in Angular.
👉 Try it live on StackBlitz to see Incremental Hydration and Event Replay in action! Core Web Vitals, reduce Time to Interactive, and simplify performance optimization in Angular.

If you found this helpful, follow me here and on LinkedIn for more deep dives into Angular, web performance, and modern frontend development.

See you in the next one! 🤙🏻
— G.

Angular v18+ — Understanding @defer: Blocks, Triggers, and Deferrable Views (Part 1) 🔥🚀

Giorgio Galassi — Sun, 07 Dec 2025 10:02:30 +0000

Angular v18 continues to introduce powerful new features, some aimed at simplifying development workflows, such as the @let syntax, redirectTo as a function, and ng-content fallback content. Other functionalities, however, are designed to enhance application performance.

What is Angular’s `@defer` Block?

The @defer block is part of Angular's newly introduced control-flow syntax family (@if, @for, @switch, and more). This feature allows developers to delay the loading of specific elements until certain pre-determined triggers are met. These triggers can be selected from a predefined list or customized. You can also create a sequence of triggers to control exactly when the component is loaded.

@defer {
  <my-very-heavy-component />
}

Why use Angular’s deferrable views for optimized performance?

Deferrable views offer the advantage of significantly reducing the initial bundle size. By deferring a view, you can avoid loading a heavy component until it’s needed, improving both performance and user experience. For example, you might delay loading a component that becomes relevant later in the application’s flow.

Note: Not all components are deferrable. To use @defer, a component must be standalone, and it's essential to avoid referencing it outside the @defer block (e.g., using @ViewChild).*

Starting with Angular v19, newly created components will be standalone by default, meaning they will also be deferrable by default.

Exploring `@defer` Blocks: Syntax and Usage

This section breaks down the different @defer sub-blocks:

@placehodelr\: Displays default content while the deferred component is loading.
@loading\: Shows a loading indicator while the deferred content is being fetched.
@error\: Displays a fallback message if the deferred content fails to load.

Note: All components, directives, or pipes used within any of these sub-blocks are eagerly loaded.*

How to Combine Multiple Triggers with `@defer` in Angular v18

Angular offers various triggers for controlling when deferred content is loaded:

on idle: Loads when the browser is idle; it’s the default trigger for the @defer block.
on viewport: Loads when the content enters the viewport.
on interaction: Loads based on specific user interactions, such as clicks or form submissions.
on hover: Triggers when the user hovers over the element.
on immediate: Loads content immediately under specific conditions.
on timer: Loads after a specified time delay.
when: Specifies a condition as an expression that returns a boolean.

You can also combine triggers to create complex loading scenarios, such as loading content when it enters the viewport or when the user hovers over it.

<!-- More than one `on` example -->
<!-- Multiple on triggers are always `OR` conditions -->
@defer (on viewport; on timer(5s)) {
  <my-very-heavy-component />
} @placeholder {
  <img src="placeholder.png" />
}

<!-- Defer `when` example -->
@defer (when cond) {
  <my-very-heavy-component />
}

<!-- Defer `on` and `when` example -->
<!-- `on` and `where` conditions are always `OR` conditions -->
@defer (on viewport; when cond) {
  <calendar-cmp />
} @placeholder {
  <img src="placeholder.png" />
}

Best Practices for Using `@defer` in Angular v18: Tips and Considerations

To use @defer effectively, it’s essential to understand potential performance implications and optimize its usage:

Avoiding Layout Shifts: Ensure that deferred components do not cause layout shifts that could impact the user experience.
Standalone Components Only: Make sure components used with @defer are standalone to avoid dependency conflicts.
Combining Triggers Wisely: Use combinations of triggers strategically to maximize performance and user engagement.

Nested `@defer` Blocks

It is possible to have nested @defer blocks, with each block respecting and waiting for its own trigger. To prevent unexpected behavior, it is recommended to assign different triggers to each block, unless you intentionally want multiple blocks to respond to the same triggers.

Below, you can find a StackBlitz project where you can explore nested @defer blocks:

stackblitz.com

At the time of this article’s publication, the StackBlitz contains examples of:

on interaction
on viewport
Nested @defer blocks

To observe the deferred loading in action, open the network tab in your browser’s developer tools and filter by JavaScript (JS) to see only the downloaded files. Experiment with the application, and you will notice different chunks of components being loaded in a deferred manner.

Conclusion

Starting with Angular v18, the @defer feature provides a powerful way to optimize your application’s loading strategy. By leveraging triggers and fallback blocks (@placeholder, @loading, @error), you can create efficient, user-friendly experiences.

Adopting a “deferrable-first” mindset is both useful and important, as it allows us to deliver smoother user experiences, thanks in part to a lighter bundle.

Future articles will dive deeper into advanced @defer usage and its integration with other Angular features, so stay tuned!

Next steps

Prefetching

The @defer block also supports configuration for pre-fetching components. Prefetching is a process where we anticipate where the user might navigate after a specific action and begin loading resources that could be needed. In Angular, this can be achieved using the @defer block. The prefetch syntax works similarly to main @defer conditions; when and/or on can be used to declare different triggers.

@defer (on interaction; prefetch on idle) {
  <calendar-cmp />
} @placeholder {
  <img src="placeholder.png" />
}

Incremental Hydration

Hydration transforms a pre-rendered HTML page (produced by server-side rendering) into a fully interactive Angular application on the client side. With incremental hydration (here the complete RFC), you can determine when specific parts of your application need to become interactive.

This helps improve Core Web Vitals and provides a faster initial paint with better performance for the end-user.

<!-- Hydrate `when` example -->
@defer (hydrate when user() !== null){
  <some-cmp />
}

<!-- Hydrate `on` example -->
@defer (hydrate on interaction) {
  <some-cmp />
}

<!-- Defer plus Hydrate `on` example -->
@defer (on viewport; hydrate on interaction) {
  <some-cmp />
}

If you found this helpful, follow me here and on LinkedIn for more deep dives into Angular, web performance, and modern frontend development.

See you in the next one! 🤙🏻
— G.

Angular v19+ — computed vs linkedSignal signals 🔥🚀

Giorgio Galassi — Sun, 07 Dec 2025 09:53:01 +0000

Angular’s move toward a signal‑first ecosystem didn’t end with resource(), rxResource() or httpResource(). Those primitives made async flows cleaner, but they also exposed a deeper shift: the way we model state is changing. When you start structuring components around signals, two primitives quickly become the backbone of state organization: computed and linkedSignal.

At a glance they seem similar, but they solve very different problems. One focuses on pure derivation. The other acts as a controlled bridge between component state and something external. Understanding the difference is key to avoiding subtle bugs.

🔧 Signals in Angular — a quick recap

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

const count = signal(0);
const double = computed(() => count() * 2);

A signal stores writable state. A computed value is automatically recalculated whenever its dependencies change. You never set it manually, and it shouldn’t perform side effects. It’s a clean, predictable way to model values that depend entirely on other signals.

linkedSignal builds on this mechanism but shifts the focus: instead of deriving values, it synchronizes state with a source that lives outside the local signal graph.

📐 What computed actually does

A computed value is nothing more than a function of other signals. Its job is to keep a derived value always in sync with its inputs. You give it the signals it depends on, and Angular takes care of the rest.

For example, if you have two form fields and want a combined value and a quick validity check, a computed is exactly the right tool:

const firstName = signal('');
const lastName = signal('');

const fullName = computed(() => `${firstName()} ${lastName()}`.trim());
const isValid = computed(() => fullName().length > 0);

Here everything is deterministic: every value can be recalculated at any time from the source signals. You never push data back, and nothing lives outside the model. As long as your flow is one‑way, state that drives other state, computed is the cleanest and simplest option.

Where it falls short is when you need to mirror or update something that doesn’t originate inside the component. For that, it’s the wrong tool.

🔗 Why linkedSignal exists

Some state relationships require a value to reset reactively when its source changes while still remaining fully writable by the user. A computed can handle the reactive reset but cannot be written to. A plain signal can be written to, but it cannot reactively recalculate itself from a source. linkedSignal fills this exact gap.

Instead of wiring effects to manually reset values, a pattern that becomes noisy and risks unintended write loops, linkedSignal expresses the relationship declaratively: “derive from this source unless the user overrides it.”

Under the hood, linkedSignal listens to the source and recalculates its value whenever that source changes.

🔍 Note:

The computation function receives two arguments: the new source value and a previous object. previous.source holds the source value before the update, while previous.value contains the previous linkedSignal value, including user overrides. This allows you to implement simple resets, conditional resets, or more advanced transition rules based on both old and new state.

In parallel, the linked signal continues to expose the usual writable signal API (set, update), so user overrides remain straightforward.

🧪 Two practical examples

Pure derived state — computed

If a value can always be derived directly from its inputs and never needs manual intervention, a computed is the simplest fit. Filtering a list based on user input is a classic example where nothing external is involved and no override is necessary.

const items = signal<string[]>(['Angular', 'React', 'Vue']);
const filter = signal('a');

const filteredItems = computed(() =>
  items().filter(item => item.toLowerCase().includes(filter().toLowerCase()))
);

Reactive default with user override — linkedSignal

A more nuanced scenario is when the value depends on another piece of state but must still allow direct user edits. Consider an app with a theme selector and a user‑adjustable contrast slider.

The contrast should reset to the optimal default whenever the theme changes, but the user must be able to override that value afterward.

// The source signal
selectedTheme = signal<'light' | 'dark'>('light');

// Linked signal that recomputes when the theme changes
contrastLevel = linkedSignal<'light' | 'dark', number>({
  source: selectedTheme,
  computation: (newTheme) => {
    // Default contrast for dark theme
    if (newTheme === 'dark') return 80; 
    return 50; // Default contrast for light theme
  }
});

// User interaction and manual override
onContrastChanged(newContrast: number) {
  this.contrastLevel.set(newContrast);
}

In this setup, linkedSignal makes the relationship explicit and predictable. When the theme changes, contrastLevel recomputes based on the new theme. When the user adjusts the value, the override takes priority. This avoids side‑effect‑driven resets and keeps the logic clean and declarative.

🧠 How to reason about the two

The difference is straightforward once you think in terms of data direction.

A computed value is one‑way. Data flows from your signals into the computed output. There’s no feedback loop and no external synchronization.

A linkedSignal is two‑way. It sits between your component and another system. Reading it pulls in the current external value, while updating it pushes data out.

Whenever you need writable state that remains aligned with an external layer, linkedSignal is the right choice.

🎯 Picking the right tool

Use a computed when the value is entirely derived from other signals and doesn’t need to be written manually. It’s ideal for internal one‑direction flows within a component.

Use a linkedSignal when the component must expose a writable signal that represents an external state and must stay synchronized with it. This applies to inputs, stores, and any layer where the source of truth lives outside the component.

When you’re unsure, start with computed. If you later realize you’re wiring manual read‑and‑write glue between the component and external state, that’s usually the moment when switching to linkedSignal cleans everything up.

✨ Closing thoughts

computed and linkedSignal address distinct needs. The first keeps derived values predictable and local. The second gives you a structured way to mirror and update external state without abandoning the signal mindset.

Most of your application logic will rely on signal and computed. Reach for linkedSignal only when synchronization with something external is required.

If you found this helpful, follow me here and on LinkedIn for more deep dives into Angular, web performance, and modern frontend development.

See you in the next one! 🤙🏻
— G.

Angular v18+ — Introducing @let syntax: A New Way to Declare Variables and do Logic in Templates 🔥🚀

Giorgio Galassi — Fri, 21 Mar 2025 10:50:03 +0000

Here we are again with another article that dives into the new features of Angular v18.

In this article, you will explore, understand the pros and cons, and learn how to use the new @let template syntax. This powerful feature comes with great responsibility, as Uncle Ben would say.

🧠 What’s `@let` syntax?

As TypeScript developers, we are familiar with creating variables using var, const, and let. In this scenario, @let works similarly, but with one key difference: you can now create variables directly at the template level.

💡 How to use the `@let` Syntax in Angular?

Nothing is better to see some code in order to understand something.

Let’s see a basic example:

@let name = 'Giorgio';

<label>{{ name }}</label>

As you might expect, the content of the variable will be rendered correctly:

<label>Giorgio</label>

This opens up many new ways to handle our code, allowing us to move some logic directly within the template itself. With @let, you can declare variables and use them throughout your template.

🔍 Advanced usage of `@let`

Of course, the power of @let does not stop here. You can also perform conditional logic:

@let isAuth = authService.isAuth();
@let username = authService.getUsername();

@let message = isAuth ? 'Welcome, ' + username + '!' : 'Welcome Anonymus!'

<label>{{ message }}</label>

From this simple example, you can already see how much cleaner our code can be. Let’s take it a step further.

🧮 Working with Arrays

Sometimes you want to map or filter your arrays. Generally, you would write a function for that, save the output within the TypeScript file, and use it in the template. Now, you can do it as follows:

@let onlineUsers = users.filter(({ status }) => status === 'online');

@for(user of onlineUsers; track user.id) {
  <label>{{ user.name }} {{ user.surname }}</label>
}

🔄 Working with the Angular Async Pipe

If you’ve worked with Angular, you’ve likely used the async pipe. Here's how you can combine it with @let:

@let user = user$ | async;

<per>{{ user | json }}</pre>

@let userPosts = user.posts || [];

@for(post of userPosts; track post.id) {
  <label>{{ post.title }}</label>
  <p>{{ post.content }}</p>
} @empty {
  <label>No post to show!</label>
}

In this example, @let is used to handle asynchronous data and iterate over user posts. The code is cleaner and keeps the logic within the template, reducing the need for additional component code.

However, be careful when using @let in combination with the async pipe, as it may cause some performance issues.

To avoid this, declare a variable to handle the subscription and use that variable wherever needed, as shown in the example above.

This approach ensures a single subscription and avoids multiple re-evaluations, which can improve performance.

✅ Conclusions

The @let syntax in Angular v18 offers a powerful way to declare variables and handle logic directly in templates. It simplifies the code and enhances readability, making it easier to manage dynamic and conditional content. However, with great power comes great responsibility, so use it wisely to keep your templates clean and maintainable.

Thank you for staying with me, and I hope everything was clear. Feel free to explore more of my articles and follow me on LinkedIn!

See you in the next one!

Best, G.

Angular v19+ — Understanding the New httpResource() API 🔥🚀

Giorgio Galassi — Thu, 20 Mar 2025 10:50:11 +0000

Angular v19.2 is here, bringing yet another set of features designed to simplify our development experience.

This time, the spotlight is on the new httpResource() API, which joins the resource family, alongside resource() and rxResource().

We previously explored these APIs in another article that you can find below:

Giorgio Galassi

Mar 20 '25

Angular v19+ — Understanding the New resource() and rxResource() APIs 🔥🚀

#typescript #angular #resource #http

4 min read

❓How Does It Work?

Let’s first take a look at how the rxResource() API is typically used to perform a backend call:

import { rxResource } from "@angular/core/rxjs-interop";

rxUsers = rxResource<User[], string | undefined>({
  request: () => this.query(),
  loader: ({ request }) =>
    this.#http.get<{ users: User[] }>(`${API_URL}/search?q=${request}`)
    .pipe(
      distinctUntilChanged(),
      map(({ users }) => users),
      catchError(() => {
        throw Error('Unable to load!');
      })
    ),
});

In this example, we still rely on HttpClient, and the .get() method returns an Observable, which we process using RxJS operators like map() and catchError().

✅ Nothing is wrong with this approach, but what if we wanted a simpler API that integrates directly with HttpClient and eliminates the need to manually handle Observables?

🚀 Exploring `httpResource()`

Since httpResource() is built directly on top of HttpClient, we no longer need to manually handle API requests.

Instead, we can simply pass the API URL as a parameter:

import { httpResource } from "@angular/common/http";

httpUsers = httpResource<User[]>(API_URL);

With just this single line of code, httpResource() automatically manages the request logic, leveraging Angular's HttpClient behind the scenes.

✅ But what if we need more flexibility?
Real-world applications often require:

Setting default values to prevent UI issues.
Parsing API responses before assigning them to the Signal.

Let’s explore how httpResource() handles this next.

📌 Using `defaultValue` and `parse` for Safer Data Handling

By default, httpResource() expects valid data from the API. However, in real-world scenarios, we might need to:

✅ Ensure a default value when the API returns null or undefined.
✅ Validate and parse responses before assigning them to the signal.

Using Zod for schema validation, we can enforce type safety directly within httpResource():

import { httpResource } from "@angular/common/http";
import { z } from 'zod';

// Define a schema using Zod
const UserSchema = z.object({ name: z.string(), surname: z.string() });
const UserResultsSchema = z.array(UserSchema);

type User = z.infer(typeof UserSchema);

httpUsers = httpResource<User[]>(
  () => `${API_URL}/search?q=${this.query()}`,
  {
    defaultValue: [], // Ensures an empty array if no data is returned
    parse: (data) => UserResultsSchema.parse(data) // Validates and parses the API response
  }
);

✅ Why is this useful?

Prevents UI errors from unexpected null values.
Ensures type safety by validating API responses.
Eliminates extra validation logic in the component

🔍 Advanced Use Case

Passing just the API URL is often not enough. In our rxResource() example, we included a search query parameter tied to the query() signal. Let’s explore how to achieve the same behavior using the httpResource() API:

import { httpResource } from "@angular/common/http";

httpUsers = httpResource<User[]>(() => `${API_URL}/search?q=${this.query()}`);

By passing a reactive function to httpResource(), the API automatically listens for changes in the query signal.
Every time query() updates, a new request is triggered, ensuring that the latest data is always fetched.

⚠️ Important Considerations

Each new API request cancels the previous one, similar to how the switchMap operator works in RxJS.
This is the default behavior of httpResource().

Be cautious when using this API for updates (PUT, POST, DELETE requests).
A subsequent update could cancel a previous request before it completes, leading to potential data loss.

❌ Avoid using httpResource() for mutations
✔️ Use it for fetching data (GET requests) instead

⏳ Enabling API Calls Only When Needed

By default, httpResource() automatically executes the API call whenever the request function changes. However, in some cases, we don't want the API to trigger immediately—for example, when data fetching should only happen after a user action (e.g., clicking a button).

We can conditionally enable the request by returning undefined when it should not be executed:

import { httpResource } from "@angular/common/http";

httpUsers = httpResource<User[]>(() => {
  const enabled = this.isApiEnabled();
  return enabled ? `${API_URL}/search?q=${this.query()}` : undefined;
});

✅ Why is this useful?

Avoids unnecessary API calls when data isn’t required.
Helps control execution flow, ensuring the request happens only when a condition is met.
Ideal for scenarios like lazy loading, conditional search, or toggle-based requests.

⚡ What If I Want to Use Pipeable Operators?

Everything is working as expected, but there’s a key difference between rxResource() and httpResource().

Since httpResource() does not expose an observable, we can't apply RxJS operators like distinctUntilChanged() or debounceTime() directly.
This means we need an alternative approach to manage request optimizations.

There are two possible solutions:

Use rxResource() when you need to transform or process the response using RxJS operators.
Create a utility function that allows us to bridge the gap, applying RxJS operators to Signals before passing them to httpResource().

Let’s explore Approach #2 in detail.

🔄 From Signal to Observable and Back to Signal

Angular provides interoperability functions that help bridge the gap between Signals and Observables:

toObservable() → Converts a Signal into an Observable.
toSignal() → Converts an Observable back into a Signal.

By leveraging these utilities, we can apply RxJS operators like debounceTime() and distinctUntilChanged() while keeping httpResource() reactive.

🔗 Applying RxJS Operators to Signals

import { signal } from "@angular/core";
import { httpResource } from "@angular/common/http";
import { toObservable, toSignal } from "@angular/core/rxjs-interop";

import { debounceTime, distinctUntilChanged } from 'rxjs/operators';

inputQuery = signal<string>('');

inputQuery$ = toObservable(this.inputQuery).pipe(
  distinctUntilChanged(), 
  debounceTime(400)
);

query = toSignal(this.inputQuery$);

httpUsers = httpResource<User[]>(() => `${API_URL}/search?q=${this.query()}`);

Here, we use a Signal to manage the input event and trigger API requests while leveraging an Observable to handle the stream flow efficiently.

Note:
This example works as expected, but since we are delaying the event and not the actual API request, the isLoading state could not reflect the truth.

🛠 Simplifying with a Utility Function

To avoid writing this logic repeatedly, we can create a utility function that applies debouncing and distinct filtering to any Signal:

import { Signal } from "@angular/core";
import { toObservable, toSignal } from "@angular/core/rxjs-interop";
import { distinctUntilChanged, debounceTime } from "rxjs";

export function debounceDistinctSignal<T>(signal: Signal<T>, time: number) {
  const obs$ = toObservable(signal).pipe(
    distinctUntilChanged(),
    debounceTime(time)
  );

  return toSignal(obs$);
}

Now, we can simplify our original implementation like this:

import { httpResource } from "@angular/common/http";
import { debounceDistinctSignal } from 'signal-utils';

query = debounceDistinctSignal(this.inputQuery, 400);

httpUsers = httpResource<User[]>(() => `${API_URL}/search?q=${this.query()}`);

🎯 Try it in Action! 🚀

Want to see httpResource() in action? Check out this interactive StackBlitz demo, where you can:

✅ Experiment with httpResource() for API calls
✅ Test a search bar with debounce & distinctUntilChanged
✅ Compare side-by-side with rxResource() and resource()

stackblitz.com

📖 Summary & Next Steps

Here’s what we’ve learned in this article:

httpResource() simplifies API calls by integrating directly with HttpClient.
toObservable() and toSignal() provide interoperability between Signals and RxJS.
A custom utility function (debounceDistinctSignal()) helps clean up our code and makes this approach reusable.

Thank you for staying with me, and I hope everything was clear. Feel free to explore more of my articles and follow me on LinkedIn!

See you in the next one!

Best, G.

Angular v19+ — Understanding the New resource() and rxResource() APIs 🔥🚀

Giorgio Galassi — Thu, 20 Mar 2025 10:49:13 +0000

Angular 19 is here, and its renaissance continues, further embracing the power of signals.
This release introduces two new primitives that simplify handling asynchronous requests: resource() and rxResource(). These APIs enable a cleaner and more intuitive way to manage asynchronous data in Angular applications.

While resource() and rxResource() provide powerful tools for handling API calls reactively, Angular 19.2 introduces yet another step forward: httpResource(), a new API that integrates seamlessly with HttpClient, eliminating even more boilerplate.
If you're interested in taking reactive API calls to the next level, don't miss our deep dive into httpResource() and how it compares with the existing solutions.

Check out the new article on httpResource() 👇🏻

Giorgio Galassi

Mar 20 '25

Angular v19+ — Understanding the New httpResource() API 🔥🚀

#typescript #angular #httpresource #http

5 min read

Note: These APIs are still in experimental state!

Signals: A Quick Refresher

Signals represent a new paradigm for Angular application development. Paired with a Zoneless approach, they not only enhance application performance but also improve the Developer Experience (DX).

By using a signal in your view, you can precisely inform Angular which node in the component tree needs to be updated. This fine-grained reactivity results in faster updates and a more efficient rendering pipeline.

Here’s a quick example demonstrating how to create and manipulate a signal in Angular:

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

@Component({
  selector: "my-component",
  template: `
    <p>{{ counter() }}</p>

    <button (click)="add()">Add</button>
    <button (click)="remove()">Remove</button>
    <button (click)="reset()">Reset</button>
  `,
})
export default class MyComponent {
  counter = signal<number>(0);

  add() {
    this.counter.update((current) => current + 1);
  }

  remove() {
    this.counter.update((current) => current - 1);
  }

  reset() {
    this.counter.set(0);
  }
}

Which Problem Are They Solving?

In the early days of Angular signals, several new patterns emerged. One of these patterns tackled how to combine signals with the HttpClient to manage API responses. A common implementation might look like this:

import { Injectable, inject, signal } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { map } from 'rxjs';

import { API_URL, User } from './user';

@Injectable({ providedIn: 'root' })
export class ApiService {
  #http = inject(HttpClient);
  #response = signal<User[] | null>(null);

  get users() {
    return this.#response.asReadonly();
  }

  doApiCall(request: string = '') {
    this.#http
      .get<{ users: User[] }>(`${API_URL}/search?q=${request}`)
      .pipe(map(({ users }) => users))
      .subscribe((response) => this.#response.set(response));
  }
}

While functional, this approach feels clunky and verbose. It introduces unnecessary boilerplate and requires developers to manually manage loading and error states. Moreover, mixing signals with observables can lead to code that is harder to maintain and reason about, reducing clarity and increasing cognitive overhead.

resource(): Simplifying Asynchronous API Calls

The new resource primitive in Angular provides an elegant way to manage asynchronous API calls in a signal-based application. By leveraging resource, you can seamlessly integrate reactive API calls into your app with better state handling and cleaner code.

Here’s an example of how resource() can be used:

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

@Component({
  selector: "my-component",
  template: `
    <input (input)="search($event)" placeholder="Search user..."/>

    <br />
    <ul>
      @let error = users.error();
      @if (error) {
        <p>{{ error }}</p>
      }

      @if (users.isLoading()) {
        <p>Loading Users...</p>
      }

      @for (user of users.value(); track user.id) {
        <li>{{ user.firstName }} {{ user.lastName }}</li>
      } @empty {
        <p>No Users!</p>
      }
    </ul>
  `,
})
export default class MyComponent {
  query = signal<string>("");

  // The resource can be typed as follows:
  // resource<response type, request type>
  users = resource<User[], string>({
    request: () => this.query(),
    loader: async ({ request, abortSignal }) => {
      const response = await fetch(`${API_URL}/search?q=${request}`, {
        signal: abortSignal,
      });

      if (!response.ok) throw new Error("Unable to load users!");
      return (await response.json()).users;
    },
  });

  search(event: Event) {
     const { value } = event.target as HTMLInputElement;
     this.query.set(value);
  }
}

Diving Deeper into the resource() API

The resource() API introduces two essential components to handle asynchronous data:

request: A function that returns a value used for the loader computation. Every time query() changes, the loader function is re-triggered, behaving similarly to a computed signal.
loader: The function where the actual API call is performed. It must return a promise, and errors can be handled like any standard promise.

Built-In Properties of resource()

The resource primitive comes with several useful out-of-the-box properties, all of which are signals:

value(): Retrieves the current value of the resource's response.
isLoading(): Indicates whether the resource is currently loading.
error(): Contains the error, if any, encountered during the API call.

What About rxResource()?

While resource() uses a promise-based loader, rxResource() provides a similar abstraction but leverages Observable streams instead. This makes it a perfect fit for scenarios where your application is already heavily reliant on RxJS or where Observables are the preferred choice for handling asynchronous data.

To illustrate this, let’s look at an example of how rxResource() can be used to perform a backend call while applying RxJS operators like distinctUntilChanged and map:

rxUsers = rxResource<User[], string | undefined>({
  request: () => this.query(),
  loader: ({ request }) =>
    this.#http.get<{ users: User[] }>(`${API_URL}/search?q=${request}`).pipe(
      distinctUntilChanged(),
      map(({ users }) => users),
      catchError(() => {
        throw Error('Unable to load!');
      })
    ),
});

Practical Example and Hands-On Exploration

The power of resource() and rxResource() becomes evident when managing complex asynchronous workflows in your Angular application. By combining signals and these primitives, you can reduce boilerplate code while maintaining clarity and reactivity.

For example:

Dynamically update UI components based on isLoading() or error() states.
Create powerful search interfaces, as shown in the code above, that adapt in real-time as the user interacts.

To see these concepts in action, check out this interactive StackBlitz example:

stackblitz.com

In this demo, you’ll find:

A fully functional search bar integrated with the resource() API.
Examples of handling loading states, error handling, and real-time updates using signals.

Feel free to experiment by tweaking the code and observing how Angular’s reactivity makes the process seamless.

Thank you for staying with me, and I hope everything was clear. Feel free to explore more of my articles and follow me on LinkedIn!

See you in the next one!

Best, G.

DEV Community: Giorgio Galassi

validateHttp() Has No Async Machinery: A Trace From Signal Forms Down to fetch() 🔍🚀

🧩 The View From Outside

🔍 Layer 1: validateHttp() Is a Delegation

🧠 Layer 2: Three Behaviours, Zero New Mechanisms

⚙️ Layer 3: httpResource() Swaps the Loader

🔧 Layer 4: The Pipeline Everything Shares

🔌 Layer 5: Where the Trace Goes Dark

🌐 Layer 6: The Floor

✅ Closing Thoughts

Angular WebMCP — Your App is Now an AI Tool 🔥🚀

🧭 The Idea: Outside → In

🔧 Browser Support

🛠️ Building Your First WebMCP Tool

Step 1: The service

Step 2: Declaring the tool

Step 3: Registering in the app

🔍 What the Agent Actually Sees

⚛️ Signal Forms as Agent Tools

💡 Beyond the Happy Path

🔒 One Thing Worth Getting Right Early: Trust

⚠️ The Honest Caveat

linkedSignal() Writes Back: A Trace Through the Reactive Graph 🔍🚀

🧩 Before: Reading Was Clean, Writing Wasn't

🔧 After: A Custom set()

🧠 Wait, Doesn't This Loop?

🔍 Under the Hood: The Write Path

⚙️ Under the Hood: The Recompute Path

✅ Closing Thoughts

Angular v19+ — Understanding @defer: Blocks, Triggers, and Deferrable Views (Part 2) 🔥🚀

💧 Incremental Hydration

Why it matters

⚡ Event Replay

Why it matters

🧩 Combined Example

🧠 Behind the Scenes

🪄 Key Takeaways

Angular v18+ — Understanding @defer: Blocks, Triggers, and Deferrable Views (Part 1) 🔥🚀

What is Angular’s @defer Block?

Why use Angular’s deferrable views for optimized performance?

Exploring @defer Blocks: Syntax and Usage

How to Combine Multiple Triggers with @defer in Angular v18

Best Practices for Using @defer in Angular v18: Tips and Considerations

Nested @defer Blocks

Conclusion

Next steps

Prefetching

Incremental Hydration

Angular v19+ — computed vs linkedSignal signals 🔥🚀

🔧 Signals in Angular — a quick recap

📐 What computed actually does

🔗 Why linkedSignal exists

🧪 Two practical examples

Pure derived state — computed

Reactive default with user override — linkedSignal

🧠 How to reason about the two

🎯 Picking the right tool

✨ Closing thoughts

Angular v18+ — Introducing @let syntax: A New Way to Declare Variables and do Logic in Templates 🔥🚀

🧠 What’s @let syntax?

💡 How to use the @let Syntax in Angular?

🔍 Advanced usage of @let

🧮 Working with Arrays

🔄 Working with the Angular Async Pipe

✅ Conclusions

Angular v19+ — Understanding the New httpResource() API 🔥🚀

Angular v19+ — Understanding the New resource() and rxResource() APIs 🔥🚀

❓How Does It Work?

🚀 Exploring httpResource()

📌 Using defaultValue and parse for Safer Data Handling

🔍 Advanced Use Case

⚠️ Important Considerations

⏳ Enabling API Calls Only When Needed

⚡ What If I Want to Use Pipeable Operators?

🔄 From Signal to Observable and Back to Signal

🔗 Applying RxJS Operators to Signals

🛠 Simplifying with a Utility Function

🎯 Try it in Action! 🚀

📖 Summary & Next Steps

Angular v19+ — Understanding the New resource() and rxResource() APIs 🔥🚀

What is Angular’s `@defer` Block?

Exploring `@defer` Blocks: Syntax and Usage

How to Combine Multiple Triggers with `@defer` in Angular v18

Best Practices for Using `@defer` in Angular v18: Tips and Considerations

Nested `@defer` Blocks

🧠 What’s `@let` syntax?

💡 How to use the `@let` Syntax in Angular?

🔍 Advanced usage of `@let`

🚀 Exploring `httpResource()`

📌 Using `defaultValue` and `parse` for Safer Data Handling