DEV Community: Suguru Inatomi

Angular: Router Resources Explained

Suguru Inatomi — Sun, 11 Oct 2026 12:18:00 +0000

Router Resources, released in Angular v22.2, is the long-awaited full-scale integration API for the Router and Signals. In this article, I will explain its basic usage through specific use cases.

How to Use Router Resources

Blocking Data Fetching During Navigation

The most typical use case is fetching data during a Router navigation and waiting for the data to be ready before moving to the page. Until now, Observable/Promise-based data resolvers handled this, but an intuitive Signal-based API has been introduced to take over the same role. Let’s look at a concrete comparison between the old and new code.

Take the case of fetching user data using an ID in the URL path during page navigation. Conventionally, you would declare a resolver function like this, and the component would receive the already fetched user data.

// app.config.ts
import { ApplicationConfig } from '@angular/core';
import { provideRouter, withComponentInputBinding } from '@angular/router';
import { routes } from './app.routes';

export const appConfig: ApplicationConfig = {
  providers: [provideRouter(routes, withComponentInputBinding())],
};

// app.routes.ts
import { ResolveFn, Routes } from '@angular/router';
import { UserProfile } from './user-profile';
import { User, UserService } from './user.service';

const userResolver: ResolveFn<User> = (route) => {
  const userService = inject(UserService);
  const userId = route.paramMap.get('id')!;
  return userService.getUser(userId);
};

export const routes: Routes = [
  {
    path: 'users/:id',
    component: UserProfile,
    resolve: { user: userResolver },
  },
];

The component receives the fetched User as an input signal via withComponentInputBinding. This is typical data fetching during navigation using a data resolver.

// user-profile.ts
import { Component, input } from '@angular/core';
import { User } from './user.service';

@Component({
  selector: 'app-user-profile',
  template: `
    <h2>{{ user().name }}</h2>
  `,
})
export class UserProfile {
  readonly user = input.required<User>();
}

Rewriting this with Router Resources looks like the following. First, to use Router Resources, add withRouterResources() to the Router configuration. Then, declare a function in the Route.resources property instead of a data resolver. This function takes a ResourceContext object as an argument and returns a key-value object of resources. ResourceContext holds various parameters as Signals; for example, ctx.params() is a Signal containing the path parameters. Since the resolved value() of the resource is passed to the component, the code remains exactly the same as in the data resolver case and requires no changes.

// app.config.ts
import { ApplicationConfig } from '@angular/core';
import {
  provideRouter,
  withComponentInputBinding,
  withRouterResources,
} from '@angular/router';
import { routes } from './app.routes';

export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(
      routes,
      withComponentInputBinding(),
      withRouterResources(), // Added
    ),
  ],
};

// app.routes.ts
import { inject, resource } from '@angular/core';
import { Routes } from '@angular/router';
import { UserProfile } from './user-profile';
import { UserService } from './user.service';

export const routes: Routes = [
  {
    path: 'users/:id',
    component: UserProfile,
    resources: (ctx) => {
      const userService = inject(UserService);
      return {
        user: resource({
          params: () => ctx.params()['id'] as string,
          loader: ({ params: id }) =>
            userService.getUser(id),
        }),
      };
    },
  },
];

In this example, the data resolver was replaced by Router Resources, but if it were just about replacement, a new API wouldn’t be necessary. From here, let’s look at the advantages that only Router Resources can offer.

Non-blocking Data Fetching

The behavior of a data resolver is blocking , meaning it navigates to the page only after the data fetch is complete. While this helps in ensuring state consistency before reaching a page that needs data, it has several drawbacks. One is a user experience issue where data fetching must be waited for on the previous page, making it feel as though the screen has frozen. It is difficult to manage waiting time with skeletons or loading UIs. Another issue is the fragmentation of code. Since data resolvers are always blocking, fetching non-blocking data ends up being written on the component side. Even though it is the same concern—data fetching associated with page navigation—the code gets scattered.

Router Resources allows you to choose whether data fetching should be blocking or non-blocking. This allows data fetching code associated with Router-dependent page transitions to be centralized in one place. Let’s look at it concretely.

Unlike the previous example, let’s display a loading indicator while fetching user data, an error message if it fails, and the user info once fetched. With the conventional API, the component would receive the path parameter as an input signal via withComponentInputBinding, and it would also be the component’s responsibility to create a resource using that parameter.

// user-profile.ts
import { Component, inject, resource } from '@angular/core';
import { UserService } from './user.service';

@Component({
  template: `
    @if (userResource.isLoading()) {
      <p>Loading...</p>
    } @else if (userResource.error()) {
      <p>Failed to load user.</p>
    } @else if (userResource.value(); as user) {
      <h2>{{ user.name }}</h2>
      <p>ID: {{ user.id }}</p>
    }
  `,
})
export class UserProfile {
  private readonly userService = inject(UserService);
  private readonly id = input.required<string>(); // users/:id

  readonly userResource = resource({
    params: () => this.id(),
    loader: ({ params: id }) =>
      this.userService.getUser(id),
  });
}

// app.routes.ts
import { Routes } from '@angular/router';
import { UserProfile } from './user-profile';

export const routes: Routes = [
  { path: 'users/:id', component: UserProfile },
];

With Router Resources, it looks like this. You create the resource in the resources function of the route configuration, but unlike the previous example, you wrap the resource with the nonBlocking function. By doing this, the component receives not the value() fetched by the resource, but the resource object itself. In other words, it receives not user but userResource.

// app.routes.ts
import { inject, resource } from '@angular/core';
import { nonBlocking, Routes } from '@angular/router';
import { UserProfile } from './user-profile';
import { UserService } from './user.service';

export const routes: Routes = [
  {
    path: 'users/:id',
    component: UserProfile,
    resources: (ctx) => {
      const userService = inject(UserService);
      return {
        userResource: nonBlocking(
          resource({
            params: () => ctx.params()['id'] as string | undefined,
            loader: ({ params: id }) =>
              userService.getUser(id),
          }),
        ),
      };
    },
  },
];

The component receives the resource object as an input signal from the start. Since the resource object also holds the data fetching state and errors, it can handle UI changes according to the state, just like before. It’s also worth noting that the concern regarding data fetching has disappeared from the component, and the dependency on the service has been eliminated. Through Router Resources, a component can achieve a higher level of separation as a presentation layer. The internal details of how data is fetched are encapsulated behind the resource.

// user-profile.ts
import { Component, input, Resource } from '@angular/core';
import { User } from './user.service';

@Component({
  template: `
    @let res = userResource();
    @if (res.isLoading()) {
      <p>Loading...</p>
    } @else if (res.error()) {
      <p>Failed to load user.</p>
    } @else if (res.value(); as user) {
      <h2>{{ user.name }}</h2>
      <p>ID: {{ user.id }}</p>
    }
  `,
})
export class UserProfile {
  readonly userResource = input.required<Resource<User | undefined>>();
}

Parallel Execution of Data Fetching Across Parent and Child Routes

Another advantage of Router Resources is the ability to execute data fetching across multiple routes in parallel. Data resolvers are executed sequentially from the parent route to the child route. Even if the data fetches have no dependencies on each other, the child must wait for the parent to complete.

Let’s take a page that displays a user profile and a list of posts as an example. The parent route fetches the user information, and the child route fetches that user’s list of posts. Both can be fetched as long as the ID from the URL is known; there’s no need to wait for the user info fetch to complete to fetch the post list.

// app.routes.ts
import { inject } from '@angular/core';
import { ResolveFn, Routes } from '@angular/router';
import { UserPage } from './user-page';
import { UserPosts } from './user-posts';
import { User, UserService } from './user.service';
import { Post, PostService } from './post.service';

const userResolver: ResolveFn<User> = (route) => {
  const userService = inject(UserService);
  const userId = route.paramMap.get('id')!;
  return userService.getUser(userId);
};

const postsResolver: ResolveFn<Post[]> = (route) => {
  const postService = inject(PostService);
  const userId = route.paramMap.get('id')!;
  return postService.getPosts(userId);
};

export const routes: Routes = [
  {
    path: 'users/:id',
    component: UserPage,
    resolve: { user: userResolver },
    children: [
      {
        path: '',
        component: UserPosts,
        resolve: { posts: postsResolver },
      },
    ],
  },
];

UserPage displays the user information and a RouterOutlet, inside which UserPosts displays the list of posts. Since a child route with an empty path inherits the parent’s path parameters, the same id can be used in the child. As in the previous examples, the component receives the fetched user and posts via withComponentInputBinding. In this setup, if fetching user information takes 200ms and fetching the post list takes 300ms, the total wait time for data fetching would be 500ms.

Replacing this with Router Resources looks like the following. Router Resources loads resources for the parent and child routes that match the destination in parallel. Since the fetching of user info and the post list proceeds in parallel, in the previous example, the total wait time for data fetching would not be 500ms, but around 300ms, which is the duration of the slower one.

// app.routes.ts
import { inject, resource } from '@angular/core';
import { ResourceContext, Routes } from '@angular/router';
import { UserPage } from './user-page';
import { UserPosts } from './user-posts';
import { UserService } from './user.service';
import { PostService } from './post.service';

const userResource = (ctx: ResourceContext) => {
  const userService = inject(UserService);
  return resource({
    params: () => ctx.params()['id'] as string,
    loader: ({ params: id }) =>
      userService.getUser(id),
  });
};

const postsResource = (ctx: ResourceContext) => {
  const postService = inject(PostService);
  return resource({
    params: () => ctx.params()['id'] as string,
    loader: ({ params: id }) =>
      postService.getPosts(id),
  });
};

export const routes: Routes = [
  {
    path: 'users/:id',
    component: UserPage,
    resources: (ctx) => ({ user: userResource(ctx) }),
    children: [
      {
        path: '',
        component: UserPosts,
        resources: (ctx) => ({ posts: postsResource(ctx) }),
      },
    ],
  },
];

Appendix: Depending on a Parent Route’s Resource

Consider a case where a child route fetches a post list using an organization ID included in the user information fetched by the parent route. In this case, the fetching criteria cannot be determined by URL parameters alone; the child depends on the parent’s resource. As of v22.2.0, Router Resources does not have an API to reference a parent route’s resource from the context of the resources function, but PR #70587, which addresses this use case, is currently in development.

In this draft, ResourceContext.resources is exposed to inherit resources from ancestor routes, allowing resources declared in the parent to be retrieved via ctx.resources(). Rewriting the previous postsResource according to this proposal would look like the following. In this example, assume User has an organizationId and the post fetching service accepts that ID.

// app.routes.ts
import { inject, Resource, resource } from '@angular/core';
import { ResourceContext } from '@angular/router';
import { User } from './user.service';
import { PostService } from './post.service';

const postsResource = (ctx: ResourceContext) => {
  const postService = inject(PostService);
  return resource({
    params: ({ chain }) => {
      const userResource = ctx.resources()['user'] as Resource<User | undefined>;
      return chain(userResource)?.organizationId;
    },
    loader: ({ params: organizationId }) =>
      postService.getPostsByOrganization(organizationId),
  });
};

Reloading Without Re-navigation

Consider a scenario where you edit a name in a user list and want to re-fetch the list after saving. Instead of just displaying the saved value, you want to reflect the updated data from the server in the list. In this example, assume UserService.getUsers() returns the list as a Promise<User[]> and saveUser(user) saves the user info and returns a Promise<void>.

If you are fetching the list using a data resolver, re-fetching after saving also requires navigation. You would specify onSameUrlNavigation: 'reload' to handle navigation to the same URL, and runGuardsAndResolvers: 'always' to re-execute the resolver even if the path parameters haven’t changed. With this method, route matching and guard evaluation are also re-executed just to update the list after saving.

// app.routes.ts
import { inject } from '@angular/core';
import { ResolveFn, Routes } from '@angular/router';
import { UserList } from './user-list';
import { User, UserService } from './user.service';

const usersResolver: ResolveFn<User[]> = () => {
  const userService = inject(UserService);
  return userService.getUsers();
};

export const routes: Routes = [
  {
    path: 'users',
    component: UserList,
    resolve: { users: usersResolver },
    runGuardsAndResolvers: 'always',
  },
];

// user-list.ts
import { Component, inject, input } from '@angular/core';
import { Router } from '@angular/router';
import { User, UserService } from './user.service';

@Component({
  template: `
    @for (user of users(); track user.id) {
      <input #name [value]="user.name" />
      <button (click)="saveUser(user, name.value)">Save</button>
    }
  `,
})
export class UserList {
  readonly users = input.required<User[]>();
  private readonly userService = inject(UserService);
  private readonly router = inject(Router);

  async saveUser(user: User, name: string) {
    await this.userService.saveUser({ ...user, name });
    await this.router.navigateByUrl(this.router.url, {
      onSameUrlNavigation: 'reload',
    });
  }
}

With Router Resources, you only need to call reload() on the list’s resource after the save is complete.

// app.routes.ts
import { inject, resource } from '@angular/core';
import { Routes } from '@angular/router';
import { UserList } from './user-list';
import { UserService } from './user.service';

const usersResource = () => {
  const userService = inject(UserService);
  return resource({
    loader: () => userService.getUsers(),
  });
};

export const routes: Routes = [
  {
    path: 'users',
    component: UserList,
    resources: () => ({ users: usersResource() }),
  },
];

// user-list.ts
import { Component, inject, input } from '@angular/core';
import { ActivatedRoute } from '@angular/router';
import { User, UserService } from './user.service';

@Component({
  template: `
    @for (user of users(); track user.id) {
      <input #name [value]="user.name" />
      <button (click)="saveUser(user, name.value)">Save</button>
    }
  `,
})
export class UserList {
  readonly users = input.required<User[]>();
  private readonly userService = inject(UserService);
  private readonly usersResource =
    inject(ActivatedRoute).resources?.['users']!;

  async saveUser(user: User, name: string) {
    await this.userService.saveUser({ ...user, name });
    this.usersResource.reload();
  }
}

