DEV Community: Nicolas Frizzarin

INP and Partytown: give the main thread back to your users

Nicolas Frizzarin — Wed, 23 Sep 2026 08:18:37 +0000

Introduction

You click on a button. Nothing happens.
You click again. Still nothing.
Then the menu opens... and closes right away.

We have all lived this. It's a responsiveness problem. And since March 12, 2024, Google measures it with a Core Web Vital: INP.

Very often, the problem is not your code. It's the code you didn't write: analytics, tag managers, pixels, A/B testing tools...

This article explains:

What INP really measures
Why third-party scripts hurt it so much
How Partytown works
How to use it in React and Angular, with real examples
When you should not use it

INP in a few words

INP means Interaction to Next Paint.

It measures the time between a user interaction and the next frame painted by the browser. In other words: how long does the user wait before seeing that something happened?

Only three types of interaction count:

a click with a mouse
a tap on a touchscreen
a key press

Scroll, hover and zoom are not measured.

INP looks at all the interactions during the visit, and reports the worst one. If there are a lot of interactions, the browser ignores the highest one for every 50 interactions. That way, one random hiccup does not ruin your score.

The thresholds, at the 75th percentile of your real users:

INP	Result
≤ 200 ms	🟢 Good
200 ms to 500 ms	🟠 Needs improvement
> 500 ms	🔴 Poor

Just a reminder: INP replaced FID (First Input Delay). FID only measured the waiting time of the first interaction. INP measures every interaction, from start to paint. Much stricter.

What's inside an interaction?

An interaction has three phases:

 user clicks                                              next frame
     │                                                        │
     ▼                                                        ▼
     ├────────────────┬──────────────────────┬────────────────┤
     │  Input delay   │ Processing duration  │ Presentation   │
     │                │                      │ delay          │
     └────────────────┴──────────────────────┴────────────────┘
     │◄───────────────── interaction latency ───────────────►│

Input delay: the time before your event handlers start. The browser is busy with something else.
Processing duration: the time to run all your event handlers.
Presentation delay: the time to compute style, layout and paint the next frame.

Keep the first one in mind. This is where third-party scripts hurt the most.

The main thread: a one lane road

The browser has one main thread. It does everything:

runs JavaScript
handles events
computes style and layout
paints

And it does one thing at a time.

A task longer than 50 ms is a long task. During a long task, the browser can't respond to the user.

Now imagine your page with Google Tag Manager, a marketing pixel and an analytics script. The user clicks at the wrong moment:

Main thread, without Partytown

──[ your app ]──[ tag manager 180ms ]──[ pixel 120ms ]──[ click handler ]──[ paint ]──
                      ▲
                user clicks here
                      │◄──────── input delay ────────►│

Your click handler is fast. Your code is clean. And your INP is still bad.

This is the key point: you can write perfect code and still fail INP, because you share the road with scripts you don't control.

Partytown: move the party somewhere else

Partytown is a small library, lazy-loaded, maintained by the QwikDev team. Its goal is simple: move third-party scripts from the main thread into a web worker.

The philosophy: the main thread is for your code. Everything that is not in the critical path can go elsewhere.

flowchart LR
  subgraph Before["Without Partytown"]
    MT1["Main thread<br/>your app + GTM + pixel + analytics"]
  end
  subgraph After["With Partytown"]
    MT2["Main thread<br/>your app"]
    WW["Web worker<br/>GTM + pixel + analytics"]
    WW -. "DOM calls through a proxy" .-> MT2
  end

And the same timeline as before:

Main thread, with Partytown

──[ your app ]──[ click handler ]──[ paint ]──
                ▲
          user clicks here: almost no input delay

Web worker

──[ tag manager 180ms ]──[ pixel 120ms ]──   ← nobody waits for this

The long tasks still exist. They just don't block the user anymore.

⚠️ Partytown is still in beta. It's not guaranteed to work for every script. Test before you ship.

How does it work?

Here comes the tricky part.

A web worker has no DOM. No document, no real window. But third-party scripts expect them. They call document.cookie, getBoundingClientRect(), addEventListener...

On top of that, communication between a worker and the main thread is asynchronous. Third-party scripts are written in a synchronous way. No await, no callback.

So Partytown does two things:

In the worker, it creates JavaScript Proxies that look like window and document.
Each call to these proxies is sent to the main thread through a synchronous channel, and the worker waits for the answer.

From the script's point of view, nothing changed. This code works as is inside the worker:

const rect = element.getBoundingClientRect(); // blocking call, like on the main thread
console.log(rect.x, rect.y);

There are two ways to get this synchronous channel.

Option 1: Service Worker (the fallback)

The worker sends a synchronous XHR. A service worker intercepts it, asks the main thread, and answers.

sequenceDiagram
  participant W as Web worker (3rd-party script)
  participant SW as Service worker
  participant M as Main thread (DOM)
  W->>SW: sync XHR "getBoundingClientRect()"
  SW->>M: postMessage
  M-->>SW: result
  SW-->>W: response { x, y }
  Note over W: for the script, it was a normal blocking call

That's why you'll see a lot of proxytown requests in the network tab. They are not real HTTP requests. They're handled locally. You can hide them with the -url:proxytown filter in Chrome DevTools.

Option 2: Atomics (the fast one)

With Atomics and SharedArrayBuffer, the worker writes the request, calls Atomics.wait(), and reads the result when the main thread answers. No service worker needed.

It's about 10x faster to transfer data between threads.

But there's a condition: the page must be cross-origin isolated. You need these response headers on your document:

Cross-Origin-Embedder-Policy: credentialless
Cross-Origin-Opener-Policy: same-origin

Two things to know:

Safari doesn't support credentialless. So Safari falls back to the service worker.
You can use require-corp instead, which works in Safari. But it blocks every cross-origin image, script or video that doesn't have a crossorigin attribute. Be careful with your CDN.

If the headers are not there, no problem: Partytown falls back to the service worker automatically.

The two rules to remember

Before the code, two rules. They are the same for every framework.

Rule 1: type="text/partytown"

The browser doesn't know this type, so it doesn't run the script. Partytown finds it with a selector and runs it in the worker.

- <script src="https://third-party.com/script.js"></script>
+ <script type="text/partytown" src="https://third-party.com/script.js"></script>

Partytown is opt-in. Only the scripts with this type move. All the others stay where they are. You choose.

Rule 2: forward

Your own code still calls dataLayer.push(...) on the main thread. For example, when a user adds a product to the cart.

But GTM now lives in the worker. So Partytown needs to know which window functions to patch and send to the worker. That's the role of forward. It even queues the calls made before Partytown is ready.

flowchart LR
  A["Your code<br/>dataLayer.push(...)"] -->|"patched by forward"| B["Partytown<br/>(main thread side)"]
  B -->|"serialized message"| C["GTM<br/>in the web worker"]
  C -->|"network"| D["Google servers"]

By default, a forwarded call only runs in the worker. If you need the original function to also run on the main thread, use preserveBehavior:

partytown = {
  forward: [
    ['dataLayer.push', { preserveBehavior: true }], // runs on both sides
    'fbq'                                           // worker only (default)
  ]
};

Now let's have some code.

Angular

Our goal: run Google Tag Manager in the worker, and track page views and a click from our Angular app.

Step 1: install

npm install @qwik.dev/partytown

Step 2: serve the Partytown files

The worker and the service worker are real files. They must be served by your app. In angular.json, add them to the assets:

"build": {
  "options": {
    "assets": [
      {
        "glob": "**/*",
        "input": "node_modules/@qwik.dev/partytown/lib",
        "output": "/~partytown"
      }
    ]
  }
}

After a build, you should see a ~partytown/ folder in your output, with partytown.js, partytown-sw.js, partytown-atomics.js...

Step 3: `index.html`

Third-party scripts must be there early, before Angular starts. So we put everything in src/index.html:

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>My Shop</title>
  <base href="/">

  <!-- 1. Partytown configuration: BEFORE partytown.js -->
  <script>
    partytown = {
      forward: ['dataLayer.push']
    };
  </script>

  <!-- 2. Partytown itself: no async, no defer -->
  <script src="/~partytown/partytown.js"></script>

  <!-- 3. Google Tag Manager, moved to the worker -->
  <script type="text/partytown">
    (function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
    new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
    j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
    'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
    })(window,document,'script','dataLayer','GTM-XXXXXXX');
  </script>
</head>
<body>
  <app-root></app-root>
</body>
</html>

💡 While you set things up, use /~partytown/debug/partytown.js and add debug: true to the config. You get logs in the console. Don't ship the debug build to production.

Step 4: an analytics service

Now, our Angular code must talk to GTM. We only push to dataLayer. Thanks to forward, Partytown sends it to the worker.

// analytics.service.ts
import { DOCUMENT, Injectable, inject } from '@angular/core';
import { NavigationEnd, Router } from '@angular/router';
import { takeUntilDestroyed } from '@angular/core/rxjs-interop';
import { filter } from 'rxjs';

declare global {
  interface Window {
    dataLayer: unknown[];
  }
}

@Injectable({ providedIn: 'root' })
export class AnalyticsService {
  private readonly router = inject(Router);
  private readonly window = inject(DOCUMENT).defaultView; // null on the server (SSR)

  constructor() {
    // An SPA has no real page load after the first one.
    // So we send a page view on each navigation.
    this.router.events
      .pipe(
        filter((event): event is NavigationEnd => event instanceof NavigationEnd),
        takeUntilDestroyed()
      )
      .subscribe((event) => this.track('page_view', { page_path: event.urlAfterRedirects }));
  }

  track(event: string, params: Record<string, unknown> = {}): void {
    if (!this.window) return; // nothing to do on the server

    this.window.dataLayer = this.window.dataLayer || [];
    // This call is patched by Partytown: it's serialized and sent to the worker.
    // GTM does its heavy work there, not on the main thread.
    this.window.dataLayer.push({ event, ...params });
  }
}

Start it with the application:

// app.config.ts
import { ApplicationConfig, inject, provideAppInitializer } from '@angular/core';
import { provideRouter } from '@angular/router';
import { routes } from './app.routes';
import { AnalyticsService } from './analytics.service';

export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(routes),
    provideAppInitializer(() => {
      inject(AnalyticsService); // create the service, so it listens to the router
    }),
  ],
};

Step 5: track a click

// product-card.ts
import { Component, inject, input } from '@angular/core';
import { AnalyticsService } from './analytics.service';
import { CartStore } from './cart.store';

interface Product {
  id: string;
  name: string;
  price: number;
}

@Component({
  selector: 'app-product-card',
  template: `
    <h3>{{ product().name }}</h3>
    <button (click)="addToCart()">Add to cart</button>
  `,
})
export class ProductCard {
  private readonly analytics = inject(AnalyticsService);
  private readonly cart = inject(CartStore);

  readonly product = input.required<Product>();

  addToCart(): void {
    // 1. What the user wants to see: update the UI first
    this.cart.add(this.product());

    // 2. Tracking: cheap on the main thread, GTM works in the worker
    this.analytics.track('add_to_cart', {
      item_id: this.product().id,
      value: this.product().price,
    });
  }
}

Look at the click handler. Without Partytown, dataLayer.push wakes up GTM on the main thread, in the same frame as your click. With Partytown, the push is sent to the worker, and GTM runs its tags there. Your handler stays small. Your processing duration stays small.

React

Same goal, same app: GTM in the worker, page views and a click.

There are two ways to do it in React:

Option A: index.html, for a client-side app (Vite, Create React App...). The simplest.
Option B: the <Partytown /> component, for apps rendered on the server (React Router framework mode, Remix, Gatsby...).

Step 1: install and copy the files

npm install @qwik.dev/partytown

Partytown comes with a small CLI to copy its files into your public folder. Run it before dev and build:

"scripts": {
  "partytown": "partytown copylib public/~partytown",
  "dev": "npm run partytown && vite",
  "build": "npm run partytown && vite build"
}

Add public/~partytown to your .gitignore. It's generated.

Option A: client-side app (Vite)

Everything goes in index.html, like in Angular:

<!doctype html>
<html lang="en">
<head>
  <meta charset="UTF-8" />
  <title>My Shop</title>

  <script>
    partytown = {
      forward: ['dataLayer.push']
    };
  </script>
  <script src="/~partytown/partytown.js"></script>

  <script type="text/partytown">
    (function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
    new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
    j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
    'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
    })(window,document,'script','dataLayer','GTM-XXXXXXX');
  </script>
</head>
<body>
  <div id="root"></div>
  <script type="module" src="/src/main.tsx"></script>
</body>
</html>

Why not in a component? Because a client-side app renders late. The third-party scripts would wait for React to boot. In index.html, they're found as soon as Partytown starts.

Option B: server-rendered app (the `<Partytown />` component)

The package ships a React component: @qwik.dev/partytown/react. It's a thin wrapper around the Partytown snippet. The config becomes JSX props. And the snippet is inlined in the HTML, so there's no extra request for partytown.js.

Example with a root layout (React Router framework mode / Remix style):

// app/root.tsx
import { Partytown } from '@qwik.dev/partytown/react';
import { Links, Meta, Outlet, Scripts } from 'react-router';

const GTM_ID = 'GTM-XXXXXXX';

const gtmSnippet = `
(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer','${GTM_ID}');
`;

export default function App() {
  return (
    <html lang="en">
      <head>
        <Meta />
        <Links />

        {/* 1. Partytown: config as props */}
        <Partytown forward={['dataLayer.push']} />

        {/* 2. GTM in the worker */}
        <script
          type="text/partytown"
          dangerouslySetInnerHTML={{ __html: gtmSnippet }}
        />
      </head>
      <body>
        <Outlet />
        <Scripts />
      </body>
    </html>
  );
}

