DEV Community: Giorgio Galassi

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:

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

Giorgio Galassi ・ Mar 20

#typescript #angular #resource #http

❓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() 👇🏻

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

Giorgio Galassi ・ Mar 20

#typescript #angular #httpresource #http

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

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 🔥🚀

Giorgio Galassi ・ Mar 20

❓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 🔥🚀

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

Giorgio Galassi ・ Mar 20

Signals: A Quick Refresher

Which Problem Are They Solving?

resource(): Simplifying Asynchronous API Calls

Diving Deeper into the resource() API

Built-In Properties of resource()

What About rxResource()?

Practical Example and Hands-On Exploration

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