In the case of a blocking resource, since only the fetch result is passed to the input signal, the resource object is referenced from ActivatedRoute.resources. The list is re-fetched after waiting for the save to complete, and the change in the fetch result is reflected in the input signal as well. While the saving logic remains on the component side, there is no need to duplicate the list fetching logic.

In the case of a non-blocking resource, you can directly call reload() on the received resource. However, as of 22.2.0, a type corresponding to the resource with the reload method passed by the Router has not been made public. For now, it is probably best to prepare your own type as in the following example.

// user-list.ts
import { Component, inject, input, Resource } from '@angular/core';
import { User, UserService } from './user.service';

type RouteResource<T> = Resource<T> & { reload(): boolean };

@Component({
  template: `
    @let res = usersResource();
    @if (res.isLoading()) {
      <p>Loading...</p>
    } @else if (res.error()) {
      <p>Failed to load users.</p>
    } @else if (res.value(); as users) {
      @for (user of users; track user.id) {
        <input #name [value]="user.name" />
        <button (click)="saveUser(user, name.value)">Save</button>
      }
    }
  `,
})
export class UserList {
  readonly usersResource = input.required<RouteResource<User[] | undefined>>();
  private readonly userService = inject(UserService);

  async saveUser(user: User, name: string) {
    await this.userService.saveUser({ ...user, name });
    this.usersResource().reload();
  }
}

Reactive Data Fetching Based on Query Parameters

Consider updating search results on the same page when changing search criteria. Let the URL of the user search page be /users?q=alice, where the search term is stored in the query parameter q. When the search term changes, the URL becomes /users?q=bob, and search results are updated while continuing to use the same component. In this example, assume UserService.searchUsers(q) returns the search results as a Promise<User[]>.

Conventionally, the component would receive the query parameter as an input signal and hold a resource that uses it as the fetch condition.

// user-search.ts
import { Component, inject, input, linkedSignal, resource } from '@angular/core';
import { form, FormField } from '@angular/forms/signals';
import { RouterLink } from '@angular/router';
import { UserService } from './user.service';

@Component({
  imports: [RouterLink, FormField],
  template: `
    <input type="search" [formField]="searchForm.q" />
    <button [routerLink]="[]" [queryParams]="{ q: searchForm.q().value() }">Search</button>

    @let res = usersResource;
    @if (res.isLoading()) {
      <p>Loading...</p>
    } @else if (res.error()) {
      <p>Failed to load users.</p>
    } @else if (res.value(); as users) {
      @for (user of users; track user.id) {
        <p>{{ user.name }}</p>
      }
    }
  `,
})
export class UserSearch {
  readonly q = input<string>();
  readonly searchForm = form(linkedSignal(() => ({ q: this.q() ?? '' })));
  private readonly userService = inject(UserService);

  readonly usersResource = resource({
    params: () => this.q() ?? '',
    loader: ({ params: query }) =>
      this.userService.searchUsers(query),
  });
}

// app.routes.ts
import { Routes } from '@angular/router';
import { UserSearch } from './user-search';

export const routes: Routes = [
  { path: 'users', component: UserSearch },
];

With Router Resources, the search term is read from ctx.queryParams(), and the resource is wrapped with nonBlocking(). The update of query parameters does not wait for the search to complete, and the resource fetches data in response to changes in the search term.

// app.routes.ts
import { computed, inject, resource } from '@angular/core';
import { nonBlocking, ResourceContext, Routes } from '@angular/router';
import { UserSearch } from './user-search';
import { UserService } from './user.service';

const usersResource = (ctx: ResourceContext) => {
  const userService = inject(UserService);
  const q = computed(() => (ctx.queryParams()['q'] as string | undefined) ?? '');
  return resource({
    params: () => q(),
    loader: ({ params: query }) =>
      userService.searchUsers(query),
  });
};

export const routes: Routes = [
  {
    path: 'users',
    component: UserSearch,
    resources: (ctx) => ({ usersResource: nonBlocking(usersResource(ctx)) }),
  },
];

The component receives the resource as an input signal and displays the fetch state and search results as before. The logic connecting search criteria to data fetching moves to the Router side, and the component no longer depends on the search service.

What’s important here is that the resource uses only the search term’s q parameter as a fetch condition, not the entire set of query parameters. It converts q into a Signal using computed before reading it in the params function. Even if other query parameters for toggling display methods change, as long as q remains the same, neither re-fetching nor re-rendering occurs. The benefit of Signals—fine-grained reactivity—can also be applied to changes in URL state.

// user-search.ts
import { Component, input, linkedSignal, Resource } from '@angular/core';
import { form, FormField } from '@angular/forms/signals';
import { RouterLink } from '@angular/router';
import { User } from './user.service';

@Component({
  imports: [RouterLink, FormField],
  template: `
    <input type="search" [formField]="searchForm.q" />
    <button [routerLink]="[]" [queryParams]="{ q: searchForm.q().value() }">Search</button>

    @let res = usersResource();
    @if (res.isLoading()) {
      <p>Loading...</p>
    } @else if (res.error()) {
      <p>Failed to load users.</p>
    } @else if (res.value(); as users) {
      @for (user of users; track user.id) {
        <p>{{ user.name }}</p>
      }
    }
  `,
})
export class UserSearch {
  readonly q = input<string>();
  readonly searchForm = form(linkedSignal(() => ({ q: this.q() ?? '' })));
  readonly usersResource = input.required<Resource<User[] | undefined>>();
}

Data Fetching with `httpResource`

Not only resource(), but also resources created with httpResource() can be passed to Router Resources. When fetching user information via GET /api/users/:id, instead of writing a loader through a service, you can simply construct the request URL from the path parameter. httpResource() executes an HTTP request in response to changes in the Signal read by the function that returns the URL. In this example, when the ID changes, the user info is re-fetched.

// app.routes.ts
import { httpResource } from '@angular/common/http';
import { computed } from '@angular/core';
import { nonBlocking, ResourceContext, Routes } from '@angular/router';
import { UserProfile } from './user-profile';
import { User } from './user.service';

const userResource = (ctx: ResourceContext) => {
  const id = computed(() => ctx.params()['id'] as string);
  return httpResource<User>(() => `/api/users/${encodeURIComponent(id())}`);
};

export const routes: Routes = [
  {
    path: 'users/:id',
    component: UserProfile,
    resources: (ctx) => ({ userResource: nonBlocking(userResource(ctx)) }),
  },
];

Points to Consider

A point to consider when using Router Resources is the issue of type inference. While this has existed for some time, the resource name declared in the route configuration and the input name received by the component rely on matching names. Detecting mismatches with static type checking requires some ingenuity.

For example, consider a utility type like the following. Consolidate resource declaration types and functions in user-profile.resources.ts, and use satisfies to check for a match between resource names and types. Reference that function in the route configuration, and on the component side, import and implement UserProfileResourceInputs derived from the declaration side. With this, satisfies will cause an error if the resource declaration name is wrong, and implements will cause an error if you forget to declare userResource on the component side or use a different name or type. However, what can be checked is limited to the class property names and types; it cannot verify alias usage for inputs or the correctness of the mapping to the component specified in the route.

// router-resource.types.ts
import type { InputSignal, Resource } from '@angular/core';

export type RouteResource<T> = Resource<T> & { reload(): boolean };

export type ResourceInputs<
  Blocking extends { [K in keyof Blocking]: Resource<unknown> },
  NonBlocking extends { [K in keyof NonBlocking]: Resource<unknown> },
> = {
  readonly [K in keyof Blocking]: InputSignal<ReturnType<Blocking[K]['value']>>;
} & {
  readonly [K in keyof NonBlocking]: InputSignal<NonBlocking[K]>;
};

// user-profile.resources.ts
import { inject, resource } from '@angular/core';
import { nonBlocking } from '@angular/router';
import type { ResourceContext } from '@angular/router';
import type { ResourceInputs, RouteResource } from './router-resource.types';
import { UserService } from './user.service';
import type { User } from './user.service';

export type UserResource = RouteResource<User | undefined>;

interface UserProfileBlockingResources {
  user: UserResource;
}

interface UserProfileNonBlockingResources {
  userResource: UserResource;
}

type UserProfileResources =
  UserProfileBlockingResources & UserProfileNonBlockingResources;

export type UserProfileResourceInputs = ResourceInputs<
  UserProfileBlockingResources,
  UserProfileNonBlockingResources
>;

const userResource = (ctx: ResourceContext) => {
  const userService = inject(UserService);
  return resource({
    params: () => ctx.params()['id'] as string,
    loader: ({ params: id }) => userService.getUser(id),
  });
};

export const userProfileResources = (ctx: ResourceContext) => ({
  user: userResource(ctx),
  userResource: nonBlocking(userResource(ctx)),
} satisfies UserProfileResources);

// app.routes.ts
import type { Routes } from '@angular/router';
import { UserProfile } from './user-profile';
import { userProfileResources } from './user-profile.resources';

export const routes: Routes = [
  {
    path: 'users/:id',
    component: UserProfile,
    resources: userProfileResources,
  },
];

// user-profile.ts
import { Component, input } from '@angular/core';
import type { UserProfileResourceInputs, UserResource } from './user-profile.resources';
import type { User } from './user.service';

@Component({
  template: `
    @if (user(); as user) {
      <p>ID: {{ user.id }}</p>
    }
    @let res = userResource();
    @if (res.isLoading()) {
      <p>Loading...</p>
    } @else if (res.error()) {
      <p>Failed to load user.</p>
    } @else if (res.value(); as user) {
      <h2>{{ user.name }}</h2>
    }
  `,
})
export class UserProfile implements UserProfileResourceInputs {
  readonly user = input.required<User | undefined>();
  readonly userResource = input.required<UserResource>();
}

Summary

What I realized from thinking through actual use cases is that Router Resources allows you to move the concern about the data fetching path out of the component. It enables you to handle data and its fetch state, abstracted as a resource, without having knowledge of how it is being fetched.

Even as of 22.2.0, where it was implemented as a developer preview, there are already many benefits to replacing data resolvers, and it will likely become an essential element if you design applications based on Signals. While there are still areas where functionality is lacking, I believe that by actively using it and providing feedback, we can help refine the framework.

The sample code for this article is available on GitHub in a working format.

Summary of the Angular v22.2 Update

Suguru Inatomi — Sat, 03 Oct 2026 02:39:00 +0000

Angular v22.2.0 has been released. Since it’s a monthly minor update, several new features have been added. Let’s take a look at the details. I’ve narrowed it down to the important changes, so if you want to know everything, please refer to the official CHANGELOG.

angular/angular

Main changes to the framework are as follows.

Allowing Access to Private Members from Templates

It is now possible to reference private members of a class from the component’s template HTML. I’ve already written about the background and impact of this change in a separate article, so please check that out.

Addition of `strictUnclaimedEventNames`

A compilation flag has been added that enforces that event bindings (eventName) in a template must match either an event belonging to the target DOM element or a directive’s output. This is currently opt-in and is not included in strictTemplates, so it needs to be configured individually.

<!-- error -->
<button (unknownEvent)="...">

Addition of `@Component.deferredImports`

Template type checking now verifies that components, directives, and pipes associated with a specific named @defer block via @Component.deferredImports are used only within that specified block. Using them outside of @defer or in a block with a different name will result in a compilation error.

@Component({
  deferredImports: {
    blockA: [CmpA],
    blockB: [CmpB],
  },
  template: `
    @defer (name blockA) {
      <!-- error: CmpB（selector: 'cmp-b'）はblockB用の依存 -->
      <cmp-b />
    }
  `,
})
export class App {}

Addition of ErrorBoundary Feature

An @boundary block has been added to catch rendering errors within a template. If rendering inside the block fails, it switches to the @error block, allowing errors in a portion of the screen to be handled within that scope. In the @error block, you can reference the error using $error and attempt a re-render by clearing the error state with $reset().

@boundary {
  <complex-chart [data]="data" />
} @error {
  <p>チャートの描画に失敗した: {{ $error.message }}</p>
  <button (click)="$reset()">再試行</button>
}

An onViewError hook has also been added to ErrorHandler, allowing you to receive details about rendering errors. Along with this, the Angular Language Service now supports @boundary and @error, enabling features like autocomplete, hover, go-to-definition, and block folding for the new syntax.

Addition of Testing Utilities for Directives

TestBed.createDirective has been added, allowing you to test directives without having to define a host component for testing yourself. From the returned DirectiveFixture, you can reference the directive itself via directiveInstance and the host element via nativeElement, and perform change detection with detectChanges().

You can specify inputBinding or outputBinding in bindings. Since the tag name of the host element cannot be inferred for directives with only attribute selectors, you also specify a tagName.

import { Directive, input, inputBinding, signal } from '@angular/core';
import { TestBed } from '@angular/core/testing';

@Directive({
  selector: '[active]',
  host: { '[class.active]': 'active()' },
})
class ActiveDirective {
  active = input(false);
}

it('入力に応じてホスト要素のクラスを切り替える', () => {
  const active = signal(true);
  const fixture = TestBed.createDirective(ActiveDirective, {
    tagName: 'div',
    bindings: [inputBinding('active', active)],
  });
  fixture.detectChanges();
  expect(fixture.nativeElement.classList.contains('active')).toBe(true);

  active.set(false);
  fixture.detectChanges();
  expect(fixture.nativeElement.classList.contains('active')).toBe(false);
});

Retrieving `Injector` in View and Content Queries

It is now possible to specify Injector in the read option of view queries and content queries. This retrieves the node injector of the element found by the query, allowing you to resolve providers visible from that element’s position.

import { Component, Directive, InjectionToken, Injector, viewChild } from '@angular/core';

const TOKEN = new InjectionToken<string>('TOKEN');

@Directive({
  selector: '[localProvider]',
  providers: [{ provide: TOKEN, useValue: '要素内の値' }],
})
class LocalProviderDirective {}

@Component({
  imports: [LocalProviderDirective],
  template: '<div #target localProvider></div>',
})
class AppComponent {
  targetInjector = viewChild.required('target', { read: Injector });