💡 Add debug={true} on <Partytown /> while you set things up.

Scripts added later

If a text/partytown script is added to the page after Partytown started (lazy loading, route change...), recent versions of Partytown (0.14.3 and later) find it automatically. On older versions, you have to tell Partytown:

const script = document.createElement('script');
script.type = 'text/partytown'; // set the type BEFORE adding it to the DOM
script.src = 'https://third-party.com/widget.js';
document.head.appendChild(script);

window.dispatchEvent(new CustomEvent('ptupdate')); // only needed before 0.14.3

Track page views and clicks

A small module, no library needed:

// analytics.ts
declare global {
  interface Window {
    dataLayer: unknown[];
  }
}

export function track(event: string, params: Record<string, unknown> = {}): void {
  if (typeof window === 'undefined') return; // nothing to do on the server

  window.dataLayer = window.dataLayer || [];
  // Patched by Partytown: serialized and sent to the worker
  window.dataLayer.push({ event, ...params });
}

A hook for page views:

// usePageView.ts
import { useEffect } from 'react';
import { useLocation } from 'react-router';
import { track } from './analytics';

export function usePageView(): void {
  const location = useLocation();

  useEffect(() => {
    track('page_view', { page_path: location.pathname + location.search });
  }, [location.pathname, location.search]);
}

Call it once, in your layout:

// Layout.tsx
import { Outlet } from 'react-router';
import { usePageView } from './usePageView';

export function Layout() {
  usePageView();
  return <Outlet />;
}

And the click:

// ProductCard.tsx
import { track } from './analytics';
import { useCart } from './useCart';

interface Product {
  id: string;
  name: string;
  price: number;
}

export function ProductCard({ product }: { product: Product }) {
  const { add } = useCart();

  function handleAddToCart() {
    // 1. UI first: this is what the user is waiting for
    add(product);

    // 2. Tracking: GTM does the heavy work in the worker
    track('add_to_cart', { item_id: product.id, value: product.price });
  }

  return (
    <article>
      <h3>{product.name}</h3>
      <button onClick={handleAddToCart}>Add to cart</button>
    </article>
  );
}

Using Next.js? Partytown has its own Next.js integration page. Check it, the setup is a bit different.

Check that it works

Don't trust, verify. Three quick checks in Chrome DevTools:

Console: with the debug build, Partytown logs what runs in the worker.
Sources panel: look at the threads. GTM should run in the Partytown web worker, not in the main one.
Performance panel: record a page load and a few clicks. The long tasks from googletagmanager.com should be gone from the main thread track.

Then check in GTM Preview mode that your page_view and add_to_cart events arrive. If nothing arrives, check your forward config first. It's the most common mistake.

Where INP really wins

Let's go back to our three phases.

               Input delay     Processing      Presentation
               ───────────     ──────────      ────────────
Partytown:     big impact      some impact     small impact

Input delay: the big win. Third-party long tasks no longer block the main thread, so the click is handled right away.
Processing duration: the work done by third-party scripts when you push an event (like in addToCart) happens in the worker, not in your handler's frame.
Presentation delay: Partytown batches DOM reads and writes into group updates. Less layout thrashing from third-party code.

Trade-offs: no magic here

Partytown is a great tool. It's not a silver bullet. Here is what you need to know before using it.

preventDefault() has no effect. When the worker receives the event, it's already too late. A script that needs to block a link or a form submit won't work.
DOM operations are throttled. Each call crosses threads. That's fine for analytics, not for scripts that build UI.
UI-heavy scripts are a bad fit. A chat widget, a cookie banner with a dialog, anything that injects a lot of DOM nodes: keep them on the main thread.
CORS. Some third-party scripts don't send the right CORS headers. You'll need to proxy them.
Cross-origin iframes created from a Partytown script can't persist cookies or storage.
Bad scripts stay bad. A script that reads the whole document every X milliseconds with setInterval will overload Partytown.

A quick rule:

Good fit ✅	Bad fit ❌
Google Tag Manager	Chat widgets
Google Analytics 4	Cookie consent dialogs
Facebook Pixel	Scripts that call `preventDefault()`
Mixpanel, Segment, Amplitude	Scripts that inject a lot of DOM

Measure, don't guess

Never move a script "because it should be better". Measure before, measure after.

INP is a field metric. Your real users on real devices are the source of truth. Use the web-vitals library with the attribution build to see which phase is slow. It works the same in React and Angular:

import { onINP } from 'web-vitals/attribution';

onINP(({ value, attribution }) => {
  console.log('INP:', value);
  console.log('Element:', attribution.interactionTarget);
  console.log('Input delay:', attribution.inputDelay);
  console.log('Processing:', attribution.processingDuration);
  console.log('Presentation:', attribution.presentationDelay);
  // send it to your analytics
});

Put it in main.ts (Angular) or main.tsx (React).

Here's how to read the result:

High input delay? Look at what runs before the click. Third-party scripts are the usual suspects. This is where Partytown shines.
High processing duration? It's probably your handler. Partytown won't help.
High presentation delay? Look at your DOM size and your layout.

In the lab, INP depends on what you click. Two tips:

Interact with the page while it loads. That's when the main thread is the busiest.
Use Total Blocking Time (TBT) as a proxy. It's not INP, but it tells you if the main thread is crowded.

Partytown won't fix your own code

If your click handler takes 400 ms, moving GTM to a worker changes nothing.

For your own code, the classic tools still apply:

Break long tasks into smaller ones.
Yield to the main thread (setTimeout, or scheduler.yield() where it's supported).
Show visual feedback first, do the heavy work after.
Move heavy computation to your own web worker.

Partytown handles the code you don't own. You handle the code you own.

Conclusion

INP measures what users feel: "I clicked, did something happen?"

Third-party scripts are often the hidden reason for a bad INP. They take the main thread, and your users wait.

Partytown moves them into a web worker, and keeps them working thanks to a clever synchronous bridge (Atomics or a service worker).

In Angular and React, the setup is small:

serve the Partytown files
add the config and type="text/partytown"
forward the functions your code calls
keep your tracking code as simple as a dataLayer.push

It's not magic. It's in beta, it has trade-offs, and it's not made for UI scripts. But for analytics, tag managers and pixels, it can give the main thread back to the only code that should be there: yours.

Measure first. Move the right scripts. Measure again. 🎉

Route Resources in Angular: what the Router actually does with your Signal under the hood

Nicolas Frizzarin — Tue, 15 Sep 2026 06:24:17 +0000

Introduction

Route resolvers have been around in Angular for years, and they do their job, but they come with a price you pay on every navigation: they run one after the other, parent to child, and they can't be refreshed without triggering a full navigation. Angular now ships an alternative built directly on Signals, exposed through the router as a resources route property. The official guide covers the "how to use it" part pretty well: https://next.angular.dev/guide/routing/data-fetching-with-resources.

What the guide doesn't show you is what happens between the moment you write resource({...}) in your route config and the moment your component receives a value. There's an entire file dedicated to that, router_resource.ts.
This article is what I found in there (it's a depth technical article ): how blocking works, why your UI doesn't flash a loading skeleton when you navigate between two similar pages, and where a navigation cancellation can leave you stuck if you don't understand the reload guard.

I'll assume you already know what a resource() is (a value(), an isLoading(), an error(), a status(), and a reload(), all as signals). If not, go read the Resource API guide first, this article builds on top of it.

Turning it on

Route resources are gated behind a feature you have to opt into, withRouterResources():

import { bootstrapApplication } from '@angular/platform-browser';
import { provideRouter, withComponentInputBinding, withRouterResources } from '@angular/router';
import { routes } from './app.routes';
import { App } from './app';

bootstrapApplication(App, {
  providers: [
    provideRouter(routes, withComponentInputBinding(), withRouterResources()),
  ],
});

Notice withComponentInputBinding() next to it. It's not mandatory to make resources work, but without it you'll have to reach into ActivatedRoute.resources manually instead of getting your data as a plain component input(). In practice you'll almost always want both together.

Defining resources on a route

A route now accepts a resources property, a function returning a map of Resource instances:

import { inject } from '@angular/core';
import { resource } from '@angular/core';
import { Routes } from '@angular/router';
import { ProductService } from './product.service';

export const routes: Routes = [
  {
    path: 'products/:sku',
    component: ProductPage,
    resources: (ctx) => {
      const productService = inject(ProductService);
      return {
        product: resource({
          params: () => ctx.params()['sku'],
          loader: ({ params: sku }) => productService.getBySku(sku),
        }),
      };
    },
  },
];

ctx here is a ResourceContext, giving you params, queryParams, data, and a static snapshot, all as signals. The resources function itself runs in an injection context, which is why inject(ProductService) works directly at the top, without a factory wrapper.

One detail that will bite you if you skip it: pass the primitive you actually need to params, not the whole object. params: () => ctx.params() looks harmless, but the router creates a fresh params object on every navigation, so the resource sees a new reference every time and reloads even when sku didn't change. params: () => ctx.params()['sku'] fixes that, because now the resource only reacts to the primitive value.

resources can also be async, if you need a dynamic import before wiring things up:

resources: async (ctx) => {
  const { fetchProductBySku } = await import('./product-api');
  return {
    product: resource({
      params: () => ctx.params()['sku'],
      loader: ({ params: sku }) => fetchProductBySku(sku),
    }),
  };
},

Any Resource implementation is accepted, not just resource(). If your team is still RxJS-heavy, rxResource() works the same way, swapping loader for stream:

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

resources: (ctx) => ({
  product: rxResource({
    params: () => ctx.params()['sku'],
    stream: ({ params: sku }) => productService.getBySku$(sku),
  }),
}),

Blocking vs non-blocking, and what actually gets bound to your input

By default every resource is blocking: the router waits for it before activating the route. That has a nice consequence for your component, the input type is the resolved value T, not Resource<T>, because your component never sees a loading or error state, the router already handled that for you.

If you don't want to block navigation, wrap the resource with nonBlocking():

import { Resource, resource } from '@angular/core';
import { Routes, nonBlocking } from '@angular/router';

export const routes: Routes = [
  {
    path: 'products/:sku',
    component: ProductPage,
    resources: (ctx) => ({
      product: nonBlocking(
        resource({
          params: () => ctx.params()['sku'],
          loader: ({ params: sku }) => productService.getBySku(sku),
        }),
      ),
      reviews: resource({
        params: () => ctx.params()['sku'],
        loader: ({ params: sku }) => reviewsService.getForProduct(sku),
      }),
    }),
  },
];

Here product won't block navigation, reviews will. Your component now has to handle both shapes at once:

@Component({
  template: `
    @if (product().isLoading()) {
      <p>Loading product…</p>
    } @else if (product().hasValue()) {
      <h1>{{ product().value().name }}</h1>
    }
    <app-reviews [reviews]="reviews" />
  `,
})
export class ProductPage {
  product = input.required<Resource<Product>>();
  reviews = input.required<Review[]>();
}

nonBlocking() itself is trivial, it just tags the resource with an internal symbol so the router knows to keep the wrapped Resource<T> object as-is instead of unwrapping it:

export function nonBlocking<T, R extends Resource<T>>(res: R): R {
  (res as unknown as InternalRouterResource<T>)[BLOCKING_SYMBOL] = false;
  return res;
}

The actual unwrapping for blocking resources happens in createResourceOutletBindingEffects, in the same file. It uses reflectComponentType to read the component's declared inputs, then for every input name that matches a key in route.resources and whose BLOCKING_SYMBOL isn't explicitly false, it sets up an effect() that calls componentRef.setInput(templateName, resource.value()):

for (const {templateName} of mirror.inputs) {
  const resource = route.resources?.[templateName];
  if (!resource || !(resource as InternalRouterResource)[BLOCKING_SYMBOL]) {
    continue;
  }
  const effectRef = effect(() => {
    componentRef.setInput(templateName, resource.value());
  }, {injector: componentRef.injector});
  createdEffects.push(effectRef);
  handledKeys.push(templateName);
}

Two things worth calling out here. First, the matching is done by input name against the resource map key, so product: resource({...}) only reaches an @Input() (or input()) literally named product.

Rename one without the other and the binding silently stops working, there's no compile-time link between the two.

Second, handledKeys is returned to the caller so that the router's standard data-binding subscription (RoutedComponentInputBinder) skips those keys. Non-blocking resources are never added to handledKeys, they go through that standard data stream instead, bound as the full Resource object.

What `routerResource()` actually wraps

Every resource you hand to the resources map gets passed through routerResource() internally before the router uses it. This is the function doing the heavy lifting:

export function routerResource<T>(source: Resource<T>): Resource<T> & {reload(): boolean} {
  const injector = inject(Injector);
  const router = injector.get(Router);
  const {snapshot: snapshotSignal, frozenSnapshot} = createTransactionalSnapshot(source, router, injector);
  const res = resourceFromSnapshots(snapshotSignal) as unknown as InternalRouterResource<T>;
  res[SOURCE_RESOURCE_SYMBOL] = source;
  res[BLOCKING_SYMBOL] = (source as unknown as InternalRouterResource<T>)[BLOCKING_SYMBOL] !== false;
  // ...reload wiring omitted here, see below
  return res;
}

It doesn't touch your loader, your params function, or your original resource at all. It reads your resource's snapshot() signal (a ResourceSnapshot, the internal shape carrying status/value/error together) through createTransactionalSnapshot, and rebuilds a brand-new Resource from that snapshot stream using resourceFromSnapshots. Your original resource is kept around under SOURCE_RESOURCE_SYMBOL, purely so reload() can delegate to it later. Everything the router hands to your component is this wrapper, not your original resource instance.

The frozen snapshot: why navigating doesn't flash a loading spinner

This is the part I found genuinely clever. When you navigate from /products/1 to /products/2, both routes resolve to the same component and the same product resource key, just with a different sku param. Naively, that resource would immediately flip to isLoading() the moment the param changes, and your component would render a loading skeleton for a split second before the new product shows up. The router avoids that by freezing the resource's snapshot for the duration of the navigation.

createTransactionalSnapshot subscribes to router.events and reacts to five event types:

const sub = router.events.subscribe((e) => {
  if (e instanceof NavigationStart) {
    isRollbackRecoveryPending.set(false);
    if (frozenSnapshot() === null) {
      frozenSnapshot.set(source.snapshot());
    }
  } else if (e instanceof NavigationEnd) {
    frozenSnapshot.set(null);
    isRollbackRecoveryPending.set(false);
  } else if (e instanceof NavigationSkipped) {
    if (frozenSnapshot() !== null) {
      isRollbackRecoveryPending.set(true);
    }
  } else if (e instanceof NavigationCancel || e instanceof NavigationError) {
    const isRollback =
      e instanceof NavigationError ||
      (e instanceof NavigationCancel &&
        e.code !== NavigationCancellationCode.SupersededByNewNavigation &&
        e.code !== NavigationCancellationCode.Redirect);
    if (!isRollback) return;
    isRollbackRecoveryPending.set(true);
  }
});

And the exposed snapshot signal is simply:

snapshot: computed(() => frozenSnapshot() ?? source.snapshot()),

So the flow for a plain, successful navigation is: NavigationStart fires, the router grabs whatever the source resource's snapshot currently is (the old product, already resolved) and locks it in frozenSnapshot. From that point on, even though the underlying resource has already started loading the new sku behind the scenes, your component keeps rendering the frozen, old value — no isLoading flicker, no jump to an empty state. When NavigationEnd fires, the freeze is lifted, frozenSnapshot goes back to null, and the computed falls through to source.snapshot(), which by then holds the new product.

There's a subtlety in that if (frozenSnapshot() === null) guard on NavigationStart. If a second navigation starts while the first hasn't finished (you click fast between two product cards), the router won't re-freeze on top of an existing freeze, it keeps the original snapshot from before the first navigation began. That's intentional, it prevents freezing an intermediate, already-stale value.

Rollback recovery: the part almost nobody thinks about

Here's a scenario the guide only mentions briefly but the source code handles explicitly. Say a canActivate guard rejects a navigation to /products/2. The router cancels it and rolls the URL and route params back to /products/1. That rollback is itself a change in the params signal your resource depends on, from 2 back to 1, so your resource, doing exactly what it's supposed to, fires a new load for sku: 1 — data it already had, and had already shown a second ago.

Without extra handling, that would mean: user clicks, sees the current product freeze for a moment (NavigationStart), sees the guard reject it, then sees a loading flash for the product they were already looking at. The code guards against exactly that with isRollbackRecoveryPending:

} else if (e instanceof NavigationCancel || e instanceof NavigationError) {
  const isRollback =
    e instanceof NavigationError ||
    (e instanceof NavigationCancel &&
      e.code !== NavigationCancellationCode.SupersededByNewNavigation &&
      e.code !== NavigationCancellationCode.Redirect);
  if (!isRollback) return;
  isRollbackRecoveryPending.set(true);
}

Cancellations caused by a newer navigation superseding this one, or by an internal redirect, are not treated as a rollback (the frozen snapshot gets released normally through the navigation that superseded it). Everything else, guard rejections, NavigationError, is treated as a rollback, and the frozen snapshot is kept alive until the resource has actually settled again:

effect(() => {
  if (isRollbackRecoveryPending() && !source.isLoading()) {
    isRollbackRecoveryPending.set(false);
    frozenSnapshot.set(null);
  }
}, {injector});

The freeze only lifts once source.isLoading() is false again, which in the rollback case happens once the resource has re-fetched (or, if it's cached, re-resolved instantly) the old param value. From the user's perspective, nothing happened, the product they were looking at stayed exactly as it was, even though under the hood a full reload was silently triggered and absorbed.

Why `reload()` sometimes just returns `false`

Route resources expose .reload(), but it's not a direct passthrough to your original resource's .reload(). It's guarded:

res.reload = function (): boolean {
  if (frozenSnapshot() !== null) {
    return false;
  }
  return (source as any).reload();
};

If you call .reload() while a navigation is pending, or while the router is in the middle of a rollback recovery, the call is rejected and returns false, your original resource's reload() is never invoked. The reasoning tracks with everything above: during those windows the router is already managing the resource's lifecycle for you, and a manual reload sneaking in would fight with that transition tracking, possibly unfreezing something the router is deliberately keeping frozen. If your source resource doesn't implement reload at all (a custom Resource that only has loader, say), res.reload is just () => false unconditionally.

This is worth checking for in your own code. If you wire a refresh button to userResource?.reload() and nothing happens, the boolean return value is telling you exactly why, it's just easy to ignore a boolean you don't check.

@Component({
  template: `<button (click)="refresh()">Refresh</button>`,
})
export class ProductPage {
  private productResource = inject(ActivatedRoute).resources?.['product'];

  refresh() {
    const didReload = this.productResource?.reload();
    if (!didReload) {
      console.warn('Reload skipped, a navigation transition is in progress.');
    }
  }
}

Redirecting from inside a loader

Blocking resources can redirect before the route ever activates, by throwing a RedirectCommand:

import { inject, resource } from '@angular/core';
import { RedirectCommand, Router } from '@angular/router';

resources: (ctx) => {
  const router = inject(Router);
  return {
    product: resource({
      params: () => ctx.params()['sku'],
      loader: async ({ params: sku, abortSignal }) => {
        const product = await productService.getBySku(sku, { signal: abortSignal });
        if (!product) {
          throw new RedirectCommand(router.parseUrl('/not-found'));
        }
        return product;
      },
    }),
  };
},

Note the abortSignal in the loader arguments, forward it into your fetch call. When the router supersedes a navigation or rolls it back, it aborts the in-flight request through that signal instead of letting an orphaned request finish and update state nobody asked for anymore.

Where this gets uncomfortable

Everything above is solid engineering, but a few things are worth flagging before you rely on this in production.

It's a developer preview API (22.2 at the time of writing). The shapes of ResourceContext, nonBlocking, and the internal snapshot mechanism can change between minors. If you build a design system component library around route.resources, expect to revisit it.

Blocking-resource errors kill the entire navigation, not just the affected component. If you have three parallel blocking resources on a route and one of them throws, the router cancels the whole navigation and fires NavigationError, even if the other two resolved fine and their data would have been perfectly usable. There's no equivalent of a partial activation, you either get every blocking resource or none of them. nonBlocking() sidesteps this, but only if you're willing to accept the full Resource<T> object as your input type instead of the unwrapped value.

The input binding is name-matching, not type-checked. createResourceOutletBindingEffects matches on templateName between your resources map and your component's declared inputs. Rename an input, rename a resource key, or introduce an alias, and the binding breaks silently. TypeScript won't catch this for you, you'll find out at runtime when the input stays undefined.

Manual reload has a silent failure mode. As shown above, .reload() returns false during transitions and rollback recovery instead of throwing or queuing the request. That's the right call for correctness, but it means a "refresh" button clicked at the wrong moment does nothing, and your only way to notice is checking the boolean.

Params identity is a footgun the type system won't warn you about. Passing ctx.params() instead of ctx.params()['id'] compiles fine and works fine in your first manual test, then quietly reloads on every navigation once you actually have more than one route parameter changing shape. This is exactly the kind of bug that survives a demo and shows up three sprints later as "why does this refetch on every click."

Testing route resources properly means testing through the router. Because the freezing and rollback logic lives on router.events subscriptions tied to NavigationStart / NavigationEnd / NavigationCancel, a shallow component test that stubs your service won't exercise any of that behavior. You need a RouterTestingHarness (or equivalent) actually driving navigations to see the freeze/unfreeze cycle at all, plain TestBed.createComponent won't cut it.

Wrapping up

Route resources solve a real problem, resolvers force a sequential waterfall and can't be refreshed without a full renavigation. What the docs describe as "the router masks loading states during pending navigations" is, under the hood, a computed signal falling back between a frozen snapshot and the live one, driven by five router events and one small state machine for rollback recovery. It's not magic, it's a resource wrapper subscribing to navigation lifecycle events and freezing a value at the right moment, then releasing it at the right moment.

If you're adopting this feature now, keep it away from anything load-bearing until it graduates out of developer preview, and keep an eye on that reload() return value.

Web MCP: give some tools to your agent

Nicolas Frizzarin — Thu, 11 Jun 2026 15:50:17 +0000

Introduction

Nowadays, AI agents are becoming increasingly powerful at assisting users in their daily web activities. However, we cannot yet allow them to act completely autonomously—there is still a risk of them clicking on the wrong elements, for instance.

In theory, these agents are capable of performing impressive tasks, provided they are guided step-by-step through the interface. The challenge here is not a lack of intelligence in the model, nor a shortage of web APIs to expose data to the agent. The core issue lies in the fact that the agent must currently "guess" its way through applications that were designed exclusively for humans.

This is precisely the problem that WebMCP is here to solve.

It is important to note that these are not intended to replace standard APIs as access points for an application. Instead, they provide a structured way for a web application to "instruct" the AI agent used in the browser on how to navigate its interface. This results in:

Fewer misplaced clicks.
Less trial-and-error when interacting with the UI.

When utilized to their full potential, WebMCPs could redefine the user experience in the coming years.

What is WEBMCP?

As you may have guessed, WebMCP is a browser-side "guide/standard" for exposing tools to an AI agent directly from an active web page.

During Google I/O, this new feature was introduced as a way for web applications to describe how a page functions—and what actions can be performed—to various AI agents. As a result, agents can execute these described actions faster, more efficiently, and with greater precision.

Unsurprisingly, the syntax for creating these descriptions relies on JavaScript functions. These functions take natural language descriptions as parameters, along with structured schemas directly exposed from the web page.

This is exactly where the power of WebMCP lies.

Today, while we have Playwright (designed for end-to-end testing of web applications) and Playwright MCP (which extends this model to LLMs), WebMCP sits right at the intersection. It allows a page to effectively communicate to the agent: "Here are the actions you can perform on this page, how it works, and how you can trigger them."

Difference between WebMCP | MCP | Automation

At first glance, it may seem like all these approaches are similar and perform the same functions. In reality, each serves a well defined purpose, and they are highly complementary. To better understand the distinctions between them, let’s look at things from an AI integration perspective.

Backend MCP

At its core, an MCP server acts as a specialized bridge between AI models and external systems. It functions by providing a direct connection to APIs, effectively removing the friction typically involved in integrating new tools. By establishing a structured framework for data access, it ensures that the information exposed to the agent is organized, predictable, and secure. This architecture makes it an ideal solution for executing data-driven actions, allowing AI agents to perform complex, precise tasks with the reliability required for production grade applications.

Browser Automation

Traditional automation concepts rely on mimicking user behavior to interact with the web. They reproduce human-like interactions, such as clicking buttons or scrolling through pages, and can access any element within the UI by targeting it directly in the DOM. A key characteristic of these methods is that they do not require a predefined data structure, as they operate by observing the visual state of the application. However, because they are so tightly coupled to the underlying HTML structure, the main flow can be quite brittle; even minor UI changes often cause the automation to break, requiring constant maintenance.

WebMCP

By design, it shares the current application context directly with the AI, moving beyond what is merely visible on the screen. It structures and describes UI actions, providing the agent with a clear map of what is possible rather than forcing it to guess. This results in a highly reliable, context-aware interaction model that significantly reduces errors. Furthermore, the architecture is designed with human-in-the-loop capabilities at its core, ensuring that users maintain oversight and can intervene whenever necessary for sensitive or complex workflows.

When to use what: rules to apply.

To ensure your AI agent performs at its best, it is important to select the right integration strategy based on your specific requirements:

When an agent requires direct, structured access to data without interacting with a live web page, an MCP server is the ideal solution.
When you need to interact with a web interface exactly like a human would—whether for automated testing, task execution, or full application usage—browser automation is the right choice.
When a user is already actively navigating your web application and requires an agent that can interact with the entire page with high precision, WebMCP is the optimal path forward.

Different layers, different jobs.

How to use WEBMCP

It is worth noting that, for now, WebMCP is only available in Chrome starting from version 149 (with a strong drive to integrate this feature into the Baseline movement).

To enable this functionality in Chrome today, you need to use a feature flag:

Navigate to chrome://flags in your browser.
Search for and enable the enable-webmcp-testing flag.
Relaunch your browser to apply the changes.

There are two primary ways to utilize the WebMCP APIs to configure the tools exposed by your page:

The Declarative API: This method enables you to create WebMCP tools simply by adding annotations to your standard HTML forms, making the integration process more streamlined and semantic.
The Imperative API: This approach allows you to define custom tools such as form submission, navigation, or other specialized actions directly using standard JavaScript functions.

Defining tools using the Imperative API

document.modelContext.registerTool({
  name: 'search_product',
  description: 'search product based on a user search input'
  inputSchema: {
    type: "object",
    properties: {
      search: { type: 'string' }
    }
    required: ['search']
  }
  outputSchema: { type: 'string', description: 'List of products corresponding to the search'} 
  execute: async ({ search }) => {
    if(!search) return [];
    const products = await (await(fetch(`${url}?search=${search}`)).json());

    return JSON.stringify(products);
  }
})

Defining Form tool with the Declarative API

As previously mentioned, the Declarative API allows you to create form-based tools using annotations. More specifically, it leverages standard HTML attributes on your forms to define and manage how the tool is created.

<form toolname="supportRequestTool"
  tooldescription="Submit a request for support."
  action="/submit">

  <label for="firstName">First Name</label>
  <input type=text name=firstName>

  <label for="lastName">Last Name</label>
  <input type=text name=lastName>

  <select name="select" required 
    toolparamdescription="Determines what team this request is routed to.">
    <option value="Customer happiness team">Return my purchase.</option>
    <option value="Distribution team">Check where my package is.</option>
    <option value="Website support team">Get help on the website.</option>
  </select>

  <button type=submit>Submit</button>
</form>

The declaration process relies on specific attributes to define your tools:

toolname: Used to assign a specific name to your tool, reflecting its purpose.
tooldescription: Used to provide a clear explanation of the action the tool performs.

In practice, when the agent invokes the supportRequestTool, the browser brings the corresponding form to the foreground and fills out the fields while keeping the form visible to the user. Note that if you remove either the toolname or tooldescription attribute, the tool will be automatically unregistered and become inaccessible to the agent.

toolparamdescription: This optional attribute allows you to map a specific element to a detailed description. If this attribute is omitted, the agent will default to using the field's label as the description.

Security

As a reminder, LLMs process all text—including instructions and user data—as a single sequence of tokens. Consequently, once your application implements the WebMCP feature, it becomes susceptible to indirect prompt injection, where malicious instructions can be hidden within the content.

To mitigate these risks, here are several security recommendations for implementing WebMCP:

untrustedContentHint: Use this attribute to signal to the agent that the data originates from an external source, prompting it to exercise greater vigilance.
readOnlyHint: Apply this attribute to tools that should not modify data states, ensuring they require explicit agent confirmation before execution.
Character budgets: Define strict character limits for your tool names and descriptions to prevent prompt-injection attempts via long, malicious strings.
exposedTo: Use this property to restrict access to your tools, limiting them to specific, trusted domains.

It is important to remember that by default, tools are only exposed to the AI agent and are not accessible to other websites or iframes.

Conclusion

WebMCP represents a fundamental shift in how AI agents interact with the web. We are moving beyond the era of "computer-use stunts" where agents must guess intent from messy interfaces toward a model of direct, structured cooperation between sites and assistants.

By exposing structured actions and context, WebMCP allows the browser to share what it already knows: the current page, the user's session, and the precise moment help is needed. While backend integrations remain the best fit for bulk data processing, WebMCP is the optimal path for sites that want to provide a reliable, context-aware experience during live navigation.

We have only scratched the surface. In our next article, we will move from theory to practice by diving deep into implementation join us as we explore how to seamlessly integrate WebMCP into Angular applications.

Angular Signals Form: Validation and Logic

Nicolas Frizzarin — Mon, 15 Sep 2025 21:10:41 +0000

Introduction

In the previous article, we explored how to create a form based entirely on signals. However, that was a simple form with no business logic and, most importantly, no validation.

This article aims to detail how we can write our business logic simply and in a scalable way.

Just a reminder

Just a reminder, the form we created is as follows:

interface Assigned {
  name: string;
  firstname: string;
}

interface Todo {
  title: string;
  description: string;
  status: TodoStatus;
  assigned: Assigned[]
}


@Component({
  selector: 'app-form',
  templateUrl: './app-form.html',
  imports: [Control]
})
export class AppForm {
  todoModel = signal<Todo>({ 
    title: '',
    description: '', 
    status: 'not_begin',
    assigned: []
  }); // We create the model that will be the source of truth for the form and it's tree field

  todoForm = form(this.todoModel); // we create the form which is linked to the model
}

As shown in the previous article, a FieldState instance exposes a signal (and therefore a reactive state) like valid or disabled. However, this state isn't defined directly. In reality, it's a derived state (technically, it's a computed). This derived state comes directly from the field logic part of the form.

Adding Field Logic

One of the key aspects of signals-based forms in Angular is the very definition of business logic and validation. This definition is done declaratively in TypeScript when the form is defined. This implies two important things:

There are no imperative commands to modify a field's state later on; in other words, there are no methods like disable.
A field can be required or disabled based on other signals or static conditions.

Essentially, the business and validation logic is represented by a schema. A schema can be considered as a blueprint containing all our business rules for:

The entire form
A specific Field

schema is defined using the schema function. This function is generically typed and takes:

The FieldPath interface as a generic type.
A function that takes the FieldPath as an input and defines its business logic.

The generic type here is of utmost importance because it's what dictates the rule's definition:

a Todo type schema defines the rules for a Todo type field
a Boolean type schema defines the rules for a Boolean type field

Type and rule definition are extremely linked. This link ensures that the field's logic is perfectly aligned with the form's structure.

A Schema can be created by calling schema() and passing it a schema function, or just passing a schema function directly to form() or other methods that expect a Schema.

Once you have defined a schema, you associate it with your Field structure by passing it as the second argument to the form() function

let's have some code

interface Assigned {
  name: string;
  firstname: string;
}

interface Todo {
  title: string;
  description: string;
  status: TodoStatus;
  assigned: Assigned[]
}

@Component({
  selector: 'app-form',
  templateUrl: './app-form.html',
  imports: [Control]
})
export class AppForm {
  todoModel = signal<Todo>({ 
    title: '',
    description: '', 
    status: 'not_begin',
    assigned: []
  }); // We create the model that will be the source of truth for the form and it's tree field

  todoForm = form(this.todoModel, (path: FieldPath<Todo>) => {}); // we create the form which is linked to the model
}

In this example, we've defined a schema by its function. The main drawback of this solution is that it's not scalable. The schema here can't be exported by a library or reused across an application.

let' rework a little bit the previous code

interface Assigned {
  name: string;
  firstname: string;
}

interface Todo {
  title: string;
  description: string;
  status: TodoStatus;
  assigned: Assigned[]
}

/**
* Define a schema exportable:
* - let you to create some library that export your custom schema
* - could be used later in an other place of your application
*/
export const TodoSchema = schema<Todo>(path => {});

@Component({
  selector: 'app-form',
  templateUrl: './app-form.html',
  imports: [Control]
})
export class AppForm {
  todoModel = signal<Todo>({ 
    title: '',
    description: '', 
    status: 'not_begin',
    assigned: []
  });
  todoForm = form(this.todoModel, TodoSchema);
}

Right now, our schema doesn't do... anything. Let's see how we can add some functionality to it.

Let's have some logic

Just like with Reactive Forms, there are built-in validations. You'll find the classic validation types:

For a complete list of existing validators, please go here

Let's add some validation to our form.

interface Assigned {
  name: string;
  firstname: string;
}

interface Todo {
  title: string;
  description: string;
  status: TodoStatus;
  assigned: Assigned[]
}

/**
* Define a schema exportable:
* - let you to create some library that export your custom schema
* - could be used later in an other place of your application
*/
export const TodoSchema = schema<Todo>(path => {
  required(path.title);
  required(path.description);
  minLength(path.description, 10);
});

@Component({
  selector: 'app-form',
  templateUrl: './app-form.html',
  imports: [Control]
})
export class AppForm {
  todoModel = signal<Todo>({ 
    title: '',
    description: '', 
    status: 'not_begin',
    assigned: []
  });
  todoForm = form(this.todoModel, TodoSchema);
}

If you want to use your own validation logic instead of the built-in validators, two new functions are available to us:

validate
error

The `validate` function

The validate function is used to add custom validation to a field. A single field can have multiple validation rules, and all validation rule errors can be found in the FieldState.

Example:

const emailSchema = schema<string>(path => {
  validate(path, (value) => {
    const email = value();
    const sfeirPattern = /^\w+\.\w@sfeir.com$/;
    return sfeirPattern.test(email) ? 
      [] : [{ kind: 'sfeir-mail-incorrect', message: 'Required format: x.x@sfeir.com'}]
  });
})

This function can be much more powerful than a simple email validator. Since the function takes a FieldPath as its first parameter, it can validate a single field but also an entire form :). For the die-hard fans of Zod, it becomes very easy to link the form's validation with Zod's validation.


const UserSchema = z.object({
  name: z.string().min(1, 'Name is required'),
  email: z.string().email('Invalid email'),
  age: z.number().min(18, 'Must be 18 or older'),
});

const userFormSchema = schema<User>(path => {
  validate(path, ({ value }) => {
    const validation = UserSchema.safeParse(value());
    return validation.success ?
      [] :
      validation.error!.issues.map(issue => ({
        kind: `${issue.path[0]_${issue.expected}`
        message: issue.message
      }))
  });

/**
* Focus of ({ value }) => {}
* This function is called an helper fonction
* Helper function take an object with three properties
* - value: signal that return the value of the `FieldPath`
* - valueOf: function that take a `FieldPath` and return the associate value
* - stateOf: function that take a `FieldPath` and return the `FieldState` of this `FieldPath`
* - fieldOf: function that take a `FieldPath` and return the `Field` of this `FieldPath` 
*/
});

The `error` function

The error function is a simplified version of the validate function due to its return type. Unlike the validate function, error function returns a boolean, optionally with a message that's properly formatted for the user experience.

true if the validation is successful
false if the validation fails

const emailSchema = schema<string>(path => {
  error(path, (value) => {
     const email = value();
     const sfeirPattern = /^\w+\.\w@sfeir.com$/;
     return sfeirPattern.test(email)
   }, 'Required format: x.x@sfeir.com');
})

Composition built-in

As the examples above show, validation with form signals is very powerful, but it can get quite verbose and quickly complicate our form.

This is where schema composition and flexibility become very useful.

Let's go back to the example above.

export const TodoSchema = schema<Todo>(path => {
  required(path.title);
  required(path.description);
  minLength(path.description, 10);
  maxLength(path.description, 150);
});

We're adding three validations to the description field. When the model is small, the impact is minimal, but as it grows, poor structuring and business logic management become a nightmare.

This is where the composition pattern truly makes sense.

The composition pattern is a simple pattern based on the act of composing. You compose smaller things to solve a complex problem.

With Signals Form, it's entirely possible to compose with schemas. This composition happens around the simple apply function.

The apply function lets you assign a schema to a FieldPath. This function, therefore, allows for two things.

To break down our form validation into smaller schemas
To share generic schemas throughout our application, or even better, across an multiple application if we create a schema library.

const descriptionSchema = schema<string>(path => {
  required(path);
  minLength(path.description, 10);
  maxLength(path.description, 150);
});

export const TodoSchema = schema<Todo>(path => {
  required(path.title);
  apply(path.description, descriptionSchema);
});

The apply function has some new companions.

applyEach allows you to apply a schema to each element of an array. This function therefore takes an Array-type FieldPath and a schema
applyWhen which allows a schema to be applied conditionally. This function therefore takes the fieldPath on which to apply the validation, the condition to apply the validation, and finally the schema.


interface User {
  email: string;
  password: string;
  confirmPassword: string;
}

const UserSchema = schema<User>(path => {
  required(path.email);
  applyWhen(
     path.confirmPassword,
     ({ valueOf }) => Boolean(valueOf(path).password),
     (confirmPasswordPath) => {
       required(confirmPassword)
     }
  )
});

@Component({
  selector: 'app-user',
  templateUrl: './user-form.html',
  imports: [Control]
})
export class AppForm {
  usersModel = signal<User[]>([]);
  usersForm = form(this.usersModel, (path => {
    applyEach(path);
  });
}

Conclusion

The business logic of a form is defined using a schema, which can be thought of as a blueprint.

The signal form package provides numerous helpers, including built-in validators and tools that allow for the use of the composition pattern within forms.

What previously required a lot of code and extensive thought about form structure can now be accomplished with just a few simple lines of code.

This really shows a strong desire to improve the developer experience and abstract away the complexity of form creation, allowing developers to focus on their business logic.

Signals Form: Introduction

Nicolas Frizzarin — Tue, 09 Sep 2025 06:17:00 +0000

Introduction and Disclaimer

First and foremost, the APIs that will be mentioned in this article are still highly experimental and may be subject to change in the future. As with all experimental APIs, I do not recommend using them in an application that is scheduled to go into production in the near future.

Today, and to no great surprise, the Angular Team is trying to incorporate signals as much as possible into existing APIs. Naturally, forms aren't being left behind, and a new type of form is emerging: Signal forms. This addition brings the total number of possible forms in Angular to three:

React Form: forms controlled by the component
Template Driven Form: forms controlled by the template
Signal Form: forms controlled by signals

Mindset of Signal Forms

No matter the framework or library you use to create a form, a form is simply a set of UI fields that allow the user to enter structured data, which can be governed by validation rules to ensure its integrity.

With Signal forms, this concept is separated into four distinct parts:

Data model: the form's current data model
Field State: the metadata associated with a form field (value, validity, and control state)
Field logic: the business logic of the field (validation rules, conditional display of the field)
UI Control: the control that enables interaction between native elements, custom components, and the user.

One of the key points of Signal's form is that it doesn't maintain its own data internally. Instead, we, the developers, expose this data model through a signal that the library will use as the uniq source for the fields of our form.

To illustrate this in code :)

interface Assigned {
  name: string;
  firstname: string;
}

interface Todo {
  title: string;
  description: string;
  status: TodoStatus;
  assigned: Assigned[];
}


@Component({
  selector: 'app-form',
  templateUrl: './app-form.html'
})
export class AppForm {
  todoModel = signal<Todo>({ 
    title: '',
    description: '', 
    status: 'not_begin',
    assigned: []
  }); // We create the model that will be the source of truth for the form and it's tree field

  todoForm = form(this.todoModel); // we create the form which is linked to the model

}

Establishing the model as the single source of truth means two important things:

Any modifications to the model, via the set or update function, will automatically update the form field.
Any modifications to the form due to user interaction with a field will update the model.

A tree of Field

Calling the form function gives the developer access to a Field tree. The form itself is a Field called the Root Field.

A Field instance provides its state, which later allows you to retrieve its value, validity, and more and it can be retrieve by calling the Field function.

Let's illustrate that with a bit of code :)

interface Assigned {
  name: string;
  firstname: string;
}

interface Todo {
  title: string;
  description: string;
  status: TodoStatus;
  assigned: Assigned[]
}


@Component({
  selector: 'app-form',
  templateUrl: './app-form.html'
})
export class AppForm {
  todoModel = signal<Todo>({ 
    title: '',
    description: '', 
    status: 'not_begin',
    assigned: []
  }); // We create the model that will be the source of truth for the form and it's tree field

  todoForm = form(this.todoModel); // we create the form which is linked to the model

  titleField: Field<string> = this.todoForm.title;
  firstAssigned: Field<Assigned> = this.todoForm.assigned[0];
  firstAssignedName: Field<string> = firstAssigned.name;

}

Field Instance

As explained previously, a Field instance returns the state of that field. The state is composed of 6 main points.

value: A WritableSignal that allows you to read and write the value of a field.
errors: A signal for retrieving validation errors on the field.
valid: A signal for retrieving the field's validity.
disabled: A signal for retrieving whether the field is disabled.
touched: A signal to know if the user has interacted with the field or one of its children.
dirty: A signal to know if the field or one of its children is dirty.

For more details on what a field instance can offer, or to see the concrete implementation, please refer to the following

Let's illustrate that with a bit of code.

interface Assigned {
  name: string;
  firstname: string;
}

interface Todo {
  title: string;
  description: string;
  status: TodoStatus;
  assigned: Assigned[]
}


@Component({
  selector: 'app-form',
  template: `<button [disabled]="titleField().valid()">Submit</button>`
})
export class AppForm {
  todoModel = signal<Todo>({ 
    title: '',
    description: '', 
    status: 'not_begin',
    assigned: []
  }); // We create the model that will be the source of truth for the form and it's tree field

  todoForm = form(this.todoModel); // we create the form which is linked to the model

  titleField: Field<string> = this.todoForm.title;
  firstAssigned: Field<Assigned> = this.todoForm.assigned[0];
  firstAssignedName: Field<string> = firstAssigned.name;
}

Binding the field to UI elements

We have now completed the data model definition, form creation, field tree navigation, and field instance retrieval.

It is now important to connect the UI element (input, textarea, or even a custom component) to the field so the user can interact with the control.

In Angular, the Signal Form provides a built-in directive, so you can see the source code here

This directive will have several responsibilities:

Two-way data binding to update the field's value (both from user interaction and programmatically).
Binding the field's business logic (validation rules, read-only status, etc.).
Relaying the various possible events on the control (dirty, touched, etc.).
Internally, injecting the NgControl token to get useful methods and ensure interoperability.

Here, we clearly see the intention to create a bridge between the HTML logic and Angular's forms, leveraging all the power they can provide.

Let's materialize this with some code :)

interface Assigned {
  name: string;
  firstname: string;
}

interface Todo {
  title: string;
  description: string;
  status: TodoStatus;
  assigned: Assigned[]
}


@Component({
  selector: 'app-form',
  templateUrl: './app-form.html',
  imports: [Control]
})
export class AppForm {
  todoModel = signal<Todo>({ 
    title: '',
    description: '', 
    status: 'not_begin',
    assigned: []
  }); // We create the model that will be the source of truth for the form and it's tree field

  todoForm = form(this.todoModel); // we create the form which is linked to the model
}

<form novalidate>
  <input type="text" [control]="todoForm.title" />
  <input type="text" [control]="todoForm.description" />
  <select [control]="todoForm.status">
    <option [ngValue]="not_begin">Not Begined</option>
    <option [ngValue]="in_progress">In Progress</option>
    <option [ngValue]="finished">Finished</option>
  </select>
</form>

Conclusion

This marks the end of the first article in a series of three. This article aimed to lay the foundations for Signal's forms.

We were able to understand how Signal's forms work by detailing their main components.

However, for now, our form contains no validation, and as a reminder, validation consists of the business logic of our field. This step will be detailed in the second article.

What to remember here is that the developer has complete control over the data model they expose. This data model will subsequently allow for the connection between the Field and the value.

The form function allows for the creation of a field tree. It is possible to navigate this tree using dot notation.

A Field instance allows you to retrieve its state by calling a function, which enables you, for example, to know its current value.

The Next Generation of Dynamic Component

Nicolas Frizzarin — Tue, 01 Apr 2025 05:34:31 +0000

Préambule

Before anything else, I want to clarify that Angular has not changed its way of dynamically creating components. The API has evolved, and what will be shown and explained in this article is still in preview and may change before the release of Angular version 20.

This article is based on the angular-next-1 version.

Introduction

With Angular, there are several ways to dynamically create components and 'attach' them to the view and the change detection cycle. However, until now, some features like setting inputs, or responding to outputs were not feasible on certain APIs (createComponent).

This article presents the evolution of the createComponent API with a reminder of the other APIs allowing the dynamic creation of components.

NgComponentOutlet: Declarative way to dynamic component creation

The NgComponentOutlet directive is a simple way to create components dynamically. It uses a declarative approach.

This directive takes several input parameters, one of which is required: the component to be created.

@Component({ 
  select: 'app-parent',
  template: `
    <ng-container *ngComponentOutlet="dynamicComponent" />
    <button type="button" (click)="loadComponent()">Load</button>`,
  imports: [NgComponentOutlet]
})
export class ParentComponent {
 component: Type<HelloComponent> | null = null;

 async loadComponent(): Promise<void> {
   component = (await import('./hello.component')).HelloComponent;
 }
}

The above code represents the implementation of the basic API of the ngComponentOutlet directive.
When the button is clicked, the loadComponent method is called. This method lazily loads the HelloComponent component (a little performance is always nice). The instance of the HelloComponent component is then assigned to the component variable.

The directive, NgComponentOutlet, which takes as input named ngComponentOutlet the instance of a component, will attach the HostView of the component in the current view.

Recently, more specifically Angular version 16, this directive allows inputs to be set automatically in the dynamic component using the ngComponentOutletInputs input

This input takes an object that will bind an input of the dynamic component to a value.

@Component({ 
  template: `Hello {{ name }}`
})
export class HelloComponent {
  name = input('DevTo');
}


@Component({ 
  selector: 'app-parent',
  template: `
    <ng-container *ngComponentOutlet="dynamicComponent; inputs: { 
      name: 'This is Angular' }" />
    <button type="button" (click)="loadComponent()">Load</button>`,
  imports: [NgComponentOutlet]
})
export class ParentComponent {
 component: Type<HelloComponent> | null = null;

 async loadComponent(): Promise<void> {
   component = (await import('./hello.component')).HelloComponent;
 }
}

Through this example, the input name is passed to the HelloComponent component. When the HostView of the HelloComponent component is inserted into the current view, the screen will display Hello This is Angular.

This method works very well if you know in advance which component is going to be created dynamically. Now let's imagine that the method loadComponent conditionally loads two components:

the HelloComponent component taking an input name
the AngularComponent component taking no input

... 
 component: Type<HelloComponent | AngularComponent> | null = null;
 isAngular = signal(false);

 async loadComponent(): Promise<void> {
   if(isAngular()) {
     component = (await import('./angular.component')).AngularComponent;
   }else {
     component = (await import('./hello.component')).HelloComponent;
   }
 }

In the case where component is an AngularComponent instance, the application will not build. An error will be raised explaining that the AngularComponent component must have an input called name even if this component has no use for it.

Another sticking point: at the moment it is not possible to react to outputs of the component created dynamically in the parent component.

This is where the createComponent function comes in.

The update of createComponent function

Please note that what follows is based on the Angular-next-1 version and may potentially change in the future.

If you would like to take a look at the sources, it's this way:

Generally, to create a dynamic component with a more functional approach, we use the createComponent function which we will explain using the ViewContainerRef class.

@Component({ 
  select: 'app-parent',
  template: `
    <section #dynamicSection></section>
    <button type="button" (click)="loadComponent()">Load</button>`,
  imports: [NgComponentOutlet]
})
export class ParentComponent {
 dynamicSection = viewChild<ViewContainerRef>('dynamicSection', { read: ViewContainerRef } );

 async loadComponent(): Promise<void> {
   const helloComponent = (await import('./hello.component')).HelloComponent
   this.dynamicSection.createComponent(helloComponent);
 }
}

In the above code, a section with a reference named dynamicSection serves as a container for displaying the dynamically created component.
When the user clicks on the button, the loadComponent method loads the HelloComponent component, then the createComponent function creates the component, attaches the host view of this component to the current view and, of course, registers this component in the change detection cycle.
Thus, when the parent component is destroyed, the hook onDestroy of the dynamic component will also be called, thus avoiding any memory leaks.

The createComponent method returns a ComponentRef. This class allows the setInput function to set inputs to the dynamic component. But once again, we cannot react to events from the dynamic component in the parent component.

Today, in Angular version 20, it is possible to go much further than setting inputs. We can

bind inputs
bind outputs
create a two-way binding between parent and child (dynamic)
apply host directives to the dynamic component and bind inputs and outputs

This function is possible thanks to the standalone component and also to the appearance of signals as Angular's primary reactive system.

@Component({ 
  template: `Hello {{ name }}
    <button type="button" (click)="refresh()">Refresh</button>
  `
})
export class HelloComponent {
  name = input('DevTo');
  refreshName = output<void>();

  refresh(): void {
    this.refreshName.emit()
  }
}

@Component({ 
  select: 'app-parent',
  template: `
    <section #dynamicSection></section>
    <button type="button" (click)="loadComponent()">Load</button>`,
  imports: [NgComponentOutlet]
})
export class ParentComponent {
 name = signal('DevTo');
 dynamicSection = viewChild<ViewContainerRef>('dynamicSection', { read: ViewContainerRef } );

 onRefresh = () => this.name.set('This is Angular');

 async loadComponent(): Promise<void> {
   const helloComponent = (await import('./hello.component')).HelloComponent
   this.dynamicSection.createComponent(helloComponent,{
     bindings: [
       inputBinding('name', this.name),
       outputBinding('refreshName', this.onRefresh),
     ]
   });
 }
}

In the above code, the HelloComponent component will be created dynamically by mapping the input name to the value This is Angular and mapping the outPut refreshName to the onRefresh function.

This way, when the user clicks on the Refresh button, the onRefresh function will be called.

Be careful to pass an arrow function so as not to lose the context

Let's go a little further, let's imagine that we want to apply a directive on the dynamic component, this directive will be in charge of adding a class red if the name is “This is Angular”.
With the new definitions of the createComponent function, this scenario is now possible.


@Directive({ 
  selector: '[rainbow]',
  host: {
   '[class.red]'= 'isRed()';
  }
})
export class ColorDirective {
  name = input<string>('');
  isRed = computed(() => this.name() === 'This is Angular');
}

@Component({ 
  template: `Hello {{ name }}
    <button type="button" (click)="refresh()">Refresh</button>
  `
})
export class HelloComponent {
  name = input('DevTo');
  refreshName = output<void>();

  refresh(): void {
    this.refreshName.emit()
  }
}

@Component({ 
  select: 'app-parent',
  template: `
    <section #dynamicSection></section>
    <button type="button" (click)="loadComponent()">Load</button>`,
  imports: [NgComponentOutlet]
})
export class ParentComponent {
 name = signal('DevTo');
 dynamicSection = viewChild<ViewContainerRef>('dynamicSection', { read: ViewContainerRef } );

 onRefresh = () => this.name.set('This is Angular');

 async loadComponent(): Promise<void> {
   const helloComponent = (await import('./hello.component')).HelloComponent
   this.dynamicSection.createComponent(helloComponent,{
     bindings: [
       inputBinding('name', () => 'This is Angular'),
       outputBinding('refreshName', this.onRefresh),
     ],
     directives: [
       { type: ColorDirective,
         bindings: [
           inputBinding('name', this.name),
         ]
       }
     ]
   });
 }
}

In the example above, the ColorDirective will be applied to the HelloComponent dynamic component by binding the input name.

Initially, the value of the signal name will be DevTo which sets the variable isRed to false

When the user clicks on the refresh button, the onRefresh function will be called, setting the value of the signal name to This is Angular, and thus the variable isRed will have the value true, applying the red css class

Conclusion

With the arrival of Angular 20, creating dynamic components by binding inputs and outputs has never been easier.

This new definition of the createComponent function gives us more freedom in the dynamic creation of components. The use case of dynamically creating a component based on certain conditions becomes much easier, to the point of imagining the possibility of “composing our dynamic components”.

In the future, it will therefore become increasingly easy to create Angular applications by applying the composition pattern.

The next improvement in Angular reactivity

Nicolas Frizzarin — Fri, 15 Nov 2024 13:43:20 +0000

Introduction

Since the latest versions of Angular, a new primitive reactivity system has been developed within the framework: signals!

Today, with hindsight, we realize that certain use cases had not been covered, and obviously the Angular team being very reactive will provide us with helpers to cover these uses cases.

What are these uses cases? What solutions are going to be put in place, and how are they going to be used?

Process of resetting one signal relative to another

Let's start by illustrating this problem.

Let's imagine we have a basket of fruit with a certain quantity.
The quantity is managed by a component, which inputs the fruit.

@Component({
  template: `<button type="button" (click)="updateQuantity()"> 
    {{quantity()}}
    </button>`
})
export class QuantityComponent() {
  fruit = input.required<string>();
  count = signal(1);

  updateQuantity(): void {
    this.count.update(prevCount => prevCount++);
  }
}

Here the variable must be reset if the input price fruit changes.

A simple solution would be to use an effect

@Component({
  template: `<button type="button" (click)="updateQuantity()"> 
    {{quantity()}}
    </button>`
})
export class QuantityComponent() {
  fruit = input.required<string>();
  quantity = signal(1);

  countEffect(() => {
    this.fruit();
    this.quantity.set(1);
  }, { allowSignalWrites: true })

  updateQuantity(): void {
    this.quantity.update(prevCount => prevCount++);
  }
}

The preceding code is bad practice. Why is this the big question?

We need to set the signalWrites option to true in order to set the signal quantity. This is due to a misinterpretation of the given problem.
In our case, we want to synchronize two variables which, in our materialization, are desynchronized

The counter is not independent of the fruit, which is our initial source. In reality, here we have a component state, whose initial source is the fruit and the rest is a derivative of the fruit.

Materialize the problem as follows

@Component({
  template: `<button type="button" (click)="updateQuantity()"> 
    {{fruitState().quantity()}}
    </button>`
})
export class QuantityComponent() {
  fruit = input.required<string>();

  fruitState = computed(() => ({
    source: fruit(),
    quantity: signal(1),
  }));

  updateQuantity(): void {
    this.fruitState().quantity.update(prevCount => prevCount++);
  }
}

This materialization strongly links the fruit to its quantity.
So as soon as the fruit changes, the computed variable fruitState is automatically recalculated. This recalculation returns an object with the quantity property, which is a signal initialized to 1.

By returning a signal, the variable can be incremented on click and simply reset when the fruit changes.

It's a relatively simple pattern to set up, but can't we simplify it?

The LinkedSignal function to the rescue.

With the arrival of Angular 19, a new function for calculating derived signals.

Until now, we had the computed function, but this function returns a Signal and not a WrittableSignal, which would have been practical in our previous use case for the quantity variable.

This is where LinkedSignal comes in. LinkedSignal, as its name suggests, allows you to strongly link two signals together.

If we return to our previous case, this function would allow us to simplify the code as follows:

@Component({
  template: `<button type="button" (click)="updateQuantity()"> 
    {{quantity()}}
    </button>`
})
export class QuantityComponent() {
  fruit = input.required<string>();
  quantity = linkedSignal({ source: fruit, computation: () => 1 });

  updateQuantity(): void {
    this.quantity.update(prevCount => prevCount++);
  }
}

The linkedSignal function is defined as follows:

linkedSignal(computation: () => D, options?: { equal?: ValueEqualityFn<NoInfer<D>>; }): WritableSignal<D>;

linkedSignal(options: { source: () => S; computation: (source: NoInfer<S>, previous?: { source: NoInfer<S>; value: NoInfer<D>; }) => D; equal?: ValueEqualityFn<NoInfer<D>>; }): WritableSignal<D>;

In the first definition, the “abbreviated” definition, the linkedSignal function takes a computation function as a parameter and a config object.

const quantity = input.required<number>();
const price = linkedSignal(() => quantity() * 0);

In this previous exemple, because the computation function depends of the quantity sigal, when the quantity change, the computation function is reevaluated.

In the second definition, the linkedFunction method takes an object as a parameter with three properties

the source: the signal on which the computation function bases its re-evaluation
the computation function
a parameter object

Contrary to the “abbreviated” computation function, here the computation function takes as parameters the value of the source and a “precedent”.

const fruits = signal(['apple', 'orange']);
const choice = linkedSignal({
  source: fruits,
  computation: (source, previous) => {
    if(!Boolean(previous)) {
      return 'apple';
    }
    return previous.source.find(fruit => fruit === previous.value) ||   
      'apple';
  }
})

The new Resource Api

Angular 19 will introduce a new API for simple data fetching and retrieval of query status (pending etc), data and errors.

For those who are a little familiar with the framework, this new API works a bit like the useRessource hook.

Let's take a look at an example:


import { resource } from "@angular/core";

@Component()
export class FruitComponent {
  fruitId = input.required<string>();
  fruitRessource = resource({
    loader: () => {
      return fetch(`https://myFruit.com/${this.fruitId()}`).then(response => 
      response.json());
    },
  });

  fruitRessourceEffect(() => {
    console.log("Status: ", this.todoResource.status());
    console.log("Value: ", this.todoResource.value());
    console.log("Error: ", this.todoResource.error());
  })
}

There are several things to know about this code snippet

There are several things to note in this snippet code:

by default, the loader takes a promise as parameter
the fruitRessource type is a WrittableRessource, which will enable us to modify the data locally if required
the request for fruit details is sent directly to the server when the resource fuitResource is created
this.fruitId() is untracked in the loader, so no new request will be send if the fruitId change
WrittableRessource have a method refresh to refresh the data

The following effect will print those value

Status: 'pending'
Value: undefined,
Error: undefined,

// When the promise is resolved, we enter again in the effect, because the status and value are signals and they changed

Status: 'resolved'
Value: { name: 'apple', count: 2 },
Error: undefined,

as explained above, by default the fruitId signal is untracked.

So how do you restart the http request each time the value of this signal changes, but also how do you cancel the previous request in the event that the value of the fruitId signal changes and the response to the previous request didn't arrive?

The resource function takes another property called request.

This property takes as its value a function that depends on signals and returns their value.


import { resource } from "@angular/core";

@Component()
export class FruitComponent {
  fruitId = input.required<string>();
  fruitRessource = resource({
    request: this.fruitId
    loader: (request, abortSignal) => {
      return fetch(`https://myFruit.com/${request}`}, { signal: abortSignal }).then(response => 
      response.json());
    },
  });

  fruitRessourceEffect(() => {
    console.log("Status: ", this.todoResource.status());
    console.log("Value: ", this.todoResource.value());
    console.log("Error: ", this.todoResource.error());
  })
}

As shown in the code above, the loader function takes two parameters

the request value: here the value of the fruitId signal
the value of the signal property of the abortController object used to cancel an http request.

So if the value of the fruitId signal changes during an httpRequest retrieving the details of a fruit, the request will be canceled to launch a new request.

Finally, Angular has also thought of the possibility of coupling this new api with RxJs, allowing us to benefit from the power of Rx operators.

Interporability is achieved using the rxResource function, which is defined in exactly the same way as the resource function.
The only difference will be the return type of the loader property, which will return an observable


import { resource } from "@angular/core";

@Component()
export class FruitComponent {
  fruitId = input.required<string>();
  fruitRessource = rxResource({
    request: this.fruitId
    loader: request => {
      return this.httpClient.get<any>(`https://myFruit.com/${request}`)
    }
  });

  fruitRessourceEffect(() => {
    console.log("Status: ", this.todoResource.status());
    console.log("Value: ", this.todoResource.value());
    console.log("Error: ", this.todoResource.error());
  })
}

Here it's not necessary to have the abortSignal, the cancelling of the previous request when the value of the signal fruitId change is implicit in the function rxResource and the behaviour will be the same as the switchMap operator.

@let: New feature compiler in Angular 18.1

Nicolas Frizzarin — Wed, 17 Jul 2024 09:19:30 +0000

Introduction

With the arrival of Angular 18.1, this version introduces an exciting new feature to the compiler: the ability to declare one or more template variables.
How is this feature used, and what are the different use cases?

This article aims to answer.

The compiler's latest feature: @let

With the latest versions of Angular, the team has introduced new functionality into the compiler, and this functionality translates into the @-syntax.

This is how the new control flow syntax came into being

and, more recently, @let

As a general rule, the easiest way to create a template variable was to use the

the *ngIf structural directive with the keyword as keyword

or using the new control flow syntax

@if with the keyword as

<!-- older control flow syntax -->
<div *ngIf="user$ |async as user">
  {{ user.name }}
</div>

<!-- new control flow syntax -->
@if(user$ |async; as user){
  <div>{{ user.name }}</div>
}

This handy feature allowed us to store the result of the async pipe in a variable for use later in the template.

However, this syntax raises a few questions. Here, the condition checks whether the return of the async pipe is true, and therefore whether the return value is different from any value considered false in javascript.

This condition will work really well if the return is an object or an array.

but if the return is a number and particularly the number 0

@if(((numbers$ |async) !=== undefined || (numbers$ |async) !=== null) ; as myNumber){
  <div>{{ myNumber }}</div>
}

This is where @let comes in.

@let doesn't check a condition, it just allows you to declare a local template variable in a simple way

so the code example above becomes much simpler and more elegant to write

@let myNumber = (numbers$ | async) ?? 0;
<div>{{ myNumber }}</div>

This way the myNumber variable will always be displayed.

The different ways of using @let

One of the most classic scenarios with variable declaration is to store the result of a complex expression.

It has always been inadvisable to use a function in a condition. The use of a function in a condition had an impact on performance in the sense that at the slightest mouse movement, or change in the template, the function was re-evaluated.

@let, as described above, does not evaluate, but simply declares a local variable. This variable will be reevaluated only if one of its dependencies changes. So calling a function is not a bad idea for expressions such as complex expression.

<ul>
  @for(user of users(); track user.id) {
    @let isAdmin = checkIfAdmin(user);
   <li>User is admin: {{ isAdmin }}</li>
  }
</ul>

Use the @let with signals

@let is compatible with signals, and is used as follows

@let userColor = user().preferences?.colors?.primaryColor || 'white';
<span>user favorite color is {{ userColor }}</span>

@let and javascript expression

As you can see, @let can be used to evaluate any kind of javascript expression, apart from, for example, the instantiation of a class

In this way, arithmetic operators are interpreted and several variables can be declared on several different lines or just on one line.

<div>  
    @for (score of scores(); track $index) {
        @let total = total + score, max = calcMax(score);
        <h1>final score: {{ total }}</h1>
    }
</div>

Other cool things that @let brings

As described above, the behaviour of @let is very similar to the behaviour of let in javascript, which has the following benefits

the scope works like the let scope in javascript
better typing interference in the template
an error is raised if a variable (let) is used before being declared

What'new in Angular 18

Nicolas Frizzarin — Tue, 28 May 2024 08:10:07 +0000

Introduction

Wednesday May 22, 2024, the Angular core team releases a new version of Angular: version 18.

This version not only stabilizes the latest APIs, but also introduces a number of new features designed to simplify use of the framework and improve the developer experience.

What are these new features? Read on to find out.

New Control flow syntax is now stable

When the latest version of Angular was released, a new way of managing the flow of a view was introduced. As a reminder, this new control flow is directly integrated into the Angular template compiler, making the following structural directives optional:

ngIf
ngFor
ngSwitch / ngSwitchCase

<!-- old way -->
<div *ngIf="user">{{ user.name }}</div>

<!-- new way -->
@if(user) {
  <div>{{ user.name }}</div>
}

This new API is now stable, and we recommend using this new syntax.

If you'd like to migrate your application to this new control flow, a schematics is available.

ng g @angular/core:control-flow

Also, the new @for syntax, which replaces the ngFor directive, obliges us to use the track option to optimize the rendering of our lists and avoid their total recreation during a change.

Two new warnings have been added in development mode:

a warning if the tracking key is duplicated. This warning is raised if the chosen key value is not unique in your collection.
a warning if the tracking key is the entire item and the choice of this key results in the destruction and recreation of the entire list. This warning will appear if the operation is considered too costly (but the bar is low).

Defer syntax is now stable

The @defer syntax, also introduced in the latest version of Angular, lets you define a block to be lazyloaded when a condition is met. Of course, any third-party directive, pipe or library used in this block will also be lazyloaded.

Here's an example of its use


@defer(when user.name === 'Angular') {
  <app-angular-details />
}@placeholder {
  <div>displayed until user.name is not equal to Angular</div>
}@loading(after: 100ms; minimum 1s) {
  <app-loader />
}@error {
  <app-error />
}

As a reminder,

the @placeholder block will be displayed as long as the @defer block condition is not met
the @loading block will be displayed when the browser downloads the content of the @defer block; in our case, the block loading will be displayed if the download takes more than 100ms, and will be displayed for a minimum duration of 1 second.
the @error block will be displayed if an error occurs while downloading the @defer block

What will happen to Zone js

Angular 18 introduces a new way of triggering a detection change. Previously, and not surprisingly, the detection change was handled entirely by Zone Js. Now, the detection change is triggered directly by the framework itself.

To make this feasible, a new change detection scheduler has been added to the framework (ChangeDetectionScheduler) and this scheduler will be used internally to raise a change detection. This new scheduler is no longer based on Zone Js and is used by default with Angular version 18.

This new scheduler will raise a detection change if

a template or host listener event is triggered
a view is attached or deleted
an async pipe receives a new value
the markForCheck function is called
the value of a signal changes etc.

Small culture moment: this detection change is due to the call to the ApplicationRef.tick function internally.

As I mentioned above, since version 18 Angular has been based on this new scheduler, so when you migrate your application, nothing should break in the sense that Angular will potentially be notified of a detection change by Zone Js and/or this new scheduler.

However, to return to the pre-Angular 18 behavior, you can use the provideZoneChangeDetection function with the ignoreChangesOutsideZone setter option set to true.

bootstrapApplication(AppComponent, {
  providers: [
    provideZoneChangeDetection({ ignoreChangesOutsideZone: true })
  ]
});

Also, if you wish to rely only on the new scheduler without depending on Zone Js, you can use the provideExperimentalZonelessChangeDetection function.

bootstrapApplication(AppComponent, {
  providers: [
    provideExperimentalZonelessChangeDetection()
  ]
});

By implementing the provideExperimentalZonelessChangeDetection function, Angular is no longer dependent on Zone Js, which makes it possible to

remove the Zone js dependency if none of the project's other dependencies depend on it
remove zone js from polifills in angular.json file

Deprecation of HttpClientModule

Since version 14 of Angular and the arrival of standalone components, modules have become optional in Angular, and now it's time to see the first module deprecated: I've named the HttpClientModule

This module was in charge of registering the HttpClient singleton for your entire application, as well as registering interceptors.

This module can easily be replaced by the provideHttpClient function, with options to support XSRF and JSONP.

This function has a twin sister for testing: provideHttpClientTesting

bootstrapApplication(AppComponent, {
  providers: [
    provideHttpClient()
  ]
});

As usual, the Angular team has provided schematics to help you migrate your application.

When issuing the ng update @angular/core @angular /cli command, a request will be made to migrate the HttpClientModule if used in the application

ng-content fallback

ng-content is an important feature in Angular, especially when designing generic components.

This tag allows you to project your own content. However, this feature had one major flaw. You couldn't give it a default content.

Since version 18, this is no longer the case. You can have content inside the tag that will be displayed if no content is provided by the developer.

Let's take a button component as an example

<button>
  <ng-content select=".icon">
   <i aria-hidden="true" class="material-icons">send</i>
  </ng-content>
  <ng-content></ng-content>
</button>

The icon send will be displayed if no element with the icon class is provided when using the button component

Form Events: a way to group the event of the form

It's a request that was made by the community a long time ago: to have an api to group together the events that can happen in a form; and when I say events, I mean the following events

pristine
touched
status change
reset
submit

Version 18 of Angular exposes a new event property from the AbstractControl class (allowing this property to be inherited by FormControl, FormGroup and FormArray), which returns an observable

@Component()
export class AppComponent {
  login = new FormControl<string | null>(null);

  constructor() {
   this.login.events.subscribe(event => {
    if (event instanceof TouchedChangeEvent) {
        console.log(event.touched);
      } else if (event instanceof PristineChangeEvent) {
        console.log(event.pristine);
      } else if (event instanceof StatusChangeEvent) {
        console.log(event.status);
      } else if (event instanceof ValueChangeEvent) {
        console.log(event.value);
      } else if (event instanceof FormResetEvent) {
        console.log('Reset');
      } else if (event instanceof FormSubmitEvent) {
        console.log('Submit');
      }
   })
  }
}

Routing: redirect as a function

Before the latest version of Angular, when you wanted to redirect to another path, you used the redirectTo property. This property took as its value only a character string

const routes: Routes = [
  { path: '', redirectTo: 'home', pathMath: 'full' },
  { path: 'home', component: HomeComponent }
];

It is now possible to pass a function with this property. This function takes ActivatedRouteSnapshot as a parameter, allowing you to retrieve queryParams or params from the url.
Another interesting point is that this function is called in an injection context, making it possible to inject services.

const routes: Routes = [
  { path: '', redirectTo: (data: ActivatedRouteSnapshot) => {
    const queryParams = data.queryParams
    if(querParams.get('mode') === 'legacy') {
      const urlTree = router.parseUrl('/home-legacy');
      urlTree.queryParams = queryParams;
      return urlTree;
    }
    return '/home';
  }, pathMath: 'full' },
  { path: 'home', component: HomeComponent },
  { path: 'home-legacy', component: HomeLegacyComponent }
];

Server Side Rendering: two new awesome feature

Angular 18 introduces two important and much-awaited new server-side rendering features

event replay
internationalization

Replay events

When we create a server-side rendering application, the application is sent back to the browser in html format, displaying a static page that then becomes dynamic thanks to the hydration phenomenon. During this hydration phase, no response to an interaction can be sent, so user interaction is lost until hydration is complete.

Angular is able to record user interactions during this hydration phase and replay them once the application is fully loaded and interactive.

To unlock this feature, still in developer preview, you can use the ServerSideFeature withReplayEvents function.

providers: [
  provideClientHydration(withReplayEvents())
]

Internationalization

With the release of Angular 16, Angular has changed the way it hydrates a page. Destructive hydration has given way to progressive hydration. However, an important feature was missing at the time: internationalization support. Angular skipped the elements marked i18n.

With this new version, this is no longer the case. Please note that this feature is still in development preview and can be activated using the withI18nSupport function.

providers: [
  provideClientHydration(withI18nSupport())
]

Internationalization

Angular recommends using the INTL native javascript API for all matters concerning the internationalization of an Angular application.

With this recommendation, the function helpers exposed by the @angular/common package have become deprecated. As a result, functions such as getLocaleDateFormat, for example, are no longer recommended.

A new builder package and deprecation

Up until now, and since the arrival of vite in Angular, the builder used to build the Angular application was in the package: @angular-devkit/build-angular

This package contained Vite, Webpack and Esbuild. A package that's far too heavy for applications that in future will use only Vite and Esbuild.

With this potential future in mind, a new package containing only Vite and Esbuild was created under the name @angular/build

When migrating to Angular 18, an optional schematic can be run if the application does not rely on webpack (e.g. no Karma-based unit testing). This schematic will modify the angular.json file to use the new package and update the package.json by adding the new package and deleting the old one.

Importantly, the old package can continue to be used, as it provides an alias to the new package.

Angular supports Less Sass Css and PostCss out of the box, by adding the necessary dependencies in your project's node_modules.

However, with the arrival of the new @angular/build package, Less and PostCss become optional and must be explicit in the package.json as dev dependencies.

When you migrate to Angular 18, these dependencies will be added automatically if you wish to use the new package.

No more donwleveling async/await

Zone js does not work with the Javascript feature async/await.
In order not to restrict the developer from using this feature, Angular's CLI transforms code using async/await into a "regular" Promise.

This transformation is called downleveling, just as it transforms Es2017 code into Es2015 code.

With the arrival of applications no longer based on Zone Js, even if this remains experimental for the moment, Angular will no longer downlevel if ZoneJs is no longer declared in polyfills.
The application build will therefore be a little faster and a little lighter.

An new alias: ng dev

From now on, when the ng dev command is run, the application will be launched in development mode.

In reality, the ng dev command is an alias for the ng serve command.

This alias has been created to align with the Vite ecosystem, particularly the npm run dev command.

Future

Once again, the Angular team has delivered a version full of new features that will undoubtedly greatly enhance the developer experience and show us that Angular's future looks bright.

What can we expect in the future?

Undoubtedly continued improvements in performance and developer experience.

We'll also see the introduction of signal-based forms, signal-based components and, very soon, the ability to declare template variables using the @let block.

Be ready for input signals in Angular

Nicolas Frizzarin — Wed, 10 Jan 2024 08:34:36 +0000

Introduction

With the release of Angular 17, the signals have become stable.

As a reminder, a signal is a wrapper around a value that can notify interested consumers when that value changes. Signals can contain any value, from simple primitives to complex data structures.

At present, the core team has only delivered the basic signals api. But its long-term goal is to go much further, and achieve signal change detection.

The next step is to have input and output based on signals. And this functionality should appear very soon this month with version 17.1.

How can we prepare for this functionality to facilitate the migration of our current Input and Output?

A litte reminder

Before getting straight to the heart of the matter, a quick reminder may be in order.

A signal is created using the signal function.

const name = signal<string | null>('DevTo');

This function returns a WritableSignal, enabling us to modify the value of our signal using the methods:

set
update

const count = signal(0);
count.set(10);
count.update(count => count + 1);

A signal can also be made readonly using the asReadonly function.

const count = signal(0);
const readonlyCount = count.asReadonly();

Why passing a signal as an input is a very bad idea ?

Working with signals in a real application can sometimes become very complicated, especially with components that take inputs.

As a reminder, modifying change detection in OnPush mode with signals improves performance, especially page refresh speed.

When a signal is used in the template of an OnPush component, Angular automatically adds it as a reactive dependency of the component, and each time this signal is modified, Angular will automatically mark the component as dirty, which will ensure that the component is refreshed the next time the change detection is run.

Now let's imagine two components with a parent-child relationship


@Component({
  selector: 'app-father',
  changeDetection: ChangeDetectionStrategy.OnPush,
  standalone: true,
  imports: [AppChildComponent],
  template: `<app-child [name]="name" />`
})
export class AppFatherComponent {
  name = signal('DevTo');
}


@Component({
  selector: 'app-child',
  changeDetection: ChangeDetectionStrategy.OnPush,
  standalone: true,
  template: `{{ name() }}`
})
export class AppFatherComponent {
  @Input({ required: true }) name !: WritableSignal<string>
}

Passing a signal as input to a child component have several problems:

unidirectional binding is lost
you force the parent to use signals
you lose the granularity of the detection change

Unidirectional binding and granularity of the detection change

When we pass a signal as input, we don't pass the value of the signal but actually its reference.

It therefore becomes normal that if the signal is modified in the child, the parent is also impacted, so a detection change cycle will have to be lifted in both the parent and the child.

An Angular application is nothing more than a tree of components, so by passing signals as input, no matter whether the component is OnPush or not, each modification of the signals in the child components will automatically trigger a change of detections in the parent, thus losing the added value of the OnPush mode.

What's more, by passing a signal as input, the logic of data centralization is totally lost, as any descendant of a parent component can modify the variable, and in the event of a bug we end up with a spaghetti node that's very complex to debug.

Force the parent to use signals

One of the workarounds used to avoid the above problems would be to switch the signals to readonly mode.

Apart from being unsightly and an anti-pattern, this would force the parent component to use signals. In other words, all inputs passed to child components must be signals.

Which makes no sense, as the parent component should be able to pass simple variables to its children.
What's more, when input signals arrive, all the code will have to be refactored.

Input as a setter for the win

In Angular, inputs can be setters. This will help you to create signal-based inputs.

This technique will avoid the problems analyzed above, but there may well be a few more boilerplates while we wait for release 17.1.

The idea is to transform all our Inputs into an aliased Input setter and create the signal associated with this input.

Let's take the example above


@Component({
  selector: 'app-father',
  changeDetection: ChangeDetectionStrategy.OnPush,
  standalone: true,
  imports: [AppChildComponent],
  template: `<app-child [name]="name" />`
})
export class AppFatherComponent {
  name = signal('DevTo');
}


@Component({
  selector: 'app-child',
  changeDetection: ChangeDetectionStrategy.OnPush,
  standalone: true,
  template: `{{ name() }}`
})
export class AppFatherComponent {
  @Input({ required: true, alias: 'name' }) set _name(name: string) {
    this.name.set(name);
  }
  name = signal<string>('');
}

With this method, the parent component is totally flexible on the type of variable passed to child components, unidirectional binding is respected and migration to signal inputs is simplified.

In fact, with version 17.1, all you need to do is remove the input setter and replace the signal function with the input function

Inputs Signal

Input signals are declared using the input function

This function not only creates readonly signals, but also ensures that the metadata passed to the input annotation is not lost.

const name = input<string>(''); // input with default value
const name = input<string>(); // input with no default value
const name = input.required<string>() // input mandatory
const name = input<string>('', { alias: 'lastname' }); // with alias
const isLoading = input<string | boolean; boolean>('', { transform: booleanAttribute });

If we go back to our previous example, the code would be as follows:


@Component({
  selector: 'app-father',
  changeDetection: ChangeDetectionStrategy.OnPush,
  standalone: true,
  imports: [AppChildComponent],
  template: `<app-child [name]="name" />`
})
export class AppFatherComponent {
  name = signal('DevTo');
}


@Component({
  selector: 'app-child',
  changeDetection: ChangeDetectionStrategy.OnPush,
  standalone: true,
  template: `{{ name() }}`
})
export class AppFatherComponent {
  name = input.required<string>();
}

What will happen in the future ?

Based on this shema, reactivity and change of detection within Angular will take place around signals.

In a few months' time, we hope to be able to do without ZoneJs with OnPush components that use signals, as well as creating components based signals like this

@Component({
  selector: 'app-father',
  changeDetection: ChangeDetectionStrategy.OnPush,
  standalone: true,
  signals: true,
  imports: [AppChildComponent],
  template: `<app-child [name]="name" />`
})
export class AppFatherComponent {
  name = signal('DevTo');
}

What's new in Angular 17

Nicolas Frizzarin — Thu, 16 Nov 2023 08:00:10 +0000

Introduction

Angular version 17 was released on November 8, 2023, and this application sounds like an hour of rebirth for the framework, which dates back to September 2016.

First and foremost, while we're talking about rebirths, we're not talking about a complete rewrite of the framework. We're talking about adding major functionalities that use the latest browser features and make the framework even more powerful.

The questions that remain are: How is this release a major turning point for Angular? What makes this release so exceptional?

A new Branding

After a few days where the Angular logo had disappeared, replaced by a question mark on social networks such as X to name but the most famous, on Monday November 6, the Angular team announced a new Logo but also a brand new documentation site available here.

This brand-new site (still under construction in terms of APIs) brings many improvements, such as:

the ability to experiment with features in a sandbox
new tutorials with the option of creating them in a sandbox
a brand-new organization by theme (component, form, accessibility, best practices, etc.).

Don't hesitate to give it a try, and report any questions or errors you come across.

The @Component annotation

The @Component anotation has been improved. Since the beginning of Angular, it has been mandatory to pass a style array or an array of relative stylesheet paths to bind style to our components.

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.css']
})
export class AppComponent {}