  ngAfterViewInit() {
    console.log(this.targetInjector().get(TOKEN)); // 'Value within the element'
  }
}

Specifying Fixed Hidden Fields in Signal Forms

The condition for the hidden rule in Signal Forms can now be omitted. Previously, even if you wanted to keep a field always hidden, you had to specify { when: () => true }, but now you can just write hidden(path). The target field will always have hidden() as true and will also be excluded from validation.

import { Component, signal } from '@angular/core';
import { form, FormField, hidden } from '@angular/forms/signals';

@Component({
  imports: [FormField],
  template: `
    @if (!profileForm.publicUrl().hidden()) {
      <input [formField]="profileForm.publicUrl" />
    }
  `,
})
class ProfileComponent {
  profileModel = signal({ publicUrl: '' });
  profileForm = form(this.profileModel, (path) => {
    hidden(path.publicUrl);
  });
}

hidden is a rule for specifying the state of a field within the form data and does not automatically hide the DOM. To toggle visibility, you reference hidden() on the template side as shown in the example above.

Public Release of `containsTree` API

containsTree, which was used internally by the router, is now a public API in @angular/router. You can pass two UrlTree objects to determine if one is contained within the other. It can be used for comparing any URLs, not just for comparison with the current URL.

import { containsTree, DefaultUrlSerializer } from '@angular/router';

const serializer = new DefaultUrlSerializer();
const container = serializer.parse('/products/42?category=books&page=2');
const target = serializer.parse('/products?category=books');

containsTree(container, target); // true
containsTree(container, target, { paths: 'exact' }); // false
containsTree(container, target, { queryParams: 'exact' }); // false

Redirecting via throwing `RedirectCommand`

It is now possible to redirect by throwing a RedirectCommand from guards or resolvers. RedirectCommand now inherits from Error, and the router treats the thrown command as a redirect rather than a typical navigation error.

Previously, you had to return a redirect instruction as a return value, but now you can interrupt processing with a throw even from nested helper functions. This eliminates the need to propagate a RedirectCommand back to the caller and avoids mixing redirect types into the return type of the helper.

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

function requireId(id: string | null): string {
  if (id === null) {
    throw new RedirectCommand(inject(Router).parseUrl('/not-found'));
  }
  return id;
}

export const idResolver: ResolveFn<string> = (route) => {
  return requireId(route.paramMap.get('id'));
};

Public Release of Router Resources API

Router Resources , which handles per-route data fetching using the Resource API, is now a public API. You can enable it with withRouterResources() and define data fetching logic in the route’s resources. It supports parallel loading across routes, data fetching that doesn’t block navigation, and refetching data without re-navigation.

I plan to write more about how to use it and the differences from traditional resolvers in a separate article later.

Stabilization of Automatic Injector Cleanup per Route

The feature that automatically destroys route injectors that are no longer in use has reached stability and is now available as withAutoCleanupInjectors(). The previous withExperimentalAutoCleanupInjectors() has been deprecated.

Normally, route injectors and the services provided there are retained even after navigating to a different screen. With this feature enabled, the router checks the routes in use and those saved for reuse after navigation completes, and destroys injectors that are no longer needed. Cleanup tasks registered in a service’s ngOnDestroy or DestroyRef will also be executed.

import { ApplicationConfig } from '@angular/core';
import { provideRouter, withAutoCleanupInjectors } from '@angular/router';
import { routes } from './app.routes';

export const appConfig: ApplicationConfig = {
  providers: [provideRouter(routes, withAutoCleanupInjectors())],
};

Encapsulation Support for CSS Native Nesting Syntax

CSS native nesting syntax is now handled correctly with ViewEncapsulation.Emulated style encapsulation. It now adds component-scoping attributes to nested child selectors and can handle the & that references the parent selector.

.card {
  .title {
    color: red;
  }

  &:hover {
    background: lightgray;
  }
}

Binding Functions and Signals to `animate.enter` and `animate.leave`

A bug where animations would not run when passing a function or Signal that returns a class name directly to [animate.enter] or [animate.leave] has been fixed. Previously, you had to call it on the template side like enterClass(), but now you can get the class name even if you pass a reference like enterClass.

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

@Component({
  template: `
    <button (click)="show.set(!show())">切り替え</button>
    @if (show()) {
      <div [animate.enter]="enterClass" [animate.leave]="leaveClass">
        Hello
      </div>
    }
  `,
})
class Example {
  show = signal(true);
  enterClass = signal('fade-in');
  leaveClass = () => 'fade-out';
}

angular/angular-cli

Main changes to the Angular CLI are as follows.

Specifying the Root Directory for MCP Servers

A --root option has been added to ng mcp. You can explicitly specify the scope where the MCP server is allowed file access and the starting point for searching the Angular workspace at startup. Since you can specify --root multiple times, it can be used when handling multiple workspaces or when starting the server from outside a workspace.

ng mcp --root /path/to/app-a --root /path/to/app-b

If the MCP client provides roots via listRoots(), those will take precedence. If the client does not support it or returns an empty list, the --root specification is used; if neither exists, the current directory is used.

Narrowing the Compilation Scope Based on Test Targets

A bug has been fixed in the Vitest execution of @angular/build:unit-test where tests would fail due to type errors in test files not specified by --include. Previously, all test files included in the tsconfig were compiled, even if you narrowed down the tests to be executed.

ng test --include='src/app/services/test.service.spec.ts'

Migration to Native Implementation for File Watching

File watching in @angular/build has been replaced with an implementation centered around @parcel/watcher instead of watchpack. It utilizes the OS’s file watching APIs through C++ native bindings, reducing CPU and memory usage in watch mode. In environments where polling is used or native watching is unavailable, it falls back to chokidar.

Migration to Native Implementation for the Sass Compiler

Sass compilation in @angular/build has migrated from running the JavaScript version of Dart Sass in worker threads to using sass-embedded. It starts the AOT-compiled Dart binary as a separate process and requests compilation asynchronously via standard input/output. The compiler process is reused across multiple compilations.

Benchmarks report the following improvements:

For Sass processing alone, a speedup of approximately 1.3x to 4.3x for median compilation time after compiler startup, and approximately 2x to 3x for incremental compilation.
For total ng build wall-clock time, a reduction of about 8% to 14% for small apps with 5 Sass files. For large apps with 500 files, the first build is roughly equivalent, while subsequent builds are reduced by about 2% to 3%.
Peak memory usage for ng build was reduced by about 14% to 29% for small apps and 31% to 33% for large apps.

In the measurement examples, large apps see a greater effect in memory reduction than in time reduction.

Pre-compilation of Critical CSS Processing for SSR

Analysis of stylesheets for Critical CSS inlining in @angular/ssr is now performed at build time. Critical CSS is a process that embeds CSS required for rendering directly into the HTML so that it can be displayed without waiting for external stylesheets to load. Previously, HTML and CSS were analyzed during request processing, but this has changed to a method where a “plan” for processing is generated in advance from the CSS and included in the server manifest. This reduces the burden of analyzing CSS for every request, significantly reducing SSR CPU usage and response wait times.

angular/components

Main changes for Angular CDK, Aria, and Material are as follows.

Automatic Detection of Material Symbols

mat-icon now identifies the loaded Material Symbols font and automatically applies the corresponding CSS class. Previously, the material-icons class for the old Material Icons was applied by default, but if only Material Symbols is loaded, the material-symbols-* class corresponding to Outlined, Rounded, or Sharp will be used.

<!-- Load fonts in index.html -->
<link rel="stylesheet"
      href="https://fonts.googleapis.com/css2?family=Material+Symbols+Outlined" />

<!-- No need to specify fontSet in the template -->
<mat-icon>home</mat-icon>

In the example above, the material-symbols-outlined class is automatically applied. This feature does not automatically load the font itself, so separate font loading is still required. If both the old Material Icons and Material Symbols are loaded, the traditional material-icons takes precedence for compatibility.

Support for `disabledInteractive` in `MatMenuItem`

A disabledInteractive input has been added to MatMenuItem. When used with disabled, it allows the item to accept focus and hover while maintaining a disabled appearance. Since it can be focused when navigating items via keyboard, it can be used for purposes such as explaining why an item cannot be operated via a tooltip.

<button [matMenuTriggerFor]="menu">操作</button>

<mat-menu #menu="matMenu">
  <button mat-menu-item disabled [disabledInteractive]="true"
          matTooltip="この操作には管理者権限が必要">
    削除
  </button>
</mat-menu>

Unlike standard disabled, the native disabled attribute is not added; instead, the disabled state is communicated via aria-disabled.

Angular Aria: Support for Omitting `value` in `MenuItem`

The value input can now be omitted in MenuItem for @angular/aria/menu. Previously, value was mandatory even when executing logic via the item’s (click), but now there’s no need to add dummy values to menu items that don’t use them. Even if multiple items omit the value, no warning about duplicate values will be issued.

<div ngMenu>
  <button ngMenuItem (click)="newFile()">新規作成</button>
  <button ngMenuItem (click)="openFile()">開く</button>
</div>

Signal Forms Support for `MatFormFieldControl`

MatFormFieldControl can now handle custom controls that use Signal Forms. By exposing the form field via the ngField property, mat-form-field can read states like valid and dirty and reflect them in the corresponding CSS classes.

You can integrate with Signal Forms by adding ngField to the class provided as MatFormFieldControl.

import { Component, forwardRef, inject } from '@angular/core';
import { FORM_FIELD, FormField } from '@angular/forms/signals';
import { MatFormFieldControl } from '@angular/material/form-field';

@Component({
  selector: 'app-custom-name-input',
  templateUrl: './custom-input.html',
  providers: [{
    provide: MatFormFieldControl,
    useExisting: forwardRef(() => CustomNameInput),
  }],
})
export class CustomNameInput {
  // Integration point with Signal Forms
  readonly ngField: FormField<string> | null =
    inject(FORM_FIELD, {optional: true, self: true}) as FormField<string> | null;
}

Users of the form pass the field via [formField] as usual and place it inside mat-form-field. The inject(FORM_FIELD) inside the control retrieves this Signal Forms directive.

<mat-form-field>
  <mat-label>名前</mat-label>
  <app-custom-name-input [formField]="profileForm.name" />
</mat-form-field>

Previously, the state of Angular Forms was referenced via ngControl, but if ngField is present, it now takes precedence for referencing the Signal Forms state.

Angular: Rethinking the Semantics of Private Fields

Suguru Inatomi — Thu, 24 Sep 2026 22:56:00 +0000

Since the Angular v22.2.0 update, the behavior of the template compiler regarding private fields in component classes has changed. In this article, I will summarize the update and share my current thoughts on the semantics of field declarations that we should perhaps reconsider as a result.

Content of the Update

With the Angular v22.2.0 update, class fields (member variables) declared with the private modifier can now be referenced from within a component’s template.

Specifically, code like the following is now executable. Referencing the name field of a component using interpolation syntax no longer causes a compilation error.

import { Component } from '@angular/core';

@Component({
  selector: 'app-greeting',
  template: `<p>Hello, {{ name }}!</p>`,
})
export class GreetingComponent {
  private name = 'Angular';
}

The restriction has only been relaxed for fields declared with the private modifier; ECMAScript private fields using the # prefix still cannot be referenced and will result in a compilation error as before.

import { Component } from '@angular/core';

@Component({
  selector: 'app-greeting',
  // Error
  template: `<p>Hello, {{ #name }}!</p>`,
})
export class GreetingComponent {
  #name = 'Angular';
}

Background of the Change

The background for this change is the support for isolatedDeclarations introduced in TypeScript 5.5. isolatedDeclarations ensures that each file can be independently converted into a type declaration file (.d.ts) without type checking.

Since Angular components are typically exported classes, their public and protected members are included in the class’s external type declaration. For example, suppose you declare a Signal to be referenced from a template like this:

export class GreetingComponent {
  protected readonly name = signal('Angular');
}

Because protected members are accessible from derived classes, they are part of the class’s external type. Therefore, under isolatedDeclarations, an explicit type annotation becomes necessary, as shown below:

export class GreetingComponent {
  protected readonly name: WritableSignal<string> = signal('Angular');
}

On the other hand, private members are implementation details of the class, and there is no need to expose their specific types as part of the external API. Consequently, if fields used exclusively for templates can be made private, we can avoid redundant type annotations solely for generating type declaration files and instead leverage TypeScript’s type inference directly.

export class GreetingComponent {
  private readonly name = signal('Angular');
}

Previously, members referenced from templates could not be private. Because of this, developers had no choice but to add type annotations to fields exposed to the template when enabling isolatedDeclarations. This change is a measure against that degradation of the developer experience.

Semantics of Component Class Fields

To use component class field declarations effectively, I think it is necessary to clarify the semantics—what intention each type of field is declared with.

While there may be differences depending on the project, the traditional typical semantics would likely be as follows. Under the previous specifications, there was no difference at the functional level of Angular components between private fields using the private modifier and those using the # prefix. Therefore, there was no semantic need to distinguish between them, and as long as a policy was established within a project, there was no confusion.

public: An API exposed for access via the class instance.
- These rarely appear in production code. They are necessary when accessing an instance from a ComponentFixture in test code, but unnecessary for DOM tests using something like Testing Library.
protected: An internal API accessed only within the component.
- Since inheritance is rarely used in component classes, these effectively function as private fields that can also be accessed from templates. Fields declared for template binding can generally be protected.
private: An internal API accessed only from class methods.
- Since they cannot be referenced from the template, they are used for injected dependency fields or internal state that you want to hide from the view.

Taken together, a component implementation like the following was a typical example until now.

import { Component, inject, signal } from '@angular/core';
import { Router } from '@angular/router';

@Component({
  selector: 'app-profile-editor',
  template: `
    <input
      #nameInput
      [value]="name()"
      (input)="name.set(nameInput.value)"
    />
    <button (click)="goBack()">戻る</button>
  `,
})
export class ProfileEditorComponent {
  // API for external calling via the class instance
  public reset(): void {
    this.name.set('');
  }