In general, a view is linked to a style sheet.

a new property is introduced: styleUrl
the styles property takes as its value a string or an array of strings

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrl: './app.component.css'
})
export class AppComponent {}

The new Application builder

Angular has always had different builders to build our applications. There are two main types of Angular application:

client-side rendering: the entire application is built client-side. In other words, the application is represented in DOM (Document Object Model) format. Navigation, data fetching and templating are managed client-side instead of server-side.
server side rendering: the application is rendered in HTML format, each page of the application is rendered in HTML format in response to navigation, and then this page is rehydrated to make it dynamic.

Depending on the type of application, the builder was different.
Angular used the builder:

@angular-devkit/build-angular:browser to build a client-side rendering application
@nguniversal/builders:ssr-dev-server to build a server-side rendering application.

With the arrival of Angular 16, a new experimental builder has appeared:
@angular-devkit/build-angular:browser-esbuild. This builder made it possible to use vite for the dev-server and esbuild for the build, and offered outstanding performance:

87% gain on an application build
82% gain on a dev-server of the application

However, the builder for server rendering had not changed.
With the arrival of Angular 17, a brand-new "generic" builder has appeared. This builder allows you to build both a client-side rendering application and a server-side rendering application.
A round of applause for the builder:
@angular-devkit/build-angular:application