  // Internal API referenced from the template
  protected readonly name = signal('');

  // Implementation details referenced only from class methods
  private readonly router = inject(Router);

  protected goBack(): void {
    this.router.navigate(['/profiles']);
  }
}

A Proposal for Semantics in the New Specification

Given this change, it seems natural to view the template not as something external to the component class, but as something that constitutes the component’s implementation along with the class.

Under this premise, the declarations could be used as follows:

public: An API exposed to users of the class instance.
- Use only when direct external access via the component instance is required.
protected: An API exposed to derived classes.
- Basically not used. Use cases exist only in components designed for inheritance, which is extremely rare.
private: An internal component API.
- Can be used by both the class and the template. This becomes the basic form for state and methods referenced by the template.

In this organization, by moving the role of “internal API for templates” previously held by protected to private, we avoid exposing specific types in the external type declaration and can utilize type inference even under isolatedDeclarations.

On the other hand, what should we do with implementation details like dependency services or internal state that we do not want the template to reference directly? I think there are two main approaches to facing this problem.

Strategy 1: Maintain Information Hiding within the Component

One approach is to use TypeScript’s private and ECMAScript’s #private as different levels of visibility.

private: An internal component API shared by the class and the template.
#private: An implementation detail hidden even from the template, used only within the class body.

@Component({
  selector: 'app-user-list',
  template: `
    @for (user of users.value(); track user.id) {
      <button (click)="selectUser(user.id)">
        {{ user.name }}
      </button>
    }
  `,
})
export class UserListComponent {
  #http = inject(HttpClient);
  #selectedUserId = signal<string | null>(null);

  private readonly users = resource({
    loader: () =>
      firstValueFrom(
        this.#http.get<readonly User[]>('/api/users'),
      ),
  });

  private readonly selection =
    this.#selectedUserId.asReadonly();

  private selectUser(id: string): void {
    this.#selectedUserId.set(id);
  }
}

In this strategy, we maintain information hiding within the component between “visible to the template” and “class body only.” We expose only read-only Signals, Resources, or intended operations to the template, while confining mutable state or low-level dependencies within #private. This effectively continues the traditional semantics of protected and private by shifting them to private and #private.

The advantage of this method is that visibility can be enforced by language features. On the other hand, two types of private syntax will coexist within a single class, and a mere difference in notation will carry the significant meaning of visibility from the Angular template.

Strategy 2: Replace Information Hiding with Separation of Concerns

Another approach, which is my preference, is to interpret the template and the class as a single unit forming the component, and opt not to perform information hiding within the component. Instead, implementation details that need to be hidden from the template should not be held by the component in the first place.

What this change allows is access from the template to the component’s own private fields. It does not mean that the private fields of nested objects are exposed. Taking advantage of this property, we move dependencies, state, and processes that should not be exposed to the template into other objects such as a Facade, ViewModel, or Store.

@Injectable()
class UserListViewModel {
  private readonly http = inject(HttpClient);
  private readonly selectedUserId = signal<string | null>(null);

  readonly users = resource({
    loader: () =>
      firstValueFrom(
        this.http.get<readonly User[]>('/api/users'),
      ),
  });

  readonly selection = this.selectedUserId.asReadonly();

  selectUser(id: string): void {
    this.selectedUserId.set(id);
  }
}

@Component({
  selector: 'app-user-list',
  providers: [UserListViewModel],
  template: `
    @for (user of vm.users.value(); track user.id) {
      <button (click)="vm.selectUser(user.id)">
        {{ user.name }}
      </button>
    }
  `,
})
export class UserListComponent {
  private readonly vm = inject(UserListViewModel);
}

What is directly visible from the template is the component’s vm field. Beyond that, only the public API of the UserListViewModel is available; private members like http or selectedUserId cannot be accessed.

In this strategy, the component class focuses on the responsibility of integrating the template with external objects, and implementations requiring information hiding are moved to separate objects.

The Two Strategies

The fundamental difference between the two proposals is whether or not to establish a boundary for information hiding inside the component. Depending on whether you think the class and the template have different contexts or share the same context, the semantics of private fields will change.

	Information Hiding via Field Visibility	Information Hiding via Objects
Visibility within the component	Divided into two stages with `private` and `#private`	All members are exposed to the template
Location of implementation details	The same component class	Separate objects like ViewModel, Facade, Store
Enforcement mechanism	Language features	Object boundaries
Pros	Fewer additional abstractions; full tool support	No mixing of private syntaxes
Cons	Two types of private syntax coexist	Effort of separating concerns; may be over-engineering for small components

There might be other approaches, but semantically, they will likely be variations of one of these two. Alternatively, if a project decides to expose everything to the template without much thought, that is not a problem either. What matters is intent and consistency.

Adoption of oxc-parser in Angular v22.1

Suguru Inatomi — Thu, 30 Jul 2026 03:57:00 +0000

In Angular CLI v22.1.0, part of the build pipeline in @angular/build has been migrated from Babel to oxc-parser + magic-string.

https://github.com/angular/angular-cli/commit/10dc30f9c680f46f65b5beb030f2a75c422a3e71

https://github.com/angular/angular-cli/commit/917393a4cd85172574b155f727da5c1eae196fb1

This change only affects the angular/angular-cli repository, and oxc is not included in the dependencies of angular/angular. ngtsc and @angular/compiler remain in TypeScript. The migration is limited to the pre-processing JS-to-JS transformation before passing code to esbuild.

The Role of oxc-parser

oxc is a JavaScript toolchain written in Rust, and oxc-parser is a package that allows its parser functionality to be used from Node.js via NAPI. It obtains an AST using parseSync(filename, code, options) and traverses it with a Visitor.

After oxc-parser converts the compiled JS into an AST, a separate library called magic-string performs the code rewriting for optimization. While oxc also has a transformer written in Rust (the oxc-transform package), it is not currently being used.

import { MagicString } from 'magic-string';
import { Visitor, parseSync } from 'oxc-parser';

Changes in @angular/build

With this change, part of the Angular CLI build-time optimization process has switched from a Babel plugin-based mechanism to a custom mechanism using oxc-parser + magic-string. The goal seems to be removing the Babel dependency and shortening build times.

In the Babel plugin-based mechanism, the source code is parsed into an AST, the AST is modified, and then the entire code is re-generated from the AST. In contrast, the new mechanism does not modify the AST parsed by oxc-parser; instead, it uses magic-string to perform string manipulations only on the specific ranges of the original code that require changes. The idea is likely to try to reduce build times by using the faster oxc-parser in cases where Babel is not required.

Before Migration: AST Editing with Babel Plugins

Before the migration, javascript-transformer-worker.ts was structured to stack four optimization plugins along with coverage instrumentation and the Angular Linker into a plugins array and then call transformAsync.

if (options.advancedOptimizations) {
  const { adjustStaticMembers, adjustTypeScriptEnums, elideAngularMetadata, markTopLevelPure } =
    await import('../babel/plugins');

  const sideEffectFree = options.sideEffects === false;
  const safeAngularPackage =
    sideEffectFree && /[\\/]node_modules[\\/]@angular[\\/]/.test(filename);

  plugins.push(
    [markTopLevelPure, { topLevelSafeMode: !safeAngularPackage }],
    elideAngularMetadata,
    adjustTypeScriptEnums,
    [adjustStaticMembers, { wrapDecorators: sideEffectFree }],
  );
}

// ...

const result = await transformAsync(data, {
  filename,
  inputSourceMap: (useInputSourcemap ? undefined : false) as undefined,
  sourceMaps: useInputSourcemap ? 'inline' : false,
  compact: false,
  configFile: false,
  babelrc: false,
  browserslistConfigFile: false,
  plugins,
});

The processes performed by the four optimization plugins were as follows. All of them are markings for tree shaking.

markTopLevelPure: Appends /*# __PURE__ */ to top-level function calls and constructor calls.
elideAngularMetadata: Removes calls like ɵsetClassMetadata.
adjustTypeScriptEnums: Wraps enums output by TypeScript in a pure IIFE.
adjustStaticMembers: Wraps static members like ɵcmp and ɵfac in a pure IIFE.

After Migration: String Editing with magic-string

The four plugins have been integrated into the transform() function in oxc-transform.ts. While traversing the parsed AST, all edits are stacked into a single MagicString instance.

export function transform(filename: string, code: string, options: OxcTransformOptions) {
  const { program } = parseSync(filename, code, { range: true });
  const s = new MagicString(code);
  // ...

The removal of Angular metadata is implemented as follows:

if (calleeName && angularMetadataFunctions.has(calleeName)) {
  const parentFunc = functionStack[functionStack.length - 1];
  if (
    parentFunc &&
    (parentFunc.type === 'FunctionExpression' ||
      parentFunc.type === 'ArrowFunctionExpression')
  ) {
    s.overwrite(node.start, node.end, 'void 0');
    markEdited(node.start, node.end);

    return;
  }
}

The angularMetadataFunctions contains three items: ɵsetClassMetadata, ɵsetClassMetadataAsync, and ɵsetClassDebugInfo. The range of the corresponding call expression is overwritten with void 0. For insertions like the pure annotation, appendLeft and appendRight are used.

s.appendLeft(decl.id.end, ' = /*# __PURE__ */ ');

Path Bypassing Babel

javascript-transformer-worker.ts, the process for post-build JS, has been split into two phases.

let code = data;

// If Babel is needed, run it first
if (babelPlugins.length > 0) {
  const result = await transformAsync(code, { /* ... */ plugins: babelPlugins });
  code = result?.code ?? code;
}

// Run advanced optimizations using our fast oxc-transform
if (options.advancedOptimizations) {
  const { transform } = await import('../babel/plugins/oxc-transform.js');
  const sideEffectFree = options.sideEffects === false;
  const safeAngularPackage =
    sideEffectFree && /[\\/]node_modules[\\/]@angular[\\/]/.test(filename);
  const topLevelSafeMode = !safeAngularPackage;

  const result = transform(filename, code, {
    sourcemap: useInputSourcemap,
    sideEffects: options.sideEffects,
    jit: options.jit,
    topLevelSafeMode,
  });
  code = result.code;
  // ...
}

Now, only coverage instrumentation and the Angular Linker have the potential to be added to babelPlugins. If neither of these is needed, the code never reaches transformAsync, and the dynamic import of @babel/core does not occur. The Linker is only necessary for files containing ɵɵngDeclare—namely, libraries that have been partially compiled.

This covers the introduction of oxc-parser in build-time optimization; similarly, the i18n inlining process can now also bypass Babel.

Future Outlook

Although a bypass path that doesn’t call Babel has been created for some processes, @babel/core still remains in the dependencies for v22.1.0. There are two paths where Babel still runs at runtime.

One is code coverage instrumentation. Since the programVisitor from istanbul-lib-instrument can only be used as a Babel plugin, Babel will run if codeCoverage: true is specified in the karma builder. This path will eventually disappear with the migration to the Vitest-based @angular/build:unit-test builder.

The other is the Angular Linker, which still uses @angular/compiler-cli/linker/babel as is. PR #33625, which migrates the Angular Linker to oxc, is still open at the time of writing and is not included in v22.1. Once this is also merged, all paths that call Babel in a modern Angular project will likely disappear. It will be some time before the dependency is completely gone, but the benefits of faster builds should be felt immediately.

Note that, currently, oxc-parser is only adopted for post-compilation processing into JS; there are no changes in the areas responsible for compiling TypeScript code or template HTML. Since there is no primary information from official sources yet, I think it’s important not to misunderstand its scope.

Angular Update Guide Skill for Agents

Suguru Inatomi — Mon, 27 Jul 2026 00:54:00 +0000

The Angular Update Guide in the official Angular documentation is a useful tool for checking the scope of impact when upgrading Angular versions. However, because it’s dynamic content on a website, it’s difficult to provide as a data source when instructing an AI agent to perform an Angular update, and the need for steps like WebFetch or scraping via browser automation is a problem.

Update guide • Angular

The web development framework for building modern apps.

angular.dev

By the way, the content of this update guide exists statically as a TypeScript object in the source code, so it becomes easier to use if you process it beforehand and turn it into an agent skill. That’s why I created the lacolaco/angular-skills angular-update-guide skill.

lacolaco / angular-skills

Unofficial agent skills for working with Angular.

angular-skills

日本語

Agent skills for working with Angular. These do not replace the official angular/skills; they cover ground the official skills leave open.

Unofficial. This repository is not affiliated with, endorsed by, or supported by Google or the Angular team.

Skills

angular-update-guide: Breaking changes and migration items for every Angular major-to-major step from v6 to v22, generated from the Angular Update Guide data in angular/angular so an agent can read it directly instead of browsing the docs site. Reference data only; it does not describe how to run the update.

Install

# In your project
npx skills add lacolaco/angular-skills

# Or globally for your user
npx skills add lacolaco/angular-skills -g

# Just one of the skills
npx skills add lacolaco/angular-skills -s angular-update-guide

Usage

`angular-update-guide` : what breaks between two Angular majors

It does its work inside whatever you were already going to ask. Nothing needs to name it:

…

View on GitHub

# Install skills
npx skills add lacolaco/angular-skills

# Just one of the skills
npx skills add lacolaco/angular-skills -s angular-update-guide

If you look at the source code, you’ll see it consists of a single SKILL.md and a set of XML files referenced from it, with no external tool calls or anything like that. I’ve converted the guide content for each major version into XML files, aiming to have the AI agent gather information by referencing them according to the context.

If anyone feels that getting an AI agent to read the Angular Update Guide content is a hassle, please give it a try. Also, since something equivalent to this skill is something I’d ideally like to see included in the official Angular Skills, I intend to proceed with a proposal for that as well.

Angular: Resource API Family System Diagram

Suguru Inatomi — Sun, 12 Jul 2026 00:57:00 +0000

In this article, I’ll provide an overview of the relationships within the Resource API family, which became stable in Angular v22.

Resource API Family

As of v22, the main public APIs included in the Resource API are as follows:

Resource<T> interface
WritableResource<T> interface
ResourceSnapshot<T> interface
resourceFromSnapshots function
resource function
httpResource function

Let’s confirm their positions within the API family while explaining each one.

`Resource<T>` Interface

This interface sits at the heart of the API family. The Resource API family can be broadly divided into APIs that represent Resource objects and factory APIs for creating Resource objects. The Resource<T> interface is the common base type for all Resource objects and serves as the return type for factory APIs.

export interface Resource<T> {
  readonly value: Signal<T>;
  readonly status: Signal<ResourceStatus>;
  readonly error: Signal<Error | undefined>;
  readonly isLoading: Signal<boolean>;
  readonly snapshot: Signal<ResourceSnapshot<T>>;

  hasValue(this: T extends undefined ? this : never): this is Resource<Exclude<T, undefined>>;
  hasValue(): boolean;
}

As you can see, Resource<T> is read-only, and its responsibility is to return the values and states held by the Resource as Signal types. If an object conforms to this interface, it can be considered a Resource object. If you’re writing code that takes a Resource object as an argument and performs some action, that argument would require the Resource<T> type.

`WritableResource<T>` Interface

The WritableResource<T> interface extends Resource<T>, with the difference being that it supports writes. The value field is of type WritableSignal<T>, and it also provides set and update methods. You can also convert it to a read-only Resource<T> using the asReadonly method. Additionally, the reload method re-executes the last resource resolution, which also updates the value internally. In essence, WritableResource<T> allows the user to trigger value updates.

export interface WritableResource<T> extends Resource<T> {
  readonly value: WritableSignal<T>;

  set(value: T): void;
  update(updater: (value: T) => T): void;
  asReadonly(): Resource<T>;
  reload(): boolean;
}

`ResourceSnapshot<T>` Interface

The ResourceSnapshot<T> interface represents an immutable object that captures the internal state of a Resource object at a specific moment. Specifically, it includes a status field indicating the resolution state of the Resource, and additional fields corresponding to each status. While a Resource is an object whose state changes asynchronously, that state always follows a so-called Discriminated Union type that falls into one of these snapshot types.

export type ResourceSnapshot<T> =
  | {readonly status: 'idle'; readonly value: T}
  | {readonly status: 'loading' | 'reloading'; readonly value: T}
  | {readonly status: 'resolved' | 'local'; readonly value: T}
  | {readonly status: 'error'; readonly error: Error};

The snapshot field of Resource<T> is related in that it returns the state at the time of calling as a ResourceSnapshot<T> type object.

`resourceFromSnapshots` Function

The fact that the possible states of Resource<T> can always be extracted as ResourceSnapshot<T> means that the continuous changes of ResourceSnapshot<T> are what define the Resource<T> itself. In other words, a Resource<T> is a Signal<ResourceSnapshot<T>>.

The resourceFromSnapshots function expresses this directly. It takes a function that returns a ResourceSnapshot<T> as an argument. If the argument is a Signal<ResourceSnapshot<T>>, it is subscribed to internally and automatically reflected in the state of the Resource<T>. Since the source is the source of truth for the state, what’s returned is a read-only Resource object.

function resourceFromSnapshots<T>(
  source: () => ResourceSnapshot<T>,
): Resource<T>;

  const source = signal<ResourceSnapshot<string>>({status: 'idle', value: ''});
  const res = resourceFromSnapshots(source);
  expect(res.status()).toEqual('idle');
  expect(res.value()).toEqual('');
  expect(res.isLoading()).toBeFalse();
  expect(res.hasValue()).toBeTrue();

  // Update snapshot
  source.set({status: 'loading', value: 'alpha'});
  expect(res.status()).toEqual('loading');
  expect(res.value()).toEqual('alpha');
  expect(res.isLoading()).toBeTrue();
  expect(res.hasValue()).toBeTrue();

You’re completely free to decide how to create the source Signal—it could be via the signal function, the input function, linkedSignal, or computed. As long as it ends up as a Signal<ResourceSnapshot<T>>, it’s fine. If you’re creating a Resource object for a specific purpose, this method is quite handy. Of course, if the built-in factory APIs I’ll mention later suffice, those are fine too.

`resource` Function

The resource function is a built-in Resource factory API. Unlike the resourceFromSnapshots function, it returns a writable Resource object based on declarative options. ResourceRef<T> is almost the same as WritableResource<T>.

function resource<T, R>(
  options: ResourceOptions<T, R> & { defaultValue: NoInfer<T> },
): ResourceRef<T>;

I’ll skip the details of how to use the API since you can find that in the documentation, but broadly speaking, you can construct a Resource object in two ways. One is by using a Loader that returns a Promise, and the other is by using a Loader that returns a Stream. By Stream, I mean a sequence of values—specifically, a Signal<ResourceStreamItem<T>>. ResourceStreamItem<T> specifically refers to {value: T} | {error: Error}.

const userId: Signal<string> = getUserId();

// Promise-based Loader
const userResource = resource({
  params: () => ({id: userId()}),
  loader: ({params}): Promise<User> => fetchUser(params),
});

// Signal-based Streaming Loader
const chunkedMessageResource = resource({
  params: () => ({id: messageId()}),
  stream: ({params}): Signal<ResourceStreamItem<string>> => {
    const message = signal<string>('');
    chunkedMessage(params).subscribe({
      next: (chunk) => {
        message.update(item => ({ value: item.value + chunk }));
      },
      error: (err) => message.set({ error: err }),
    });
  },
});

If you have a use case that requires multiple value writes rather than a Promise model where resolution finishes once, you can configure it with a Stream-based Loader. However, for this use case, I think resourceFromSnapshots, mentioned earlier, is generally more versatile and easier to use, and personally, I think it wouldn’t be surprising if this eventually disappeared. Unless there’s a specific reason, I think it’s best to limit the use of the resource function to when you have a Promise-based Loader.

`httpResource` Function

The final one, httpResource, is a built-in Resource factory API like the resource function, but its purpose is more specific. As the name suggests, it’s a factory for constructing a Resource that resolves its value via HTTP requests. It takes a function that resolves a url, and you can obtain the response fetched internally using Angular’s HttpClient as a Resource object. Since its purpose is clear, you shouldn’t have trouble deciding when to use it over other Resource factories.

function httpResource<T>(
  url: (ctx: ResourceParamsContext) => string | undefined, 
  options: HttpResourceOptions<T, unknown> & { defaultValue: NoInfer<T>; }
): HttpResourceRef<T>;

const userId = signal<string>('id');
const user = httpResource(() => `/api/user/${userId()}`);

The HttpResourceRef<T> interface adds HTTP-specific states to WritableResource<T>. Since value is managed by WritableResource<T>, it is read-write, but response headers and status codes are read-only. Also, note that calling asReadonly will turn it into a plain Resource<T>, causing any HTTP-specific information to be lost.

export interface HttpResourceRef<T> extends WritableResource<T>, ResourceRef<T> {
  readonly headers: Signal<HttpHeaders | undefined>;
  readonly statusCode: Signal<number | undefined>;
  readonly progress: Signal<HttpProgressEvent | undefined>;
}

Summary

I’ve summarized the relationships among the main APIs covered so far. Centered around Resource<T>, derived interfaces and their corresponding factory functions are provided out of the box. At the same time, implementations for these interfaces are interchangeable. The built-in factory APIs are not anything special; they are open so that you can create implementations specialized for individual use cases. I think keeping these relationships in mind will help you master the Resource API.

Angular v22: Lazy Loading Business Logic with injectAsync

Suguru Inatomi — Sun, 21 Jun 2026 23:49:00 +0000

The injectAsync function added in Angular v22 provides a new option for improving loading speeds. I’ll introduce this new API while reviewing the lazy loading APIs that have existed until now.

`injectAsync`

The inject function used for dependency injection creates a static reference to the target being injected. Therefore, if the dependent side is included in the initial load JS, the side being depended upon will also increase the bundle size. In the following example, the ReportView component and the ReportExporter service are statically coupled, and their loading timing cannot be separated.

// Static import
import { ReportExporter } from './exporter';

@Component({...})
export class ReportView {
  // ReportView statically references ReportExporter
  exporter = inject(ReportExporter);

  export() {
    this.exporter.export();
  }
}

If ReportExporter is not a feature that is always used, we might want to keep only ReportView in the initial load and delay ReportExporter so it’s only loaded when the export button is pressed. That’s what injectAsync achieves. This function asynchronizes the injection of a specific service, allowing for bundle splitting and making the module lazy-loadable.

Following the example below, replace the reference to the ReportExporter service from a static import to a dynamic import in the argument of the injectAsync function. By doing this, the this.exporter field becomes a function that returns a reference to the service asynchronously when called. By await-ing the return value, you can use the service just as before.

@Component({...})
export class ReportView {
  // Dynamic import
  // ReportView dynamically references ReportExporter
  exporter = injectAsync(() => import('./exporter').then(m => m.ReportExporter));

  async export() {
    const exporter = await this.exporter();
    exporter.export();
  }
}

Usage Constraints

Only services declared with @Injectable({ providedIn: 'root' }) or the @Service() decorator can use injectAsync. Because they are integrated into the dependency injection system dynamically as modules are loaded, complex provider definitions are not supported.

Lazy Loading Methods and Use Cases

As in the example above, if a portion of the features provided by an application is infrequently used, it’s worth considering lazy loading to avoid compromising the experience for users who don’t use those features. Angular provides several lazy loading APIs, but how to choose between them depends on the application domain—specifically, what granularity and at what boundaries the application’s features can be divided.

Lazy Loading via Routes

The largest granularity for lazy loading is splitting bundles by the Router’s page loading unit (route). When you want to lazy load pages under a certain path together using parent-child route relationships, you can use loadChildren; when you want to lazy load a specific route, you can use loadComponent.

import { Routes } from '@angular/router';

export const routes: Routes = [
  {
    path: 'login',
    // Lazy load the login page
    loadComponent: () => import('./components/auth/login-page'),
  },
  {
    path: 'admin',
    // Lazy load the admin pages
    loadComponent: () => import('./admin/admin.component'),
    loadChildren: () => import('./admin/admin.routes'),
  },
];

In cases where accessible pages are clearly separated, such as by user permissions, introducing route-based lazy loading would likely be effective.

Lazy Loading Partial Views

Using the @defer block, parts of a component view can be made lazy-loadable. The view is loaded and initialized only when that area enters the viewport or when the user performs an action.

@defer {
  <large-component />
} @placeholder {
  <p>プレースホルダーコンテンツ</p>
}

This is an option when a specific component within a descendant view has a large impact on bundle size, and its display speed is not mission-critical. For example, calendar widgets or complex forms come to mind. The comment section of a blog post that isn’t part of the initial view would also be a prime candidate for this.

In cases where the frequency and timing of feature use vary depending on the screen area, lazy loading views with @defer would work effectively.

Lazy Loading Services

When a part of the logic, rather than the view, is deferrable, injectAsync, which I’ve introduced here, is the choice. If logic that uses a large third-party library is not needed for the initial load and its loading can be triggered when needed, that’s where injectAsync comes in.

Lazy Loading Modules

Finally, it’s a method often forgotten because it’s not an Angular API, but lazy loading at the module level can be achieved simply by using standard ES Module dynamic imports (import(...)). This is because dynamic imports are converted into lazy loading within the Angular CLI build process. If the target to be loaded is just a function, class, or constant, it doesn’t involve Angular’s dependency injection or component system, so using plain dynamic imports is sufficient.

You could split by the service that uses it—such as a library used only in specific use cases—or you could reference the service statically and then split by module inside it. This can be decided based on implementation preference. The only difference is whether the responsibility for asynchronous processing lies outside or inside the service. Personally, I think if injectAsync can cover it, that’s fine, but when complex DI provider definitions are required, I wonder if it might be better to combine it with module-level lazy loading as appropriate.

Summary

injectAsync enables bundle splitting and lazy loading at the service level by replacing DI references with dynamic imports.
It is limited to services declared with @Injectable({ providedIn: 'root' }) or @Service(), and does not support complex provider definitions.
Lazy loading methods and units provided by Angular:
- Routes: loadChildren / loadComponent
- Partial Views: @defer
- Services: injectAsync
- Other modules: import(...)

Angular: Implementing summaryResource to Signal-ize Built-in AI

Suguru Inatomi — Mon, 27 Apr 2026 07:49:00 +0000

I previously posted an article about enabling blog post summarization using the Summarizer API, which is a built-in AI feature in Chrome.

Summarize with built-in AI | AI on Chrome | Chrome for Developers

Distill lengthy articles, complex documents, or even lively chat conversations into concise and insightful summaries.

developer.chrome.com

ブログに記事要約機能を実装した（Built-in AI on Chrome） | lacolaco's marginalia

blog.lacolaco.net

This time, I tried an implementation that wraps the asynchronous processing of this Summarizer API with Angular’s Resource API for use within an Angular application. Let’s try calling the Summarizer API reactively in a way that links with the application state managed by Signals.

You can see a working sample on StackBlitz. Note that since only Chrome currently supports the Summarizer API, it will not work in browsers other than Chrome.

stackblitz.com

Prototype: `summaryResource`

First, I’ll introduce the interface of the final version, summaryResource. In the following App component, the summaryResource function is called with the input string signal bound to a textarea as an argument. The returned SummaryResource provides the Summarizer API status as a summary.summarizerAvailability() status signal and the summarized result of the input content as a summary.value() string signal.

import { Component, signal } from '@angular/core';
import { debounce, form, FormField } from '@angular/forms/signals';
import { summaryResource } from './summarized.resource';

@Component({
  selector: 'app-root',
  imports: [FormField],
  template: `
    <div>
      <h1>Built-in AI Summarizer</h1>

      <div>
        <div>
          <label for="input-text">入力テキスト</label>
        </div>
        <textarea
          id="input-text"
          [formField]="inputForm"
          placeholder="要約したい長文をここに貼り付け"
        ></textarea>
      </div>

      <section>
        @switch (summary.summarizerAvailability()) {
          @case ('unavailable') {
            <p>要約機能は利用できません。</p>
          }
          @case ('downloadable') {
            <button type="button" (click)="summary.initialize()">
              要約機能を初期化
            </button>
          }
          @case ('downloading') {
            <p>要約機能をダウンロード中…</p>
          }
          @case ('available') {
            @switch (summary.status()) {
              @case ('idle') {
                <p>テキストを入力すると要約が表示されます。</p>
              }
              @case ('loading') {
                <p>要約しています…</p>
              }
              @case ('error') {
                <p>{{ summary.error()?.message }}</p>
              }
              @case ('resolved') {
                <p>{{ summary.value() }}</p>
              }
            }
          }
        }
      </section>
    </div>
  `,
})
export class App {
  protected readonly input = signal('');
  readonly inputForm = form(this.input, (control) => {
    debounce(control, 500);
  });

  protected readonly summary = summaryResource(this.input, {
    summarizerOptions: {
      outputLanguage: 'ja',
    },
  });
}

It hides the internal asynchronous processing with a mental model similar to Angular’s built-in httpResource, and is able to represent the result of asynchronous processing for dynamic values using the Resource type.

From here, I will explain how this summaryResource is constructed.

Summarizer API

I’ve already introduced this in the aforementioned article, and since I’d like you to refer to the official documentation for the latest information, I won’t go too deep into the details of the Summarizer API itself. First, we create a function to call the Summarizer API directly from the application. In the following code, I wrote a function that wraps the detection of whether the Summarizer variable even exists in the execution environment and the calls to Summarizer.availability and Summarizer.create. This allows other parts of the application to remain unaware of the details of how to call the Summarizer API.

// ai/summarizer.ts
export const isSummarizationSupported = 'Summarizer' in self;

export async function getBuiltinAISummarizerAvailability(
  options?: SummarizerCreateCoreOptions,
): Promise<Availability> {
  if (!isSummarizationSupported) return 'unavailable';
  return Summarizer.availability(options);
}

export async function createBuiltinAISummarizer(
  options: SummarizerCreateOptions = {},
): Promise<Summarizer> {
  const availability = await getBuiltinAISummarizerAvailability(options);
  if (availability === 'unavailable') {
    throw new Error('Summarizer API is unavailable on this device.');
  }
  return Summarizer.create(options);
}

SummarizerFactory

This isn’t the essential part of this topic, but it’s a necessary piece for handling environment differences to use the Built-in AI feature in practice. I’ve set it up to switch via DI so that it swaps to a Noop implementation that summarizes nothing in environments where the Summarizer API is unavailable. Of course, it also serves as a hook point that can be replaced with any Summarizer implementation during testing.

// summarizer-factory.ts
import { Injectable } from '@angular/core';
import {
  createBuiltinAISummarizer,
  getBuiltinAISummarizerAvailability,
  isSummarizationSupported,
} from './ai/summarizer';

@Injectable({
  providedIn: 'root',
  useFactory: () =>
    isSummarizationSupported ? new BuiltinAISummarizerFactory() : new NoopSummarizerFactory(),
})
export abstract class SummarizerFactory {
  abstract availability(options?: SummarizerCreateCoreOptions): Promise<Availability>;
  abstract create(options?: SummarizerCreateOptions): Promise<Summarizer>;
}

@Injectable()
export class BuiltinAISummarizerFactory extends SummarizerFactory {
  override availability(options?: SummarizerCreateCoreOptions): Promise<Availability> {
    return getBuiltinAISummarizerAvailability(options);
  }

  override create(options?: SummarizerCreateOptions): Promise<Summarizer> {
    return createBuiltinAISummarizer(options);
  }
}

@Injectable()
export class NoopSummarizerFactory extends SummarizerFactory {
  override async availability(): Promise<Availability> {
    return 'available';
  }

  override async create(): Promise<Summarizer> {
    // Minimal stub for environments without Built-in AI API support / tests.
    return {
      summarize: async (input: string) => input,
      summarizeStreaming: () => new ReadableStream<string>(),
      destroy: () => {},
    } as unknown as Summarizer;
  }
}

SummaryResource

This is the body of the summaryResource function. It’s a bit complex, so let’s look at the parts one by one.

First, regarding the SummaryResource type that serves as the function’s return value. This adds two fields to the Resource<T> type provided by Angular. summarizerAvailability is, as the name suggests, a signal representing the availability status of the Summarizer instance itself. And the other, initialize, is a function to explicitly trigger the creation of the Summarizer instance.

/**
 * Resource returned by {@link summaryResource}.
 * Standard Resource<string> with Summarizer-specific properties added.
 */
export interface SummaryResource extends Resource<string> {
  /** Summarizer availability. Reflects the return value of Summarizer.availability(). */
  readonly summarizerAvailability: Signal<Availability>;

  /**
   * Creates a Summarizer and starts summarization. Idempotent.
   * When `summarizerAvailability()` is `'downloadable'`, it must be called from a user-initiated action (e.g., a click).
   */
  initialize(): void;
}

Why is initialize necessary? It’s because the AI model used internally by the Summarizer API is downloaded on-demand when needed, but the specification states that user activation is required to start that download. In other words, it cannot be started by events like page loading; it must be triggered by a user interaction event such as a button click.

If the device can support built-in AI APIs, but the model is not yet downloaded, the user must meaningfully interact with your page for your application to start a session with create().

Therefore, in summaryResource, I’ve added a conditional branch to automatically call initialize only when the result of calling factory.availability is available or downloading, as follows.

export const summaryResource = (
  source: () => string,
  options: {
    summarizerOptions?: SummarizerCreateOptions;
    injector?: Injector;
  } = {},
): SummaryResource => {
  const injector = options.injector ?? inject(Injector);
  const factory = injector.get(SummarizerFactory);
  const summarizerOptions = options.summarizerOptions;

  const state = signal<ResourceSnapshot<string>>({ status: 'idle', value: '' });
  const summarizerAvailability = signal<Availability>('unavailable');

  let initialized = false;

  const initialize = async () => {
    if (initialized) {
      return;
    }
    initialized = true;
    // ...
  }

  factory.availability(summarizerOptions).then((availability) => {
    if (availability === 'unavailable') {
      initialized = true;
      state.set({ status: 'idle', value: '' });
      return;
    }
    if (availability === 'available' || availability === 'downloading') {
      initialize();
    }
  });

  return {
    ...resourceFromSnapshots(state),
    summarizerAvailability,
    initialize,
  };
};

Next, regarding the creation of the Summarizer instance. As shown below, in the initialize function, the factory.create function is called to create the Summarizer instance. This factory.create function’s Promise will wait for the model download. In other words, by the time the Promise resolves, summarizerAvailability is available.

Also, in coordination with the destruction of the Resource, I am using DestroyRef to perform the instance destruction of the Summarizer. This prevents unintended memory leaks.

export const summaryResource = (
  source: () => string,
  options: {
    summarizerOptions?: SummarizerCreateOptions;
    injector?: Injector;
  } = {},
): SummaryResource => {
  const injector = options.injector ?? inject(Injector);
  const destroyRef = injector.get(DestroyRef);
  const factory = injector.get(SummarizerFactory);
  const summarizerOptions = options.summarizerOptions;

  const state = signal<ResourceSnapshot<string>>({ status: 'idle', value: '' });
  const summarizerAvailability = signal<Availability>('unavailable');

  let initialized = false;
  let activeSummarization: Promise<string> | null = null;

  const initialize = async () => {
    if (initialized) {
      return;
    }
    initialized = true;

    const summarizer = await factory.create(summarizerOptions);
    summarizerAvailability.set('available');
    destroyRef.onDestroy(() => {
      summarizer.destroy();
    });
  };

  return {
    ...resourceFromSnapshots(state),
    summarizerAvailability,
    initialize,
  };
};

Finally, the implementation of the part that reactively summarizes the input text. In the following code, an effect is declared inside the initialize function. This effect subscribes to the source signal, and whenever source is updated, this function is re-executed. If the input text is not empty, it calls the summarizer.summarize function to generate a summary. Since this summarization process takes time, there is a possibility that the input text has been updated while it is summarizing. The key point is that I’ve implemented state management with an activeSummarization variable, as well as cancellation processing using an AbortController and the onCleanUp function, so that old summaries are not processed unnecessarily.

export const summaryResource = (
  source: () => string,
  options: {
    summarizerOptions?: SummarizerCreateOptions;
    injector?: Injector;
  } = {},
): SummaryResource => {
  const injector = options.injector ?? inject(Injector);
  const destroyRef = injector.get(DestroyRef);
  const factory = injector.get(SummarizerFactory);
  const summarizerOptions = options.summarizerOptions;

  const state = signal<ResourceSnapshot<string>>({ status: 'idle', value: '' });
  const summarizerAvailability = signal<Availability>('unavailable');

  let initialized = false;
  let activeSummarization: Promise<string> | null = null;

  const initialize = async () => {
    //...

    effect(
      (onCleanUp) => {
        const input = source();
        if (!input.trim()) {
          state.set({ status: 'idle', value: '' });
          return;
        }

        const abortController = new AbortController();
        onCleanUp(() => {
          abortController.abort();
        });

        const summarizePromise = summarizer.summarize(input, { signal: abortController.signal });
        activeSummarization = summarizePromise;

        state.set({ status: 'loading', value: '' });
        summarizePromise
          .then((result) => {
            // Reflect only the latest Promise to avoid overwriting the new state with the results of an old summarize call.
            if (activeSummarization === summarizePromise) {
              state.set({ status: 'resolved', value: result });
            }
          })
          .catch((error) => {
            if (activeSummarization === summarizePromise) {
              state.set({ status: 'error', error });
            }
          });
      },
      { injector },
    );
  };

  //...

  return {
    ...resourceFromSnapshots(state),
    summarizerAvailability,
    initialize,
  };
};

By combining these, the summaryResource mentioned at the beginning is completed. If you want to read the entire source code, you can check it on StackBlitz or GitHub.

lacolaco / angular-built-in-ai

AngularBuiltInAi

This project was generated using Angular CLI version 21.2.8.

Development server

To start a local development server, run:

ng serve

Once the server is running, open your browser and navigate to http://localhost:4200/. The application will automatically reload whenever you modify any of the source files.

Code scaffolding

Angular CLI includes powerful code scaffolding tools. To generate a new component, run:

ng generate component component-name

For a complete list of available schematics (such as components, directives, or pipes), run:

ng generate --help

Building

To build the project run:

ng build

This will compile your project and store the build artifacts in the dist/ directory. By default, the production build optimizes your application for performance and speed.

Running unit tests

To execute unit tests with the Vitest test runner, use the following command:

ng test

Running end-to-end tests

For end-to-end (e2e) testing, run:

ng e2e

Angular CLI…

View on GitHub

Summary

I prototyped summaryResource to reactively handle the Summarizer API, a Chrome Built-in AI, using Angular’s Resource API and Signals.
SummaryResource extends Resource<string> and provides summarizerAvailability, which indicates the availability of the Summarizer, and initialize(), which is used to initialize from a user operation.
Since on-demand model downloading requires user activation, it is designed to either auto-initialize based on availability or have initialize() called explicitly from a button or similar.
In the implementation, I switched SummarizerFactory via DI to allow falling back to a Noop implementation in unsupported environments.
Input text summarization is subscribed to via effect, and by using an AbortController and a guard that only reflects the latest Promise, it follows input updates while avoiding unnecessary processing or conflicts.

Angular v22: Introducing ChangeDetectionStrategy.Eager and OnPush By Default

Suguru Inatomi — Wed, 22 Apr 2026 14:43:00 +0000

In Angular v21.2, ChangeDetectionStrategy.Eager was newly added as an option for a component’s change detection strategy. That said, this has exactly the same behavior as the existing ChangeDetectionStrategy.Default; it’s essentially just an alias.

As of v21, you can choose between Eager (= Default) and OnPush for the change detection strategy, but in v22, OnPush will finally become the default. A migration path for existing projects is also planned, so I’ll explain that here.

Default-to-Eager Migration

Through the ng update migration to Angular v22, components that have no strategy specified or are set to Default will be automatically rewritten to Eager. Because of this, applications in existing projects will continue to operate with the same change detection behavior as before, so no breaking changes should occur.

OnPush By Default

Starting from v22, the change detection strategy for components generated via ng new or ng generate will be OnPush by default. Of course, if you have explicitly set component generation options to changeDetection: Eager in your configuration files, that will be applied, but otherwise, new code will operate in OnPush mode without any extra effort.

Eager-to-OnPush Migration?

For now, there doesn’t seem to be any discussion about deprecating Eager mode. While OnPush has performance advantages, there is likely no need to rush the migration of existing code. When you do proceed with migration, it often goes smoothly if you first migrate the component’s internal state to a Signal. The primary reason a component stops working after switching to OnPush is when class fields are being modified internally, but if those fields are Signal instances, the template will automatically subscribe to changes in the Signal.

@Component({
  template: `
- <div>{{ userData?.name }}</div>
+ <div>{{ userData()?.name }}</div>
  `,
  changeDetection: ChangeDetectionStrategy.OnPush,
})
export class Component {
   private userService = inject(UserService);

- userData?: UserData | undefined;
+ readonly userData = signal<UserData | undefined>(undefined);

loadUserData() {
    this.userService.getUserData().then((data) => {
- this.userData = data;
+ this.userData.set(data);
    });
  }
}

The reason the Angular team wants to promote OnPush more than ever is that they want to encourage the “Zoneless-ification” of existing projects. To strip away the dependency on Zone.js, moving to OnPush is recommended. While not strictly required, if everything is running entirely on OnPush, you can guarantee that Zone.js is no longer needed. Conversely, if there are components running in Eager mode, the possibility of a dependency on Zone.js cannot be entirely ruled out.

The Angular MCP Server also provides a tool called onpush_zoneless_migration to assist with OnPush migration and going Zoneless using AI agents.

Even though existing code will continue to work as is, I expect the future Angular ecosystem will evolve with the general assumption that “OnPush is the default.” If you want to receive those benefits without exception, then the path toward OnPush and Zoneless migration will likely be an unavoidable one.

Summary

In Angular v22, ChangeDetectionStrategy.Eager is treated as the successor to Default.
For existing code, components set to Default or with no strategy specified will be automatically migrated to Eager via ng update, preserving their behavior.
Newly created components will use OnPush by default.
There is no need to migrate existing Eager components immediately, but the ecosystem will likely shift toward an OnPush prerequisite in the future.

Angular v22: Explaining debounced Resource

Suguru Inatomi — Wed, 08 Apr 2026 02:03:00 +0000

In Angular v22, it looks like debounced will be newly added to the Signals API family. I’ll explain the use cases and the mechanism for this API.

`debounced()`

The debounced function returns a Resource object with a certain wait time when changes to the source Signal are high-frequency. After a change to the source occurs, the value is finalized if no additional changes happen during the wait time. The mental model is similar to debounce in jQuery or RxJS.

export function debounced<T>(
  source: () => T,
  wait: NoInfer<number | ((value: T, lastValue: ResourceSnapshot<T>) => Promise<void> | void)>,
  options?: NoInfer<DebouncedOptions<T>>,
): Resource<T>

The following pseudo-code illustrates the behavior. While a Signal is a data model that always returns values synchronously, what the debounced function returns is a Resource object. Its value property returns a Signal that doesn’t change during the wait time. During the wait time, the isLoading property of the Resource will also be true.

const source = signal('initial');
const res = debounced(source, 200);

source(); // => initial
res.value(); // => initial
res.isLoading(); // => false

source.set('updated');
source(); // => updated
res.value(); // => initial
res.isLoading(); // => true

tick(200);

source(); // => updated
res.value(); // => updated
res.isLoading(); // => false

The primary concrete use case will likely be integration with Signal Forms. In cases where an HTTP request is triggered based on a Signal bound to a text field, you’ll want to debounce the user’s input. For example, you can create an HTTP Resource that calls an API with the value after waiting for a 200ms interval from the username field input, like this:

const usernameForm = form(signal('foobar'));
const res = httpResource(() => `/api/users/${debounced(usernameForm.value, 200)}`);

A similar use case is asynchronous validation in Signal Forms. This has been added as a built-in feature where a debounce option is available in the validateHttp function, allowing for HTTP-based validation by debouncing form value updates. Internally, the debounced function is being called.

const usernameForm = form(
  signal('foobar'),
  (p) => {
    validateHttp(p, {
      request: ({value}) => `/api/check?username=${value()}`,
      debounce: 50, // Short debounce
      onSuccess: (available: boolean) => (available ? undefined : {kind: 'username-taken'}),
      onError: () => null,
    });
  },
  {injector},
);

I think this mostly explains what the debounced function is. From here, let’s look at its mechanism.

Mechanism

As in the example where I wrapped Firestore the other day, Resource is an interface, and you’re free to choose how to construct it. Even if you don’t use the built-in resource or httpResource functions, you can still create objects that follow the Resource interface. While the actual debounced function has a complex implementation including fine-grained error handling within the framework, let’s try to understand the mechanism by creating a simplified version of a debounced function ourselves.

First, as a base form, let’s create a function that returns a Resource that doesn’t do anything. From Angular v21.2 onwards, you can use the resourceFromSnapshots function to convert a Signal of a specific type into a Resource.

function debounced<T>(source: () => T): Resource<T> {
  const state = signal<ResourceSnapshot>({
    status: 'resolved',
    value: untracked(() => source()),
  });
  return resourceFromSnapshots(state);
}

With just this, changes to the source won’t propagate to the Resource. We need to use an effect to update the state when the source changes.

function debounced<T>(source: () => T): Resource<T> {
  const state = signal<ResourceSnapshot>({
    status: 'resolved',
    value: untracked(() => source()),
  });

  effect(() => {
    const changedValue = source();

    state.set({
      status: 'resolved',
      value: changedValue,
    });
  });

  return resourceFromSnapshots(state);
}

Next, we’ll introduce a wait time. By accepting an interval as an argument and passing it to setTimeout, we can delay reflecting the value in the state. While it’s delayed, we’ll keep the state in a loading status.

function debounced<T>(source: () => T, wait: number): Resource<T> {
  const state = signal<ResourceSnapshot>({
    status: 'resolved',
    value: untracked(() => source()),
  });

  effect(() => {
    const changedValue = source();

    setTimeout(()=> {
      state.set({
        status: 'resolved',
        value: changedValue,
      });
    }, wait);

    state.set({
      status: 'loading',
      value: state.value(),
    });
  });

  return resourceFromSnapshots(state);
}

Currently, it’s just delaying. If an additional change is triggered during the delay, we need to discard the ongoing wait time and wait for the value to stabilize again. To maintain this asynchronous state, let’s introduce local variables called activePromise and pendingValue. In the delayed callback via setTimeout, if the active matches, it means no additional changes occurred.

function debounced<T>(source: () => T, wait: number): Resource<T> {
  const state = signal<ResourceSnapshot>({
    status: 'resolved',
    value: untracked(() => source()),
  });

  effect(() => {
    const changedValue = source();

    const waiting = new Promise(resolve => {
      setTimeout(resolve, wait)
    });

    const activePromise = waiting;
    const pendingValue = changedValue;

    waiting.then(() => {
      // If there is an intervening change, activePromise will mismatch
      if (waiting === activePromise) {
        state.set({
          status: 'resolved',
          value: pendingValue,
        });
      }
    });

    state.set({
      status: 'loading',
      value: state.value(),
    });
  });

  return resourceFromSnapshots(state);
}

Now our simplified debounced function is complete. Although it differs from the actual framework implementation in the finer details, the basic design looks like this. The internals are simple, just managing state with a Promise and a timer.

What I’m trying to say is that creating a function that returns a Resource type is easy. When you want to integrate processing with asynchronicity into a Signal, the hurdle to creating your own is low, even if the built-in APIs don’t fit perfectly. One example of that was turning the Firestore Collection into a Resource in my previous post.

Summary

The debounced() function expected to be introduced in Angular v22 takes a high-frequency Signal as input and returns a Resource that finalizes the value once it has settled for a certain period.
Typical usage is “debouncing input,” such as HTTP Resources linked to form inputs or asynchronous validation in Signal Forms.
The key point of the implementation is monitoring input changes with an effect, managing the latest wait using a timer and a Promise, and updating the ResourceSnapshot to resolved when finalized.
Creating a function that returns a Resource type is not difficult. It’s a useful interface that can be used to integrate asynchronous data sources with Signal.

Building Browser Extensions with WXT + Angular

Suguru Inatomi — Mon, 12 Jan 2026 09:08:00 +0000

I created a starter template for developing browser extensions by combining WXT and Angular. You can efficiently develop extensions for multiple browsers including Chrome and Firefox using Angular’s latest features.

lacolaco / wxt-angular-starter

Browser extension starter template using WXT and Angular

WXT + Angular Starter

A browser extension starter template using WXT and Angular.

Features

Angular 21 with zoneless change detection
Tailwind CSS v4 for styling
WXT for cross-browser extension development
Vite 7 powered build system
TypeScript with strict mode

Quick Start

# Clone the repository
git clone https://github.com/user/wxt-angular-starter.git
cd wxt-angular-starter

# Install dependencies
pnpm install

# Start development server (Chrome)
pnpm dev

# Start development server (Firefox)
pnpm dev:firefox

Available Scripts

Script	Description
`pnpm dev`	Start dev server for Chrome
`pnpm dev:firefox`	Start dev server for Firefox
`pnpm build`	Build for Chrome
`pnpm build:firefox`	Build for Firefox
`pnpm zip`	Build and package for Chrome
`pnpm zip:firefox`	Build and package for Firefox
`pnpm compile`	Type-check without emitting

Project Structure

├── entrypoints/
│   ├── popup/          # Angular popup entrypoint
│   │   ├── index.html
│   │   ├── main.ts     # Angular bootstrap
│   │   ├── app.ts      # Root component
│   │   └── style.css

…

View on GitHub

What is WXT

https://wxt.dev/

WXT is a framework that streamlines browser extension development. Built on Vite, it provides a comfortable development experience with fast HMR (Hot Module Replacement) and a file-based manifest auto-generation system.

Particularly useful is its ability to generate extensions for multiple browsers including Chrome, Firefox, Edge, and Safari from a single codebase. It supports both Manifest V2 and V3, absorbing browser-specific differences.

Building Browser Extensions with Angular

For the UI part of browser extensions, you’ll be loading HTML. WXT officially supports several libraries. When you run the wxt init command, you can choose templates like Vanilla, React, or Vue, but there’s no Angular template yet. However, the setup isn’t too difficult - you can simply configure Angular on top of the Vanilla base.

Note that to run Angular with Vite, you need the @analogjs/vite-plugin-angular plugin. This plugin is provided by the AnalogJS project and enables Angular to work within the Vite ecosystem.

https://www.npmjs.com/package/@analogjs/vite-plugin-angular

Project Structure

The starter template has the following structure:

├── entrypoints/
│ ├── popup/ # Angular popup interface
│ │ ├── index.html
│ │ ├── main.ts # Angular bootstrap
│ │ ├── app.ts # Root component
│ │ └── style.css # Tailwind CSS
│ ├── background.ts # Background script
│ └── content.ts # Content script
├── wxt.config.ts # WXT configuration
├── tsconfig.json # Base TypeScript config
└── [tsconfig.app](http://tsconfig.app/).json # Angular-specific config

In WXT, manifests are automatically generated from files in the entrypoints directory. The popup directory serves as the entry point for the Angular application, while background.ts and content.ts can be written in plain TypeScript.

Setup Steps

Here are the steps to build from scratch.

1. Initialize WXT Project

First, create a WXT project:

pnpm dlx wxt@latest init my-extension
cd my-extension

2. Install Dependencies

Install Angular core and build tools:

# Angular core
pnpm add @angular/core @angular/common @angular/compiler @angular/platform-browser rxjs

# Build tools
pnpm add -D @analogjs/vite-plugin-angular @angular/build @angular/compiler-cli

# Tailwind CSS (optional)
pnpm add -D tailwindcss @tailwindcss/vite

3. Pin Vite Version

Since @analogjs/vite-plugin-angular requires Vite 7.x, pin the version in package.json:

{
  "pnpm": {
    "overrides": {
      "vite": "^7.3.0"
    }
  }
}

After adding this, run pnpm install to apply the version.

4. Configure WXT

Configure Vite plugins in wxt.config.ts:

import { defineConfig } from 'wxt';
import angular from '@analogjs/vite-plugin-angular';
import tailwindcss from '@tailwindcss/vite';

export default defineConfig({
  vite: () => ({
    resolve: {
      mainFields: ['module'], // Prioritize ESM
    },
    plugins: [
      angular({
        tsconfig: '[tsconfig.app](http://tsconfig.app/).json',
        // Limit Angular compilation to specific entrypoints
        transformFilter: (_code: string, id: string) => {
          return id.includes('/entrypoints/popup/');
        },
      }),
      tailwindcss(),
    ],
  }),
});

The key is the transformFilter configuration. This ensures that only files in the entrypoints/popup/ directory are processed by the Angular compiler. Background and content scripts are treated as plain TypeScript, allowing coexistence of code that doesn’t use Angular.

5. Configure TypeScript

Separate project-wide configuration from Angular-specific configuration.

tsconfig.json (project-wide):

{
  "extends": "./.wxt/tsconfig.json",
  "compilerOptions": {
    "experimentalDecorators": true,
    "useDefineForClassFields": false
  },
  "angularCompilerOptions": {
    "strictInjectionParameters": true,
    "strictInputAccessModifiers": true,
    "strictTemplates": true
  }
}

tsconfig.app.json (Angular-specific):

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "ES2022",
    "moduleResolution": "bundler",
    "lib": ["ES2022", "DOM"],
    "strict": true,
    "experimentalDecorators": true,
    "useDefineForClassFields": false,
    "skipLibCheck": true,
    "isolatedModules": true
  },
  "angularCompilerOptions": {
    "strictInjectionParameters": true,
    "strictInputAccessModifiers": true,
    "strictTemplates": true
  },
  "include": ["entrypoints/popup/**/*.ts"]
}