For existing applications using the builder: @angular-devkit/build-angular:browser-esbuild, migration to the new builder is relatively straightforward.

For server-side rendering applications, migration is a little more complex due to the number of properties to be changed.

The new Angular Code Flow

The release of Angular 17 also sees the arrival of a new, more powerful flow code.
In previous versions, we used structural directives ngIf, ngSwitch, ngFor to manage the structure of our page.
Structural directives are very powerful, thanks to the mycrosyntax of which they are composed. Unfortunately, this mycrosyntax has its limits, and so a new flow code was created.

What does this code flow look like?

@Component({
  standalone: true,
  selector: 'app-root',
  template: `
    @if(name === 'SFEIR'){
      <ul>
         @for(entity of entities; track entity.id) {
           <li>{{ entity.name }}</li>
         }@empty {
           No data
         }
      </ul>

    }@else {
      Name not correct
    }
  `
})
export class AppComponent {
  name = 'SFEIR';
  entities = [{ name: 'Luxembourg', id: 'LU' }];
}

As the code shows, there's no need to import the ngIf and ngFor directives. This new code flow is build-in to Angular and will enable simpler integration of components based on Angular signals.

Structural directives are not deprecated and there are no plans to make them deprecated.
In future, only the ngIf, ngFor and ngSwitch directives are likely to be deprecated.