The include limits the files processed by the Angular compiler. If you want to use Angular in other entrypoints like options pages, add them here.

6. Create Angular Popup

Finally, create the entry point for the Angular application.

entrypoints/popup/index.html:

<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>My Extension</title>
    <meta name="manifest.type" content="browser_action" />
  </head>
  <body>
    <app-root></app-root>
    <script type="module" src="./main.ts"></script>
  </body>
</html>

entrypoints/popup/main.ts:

import './style.css';
import { bootstrapApplication } from '@angular/platform-browser';
import { provideZonelessChangeDetection } from '@angular/core';
import { App } from './app';

bootstrapApplication(App, {
  providers: [provideZonelessChangeDetection()],
}).catch((err: unknown) => console.error(err));

entrypoints/popup/app.ts:

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

@Component({
  selector: 'app-root',
  changeDetection: ChangeDetectionStrategy.OnPush,
  host: { class: 'block p-4' },
  template: `
    <h1 class="text-lg font-bold">Hello from Angular!</h1>
  `,
})
export class App {}

entrypoints/popup/style.css:

@import 'tailwindcss';

Since we’re now on Angular v21, I’m using provideZonelessChangeDetection() to enable change detection without Zone.js. In limited environments like browser extensions, Zone.js overhead is often wasteful, so this reduces bundle size and minimizes runtime overhead.

Development and Build

Once setup is complete, you can start the development server:

# Chrome dev server
pnpm dev

# Firefox dev server
pnpm dev:firefox

For production builds and packaging:

# Chrome build
pnpm build

# Firefox build and ZIP
pnpm zip:firefox

Summary

Combining WXT and Angular enables modern browser extension development. The appeal is being able to leverage both WXT’s excellent developer experience and Angular’s powerful features. Using this starter template, you can start development immediately without the setup hassle.

The repository mentioned at the beginning is published as a GitHub template repository, so if you’re interested, click Use this template on the repository to create your own browser extension.

Understanding Angular Ivy Library Compilation

Suguru Inatomi — Wed, 24 Feb 2021 07:13:34 +0000

Original Post: https://blog.lacolaco.net/2021/02/angular-ivy-library-compilation-design-in-depth-en/

In this post, I will explain how to compile Angular libraries with Ivy, which is now possible in Angular v11.1, and its details. The intended audience is those who are developing Angular third-party libraries, or simply interested in Angular’s internal mechanism. You don’t need to know anything in this article to develop Angular applications.

The content of this article is based on the Design Doc written by the Angular team.

Ivy Library Compilation - Conceptual Design Doc

How to compile libraries with Ivy

When you develop an Angular library using Angular CLI or something similar, Ivy is currently disabled for production build. It is probably set in a file like src/tsconfig.lib.prod.json as follows.