If you want to automatically migrate your components to the new code flow, this schematic will be your best friend

ng g @angular/core:control-flow

Warning: This new flow code is very recent, so you may encounter some formatting problems. (prettier 3.1 now supports this code flow)

IDEs:

VsCode with Angular Language Service plugins already supports syntax highlighting
Webstorm EAP also supports syntax highlighting. Unfortunately, template checking is not yet supported, but will be shortly.

The most waited feature: defer

Probably one of the most important features of this release. The ability to lazyload our components easily.

Of course, we could do this before. Thanks to EsModules and the *ngComponentOutlet structural directive, it was possible to lazyload our components. However, this technique remains a source of error, in the sense that the developer has to think about the whole loading process (loading, error, etc.) and is limited in scope (complicated prefetching, etc.). In short, the developer experience wasn't there.

With Angular 17, defer comes to the rescue, making it easy to lazyload our components by taking into account all the stages of lazyloading.

@Component({
  selector: 'app-root',
  template: `
    <button type="button" #loadButton>Click Me</button>
    @defer(on interaction(loadButton)) {
      <app-lazy-component />
    }@placeholder {
      showed until the chunk file not begin to load
    }@loading {
      showed during the loading of the chunk
    }@error {
      showed if an error happen during loading
    }
  `
})
export class AppComponent {}