{
  "angularCompilerOptions": {
    "enableIvy": false
  }
}

Angular libraries compiled and published to NPM with this configuration are still compatible for use even if the applications are not Ivy-enabled.

Starting from Angular v11.1, you can experimentally remove compatibility for applications not yet Ivy-enabled, and compile the library optimized for Ivy-enabled applications. To use Ivy compilation for libraries to be published to NPM, configure as follows

{
  "angularCompilerOptions": {
    "enableIvy": true,
    "compilationMode": "partial"
  }
}

"compilationMode": "partial" is an important part, and I will explain what it means in the later part of this post. Of course, libraries compiled with this setting can only be used in Ivy-enabled applications, so it is still not currently recommended.

By the way, for libraries that are only used locally in monorepo, such as Angular CLI and Nrwl/Nx, you can simply use enableIvy: true. The "compilationMode": "partial" is required only for the libraries that are published in NPM. This difference is also explained later in this article.

{
  "angularCompilerOptions": {
    "enableIvy": true
  }
}

Terminology

In order to make the following explanations concise, let’s first sort out the terminology.

term	meaning
Angular decorators	Decorators defined by Angular such as `@Component`, `@Directive`, and `@Injectable`.
Compiler	The Angular compiler is a tool that analyzes Angular decorators and generates executable code.
`ngc`	An executable CLI for the Angular compiler
Ivy compiler	A compiler introduced in Angular v9
View Engine (VE) compiler	A deprecated compiler that was used by default until Angular v8

Ivy compilation for applications

Before we start talking about libraries, let’s start with compiling an application with Ivy already enabled by default. The Angular decorator in the application will be analyzed by the compiler to generate the executable code based on the extracted metadata.

Let’s look at an example of compiling a simple component. Suppose we have the following component.

@Component([
  selector: 'some-comp',
  template: `<div> Hello! </div>`
})
export class SomeComponent {}

If you compile this code with Ivy, you will get the following JavaScript output. The two points are as follows

The decorator does not remain in the JavaScript.
The generated code is inserted as a static field in the component class.

export class SomeComponent {}
SomeComponent.ɵcmp = ɵɵdefineComponent({
  selectors: [['some-comp']],
  template: (rf) => {
    if (rf & 1) {
      ɵɵelementStart('div');
      ɵɵtext(' Hello! ');
      ɵɵelementEnd();
    }
  },
});

The Ivy compiler generates the code to create the definition from the metadata contained in the decorator. The HTML template, which was a string, becomes executable code as a Template Function. The ɵɵelementStart and ɵɵtext used in the template functions are called Template Instructions , and abstract the concrete DOM API calls and data binding update process.

Angular compilation is internally divided into two steps; Analysis step and code generation step.

Analysis step

In the analysis step of compilation, it integrates the metadata obtained from the decorators of the entire application and detects the dependencies between components/directives. At this point, the important part is the @NgModule. It is used to determine the references corresponding to unknown HTML tags and attributes contained in templates. After the analysis step, the compiler gets the following information.

Which components depend on which directives/components
What dependencies are needed to instantiate each component/directive

Code generation step

In the code generation step, it generates the code for each Angular decorator based on the information obtained in the analysis step. The generated code has two requirements: Locality and Runtime Compatibility.

Locality

Locality is also expressed as self-contained. It means that all the references needed for compiling the component are included in the component class itself. This makes differential builds more efficient. To make it easier to understand, let’s look back at the issues in the pre-Ivy View Engine days without Locality.

The VE compiler generated code as a file named *.ngfactory.js which was independent of the original file. Angular executes this *.ngfactory.js at runtime, and the generated code refers to the original component class. This approach becomes problematic when a component depends on another component.

For example, when a component <app-parent> uses a template to call a component <app-child>, there is no reference from parent.component.ts to child.component.ts as a JavaScript module. This parent-child dependence is only visible between parent.component.ngfactory.js and child.component.ngfactory.js.

Since the direct compilation result, parent.component.js, does not refer to either child.component.js or child.component.ngfactory.js, it cannot determine when it needs to be recompiled. Therefore, ViewEngine had to recompile the entire application at each build time.

To solve this problem, the Ivy compiler generates the code as a static field of the class. In the generation code, the classes of the directives referenced in the template are included. This makes it easy to determine which files will be affected when that file is changed.

As you can see, with code generation with Locality, it is only necessary to recompile ParentComponent when itself or ChildComponent is changed.

// parent.component.js
import { ChildComponent } from './child.component';

ParentComponent.ɵcmp = ɵɵdefineComponent({
    ...
    template: function ParentComponent_Template(rf, ctx) {
        if (rf & 1) {
            ɵɵelement(2, "app-child");
        }
    },
    // Directives depended on by the template
    directives: [ChildComponent]
});

Runtime compatibility

Another important factor in code generation is runtime compatibility. This is not an issue when compiling an application, but it is critical for compiling a library.

In an application, the compiler version and the Angular runtime version basically match because the compilation is done at the same time in the application build. However, this is not the same for libraries.

For libraries published to NPM, it must be considered that the Angular version that compiles the library does not match the Angular version used by the application that uses the library at runtime. A big issue here is the compatibility of the Angular APIs called in the generated code. APIs that existed in the compile-time version may not exist in the runtime version of Angular, or their signatures may have changed. So, the rules for code generation must be determined by the Angular version of the runtime that executes it.

Libraries used locally within monorepo were Ivy compilable because as long as it is in monorepo, it is ensured that the library and the application have the same Angular version.

Library compilation

Here is the main topic. First, let’s look at compiling libraries with enableIvy: false, which is the current recommended setting for v11. Compiling a library with no Ivy is just inlining the metadata collected in the analysis step. The Angular decorator metadata is embedded in the static field as shown below.

The library compilation works to convert the metadata into a JavaScript representation that can be published to NPM. However, this is still a metadata and cannot be executed as a component when loaded into an application. It needs to be compiled again based on this metadata. Angular Compatibility Compiler , ngcc, is the tool to do it.

ngcc

As we don’t know whether the application side compiler is Ivy or VE, the only way to keep compatibility is to compile the library code on the application side. This is the reason why ngcc is run at application build time.

The compilation result of ngcc is the same as that of compiling the library directly. The difference is that ngc uses decorators in TypeScript as metadata, while ngcc uses .decorators in JavaScript as metadata.

Although ngcc achieved its purpose to allow libraries to be released to NPM with compatibility, the frequent compilations spoiled the developer experience. Many of you may have felt the frustration of running ngcc repeatedly every time you installed a library. The ngcc overwrites the library code in node_modules installed from NPM and compiles it, so if the contents of node_modules are changed by the npm install command, you have to recompile it.

But originally, ngcc is a temporary approach until the View Engine support is removed from applications. The Ivy library compiler, which will be explained below, is a new Ivy-native library compilation mechanism that solves the problems clarified by ngcc.

Ivy library compilation

The biggest issue with ngcc was the execution cost of the compilation on the application side. If ngcc was fast enough, we could have compiled the library just-in-time when the application was compiled, without persisting the compilation results in node_modules. The execution cost is high, so we want to reduce the number of times and save the results.

On the other hand, if we finish compiling the library before publishing it, we can build the application faster, but we lose runtime compatibility. The code generation step really needs to be done in the application’s Angular version.

So Ivy library compilation concept is a set of mechanism for running only the code generation step rapidly after library installation and mechanism for finishing the analysis step before NPM release. The first mechanism is called library linking , and the second mechanism is called Link-Time Optimization (LTO) compilation.

LTO compilation (Pre-Publish compilation)

LTO compilation, which is done before publishing to NPM, is a mechanism to complete only the analysis step of the entire compilation and embed the result in JavaScript. As mentioned in the Introduction, when the setting "compilationMode": "partial" is set, the compiler will perform LTO compilation of the library.

{
  "angularCompilerOptions": {
    "enableIvy": true,
    "compilationMode": "partial"
  }
}

The compiled JavaScript contains the following code. It looks similar to the normal compilation result, but the important thing is that the template is preserved as a string and it has Locality.

The information obtained from the analysis step is inlined as a declaration. It includes a list of directives on which it depends, and has a locality that allows it to execute the code generation step with only information in the file. And by deferring the code generation of template functions until they are linked, the library can ensure runtime compatibility.

Also, the Angular version of the LTO compilation is included. Even if the template is the same, it can be optimized at link time depending on the combination of both the version it is written in and the runtime version.

Linking libraries

An application that installs an LTO compiled library will link it at the building time just-in-time. The Linker , which does the linking, will generate code based on the declarations from the LTO compilation, and replace them with definitions that can be used by the application.

Unlike ngcc, which required analysis step, the linking process can be executed independently for each file thanks to Locality of LTO compilation, so it can work as a plugin in module resolution like webpack. In the Angular CLI build, it is implemented as a Babel plugin called AngularLinker.

Wrap-up

The new Ivy library compilation can be summarized as follows:

The library compilation is separated into two parts: before and after NPM release.
One is the LTO compile process that finishes the decorator analysis before publishing to NPM.
The other is the linking process, which completes the compilation of the library by generating code at application build time.

I hope this article will help you readers understand how new Ivy library compilation is designed, based on the differences between applications and libraries in compilation, and the issues of ngcc used today.

DEV Community: Suguru Inatomi

Angular: Router Resources Explained

How to Use Router Resources

Blocking Data Fetching During Navigation

Non-blocking Data Fetching

Parallel Execution of Data Fetching Across Parent and Child Routes

Appendix: Depending on a Parent Route’s Resource

Reloading Without Re-navigation

Reactive Data Fetching Based on Query Parameters

Data Fetching with httpResource

Points to Consider

Summary

Summary of the Angular v22.2 Update

angular/angular

Allowing Access to Private Members from Templates

Addition of strictUnclaimedEventNames

Addition of @Component.deferredImports

Addition of ErrorBoundary Feature

Addition of Testing Utilities for Directives

Retrieving Injector in View and Content Queries

Specifying Fixed Hidden Fields in Signal Forms

Public Release of containsTree API

Redirecting via throwing RedirectCommand

Public Release of Router Resources API

Stabilization of Automatic Injector Cleanup per Route

Encapsulation Support for CSS Native Nesting Syntax

Binding Functions and Signals to animate.enter and animate.leave

angular/angular-cli

Specifying the Root Directory for MCP Servers

Narrowing the Compilation Scope Based on Test Targets

Migration to Native Implementation for File Watching

Migration to Native Implementation for the Sass Compiler

Pre-compilation of Critical CSS Processing for SSR

angular/components

Automatic Detection of Material Symbols

Support for disabledInteractive in MatMenuItem

Angular Aria: Support for Omitting value in MenuItem

Signal Forms Support for MatFormFieldControl

Angular: Rethinking the Semantics of Private Fields

Content of the Update

Background of the Change

Semantics of Component Class Fields

A Proposal for Semantics in the New Specification

Strategy 1: Maintain Information Hiding within the Component

Strategy 2: Replace Information Hiding with Separation of Concerns

The Two Strategies

Adoption of oxc-parser in Angular v22.1

The Role of oxc-parser

Changes in @angular/build

Before Migration: AST Editing with Babel Plugins

After Migration: String Editing with magic-string

Path Bypassing Babel

Future Outlook

Angular Update Guide Skill for Agents

Update guide • Angular

lacolaco / angular-skills

Unofficial agent skills for working with Angular.

angular-skills

Skills

Install

Usage

angular-update-guide : what breaks between two Angular majors

Angular: Resource API Family System Diagram

Resource API Family

Resource<T> Interface

WritableResource<T> Interface

ResourceSnapshot<T> Interface

resourceFromSnapshots Function

resource Function

httpResource Function

Summary

Angular v22: Lazy Loading Business Logic with injectAsync

injectAsync

Usage Constraints

Lazy Loading Methods and Use Cases

Lazy Loading via Routes

Lazy Loading Partial Views

Lazy Loading Services

Lazy Loading Modules

Summary

Data Fetching with `httpResource`

Addition of `strictUnclaimedEventNames`

Addition of `@Component.deferredImports`

Retrieving `Injector` in View and Content Queries

Public Release of `containsTree` API

Redirecting via throwing `RedirectCommand`

Binding Functions and Signals to `animate.enter` and `animate.leave`

Support for `disabledInteractive` in `MatMenuItem`

Angular Aria: Support for Omitting `value` in `MenuItem`

Signal Forms Support for `MatFormFieldControl`

`angular-update-guide` : what breaks between two Angular majors

`Resource<T>` Interface

`WritableResource<T>` Interface

`ResourceSnapshot<T>` Interface

`resourceFromSnapshots` Function

`resource` Function

`httpResource` Function

`injectAsync`

Prototype: `summaryResource`

`debounced()`