There are many other options for defer, placeholder, loading. To get the most out of this feature, I recommend Tomas Trajan's fabulous article here.

Like all good things, you mustn't abuse it. Depending on your needs, defer should be applied in certain ways. As a general rule, defer will depend mainly on your network and the size of the component to be lazyloaded. Last but not least, this feature will be invaluable for optimizing Core Web Vitals' LCP and CLS metrics.

A little word about Signals

Signal was released as a developer preview with Angular 16. With Angular 17, Signal is stable and can be used.
Combined with the ChangeDetection.OnPush option, you'll operate a very precise reactivity, allowing you to refresh only the component whose signal has been modified.

The mutate method on signals is no longer available.

Effects are still in developer preview.

Angular Devtools

Angular Devtools has also been given a very nice little feature 😄 it's now possible to view the injection tree. Very useful for debugging your application when you have circular dependencies, or when a token isn't resolved correctly.

Conclusion

Angular 17 really does bring a lot of new features, and it's in this sense that we're talking about an Angular reborn. Angular 17, like all previous releases, brings no breaking changes, so it's very easy to migrate an application from Angular 16 to Angular 17.

You don't have to use all these new features; they're available for developers to try out.

Angular: How to test functional guards, resolver and intercpetors

Nicolas Frizzarin — Wed, 16 Aug 2023 08:00:48 +0000

Introduction

Since version 14 of Angular, the inject function can be used outside the injection context, making it easier to compose screens and transform gards, resolvers and interceptors into simple functions.

However, testing a service in the form of classes is much more straightforward than testing a function in which the inject function is used.

This article looks at testing of guards, resolvers and interceptors as functions.

Injector level

To understand how to properly test our guards, etc. as functions, it's important to understand how injection works and how the value of a service is retrieved.

In Angular, there are different types of injector, or to be more precise, different levels of injector:

Element Injector: This is the injector at the component level for exemple.

@Component({
  template: '',
  providers: [UserService]
})
export class UserComponent {}

module injector: This is the injector specific to the module.

@NgModule({
  declarations: [UserComponent],
  providers: [UserService]
})
export class UserModule {}

Environment Injector: Now Angular introduced a new class called EnvironmentInjector. Thanks to that we are able to make an injection wherever we want. They expect this functionality to be very useful for designing ergonomic APIs.
There is something we need to not forget. EnvironmentInjector is completely independent from Component tree. It’s a module injector, so it can’t inject anything that is not in module or router.
Root Injector: This is the top level of injector. Provider register in the root injector is accessible everywhere in the application

@Injectable({ provideIn: 'root'})
export class UserService {}

When a service is called in a component, Angular will attempt to resolve the value of that service by performing injector bubbling as follows

If the service is not found in any injector, Angular will raise an error specifying that it has failed to resolve the value of the requested service.

Test your functional guard, resolver, interceptors

What's difficult to test in guards written as functions is not the function itself, but the inject function used within it.

Example:

export function UserDetailsResolver(
route: ActivatedRouteSnapshot): Observable<User> {
  const userService = inject(UserService);
  return userService.getUserDetails(route.paramMap.get('id'))
}

If we want to be able to test our function correctly, we'll need to be able to call it in an injection context (and therefore implicitly create an environment injector).

In the application context, to carry out this type of process, the function to use is the runInInjectionContext function.

runInInjectionContext(injector, () => {});

This function takes the following parameters

the injector in which the value of the service you wish to resolve with the inject function is located
the function to run in the injector context

Typically, this is exactly the function you'd use to mock the injection of the UserService service.

However, our context is a little different in that it's the test context and not the application context.

Once again, Angular has thought of everything, and this same function can be found in tests using the TestBed class.

If you wish to use the runInjectionContext function, you must create an injection context.

const MOCK_USER_SERVICE = {
  getUserDetails: jest.fn(),
};

const MOCK_ROUTE = {
  paramMap: new Map(['id', 123]),
};

describe('UserDetailsResolver', () => {
  let service: UserService;

  beforeEach(waitForAsync(() => {
    TestBed.configureTestingModule({
      providers: [{ provide: UserService, useValue: MOCK_USER_SERVICE }]
    });

    service = TestBed.inject(UserService);
  }));

  test('should create an instance of UserService', () => {
    expect(service).toBeInstanceOf(Userservice);
  });
});

Once the injection context is set, simply call the guard function in the injection context.

test('should return the details of the user', fakeAsync(() => {
  MOCK_USER_SERVICE.getUserDetails.mockResolvedValue(of({ name: 'Nicolas' }));

  let user: User | null = null;

  const resolver: Observable<User> = TestBed.runInInjectionContext(() => {
    return UserDetailsResolver(MOCK_ROUTE);
  });

  resolver.subscribe(response => (user = response));
  tick();

expect(MOCK_USER_SERVICE.getUserDetails).toHaveBeenCalledTimes(1);
expect(MOCK_USER_SERVICE.getUserDetails).toHaveBeenCalledWith(123);
expect(user).toEqual({ name: 'Nicolas' })
});

The return type of the runInjectionContext function corresponds to the return type of the function called in the injection context.

 runInInjectionContext<T>(fn: () => T): T

In our case, the return type of the UserDetailsResolver function is an Observable.

To summarize, the test file corresponding to the UserDetailsResolver function is as follows:

const MOCK_USER_SERVICE = {
  getUserDetails: jest.fn(),
};

const MOCK_ROUTE = {
  paramMap: new Map(['id', 123]),
};

describe('UserDetailsResolver', () => {
  let service: UserService;

  beforeEach(waitForAsync(() => {
    TestBed.configureTestingModule({
      providers: [{ provide: UserService, useValue: MOCK_USER_SERVICE }]
    });

    service = TestBed.inject(UserService);
  }));

  test('should create an instance of UserService', () => {
    expect(service).toBeInstanceOf(Userservice);
  });
  test('should return the details of the user', fakeAsync(() => {
  MOCK_USER_SERVICE.getUserDetails.mockResolvedValue(of({ name: 'Nicolas' }));

  let user: User | null = null;

  const resolver: Observable<User> = TestBed.runInInjectionContext(() => {
    return UserDetailsResolver(MOCK_ROUTE);
  });

  resolver.subscribe(response => (user = response));
  tick();
expect(MOCK_USER_SERVICE.getUserDetails).toHaveBeenCalledTimes(1);
expect(MOCK_USER_SERVICE.getUserDetails).toHaveBeenCalledWith(123);
  expect(user).toEqual({ name: 'Nicolas' })
  });
});

In this article, the example corresponds to a resolver written as a function.
Interceptors and guards written as functions use exactly the same concepts as the resolver shown as an example in this article. The method used to test them will therefore be the same as that used to test the example resolver.

DEV Community: Nicolas Frizzarin

INP and Partytown: give the main thread back to your users

Introduction

INP in a few words

What's inside an interaction?

The main thread: a one lane road

Partytown: move the party somewhere else

How does it work?

Option 1: Service Worker (the fallback)

Option 2: Atomics (the fast one)

The two rules to remember

Angular

Step 1: install

Step 2: serve the Partytown files

Step 3: index.html

Step 4: an analytics service

Step 5: track a click

React

Step 1: install and copy the files

Option A: client-side app (Vite)

Option B: server-rendered app (the <Partytown /> component)

Scripts added later

Track page views and clicks

Check that it works

Where INP really wins

Trade-offs: no magic here

Measure, don't guess

Partytown won't fix your own code

Conclusion

Route Resources in Angular: what the Router actually does with your Signal under the hood

Introduction

Turning it on

Defining resources on a route

Blocking vs non-blocking, and what actually gets bound to your input

What routerResource() actually wraps

The frozen snapshot: why navigating doesn't flash a loading spinner

Rollback recovery: the part almost nobody thinks about

Why reload() sometimes just returns false

Redirecting from inside a loader

Where this gets uncomfortable

Wrapping up

Web MCP: give some tools to your agent

Introduction

What is WEBMCP?

Difference between WebMCP | MCP | Automation

Backend MCP

Browser Automation

WebMCP

When to use what: rules to apply.

How to use WEBMCP

Defining tools using the Imperative API

Defining Form tool with the Declarative API

Security

Conclusion

Angular Signals Form: Validation and Logic

Introduction

Just a reminder

Adding Field Logic

Let's have some logic

The validate function

The error function

Composition built-in

Conclusion

Signals Form: Introduction

Introduction and Disclaimer

Mindset of Signal Forms

A tree of Field

Field Instance

Binding the field to UI elements

Conclusion

The Next Generation of Dynamic Component

Préambule

Introduction

NgComponentOutlet: Declarative way to dynamic component creation

The update of createComponent function

Conclusion

The next improvement in Angular reactivity

Introduction

Process of resetting one signal relative to another

The LinkedSignal function to the rescue.

Step 3: `index.html`

Option B: server-rendered app (the `<Partytown />` component)

What `routerResource()` actually wraps

Why `reload()` sometimes just returns `false`

The `validate` function

The `error` function