Ninja Squad Blog

What's new in Angular 21.2?

2026-02-26T00:00:00Z

Angular 21.2.0 is here!

Angular 21.2 is the second minor release of the v21 cycle. Let's dive in!

Templates

Arrow functions

One of the most requested template syntax improvements is finally here: we can now use arrow functions directly in templates.

<button (click)="count.update(n => n + 1)">+1</button>

Note that you can't use an arrow function in an event listener to call a method. (click)="() => doSomething()" will not work, and will throw the following error at compile time:

Arrow function will not be invoked in this event listener. Did you intend to call a method?

instanceof is now also supported in templates, but I don't think we ever missed this one 🤷.

Exhaustive `@switch` checks

Angular now supports exhaustive type-checking for control-flow @switch blocks. You can opt in by ending the switch with @default never;.

@switch (status()) {
  @case ('idle') { 
    <p>Idle</p> 
  }
  @case ('loading') { 
    <p>Loading</p>
  }
  @default never;
}

If status() can also be another value (for example 'error'), the template type-checker now reports it at compile time:

[ERROR] TS2322: Type '"error"' is not assignable to type 'never'. [plugin angular-compiler]

    src/app/live/live.html:7:13:
      7 │     @switch (status()) {

I'm super happy to see this landing, as I opened the original feature request when the control flow syntax was announced, back in 2023 😍.

ChangeDetectionStrategy.Eager

No, this is not a new change detection strategy, but an alias for ChangeDetectionStrategy.Default. This is part of the ongoing effort to change the default change detection strategy to OnPush, as you can read in the official RFC.

In the next major release, the default change detection strategy will be switched to OnPush, and the Eager alias will be the only way to explicitly opt in to the old default behavior (Default is marked as deprecated in v21.1). That means components with no specified change detection strategy will be using OnPush and we'll have to explicitly set ChangeDetectionStrategy.Eager for components that are not OnPush compatible. An automatic migration will take care of that for existing components.

Resource snapshot

Angular now exposes a resource state as a first-class value with ResourceSnapshot<T>. A resource has a new snapshot() signal, which is a simple object containing a status and either a value or an error. Angular also introduces resourceFromSnapshots(...) to turn a snapshot signal back into a Resource.

This is an advanced API that allows you to customize the behavior of resources. You can use normal signal composition (computed, linkedSignal) to transform resource states, then convert the result back to a resource. This pattern makes it much easier to build reusable resource utilities. For example, built-in resources set the value to undefined when loading. If you don't like this behavior, you can implement a resource that keeps the stale value while loading.

function withPreviousValue<T>(input: Resource<T>): Resource<T> {
  const derived = linkedSignal<ResourceSnapshot<T>, ResourceSnapshot<T>>({
    source: () => input.snapshot(),
    computation: (snap, previous) => {
      if (snap.status === 'loading' && previous?.value?.status === 'resolved') {
        // keep previous value while loading next one
        return { status: 'loading', value: previous.value.value };
      }
      return snap;
    }
  });

  return resourceFromSnapshots(derived);
}

Signal Forms

Signal Forms received several improvements in Angular v21.2.

`FormRoot` directive and `submission` option

One of the interesting Signal Forms additions in v21.2 is the FormRoot directive. Instead of manually handling (submit) and calling submit(...), you can now bind the form directly in the template:

<form [formRoot]="loginForm">
  <input [formField]="loginForm.login" />
  <button type="submit">Log in</button>
</form>

Submission logic can be declared in the form() configuration directly:

protected readonly loginForm = form(this.credentials, {
  submission: {
    action: async () => await this.userService.authenticate(this.credentials().login, this.credentials().password),
    onInvalid: () => this.invalidSubmission.set(true),
    ignoreValidators: 'none'
  }
});

As you can see, this submission option also allows to define an onInvalid callback, which is called when the form is submitted while invalid. The ignoreValidators option let you define whether the validation should be ignored when submitting the form or not:

pending (default value) ignore pending async validators, but not synchronous validators;
all ignore all validators;
none don't ignore any validator.

The FormRoot directive also automatically adds the novalidate attribute to the form element, preventing native browser validation from interfering with Signal Forms validation.

Note that the existing submit() function now uses these form-level defaults. So if action is defined in submission, you no longer need to pass it if you manually call submit(). Angular v21.2 in fact updated the submit() API to let you pass options as the second parameter (action, onInvalid, ignoreValidators) to override these defaults, and the submit function now returns a Promise<boolean>.

focus and `registerAsBinding`

As explained in our previous blog post, Angular v21.1 introduced the focusBoundControl method on a field to programmatically focus its form control in the DOM:

protected readonly loginForm = form(this.credentials, {
  submission: {
    action: // ...
    onInvalid: () => {
      // 👇 automatically focus the first field with an error
      const firstError = this.loginForm().errorSummary()[0];
      if (firstError?.fieldTree) {
        firstError.fieldTree().focusBoundControl();
      }
    }

A typical FormField will focus its host element (input, select, etc.) when focusBoundControl is called. For custom form controls that implements FormValueControl or FormCheckControl, you'll need to implement the focus method to define how the control should be focused when focusBoundControl is called:

@Component({
  // ...
})
export class BirthYearInput implements FormValueControl<number | null> {
  // ...
  // 👇
  focus() {
    this.birthYearInput().nativeElement.focus();
  }

But we can also have components or directives that don't implement FormValueControl or FormCheckControl, and instead receive the field as an input and bind it in the template. In this case, we can use the new registerAsBinding method to register the field as a binding, which will make focusBoundControl focus the chosen element:

@Component({
  // ...
  template: `
    <input type="password" [formField]="formField()" />
    <button #button (click)="generate()">Generate</button>
   `
})
export class Password {
  readonly formField = input.required<FieldTree<string>>();
  readonly button = viewChild.required<ElementRef<HTMLButtonElement>>('button');

  constructor() {
    // 👇 register the field as a binding, and specify to focus the button element
    inject(FormField).registerAsBinding({
      focus: () => this.button().nativeElement.focus()
    });
  }
}

If the custom control is a directive, the registerAsBinding call can be done without specifying the focus method, as the directive host element will be focused by default:

@Directive({
  // ...
})
export class PasswordDirective {
  readonly formField = input.required<FieldTree<string>>();
  
  constructor() {
    // 👇 the directive host element will be focused by default
    inject(FormField).registerAsBinding();
  }
}

Note: the focus API now accepts and propagates FocusOptions which allows control over focus behavior (for example, preventing scroll on focus with { preventScroll: true }).

`transformedValue` for custom controls

Another nice addition for custom controls is the new transformedValue utility. It helps synchronize a raw value entered by the user with the model value using parse and format functions, while automatically reporting parse errors to the parent form. The parse function can either return an object with a value property containing the parsed value, or an object with an errors property containing an array of errors if the value is invalid. In this example, the user types a duration like 20m or 1h, and the form model stores the duration in minutes. If the value is invalid, then a custom parse error is reported to the form, which can be used to display an error message in the UI. You can also return built-in validation errors from the parse function, for example to report that a negative duration is not allowed using a min error.

@Component({
  selector: 'duration-input',
  template: `<input [value]="rawValue()" (input)="onDurationInput($event)" />`
})
export class DurationInput implements FormValueControl<number | null> {
  // model value exposed to the form (in minutes)
  readonly value = model.required<number | null>();

  // 👇 raw UI value (string) <-> model value (minutes)
  readonly rawValue = transformedValue(this.value, {
    parse: (raw: string) => {
      // normalize user input
      const input = raw.trim().toLowerCase();
      if (input === '') return { value: null };

      // `20m` -> 20
      if (input.endsWith('m')) {
        const minutes = Number(input.slice(0, -1));
        if (Number.isNaN(minutes)) return { error: { kind: 'parse' } };
        return minutes < 0 ? { error: minError(0) } : { value: minutes };
      }

      // `1h` -> 60
      if (input.endsWith('h')) {
        const hours = Number(input.slice(0, -1));
        if (Number.isNaN(hours)) return { error: { kind: 'parse' } };
        const minutes = hours * 60;
        return minutes < 0 ? { error: minError(0) } : { value: minutes };
      }

      // anything else is a parse error
      return { error: { kind: 'parse' } };
    },
    // format minutes back to a user-facing value
    format: (value: number | null) => (value == null ? '' : `${value}m`)
  });

  onDurationInput(event: Event) {
    this.rawValue.set((event.target as HTMLInputElement).value);
  }
}

Nullable number inputs

Note that parse errors are now also integrated for native form inputs. For example, if a user types an unparsable value in a type="number" input, the model keeps its previous value and the field reports a parse error.

Signal Forms now better supports null with native number inputs: binding null clears the input, and when users clear the field, the model becomes null.

Our online workshop showcases a more complete example of transformedValue usage in the Signal Forms exercise 👀.

`SignalFormControl` for incremental migration

Angular v21.2 also introduces SignalFormControl in @angular/forms/signals/compat. It acts as a bridge between Signal Forms and classic Reactive Forms: you can define signal-form validation rules, while still plugging this new control into a FormGroup or FormArray.

protected readonly credentials = this.fb.group({
  login: ['', [Validators.required, Validators.minLength(3)]],
  // 👇 use a SignalFormControl in a classic FormGroup
  password: new SignalFormControl('', p => {
    required(p);
    minLength(p, 6);
  })
});

On the template side, you don't need to do anything special to bind a SignalFormControl with formControlName/formControl.

@let passwordCtrl = credentials.controls.password;
<input id="password" type="password" formControlName="password" />
@if (passwordCtrl.touched && passwordCtrl.hasError('required')) {
  <div>Password is required</div>
}

It also exposes a fieldTree so the control can be bound with [formField] in templates.

@let passwordCtrl = credentials.controls.password;
<input id="password" class="form-control" type="password" [formField]="passwordCtrl.fieldTree" />
@if (passwordCtrl.touched && passwordCtrl.hasError('required')) {
  <div id="password-required-error" class="invalid-feedback">Password is required</div>
}

This is particularly useful for bottom-up migration: you can migrate one control at a time instead of rewriting the whole form in one pass.

SignalFormControl would not be really "signal-friendly" if it did not use a signal: it in fact has a sourceValue property which is a signal of the control value, and can be used:

protected readonly passwordStrength = computed(() => {
  const password = this.passwordCtrl.sourceValue();
  // ...
});

SignalFormControl intentionally does not support some imperative AbstractControl APIs:

disable() / enable()
setValidators() / addValidators() / removeValidators() / clearValidators()
setAsyncValidators() / addAsyncValidators() / removeAsyncValidators() / clearAsyncValidators()
setErrors()
markAsPending()

State and validation are expected to be derived from signal rules instead.

Reactive `validateStandardSchema()`

validateStandardSchema() now supports signal-based schemas. You can pass a function that returns the schema, so validation can react to changing signals over time. For example, if minimumLength is a signal containing the minimum length, you can now write: validateStandardSchema(p, () => z.object({ name: z.string().min(minimumLength()) })).

Warning for rendered hidden fields

Angular now warns in dev mode when a field marked as hidden is still rendered in the DOM. In Signal Forms, hidden fields should be guarded in the template (typically with @if), so this warning helps catch accidental rendering of hidden controls:

NG01916: Field 'password' is hidden but is being rendered.
Hidden fields should be removed from the DOM using @if.

Animations

It is now possible to have nested animations, where a component with its own animations is used inside another component that also has animations. Previously, only the animations of the top-level component were working when components were destroyed, but with this change, animations defined in nested components will be properly triggered first.

Router

Angular now lets you configure trailing slash behavior through dedicated location strategies. You can choose to always write URLs with a trailing slash, or to always remove it:

bootstrapApplication(AppComponent, {
  providers: [
    // 👇 always write URLs with a trailing slash
    { provide: LocationStrategy, useClass: TrailingSlashPathLocationStrategy }
    // or never
    // { provide: LocationStrategy, useClass: NoTrailingSlashPathLocationStrategy }
  ]
});

`canMatch` now gets a partial route snapshot

Another useful router change is that canMatch now receives a third argument: a partial route snapshot (PartialMatchRouteSnapshot).

This addresses a long-standing limitation where canMatch had access to route and segments, but not to params like { userId: '123' }. With this snapshot argument, the guard can directly read params, queryParams, fragment, etc.

DevTools

Angular DevTools now visualizes resource() relationships in dedicated clusters in the signal graph. DevTools also adds dependency-path highlighting from the node details panel. You can now highlight:

upstream dependencies (what this node depends on)
downstream dependents (what depends on this node)

This can be helpful when debugging update propagation in large signal graphs.

Angular CLI

Unit tests

The CLI now supports ng add for Vitest browser providers:

@vitest/browser-playwright
@vitest/browser-webdriverio
@vitest/browser-preview

When used on a project already configured with the @angular/build:unit-test builder (and Vitest runner), the schematic installs the selected provider package plus required peer dependencies (like playwright or webdriverio).

So you can now run:

ng add @vitest/browser-playwright

The unit-test builder has a new headless option to force all configured browsers to run headless:

{
  "builder": "@angular/build:unit-test",
  "options": {
    "browsers": ["Chromium"],
    "headless": true
  }
}

This is an alternative to the hard-coded convention used until now, where you had to name the browser with a Headless suffix to run it headlessly (for example ChromiumHeadless).

Prettier

The CLI now has built-in Prettier integration!

New generated applications now include a .prettierrc file, with prettier a dev dependency. Files created/modified by schematics are automatically formatted when possible and ng update migrations now also run formatting on changed files.

This reduces formatting noise after ng generate and ng update.

Summary

This was a packed release for a minor version. Arrow functions and exhaustive @switch type-checking on the template side, the ChangeDetectionStrategy.Eager alias as the OnPush as default migration is coming, and a wave of Signal Forms improvements: FormRoot, transformedValue, SignalFormControl for incremental migration. Next version should be the v22 release.

Stay tuned!

All our materials (ebook, online training and training) are up-to-date with these changes if you want to learn more!

What's new in Angular 21.1?

2026-01-15T00:00:00Z

Angular 21.1.0 is here!

Two months after the huge v21 release, the Angular team delivers a new minor update.

Let's dive in!

Signal Forms

A meaningful change in Signal Forms is the renaming of the [field] directive to [formField]. The [field] selector was too generic and likely to cause naming collisions with existing components. Therefore, the Angular team decided to rename both the directive class (from Field to FormField) and the directive selector (from [field] to [formField]).

You should now use [formField] instead of [field] to bind form controls:

<input [formField]="form.name" />

The Field directive has been removed, so you'll have some renaming to do if you already use experimental Signal Forms.

Another name change in Signal Forms is the renaming of the field property to fieldTree in validation error interfaces and field contexts. If you're writing custom validators, you'll need to update your code to use fieldTree instead of field:

// Before
const error: ValidationError = {
  // 👇 targets the password field
  field: context.fieldTree.password,
  kind: 'password-different-from-email',
  message: 'Password should not be the same as email'
};

// After v21.1
const error: ValidationError = {
  // 👇 targets the password field
  fieldTree: context.fieldTree.password,
  kind: 'password-different-from-email',
  message: 'Password should not be the same as email'
}

This change affects the ValidationError interface and the FieldContext interface.

Signal Forms gained a new feature in v21.1: the ability to automatically apply CSS classes to fields based on their state 🚀.

One of the missing features of signal forms compared to the classic reactive/template-driven forms was the automatic CSS classes that were added to form controls (ng-valid, ng-dirty, ng-touched, etc.).

This is now possible using the provideSignalFormsConfig() function in your application configuration:

provideSignalFormsConfig({
  classes: {
    'is-invalid': field => field.state().invalid() && field.state().touched()
  }
})

In this example, the is-invalid CSS class will be automatically added to any field that is invalid and touched. You can define as many classes as you want, and use any property of the Field/FormField directive, like its state (invalid(), touched(), dirty(), etc.) or its host element (a new property added in this version) to determine when the class should be applied.

This makes it easier to style your forms, especially when using CSS frameworks like Bootstrap or Tailwind that rely on specific CSS classes to style form inputs.

Note that you can have the "old" behavior with ng-valid/ng-invalid/ng-dirty/ng-touched... classes by using:

provideSignalFormsConfig({
  classes: NG_STATUS_CLASSES,
});

Signal Forms now also support custom control directives! Previously, the [field] binding could only be used with components. Now, you can create directives that implement the FormValueControl or FormCheckboxControl interfaces and bind them with [formField].

<input [formField]="form.name" appCustomControl />

Signal Forms also gained a new focusBoundControl() method on the field state. This is particularly useful for accessibility or when you want to focus a specific field after a validation error.

This allows you to programmatically focus the input element associated with a form field, for example when a submission failed:

protected async register(event: SubmitEvent) {
  event.preventDefault();
  await submit(this.userForm, async form => {
    // ...
  });
  // 👇 automatically focus the first field with an error
  const firstError = this.userForm().errorSummary()[0];
  if (firstError?.fieldTree) {
    firstError.fieldTree().focusBoundControl();
  }

This will automatically focus the first input/select/textarea associated with a field that has an error, but the cool thing is that it can also work with custom control components! You just have to implement a focus() method in your custom control, and focusBoundControl() will automatically call it:

@Component({
  // ...
})
export class BirthYearInput implements FormValueControl<number | null> {
  // ...
  // 👇
  focus() {
    this.birthYearInput().nativeElement.focus();
  }

NOTE: We added a Signal Forms exercise to our online workshop, check it out!

Control flow

The @switch control flow now supports multiple consecutive @case blocks matching a single content block.

Previously, each @case required its own content. Now you can specify multiple conditions for a single block, similar to fall-through behavior in traditional switch statements:

@switch (status) {
  @case ('draft')
  @case ('pending') {
    <p>Your document is not yet published</p>
  }
  @case ('published') {
    <p>Your document is live</p>
  }
  @default {
    <p>Unknown status</p>
  }
}

In this example, both 'draft' and 'pending' statuses will display the same message, making the code more concise when multiple conditions should produce the same result.

Template spread operator

Angular templates now support the spread operator (...)! This allows you to spread an object into an object or an array into another array:

@let users = [currentUser, ...admins];

It also supports the spread syntax in function calls. This is particularly useful for functions that use rest parameters, a syntax that allows a function to accept an indefinite number of arguments as an array:

<button (click)="sum(...counters)">Sum all</button>

Spoiler for the next version: we will get arrow function support in templates in v21.2!

Router

The router introduces a new standalone isActive() function that returns a computed signal indicating whether a given URL is currently active.

This new function is a more tree-shakeable alternative to the existing Router.isActive() method, which is now deprecated in v21.1:

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

const active = isActive(
  '/home',
  this.router, 
  { paths: 'exact', queryParams: 'exact', fragment: 'ignored', matrixParams: 'ignored' }
);

The function returns a signal that automatically updates when the router state changes, making it easier to reactively track active routes.

The router also gained better memory management capabilities in v21.1 if you use a custom RouteReuseStrategy implementation (which is not that common).

A new experimental feature withExperimentalAutoCleanupInjectors() automatically destroys unused route injectors after navigation, helping to prevent memory leaks in applications with many routes or long-lived sessions.

You can enable it when configuring your routes:

provideRouter(routes, withExperimentalAutoCleanupInjectors())

Additionally, a new destroyDetachedRouteHandle() function is available for manually cleaning up detached route handles in custom RouteReuseStrategy implementations.

Finally, the router introduces an experimental integration with the browser's Navigation API. This API is a modern alternative to the traditional History API, providing a more robust way to handle navigations.

By enabling this experimental feature, the Angular router can:

intercept navigations triggered outside the router and convert them to SPA navigations.
leverage native browser scroll and focus restoration.
communicate ongoing navigations to the browser for better accessibility and user experience (native loading progress, stop button, etc.).

You can enable it using the withExperimentalPlatformNavigation() feature:

provideRouter(routes, withExperimentalPlatformNavigation())

This feature is highly experimental and the native browser support is currently very limited. This won't be stabilized until the Navigation API is more widely supported. When this is done, it may not become a router feature (with...) but rather a different router provider, which would allow to tree-shake the current history-based classes.

Debugging stability

A new debugging utility provideStabilityDebugging() helps developers troubleshoot applications that fail to stabilize during hydration.

If your application doesn't reach a stable state within 9 seconds, this utility logs diagnostic information to the console, including pending tasks and their stack traces. This is particularly useful when debugging hydration timeouts in SSR applications.

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

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

Note that this utility is provided by default in dev mode when using provideClientHydration().

Vitest

The Angular CLI's migration schematic for converting Jasmine tests to Vitest now supports a browserMode option (a contribution from my fellow ninja JB!).

If you're migrating your tests to Vitest and plan to use Vitest's browser mode (you should, read our blog post about Vitest browser mode), you can now use this option to preserve certain assertions that are natively supported in browser mode:

ng generate refactor-jasmine-vitest --browser-mode

When this option is enabled, the migration will keep the toHaveClass matcher in its original form instead of converting it to a different assertion, since Vitest's browser mode provides its own toHaveClass matcher.

This makes the migration smoother for projects that want to run their tests in a real browser environment, ensuring your tests work as expected without manual adjustments after the migration.

The schematic also now generates a detailed migration report by default, creating a markdown file that lists all the TODOs and manual tasks that need to be addressed after the automatic migration. This report includes precise file paths and line numbers, making it easier to quickly identify and fix any remaining migration tasks in large codebases. You can disable this with --no-report if you don't need it.

# Jasmine to Vitest Refactoring Report

Date: 2025-12-17T15:16:43.108Z

## Summary

|                   | Count |
|:------------------|------:|
| Files Scanned     |   159 |
| Files Transformed |   151 |
| Files Skipped     |     8 |
| Total TODOs       |     3 |

## TODO Overview

| Category    | Count |
|:------------|------:|
| addMatchers |     3 |

## Files Requiring Manual Attention
...

AI

The MCP server gained a few new (experimental) tools that enable AI assistants to control Angular projects more effectively:

build: compiles the Angular application
devserver.start: launches the development server
devserver.stop: terminates the running development server
devserver.wait_for_build: waits until the dev server completes its build process
test: runs unit tests via ng test
e2e: runs end-to-end tests via ng e2e

These tools allow AI assistants like Claude to programmatically build your application, manage the development server, and run your tests, making it easier to verify that everything compiles correctly and all tests pass.

You can now enable all experimental tools at once using the all group in your MCP configuration, making it easier to get started with the full suite of AI assistance features: ng mcp --experimental-tool=all.

The already existing ai_tutor tool continues to evolve. A new lesson has been added to the interactive learning experience: Signal Forms!

If you're curious about Signal Forms, the AI tutor can be a nice resource, but you should definitely check out our 2 part series on Signal Forms if you haven't already 😉

The Angular team continues to improve the infrastructure for AI assistance. Code examples are now embedded directly in Angular packages (starting with @angular/forms) using a SQLite database, making them easily accessible to the MCP server and other tooling. This builds upon the code examples feature introduced in earlier versions, improving the AI's ability to provide contextual code snippets and guidance, and we'll probably see more code examples added in future releases in the various packages.

Finally, setting up the MCP server is now easier than ever. New Angular workspaces now include a .vscode/mcp.json.template file with a pre-configured setup for the Angular CLI MCP server. This eliminates the need for manual configuration and makes it straightforward to start using AI assistance in your Angular projects. You can learn more about this on the Angular MCP documentation page.

Summary

That's all for this release! Signal Forms continue to improve with CSS class configuration, custom control directives support, the focusBoundControl() method, and naming improvements. The router gained an experimental integration with the Navigation API. The CLI team focused on AI features and the Vitest stabilization.

Stay tuned!

All our materials (ebook, online training and training) are up-to-date with these changes if you want to learn more!

What's new in Angular 21.0?

2025-11-20T00:00:00Z

Angular 21.0.0 is here!

The highlights? Signal Forms and zoneless change detection by default. The CLI, with Vitest becoming the default testing framework, also delivers on a long due improvement.

Let's dive in!

Signal Forms (experimental)

Angular 21 introduces a new experimental way to build forms: Signal Forms, in the @angular/forms/signals package. This signal-based approach provides better type safety and easier validation compared to traditional reactive and template-driven forms.

private readonly credentials = signal({ email: '', password: '' });
protected readonly loginForm = form(
  this.credentials,
  // 👇 add validators to the fields, with their error messages
  form => {
    // email is mandatory
    required(form.email, { message: 'Email is required' });
    // must be a valid email
    email(form.email, { message: 'Email is not valid' });
    // password is mandatory
    required(form.password, { message: 'Password is required' });
    // should have at least 6 characters
    minLength(form.password, 6, {
      // can also be a function, if you need to access the current value/state of the field
      message: password => `Password should have at least 6 characters but has only ${password.value().length}`
    });
  }
);

We wrote a two-part series to introduce you all the concepts of Signal Forms. The first one covers the basics, while the second one dives into more advanced topics like custom validation, custom form components, etc.

Check them out!

👉 Angular Signal Forms - Part 1

👉 Angular Signal Forms - Part 2

There is also an effort to make the migration to signal forms more progressive, with the introduction of the @angular/forms/signals/compat package. This package offers a compatForm function, which is a version of the form function designed for backwards compatibility with reactive forms by accepting reactive controls as a part of the data. I'm not sure that this will save us from completely rewriting our forms, but we appreciate the effort 🫡.

Zoneless by default 🚀

Angular applications are now zoneless by default! provideZonelessChangeDetection() is no longer needed in new applications, as Angular will use zoneless change detection automatically. If your application relies on Zone.js, you will need to explicitly add provideZoneChangeDetection() in the root providers. A migration will automatically add it for you if necessary when updating to Angular v21.

The CLI now generates zoneless applications by default, and you'll note that the component tests use await fixture.whenStable() instead of fixture.detectChanges().

Core

The SimpleChanges type that we use for the ngOnChanges parameter is now generic and can be type safe, if you add the type of your component as a type parameter. To keep the backward compatibility, it defaults to any when no type parameter is provided.

export class User implements OnChanges {
  readonly name = input.required<string>();

  // 👇 ngOnChanges is now type safe
  ngOnChanges(changes: SimpleChanges<User>): void {
    const nameChange = changes.name;
    // typed as `SimpleChange<string> | undefined`
    if (nameChange) {
      console.log(`Name changed from ${nameChange.previousValue} to ${nameChange.currentValue}`);
    }
  }

Forms

In "classic" forms, a new FormArrayDirective directive has been added, allowing to have an array as the top element of a form. Until now, you had to wrap it in a FormGroup and use the FormGroupDirective.

Http

The big change is that HttpClient is now provided in the root injector by default. We no longer need to use provideHttpClient() in our applications, except when we want to customize the HTTP client (for example, to register interceptors). It also simplifies the testing setup, where it was a bit verbose to have to use both provideHttpClient() and provideHttpClientTesting(). We can now only use the latter.

The HttpClient also gained a few options in its Fetch version:

responseType has been added (corresponding to the response type property in the native fetch API, see the MDN docs)
referrerPolicy which can be used to specify the referrer information (see the MDN docs) has been added to the client and in the HttpResource options.

Router

The router gained a new scroll option that can be used when navigating to define the scrolling behaviour (allowing to override the scroll restoration behaviour that you can enable in provideRouter thanks to withInMemoryScrolling({ scrollPositionRestoration: 'enabled' })).

The scroll option can be 'manual' (no scrolling even if enabled globally) or 'after-transition' (following the global behaviour). So, using router.navigateByUrl('/', { scroll: 'manual' }) will prevent scrolling even if scroll restoration is enabled globally.

Templates

The control flow migration will automatically be applied when updating to Angular v21, if you did not apply it yet.

Since the updated style guide written for Angular v20, it is now recommended to use class and style bindings instead of the NgClass and NgStyle directives.

Angular v21 offers automatic migrations (optional) to help you with this change!

ng g @angular/core:ngclass-to-class-migration
ng g @angular/core:ngstyle-to-style-migration

Another optional migration has been added to migrate CommonModule imports to the individual directives/pipes standalone imports:

ng g @angular/core:common-to-standalone

Speaking of changes in the templates, RegExp are now supported: you can now write something like <div>{{ /\\d+/.test(id()) }}</div> in your HTML files. I'm not sure why anyone would want to do that, but well...

The @defer trigger on viewport also gained a new option, allowing to define the options of the underlying IntersectionObserver. You can now write a @defer like this:

@defer (on viewport({ trigger, rootMargin: '50px' })) {

Compiler

In v21, the compiler now has its typeCheckHostBindings option enabled by default (see our blog post about v20 to learn more about what it does).

A new diagnostic has also been added to detect when a component reads a required input/model/viewChild/contentChild property before it is initialized. This was already throwing an error at runtime, but now you will get a compile-time error instead.

Another diagnostic has been added to detect unreachable or duplicated or inefficient @defer triggers.

Styles encapsulation

A new strategy for view encapsulation has been added: ExperimentalIsolatedShadowDom. As its name indicates, it is still experimental. It leverages Shadow DOM to provide true encapsulation of styles, but also isolates the component from the rest of the application. Unlike ShadowDom encapsulation, it prevents styles from leaking in or out of the component. This is useful when you want to ensure that the component's styles are completely isolated from the rest of the application, including global styles. There are still some issues with the implementation, so it is not recommended for production use yet.

Vitest is the new default

Big change in the unit testing setup: Vitest is now the default testing framework when creating new applications with the CLI! 😲

Karma/Jasmine has been the default for a long time, even though Karma has been deprecated for a while. The experimental @angular/build:unit-test is now stable and uses Vitest by default. Some efforts have been made to simplify the configuration as much as possible, and the minimal setup in angular.json is now:

"test": {
  "builder": "@angular/build:unit-test"
}

You can see the difference in a generated project on angular-cli-diff. This little project that we maintain proves to be really useful to see what changed between CLI versions when you want to update your projects.

Even if the configuration is simpler, you can still customize it a lot with the following options, either in angular.json or via CLI options when running ng test:

coverage (and all coverage related options, like coverageInclude, coverageExclude, coverageThresholds, etc.) to configure code coverage
browsers to define which browsers to use for testing. Note that Vitest stabilized the Browser Mode in v4, so you can now run tests in real browsers instead of jsdom/happy-dom if you want to. The browserViewport option allows to define the viewport size for browser tests.
reporters to define which reporters to use, and output-file to define where to output the report.
setupFiles to define setup files to be run before the tests and providersFile to define a file that provides Angular testing providers.
ui if you want to use Vitest's UI mode.
watch to enable/disable watch mode (true by default when running ng test, but false in CI environments).
filter to run only tests matching a specific pattern in their test suite or test name.
list-tests to list all the tests without running them (useful to check what the include/exclude options are doing).

The CLI team also added a runnerConfig option to allow using a custom Vitest configuration file, if you need to customize something not covered by the CLI options. For example, if you want to enable Vitest isolation mode (disabled by default in the CLI as it slows down tests), you can add a vitest-base.config.ts file to your project using: ng g config vitest.

Then customize it like this:

import { defineConfig } from 'vitest/config';
export default defineConfig({
  test: {
    isolate: true,
  },
});

We really like Vitest and its Browser Mode that allows to use real browsers and write more expressive tests using its Locator API. We wrote a dedicated blog post to explain how to write more expressive than ever component unit tests 🤩:

👉 Angular tests with Vitest browser mode

It is still possible to use Karma if you want to, by setting the runner option to "karma". And you can generate a new project with Karma as the default by using ng new my-app --test-runner=karma.

A migration is also available to migrate existing tests from Jasmine to Vitest:

ng generate refactor-jasmine-vitest

This migration is fairly mechanical, so you'll probably have to manually adjust some tests afterward. But it should save you some time, as it replaces all Jasmine-specific functions, types, matchers and imports with their Vitest equivalents! It does not migrate the test setup or dependencies though, so you'll have to do that part manually.

The migration has some useful options:

--add-imports to automatically add the Vitest imports in your test files (if you don't want to use global imports, which is the default when generating a new application)
--file-suffix if you use a different suffix than .spec.ts for your test files
--include to target only specific files or folders

Note that fakeAsync tests need to be rewritten, as fakeAsync relies on a patched Zone.js for Jasmine, and there is no version of it for Vitest. The migration will also add helpful TODO comments in your tests to indicate where it couldn't automatically migrate them.

Vitest is definitely a great addition to Angular, and the way to go if you start a new project! The web-test-runner and jest experimental builders which were introduced as a possible alternative to Vitest will be removed in v22.

ng serve

It is now possible to define variables that will be replaced during the serve process, using the define option in the serve configuration. For example, you can define a VERSION variable that will be replaced with the version of your application from the command line (making it simple to use environment variables):

ng serve --define VERSION="'1.0.0'"

and then use it in your code:

// @ts-expect-error defined with --define flag
console.log(`App version: ${VERSION}`);

This was already possible since v17.2 in builds, but is now also available for ng serve.

Tailwind schematic

A new schematic has been added to easily set up Tailwind CSS in your Angular projects. You can use it when creating a new application:

ng new my-app --style tailwind

This sets up Tailwind CSS with a minimal .postcssrc.json configuration file and adds the required dependencies (tailwindcss, @tailwindcss/postcss, and postcss).

Interestingly, ng add now supports adding a package that is not a schematic and will fall back to installing the NPM package and then try to run its schematic if it has one. So, you can also add Tailwind CSS to an existing project with:

ng add tailwindcss

Style guide 2016

If you're nostalgic about the old Angular file naming conventions from 2016, you can now generate a project following its recommendations by using the --file-name-style-guide=2016 option when creating a new application.

This option adds a retro vibe to your project with file names like user.component.ts, user.pipe.ts, and user.service.ts 🪩.

The component, directive, and services name will also follow the 2016 conventions, with a Component, Directive, or Service suffix in their class names.

ng version

The ng version command has been improved to provide more detailed information about the packages in your Angular project (showing the requested and installed versions). A --json option has also been added to output the information in JSON format, which can be useful for automation scripts.

Accessibility

A new @angular/aria package has been introduced to provide headless and accessible directives that implement common ARIA patterns. They handle keyboard interactions, ARIA attributes, focus management, and screen reader support. These directives are built on top of the CDK and developed by the Angular Material team. The package is in developer preview in v21 and currently contains the following directives: Accordion, Autocomplete, ComboBox, Grid, ListBox, Menu, Multiselect, Select, Tabs, Toolbar, and Tree. We haven't tested them yet, so we'll let you explore them on your own.

AI

The AI section is becoming a regular section of our release review! The CLI team worked hard on the MCP server. It now offers 7 tools:

list_projects: lists the Angular projects in the workspace
get_best_practices: provides the latest best practices
find_examples (now stable): finds code examples for a given topic
search_documentation: searches the Angular documentation
modernize (still experimental): suggests modernizations for your codebase
ai_tutor (new): provides interactive learning to build a "Smart Recipe Box" application
onpush_zoneless_migration (new): helps migrate to OnPush and zoneless change detection

find_examples is now stable, and has been improved to support filtering, weighted results, and searching for specific Angular packages and versions. The examples you add to your project can now have a frontmatter description, with a title, summary and keywords. It can also be marked as experimental if they use experimental APIs. By default, the database has just one example for a @if, but we can expect the default database to grow over time.

search_documentation has also been improved to search the documentation for the specific Angular version of your project.

modernize is still experimental,, and now can run migrations directly. So if you ask your favorite AI assistant to modernize a component, the MCP server will be able to run the necessary migrations to update your codebase (control-flow, signal migrations, etc.).

onpush_zoneless_migration is an interesting new tool that analyzes your codebase and provides a step-by-step plan to migrate your application to OnPush and zoneless. It targets components and their tests, helps you identify ZoneJS usages that need to be addressed and suggests how to migrate to zoneless.

Summary

The transition to zoneless by default, the introduction of Signal Forms and Vitest as the new default testing framework are big news for Angular developers.

Migration of existing applications to turn on zoneless change detection will require a big effort though. As well as for Vitest if you have thousands of Jasmine tests like we do.

Signal forms have still some rough edges as they are still experimental, but they look very promising, and are maybe a good choice for new projects? We will keep an eye on their evolution in the coming releases, and let you know what we think about them.

Stay tuned!

All our materials (ebook, online training and training) are up-to-date with these changes if you want to learn more!

Angular tests with Vitest browser mode

2025-11-18T00:00:00Z

Unit testing our Angular applications is something we take seriously.

The TestBed helps, but I've always found it very low-level. It looks to me like it was designed mainly to test the framework itself rather than applications using the framework. For example, there is nothing to help you interact with the UI elements (form inputs, selects, etc.) other than the low-level DOM APIs.

Recent versions, along with zoneless change detection, have improved the situation a little bit. We can now replace the many fixture.detectChanges() calls with await fixture.whenStable(), and let the framework detect the changes automatically, making the code under test behave more like it would behave in real-life. You can check out this conference talk by Cédric Exbrayat (in French) if you want to learn more about this topic.

To make tests easier to write and maintain, we have developed, and still heavily use ngx-speculoos. It's a thin layer on top of the TestBed, but it offers several interesting advantages:

it makes it easier to interact with elements, in particular form elements
it offers frequently used jasmine assertions to check the state of form and other DOM elements
it drastically reduces the number of fixture.detectChanges() / fixture.whenStable() calls necessary
with the page object pattern, it allows defining the selectors to access the elements to test once, and use them across all the tests of a suite

Angular 21 changes everything for the better. Change detection is zoneless by default, and Vitest is now the default testing framework instead of Jasmine. In particular, the Browser mode of Vitest makes unit testing awesome.

Instead of using a Node-based DOM implementation like Jest (and Vitest by default) do, the Browser mode allows the code under test to run in the real production environment: the browser(s) (Chromium, Firefox and Webkit). So we keep this feature that Karma offered.

But it goes much further. Vitest comes with two killer features.

Retried assertions

Retried assertions eliminate, most of the time, the need to call fixture.detectChanges() or await fixture.whenStable(). If you've used Playwright or Cypress for end-to-end tests, you should know the principle already.

Let's say you want to check that the title of the page contains "Hello". If you write:

expect(title).toHaveTextContent('Hello');

that will just make that check, immediately, and only once.

In order for that test to pass, you need to make sure that the asynchronous task that sets the title is done, and that the framework has detected the changes and updated the DOM. That's why we litter the code with fixture.detectChanges() or await fixture.whenStable(). But Vitest allows doing the following:

await expect.element(title).toHaveTextContent('Hello');

A small change, but with big implications! This time Vitest will execute the assertion, and retry it, again and again (every N milliseconds), until it passes or until the test times out. So if you haven't waited for the fixture to be stable, no problem: the assertion will fail once, but by the time it retries, the framework will have stabilized and updated the DOM, and the test will pass.

Imagine you're using a resource and you want to test that the page displays a spinner while the resource is loading, with Jasmine and the TestBed:

it('should display a spinner while loading', async () => {
  const fixture = TestBed.createComponent(MyComponent);
  await fixture.whenStable();
  expect(fixture.nativeElement.querySelector('[data-testid=spinner]')).toBeTruthy();
});

This looks simple enough, but it doesn't work: the application won't become stable until the resource has loaded. The fix is really not easy to figure out: you need to call TestBed.tick() in that case:

it('should display a spinner while loading', async () => {
  const fixture = TestBed.createComponent(MyComponent);
  TestBed.tick();
  expect(fixture.nativeElement.querySelector('#spinner')).toBeTruthy();
});

No need to deal with these low-level details thanks to retried assertions:

it('should display a spinner while loading', async () => {
  const fixture = TestBed.createComponent(MyComponent);
  await expect(page.getByText('Loading...')).toBeVisible();
});

Locators, their interactivity and assertion API

Instead of using the DOM API and interacting directly with DOM elements, in a Vitest browser test, you use locators. A locator is an object which allows getting zero, one or several elements on the page (or inside the element of another locator).

Every time you interact with the locator, it executes the query to find the element. This means that you can use the same locator throughout the tests of a component without worrying that it might be null, or stale, or not in the DOM anymore.

In fact, in my tests, I use the same page object pattern as with ngx-speculoos. Instead of using getters to query the element(s) every time I want to interact with them, check their presence or their state, I simply initialize locators (see the complete example below).

Vitest heavily promotes writing tests that work as if you were a user in front of the screen. So instead of locating elements by their ID or element names, you locate them by their text, role, label, etc.

Locators, in addition to querying components, also offer an API to test the state of their element(s) with rich (and extensible) assertions. And they also have an interaction API to manipulate them as a user would: click, fill, select, etc.

All this combined allows writing really expressive and simple tests suites like the following (we will not mock the service that it uses, but Vitest of course has a mocking API too):

class LoginTester {
  readonly fixture = TestBed.createComponent(LoginPage);
  readonly root = page.elementLocator(this.fixture.nativeElement);
  readonly login = page.getByLabelText('Login');
  readonly password = page.getByLabelText('Password');
  readonly signIn = page.getByRole('button', { name: 'Sign in' });
  readonly error = page.getByText('Wrong credentials, try again');
}

describe('LoginPage', () => {
  let tester: LoginTester;

  beforeEach(() => {
    TestBed.configureTestingModule({
      providers: [provideRouter([])]
    });
    tester = new LoginTester();
  });

  it('should display an empty form and no error initially', async () => {
    await expect.element(tester.login).toHaveDisplayValue('');
    await expect.element(tester.password).toHaveDisplayValue('');
    await expect.element(tester.error).not.toBeInTheDocument();
  });

  it('should validate', async () => {
    await tester.signIn.click();
    await expect.element(tester.root).toHaveTextContent('The login is required');
    await expect.element(tester.root).toHaveTextContent('The password is required');
  });

  it('should display an error when login fails', async () => {
    await tester.login.fill('john');
    await tester.password.fill('wrong-password');
    await tester.signIn.click();

    await expect.element(tester.error).toBeVisible();
  });

  it('should navigate away when login succeeds', async () => {
    const router = TestBed.inject(Router);
    vi.spyOn(router, 'navigate');

    await tester.login.fill('john');
    await tester.password.fill('correct-password');
    await tester.signIn.click();

    expect(router.navigate).toHaveBeenCalled();
  });
});

Isn't that beautiful?

Another cool thing? If you edit the component or its test and save, Vitest will reexecute just that test! Jest users had this for years, but we, poor Karma users, have been struggling with the whole test suite re-running on - every - single - save.

I still wonder how much time a very big test suite would take (the biggest app we're working on has more than 7500 tests), but given that Vitest can run tests in parallel, I hope it will scale reasonably well.

Anyway, we won't be able to rewrite all these tests any time soon.

For new projects, Vitest browser mode would be my preferred choice. What would be yours?

Angular Signal Forms - Part 2

2025-11-14T00:00:00Z

Welcome back to our series on Angular Signal Forms! In Part 1, we covered the basics: creating forms, handling submissions, and adding validation.

In this second part, we'll explore all the advanced features: custom validators, cross-field validation, asynchronous validation, dynamic field behavior, debouncing form updates, custom form components, sub forms, and other powerful capabilities that make Signal Forms a compelling choice for complex form scenarios.

Custom validation with `validate()` and `validateTree()`

You can write your own custom validators, either synchronous or asynchronous, and apply them with validate().

Let's start with a synchronous validator, that checks that the password of our Register form is strong enough.

A validator is simply a function that takes a ChildFieldContext as an argument, and returns either undefined if the field is valid, or a ValidationError if the field is invalid.

The ChildFieldContext provides useful methods to get the value or state of the field (as well as the value or state of other fields, more on that later).

Validators are typed, which is a great improvement over previous form systems.

// password is strong enough
validate(form.password, (context: ChildFieldContext<string>) =>
  isTooWeak(context.value()) ? { kind: 'too-weak', message: 'Password is too weak' } : undefined
);

It is also possible to add cross-field validation, by adding the validator to the parent field, and checking the values of the sub-fields.

// password is different from email
validate(form, context => {
  const { email, password } = context.value();
  return email && password && email === password
    ? {
        kind: 'password-different-from-email',
        message: 'Password should not be the same as email'
      }
    : undefined;
});

In your template, you can display this cross-field validation error by checking the errors on the form itself:

@if (accountForm().touched() && !accountForm().valid()) {
  <div id="form-errors">
    @for (error of accountForm().errors(); track error.kind) {
      <div>{{ error.message }}</div>
    }
  </div>
}

Alternatively, you can put the cross-field validation error on a specific field, using validateTree() instead of validate(). This function works like validate(), but allows returning errors targeting specific sub-fields of the tree. For example, to validate that the password is different from the email, but show the error on the password field:

validateTree(form, context => {
  const { email, password } = context.value();
  return email && password && email === password
    ? {
        // 👇 targets the password field
        field: context.field.password,
        kind: 'password-different-from-email',
        message: 'Password should not be the same as email'
      }
    : undefined;
});

It is also possible to add a validation to a field and get the value of another field by using the valueOf() method. The same example can be written like this:

// 👇 the validator is defined on the password field
validate(form.password, context => {
  // 👇 get the value of the email field
  const email = context.valueOf(form.email);
  const password = context.value();
  return email && password && email === password
    ? {
        kind: 'is-different-from-email',
        message: 'Password should not be the same as email'
      }
    : undefined;
});

Extracting and applying schemas with `apply()`

To avoid duplicating validation logic across forms, you can extract it into reusable schemas, that can then be applied to fields using the apply() function.

If both our login and password fields should be required and with a minimum length, we can extract this logic into a schema:

const requiredAndMinLengthSchema = schema<string>(field => {
  required(field, { message: 'This field is required' });
  minLength(field, 3, { message: 'Minimum length is 3 characters' });
});

Then we can apply this schema to both fields in our forms:

protected readonly accountForm = form(this.user, context => {
  // 👇 apply the same schema to both fields
  apply(context.login, requiredAndMinLengthSchema);
  apply(context.password, requiredAndMinLengthSchema);
});

A schema can also be applied to all elements of an array using applyEach():

protected readonly eventForm = form(
  signal({
    location: '',
    participants: ['ced'] as Array<string>
  }),
  context => {
    // 👇 apply the same schema to all participants
    applyEach(context.participants, requiredAndMinLengthSchema);
  }
);

By the way, to display an array of fields in the template, all you need is a plain old @for loop. No need for any special directive.

@for (participant of eventForm.participants; track participant) {
  <div class="participant">
    <label [for]="`participant-${$index}`">Username</label>
    <input [id]="`participant-${$index}`" [field]="participant" />
    @if (participant().touched() && !participant().valid()) {
      <div [id]="`participant-${$index}-errors`">
        @for (error of participant().errors(); track error.kind) {
          <div>{{ error.message }}</div>
        }
      </div>
    }
  </div>
}

applyEach() also works with objects, applying the schema to all properties. For example, if we want to make all fields required:

protected readonly loginForm = form(
  signal({
    login: '',
    password: ''
  }),
  context => {
    // 👇 apply the required schema to all fields
    applyEach(context, requiredSchema);
  }
);

Asynchronous validation with `validateAsync()` and `validateHttp()`

The validation can also be asynchronous thanks to the validateAsync() function, which uses a Resource:

// email is not already registered (async validation)
validateAsync(form.email, {
  params: (email: ChildFieldContext<string>) => email.value(),
  factory: (params: Signal<string | undefined>) =>
    resource({
      // 👇 Params contains the `email` signal and is used to trigger the resource
      params,
      // the loader makes an HTTP call to check if the email is already registered
      loader: async (loaderParams: ResourceLoaderParams<string | undefined>) =>
        // returns true if the email is already registered
        await this.userService.isRegistered(loaderParams.params)
    }),
    // 👇 This is called with the result of the resource
    onSuccess: (response: { isRegistered: boolean }) =>
      response.isRegistered
        ? {
            kind: 'email-already-registered',
            message: 'Email is already registered'
          }
        : undefined,
    // 👇 This is called if the resource fails
    onError: () =>
      ({
        kind: 'email-check-failed',
        message: 'Could not verify if the email is already registered'
      })
});

The resource is automatically called when the value of the field changes, and the field is marked as pending() while waiting for the result of the resource. When the resource resolves, if the onSuccess function returns an error, the error is added to the errors() of the field.

As an alternative, if you need to call an HTTP endpoint to validate a field, you can use a httpResource() with the validateHttp() function:

// email is not already registered (async validation)
validateHttp(form.email, {
  // 👇 httpResource is triggered when the email signal changes
  request: (email: ChildFieldContext<string>) => `/api/users/check?email=${email.value()}`,
  onSuccess: (response: { isRegistered: boolean }) =>
    response.isRegistered
      ? {
          kind: 'email-already-taken',
          message: 'Email is already taken'
        }
      : undefined,
  onError: () =>
    ({
      kind: 'email-check-failed',
      message: 'Could not verify if the email is already taken'
    })
});

In that case, you only need to provide the request URL.

Server errors

The submit function we saw earlier has another interesting feature: if the action you provide returns errors, they are automatically added to the errors() of the corresponding fields (or to the form if you don't provide a field).

await submit(this.loginForm, async form => {
  const { login, password } = form().value();
  try {
    await this.userService.authenticate(login, password);
    return;
  } catch (error) {
    // 👇 add an error to the form
    const message = (error as Error).message;
    return [{ kind: 'invalid-credentials', message }];
  }
});

Dynamic behavior

A more realistic form often has some dynamic behavior, for example, enabling/disabling or hiding/displaying fields based on the value of other fields, or adding/removing validators.

To hide a field, you can use the hidden() function, which lets you specify when the field should be hidden or not, based on the state of the form. When a field is hidden, it is excluded from validation. In the template, you can then use an @if block to display the field only if it's not hidden.

Similarly, to disable a field, you can use the disabled() function in the form schema. Here, the password field is disabled unless the login is valid:

protected readonly loginForm = form(this.credentials, f => {
  required(f.login);
  // 👇 disable the password field until a valid login is provided
  disabled(f.password, ({ stateOf }) => {
    return !stateOf(f.login).valid();
  });
});

You can go even further and return a string from the disabled logic, in order to populate the disabledReasons() of the field.

The last function to know about is readonly(), which makes a field read-only as you imagine. This is useful when you want to display an input that the user may not edit, but that should still be submitted with the form. disabled() and readonly() automatically update the HTML attributes of the corresponding field in the template: you don't need to do anything special for an input to be disabled in the template part of the form.

NOTE: Disabled fields do not behave the same way as in reactive forms: their value is still part of the form value when submitting it. The positive side is that you don't have to deal with the fact that all properties are potentially undefined. The negative side is that you need to be careful before sending this value to the server: it could be invalid if it comes from a disabled field. The same goes for hidden fields.

These functions can be used together to create complex dynamic behavior, and they can be applied conditionally. The second parameter of the form() function is not a reactive function, which means you can't use if/else conditions based on signals. You need to use applyWhenValue()/applyWhen() to apply these functions conditionally.

For example, to make a field mandatory only when a user is not admin (and let's say this info is stored in a signal called isAdmin):

protected readonly accountForm = form(this.user, form => {
  // 👇 the birth year field is required only when the user is not admin
  applyWhenValue(
    form,
    () => !this.userService.isAdmin(),
    form => {
      required(form.birthYear, { message: 'Birth year is required for non-admin users' });
    }
  );
});

If the logic depends on another field, you can use applyWhen() instead, which gives you access to the form and its fields via valueOf/stateOf:

protected readonly accountForm = form(this.user, form => {
  // 👇 the birth year field is required only when the isAdmin checkbox is not checked
  applyWhen(
    form,
    context => !context.valueOf(form.isAdmin),
    form => {
      required(form.birthYear, { message: 'Birth year is required for non-admin users' });
    }
  );
});

Debouncing form updates with `debounce()`

Sometimes you want to control when form control changes are synchronized to the form model. For example, you might want to delay validation while a user is still typing, to avoid triggering expensive validation checks on every keystroke.

Signal forms provide a debounce() function that allows you to manage the timing of form field updates:

protected readonly accountForm = form(this.user, form => {
  // 👇 let's say the computation is expensive, and we want to debounce it
  debounce(form.password, 500);
  // password is strong enough
  validate(form.password, (context: ChildFieldContext<string>) =>
    isTooWeak(context.value()) ? { kind: 'too-weak', message: 'Password is too weak' } : undefined
  );
});

When a debounce rule is applied to a field, the value signal may lag behind the controlValue signal. The controlValue represents the current value in the form control (what the user just typed), while value represents the debounced value that gets synchronized to the form model.

The debounce delay can be a fixed number (in milliseconds) or a function that returns a promise.

Custom form components with `FormValueControl` and `FormCheckboxControl`

Sometimes we need to build custom form components. We used to have ControlValueAccessor for that in previous form systems, but with signal forms, there is a new and simpler way to do that: by implementing the FormUiControl interface, or, more accurately, one of its children interfaces FormCheckboxControl (for boolean-like controls) and FormValueControl (for other types of values).

Note: Custom form components that use ControlValueAccessor are still supported in signal forms, but it's recommended to use these new interfaces for new components.

These interfaces only define the inputs and models your component should have, and Angular will bind the Field directive state into these signals automatically.

The properties to implement are:

value: (only for FormValueControl) a model input defining the value of the field
checked: (only for FormCheckboxControl) a model input defining whether the field is checked or not
touched: model input defining whether the field has been touched or not
disabled/disabledReasons/readonly/hidden/dirty: inputs containing the state of the field
errors/invalid/pending: inputs containing the validation state of the field
required/minLength/maxLength/min/max/pattern: inputs containing the built-in validators applied to the field

All these properties are optionals, except value or checked depending on the interface you implement. Most properties are read-only inputs, except value, checked, and touched, which are model inputs, as the component is expected to update them.

Let's build a Rating component, that allows the user to select a rating from 1 to 5. The value will be a number, so let's implement the FormValueControl<number> interface:

@Component({
  selector: 'app-rating',
  template: `
    @let v = value();
    @for (pickableValue of pickableValues; track pickableValue) {
      <button
        [class.selected]="v != null && pickableValue <= v"
        type="button"
        (click)="value.set(pickableValue)"
        [disabled]="disabled()"
        (blur)="touched.set(true)"
      >
        {{ pickableValue }}
      </button>
    }
  `,
  styles: ['.selected { background-color: yellow }']
})
export class Rating implements FormValueControl<number | null> {
  readonly value = model<number | null>(null);
  readonly touched = model(false);
  readonly disabled = input(false);

  protected readonly pickableValues = [0, 1, 2, 3, 4, 5];
}

The template is straightforward. We iterate over the possible ratings and display a button for each rating. Clicking a button updates the value. And when it loses focus (blur event), we mark the field as touched.

Changing the value of the model inputs automatically updates the state of the field in the form. And in the other direction, changing the field state automatically update the inputs of the component.

Our component can then be used in a form like this:

<app-rating id="rating" [field]="movieForm.rating" />

Sub forms

Sometimes you don't want to define the entire form in a single component. You may want to split it into several sub-forms, each defined in its own component. With signal forms, this is easy to do by passing a field to the child component.

Let's say our user form has an address sub-form:

protected readonly user = signal({
  firstname: '',
  lastname: '',
  address: {
    number: '',
    street: '',
    zipcode: '',
    city: ''
  }
});
protected readonly userForm = form(this.user, f => {
  required(f.firstname, { message: 'First name is required' });
  required(f.lastname, { message: 'Last name is required' });
  // 👇the address schema can be defined separately and reused
  apply(f.address, addressSchema);
});

We can define an Address component that accepts a FieldTree for the address:

@Component({
  selector: 'app-address-form',
  template: `
    @let address = addressField();
    <div>
      @let number = address.number;
      <label for="number">Number</label>
      <input id="number" [field]="number" />
      @if (number().touched() && number().invalid()) {
        <div>
          @for (error of number().errors(); track error.kind) {
            <div>{{ error.message }}</div>
          }
        </div>
      }
    </div>
    <input id="street" [field]="address.street" />
    <input id="zipcode" [field]="address.zipcode" />
    <input id="city" [field]="address.city" />
  `,
  imports: [Field]
})
export class AddressForm {
  readonly addressField = input.required<FieldTree<AddressModel>>();
}

Then we can use our Address component in the user registration template:

<app-address-form [addressField]="userForm.address" />

That makes it really easy to split a form into several components!

Conclusion

Signal forms bring a new way to build forms in Angular, based on signals and with a fresh approach to validation and reactivity. While still experimental for now, they already offer a lot of interesting features that make building forms easier and more enjoyable than before.

Among the benefits, the type safety is better than before; cross-field validation is easier to implement (no need to use FormGroup anymore); and building custom form components is simpler as well (FormValueControl is much simpler than ControlValueAccessor).

We lose the ng-valid/ng-dirty/... CSS classes that were automatically added to form controls, but we can easily recreate them using the properties of the FieldTree, even if it requires a bit more work in the template.

A few things would be great to have in the future, like better support for displaying error messages in the template (iterating over errors() is a bit low-level for most use cases).

What's next?

We've now covered the comprehensive features of signal forms: from creating forms and handling submissions to custom validators, asynchronous validation, server error handling, dynamic field behavior, debouncing form updates, custom form components, and sub forms.

Key takeaways from this series:

Signal forms provide a new signal-based approach to forms in Angular
They offer better type safety and easier cross-field validation than previous form systems
Custom validators are simple functions using validate() that return validation error objects
Asynchronous validation uses validateAsync() or validateHttp()
Server errors can be automatically mapped to form fields
Dynamic behavior is achieved via applyWhen() and applyWhenValue()
Form updates can be debounced using debounce() to control the timing of synchronization
Custom form components use FormValueControl, which is simpler than ControlValueAccessor
Sub forms can be easily created by passing fields to child components

Signal forms are still experimental but show great promise for making form development more intuitive and type-safe in Angular applications!

All our materials (ebook, online training and training) are up-to-date with these changes if you want to learn more!

Angular Signal Forms - Part 1

2025-11-04T00:00:00Z

In Angular v21, developers will have a new way, experimental for now, to build forms: Signal Forms.

After years of working with template-driven forms (ngModel) and reactive forms (formGroup/formControl), we now have a third approach that's entirely based on signals, available in the @angular/forms/signals package.

This is the first part of our series on Angular Signal Forms. In this article, we'll explore the basics: creating forms, handling submissions, and adding validation.

Let's dive in! 🚀

Creating a form with `form()`

As this new way is based on signals, the first thing to do in your component is to define a signal that will hold the value of the form. Then you can create a FieldTree to edit the value of this signal, using the form() function from the @angular/forms/signals package.

Here I want to write a Login component, where the user inputs their credentials:

// 👇 signal to hold the form credentials
private readonly credentials = signal({
  login: '',
  password: ''
});
// 👇 form created from the credentials signal (type is `FieldTree`)
protected readonly loginForm = form(this.credentials);

Then we need to bind each input/select/textarea to a field in the form. This is done using a single directive, Field:

<form (submit)="authenticate($event)">
  <label for="login">Login</label>
  <input id="login" [field]="loginForm.login" />
  <label for="password">Password</label>
  <input id="password" [field]="loginForm.password" />
  <button type="submit">Log in</button>
</form>

That's it! With just the [field] directive, your inputs are automatically bound to the form fields. A change on an input updates the corresponding property of the signal, and a change to the signal updates the input value.

Submitting the form with `submit()`

To submit the form, you can listen to the native submit event on the form element and call a method of your component.

In this method, you can then use the submit() function from the @angular/forms/signals package to handle the submission of the form. This function:

Marks all fields as touched
Checks the form validity
If valid, calls your provided async action with the form as an argument

The argument is the same object, a FieldTree, as the loginForm returned by the form() function.

The FieldTree object is a key concept in signal forms. Your loginForm is a FieldTree, and so are loginForm.login and loginForm.password.

A FieldTree, like a Signal, is an object that is also a function. If you call it (loginForm()), it returns a FieldState object with several signal properties that represent the state of the field:

value(): the current value of the field (may be debounced)
controlValue(): the current value in the form control (always up-to-date)
touched(): whether the field has been touched or not
dirty(): whether the field is pristine or not
disabled(): whether the field is disabled or not
disabledReasons(): if the field is disabled, the reasons why
hidden(): whether the field is hidden or not
readonly(): whether the field is readonly or not
submitting(): whether the field is being submitted

Some properties are related to validation, a topic we cover below:

pending(): whether the field is pending (async validators running)
valid(): whether the field is valid (all validators passed). Note that valid() is false until all async validators are done.
invalid(): whether the field is invalid
errors(): the errors of the field (if any)
errorSummary(): the errors of the field and its sub-fields (if any)

It also has a few methods to change the state of the field:

reset() to mark the field as pristine and untouched (but does not reset the value)
markAsTouched()/markAsDirty() to mark the field as touched/dirty.

We can also grab the FieldState of a sub-field using loginForm.login() for example, and each property then represents the state of that sub-field (its value, dirtiness, etc).

So, to come back to our form submission, we can write:

protected async authenticate(event: SubmitEvent) {
  // 👇 prevents the default browser behavior
  event.preventDefault();
  // 👇 submits the form if it's valid by calling the authenticate method (a promise)
  await submit(this.loginForm, form => {
    const { login, password } = form().value();
    return this.userService.authenticate(login, password);
  });
}

Note that the function that you pass to submit() must return a Promise. So if your service returns an Observable, you'll have to convert it to a promise using, for example, the firstValueFrom() function from rxjs.

Let's now add some validation to our form.

Adding validation with built-in validators

Angular provides a validation system based on functions that can be used to programmatically constrain the value of a field.

As with the previous form systems, there are two types of validators:

synchronous validators, that run immediately
asynchronous validators, that return a Promise and only run if all the synchronous validators on the field pass

The framework itself provides some built-in synchronous validators, the same as those it provides for reactive and template-driven forms:

required(field) to mark a field as required
minLength(field, length) to set a minimum length (for strings and arrays)
maxLength(field, length) to set a maximum length (for strings and arrays)
min(field, min) to set a minimum value (for numbers)
max(field, max) to set a maximum value (for numbers)
email(field) to validate an email address
pattern(field, pattern) to validate a value against a regex pattern

The functions take the field to validate as the first argument, and other arguments depending on the validator.

Let's build another Register form, allowing the user to create an account:

protected readonly accountForm = form(
    signal({
      email: '',
      password: ''
    }),
    // 👇 add validators to the fields, with their error messages
    form => {
      // email is mandatory
      required(form.email, { message: 'Email is required' });
      // must be a valid email
      email(form.email, { message: 'Email is not valid' });
      // password is mandatory
      required(form.password, { message: 'Password is required' });
      // should have at least 6 characters
      minLength(form.password, 6, {
        // can also be a function, if you need to access the current value/state of the field
        message: password => `Password should have at least 6 characters but has only ${password.value().length}`
      });
    }
);

Each validator will then run when the value of the field changes. If the validation fails, a ValidationError is added to the errors() property of the field. A ValidationError is an object with several properties:

kind: the kind of error (for example required, minLength, etc)
field: the field that caused the error
message: an optional human-readable message. There is no message by default, you need to provide it yourself when applying the validator if you want one.

Some validators can add more properties to the error, for example, the minLength validator adds a minLength property to the error, so you can access it when displaying the error message.

These errors can be displayed in the template by iterating over the errors() property of the field:

<input id="email" [field]="accountForm.email" />
@let email = accountForm.email();
@if (email.touched() && !email.valid()) {
<div id="email-errors">
  @for (error of email.errors(); track error.kind) {
    <div>{{ error.message }}</div>
  }
</div>
}

The built-in validators do more than they used to: they also add a property on the field. This property can be useful to know if a validator is applied to a field. For example, in the template, you can add an asterisk next to the label of required fields:

<label for="email">
  <span>Email</span>
  @let isEmailRequired = accountForm.email().metadata(REQUIRED);
  @if (isEmailRequired()) {
    <span>*</span>
  }
</label>

The metadata(REQUIRED) method returns a signal, and its value can be true or false. But some validators store additional details in this metadata. For example, the signal returned by metadata(MIN_LENGTH) contains the minimum length.

Standard schema validation with `validateStandardSchema()`

In addition to the previous built-in validators, signal forms offer a new way to define the field's constraints, by using a schema validation.

A few libraries have made this popular lately, like Zod or Valibot.

Both allow you to define a schema to represent your data, using functions to define the type of each field, and to add constraints to these fields. These libraries and others even joined their effort to define a standard: Standard Schema, which provides a common interface, called StandardSchemaV1, that libraries can use.

Angular relies on this standard and offers a validateStandardSchema() function which accepts such a StandardSchemaV1 schema.

This schema can be defined with whatever library you prefer. Let's use Zod Mini to define a validation schema for our Register form:

(form) => {
  validateStandardSchema(
    form,
    z.object({ email: z.string().check(z.email()), password: z.string().check(z.minLength(6)) })
  );
};

Here, we don't define error messages. The errors will be generated automatically by the validateStandardSchema() function which returns errors of type StandardSchemaValidationError. These errors have the same properties as the previous ValidationError.

For example, if you input a too short password, you'll get an error like this:

Too small: expected string to have >=6 characters

This can be customized as well, as Zod Mini allows defining error messages when defining the schema, using z.string().check(z.minLength(6, { message: issue => `Password should have at least ${issue.minimum} characters` })) for example.

What's Next?

We've covered the fundamentals of Angular Signal Forms: creating forms, handling submissions, and adding basic validation with built-in validators or using schema validation with libraries like Zod.

In the next part, we'll explore more advanced topics: like creating custom validators, cross-field validation, and asynchronous validation.

Stay tuned for Part 2!

All our materials (ebook, online training and training) are up-to-date with these changes if you want to learn more!

What's new in Angular 20.3?

2025-09-11T00:00:00Z

Angular 20.3.0 is here!

Angular v20 will be one of the very few versions to have a third minor release. The main reason is a security patch for a vulnerability in the platform-server/ssr packages. The fix is a breaking change which was released across all active LTS versions.

Vulnerability fix in platform-server and ssr

The vulnerability is described on the Angular repo: CVE-2025-59052.

As explained there, an attacker could potentially send multiple requests and inspect responses for leaked information from other users' requests in SSR applications.

The cause is that the platform injector was shared globally during SSR. When multiple requests were processed concurrently, they could share or overwrite this global state, causing one request to respond with data meant for a different request (which could lead to bugs in addition to being a security vulnerability).

Three APIs received breaking changes to address this issue: bootstrapApplication, getPlatform, and destroyPlatform.

The new approach introduces a BootstrapContext that is passed to the bootstrapApplication function. This context provides a platform reference that is scoped to the individual request, ensuring that each server-side render has an isolated platform injector.

Instead of:

const bootstrap = () => 
  bootstrapApplication(AppComponent, config);

you now need to do:

const bootstrap = (context: BootstrapContext) =>
  bootstrapApplication(AppComponent, config, context);

getPlatform and destroyPlatform now returns null and are no-op on the server.

A schematic has been included in the release to help you migrate your code, so you just have to run ng update @angular/core.

Extended diagnostics

The Angular compiler already checks that signals are properly invoked in interpolations and bindings. The extended diagnostics in v20.3 now also check them in @if and @switch:

✘ [ERROR] NG8109: user is a function and should be invoked: user() [plugin angular-compiler]

    src/app/home/home.html:10:8:
      10 │   @if (!user) {

Angular CLI

The CLI was also released in version 20.3.0, with the same security fix as above for @angular/ssr.

The only notable change that I noticed otherwise is that the variable names are now kept when serving the application in dev mode. This means the error messages will no longer contain weird underscores like _App or _UserService, which is a nice improvement for debugging.

That's all for this small release. The next one will be v21, and will include experimental signal forms. We have a dedicated article about it coming soon, so stay tuned!

All our materials (ebook, online training and training) are up-to-date with these changes if you want to learn more!

What's new in Angular 20.2?

2025-08-20T00:00:00Z

Angular 20.2.0 is here!

This release marks a pivotal moment for the framework: the stabilization of Zoneless change detection! v20.2 also introduces a complete overhaul of the animations API, and new AI features.

Let's dive in.

Zoneless is stable!

Angular v20.2 marks the stability of the Zoneless API (provideZonelessChangeDetection()), which allows developers to build Angular applications without the need for zone.js. New applications are not zoneless by default yet, but this should be the case in the next major version.

New animations support

This version marks a significant turning point for animations in the framework. @angular/animations is now deprecated and replaced with a new, simpler, API. The animations package hasn't seen major updates since its original author left the Angular team a few years ago, and it's not been actively maintained since then. The old API was a bit complex, heavy, and built in a time where browsers did not have advanced CSS features. Most animations can now be written using pure CSS.

A RFC has been opened last June to discuss the use-cases where pure CSS is not enough. As a result, Angular 20.2 introduces a new (stable) API for animations to handle these cases.

The problem is that what we often want is to apply a transition effect when an element appears in the DOM or disappears from the DOM. But @if and @for don’t change the style of an element: they simply add or remove elements from the DOM. So we need something more to, for example, have fade-in and fade-out transitions when elements appear and disappear.

Angular lets you animate elements with the animate.enter/animate.leave syntax, introduced in v20.2, allowing you to add classes to an element when it enters or leaves the DOM. These classes are then removed by Angular when the associated animation is done.

@if (display()) {
  <div animate.enter="fade-in" animate.leave="fade-out">Content</div>
}

So here the animated classes are going to be fade-in and fade-out. Let’s define a "fading" effect in CSS using these classes:

.fade-in {
  /* initial state */
  @starting-style {
    opacity: 0;
  }
  transition: opacity 300ms;
  opacity: 1;
}

.fade-out {
  transition: opacity 300ms;
  opacity: 0;
}

Here the transition will last one second, and will progressively change the opacity from 0 to 1 when the element enters, and from 1 to 0 when it leaves.

Every time the condition of the @if changes, the element fades in or fades out over a second, instead of appearing or disappearing brutally.

Your imagination (and CSS skills) is the limit here: you can apply whatever effect you want!

You can use bindings with animate.enter and animate.leave, to bind a signal value, a method result or an array of classes for example:

@if (display()) {
  <div [animate.enter]="enterClasses()">Content</div>
}

If you don’t want to rely on CSS animations and prefer to use JavaScript animations, with the power of libraries like GSAP, then you can use animate.enter and animate.leave with the event binding syntax to call a method when the element enters or leaves:

@if (display()) {
  <div (animate.leave)="rotate($event)">Content</div>
}

The method is called with an AnimationCallbackEvent parameter, containing the target that is entering or leaving and a completeAnimation method that you must call when the animation is done:

protected rotate(event: AnimationCallbackEvent) {
  gsap.to(event.target, {
    rotation: 360,
    duration: 0.3,
    onComplete() {
      event.animationComplete();
    }
  });
}

In tests, the animations are turned off by default, so you don’t have to worry about them. If you want to test animations, you can configure the TestBed to enable animations with the animationsEnabled option:

TestBed.configureTestingModule({
  animationsEnabled: true
});

With this option enabled, elements won’t be removed until the animations are done.

You can check out the new chapter in our ebook on animations to learn more.

Templates

ARIA bindings

If you care about accessibility, you know how important ARIA (Accessible Rich Internet Applications) attributes are. Angular v20.2 introduces a new feature to make working with ARIA attributes easier and more intuitive. Until now, we had to use the attr. prefix to bind ARIA attributes, like this:

<div role="progressbar" [attr.aria-valuenow]="value()"></div>

With the new feature, you can now bind ARIA attributes directly without the attr. prefix:

<div role="progressbar" [aria-valuenow]="value()"></div>

or even:

<div role="progressbar" [ariaValueNow]="value()"></div>

Angular will automatically set the proper ARIA attributes instead of looking for aria properties.

Alias in `@else if` blocks

The control flow syntax now allows defining an alias in @else if blocks. Until now, it was only possible to use as in the first @if block, but now you can also use it in @else if blocks as well:

@if (admin(); as a) {
  Welcome Admin {{ a.name }}!
} @else if (user(); as u) {
  Welcome {{ u.name }}!
}

New characters allowed in templates

When the control flow syntax was introduced in Angular v17, it was not possible to use the @ character in templates. For example to display a user's email address, you had to use the user@mail.com property instead of user@mail.com. This is no longer the case in Angular 20.2, and you can now use the @ character directly in templates. The { and } characters are still not allowed, so you still have to use the { and } in that case.

The compiler also accepts more characters in the property binding syntax, so you can have / or other [ ] characters in your property names. This is mainly to accommodate Tailwind CSS users, who can have classes with these characters. The compiler will now correctly parse bindings like [class.text-primary/80] and [class.data-[size='large']].

Extended diagnostics

A new extended diagnostic uninvokedFunctionInTextInterpolation has been added to warn you when you forget to call a method in an interpolation.

For example, if you have a getUserName() method that returns the user's name, and used it in a template like this:

<p>{{ getUserName }}</p>

throws:

[ERROR] NG8117: Function in text interpolation should be invoked: getUserName().

Forms

It is now possible to push an array of form controls into a FormArray using the push method. Until now you had to push them one by one.

Router

The Router.getCurrentNavigation method has been deprecated and replaced with currentNavigation signal. The signal returns the same thing as the previous method, a Navigation object or null. A migration has been provided to automatically update your code when running ng update.

Performances

The internal algorithm for signals has been changed to use linked lists instead of arrays, as Preact, Vue and other libraries have done. This should improve performance, and maybe put the Angular implementation slightly higher in the reactivity benchmarks (where it currently ranks dead last).

Testing

The TestBed.createComponent and TestBed.configureTestingModule methods have a new option inferTagName. When inferTagName is set to true, the TestBed will automatically infer the tag name of the component being tested based on its selector and use this tag name in the generated DOM. Until now (or when the option is false, as it is by default), the TestBed would use a div to represent the component, which is different from what would happen at runtime. This is usually not a problem, but the plan is to switch this option to true by default in a future version to limit the discrepancies between the test and runtime environments.

Service worker

The Service Worker package has received several improvements in v20.2, focusing on better error handling and developer experience.

Angular now provides better error handling with the addition of messageerror event handling and logging. This enhancement allows developers to capture and debug communication errors between the service worker and the main application thread more effectively.

The service worker has also gained improved storage management with better detection of storage full scenarios when caching data. This prevents silent failures and provides clearer feedback when 95% of the browser's storage quota is reached during data caching operations.

A new updateViaCache option is now supported in provideServiceWorker(), giving developers more control over how the service worker updates itself. This option allows you to specify whether the service worker script should bypass the browser cache when checking for updates, which can be set to 'all', 'none', or 'imports'.

Another option, type, allows you to specify the type of the ServiceWorker script to register('classic' or 'module', defaults to 'classic'). When specifying 'module', it registers the script as an ES module and allows use of import/export syntax and module features.

Finally, the service worker now notifies clients about version failures with more detailed error information. When a service worker update fails, clients now receive VERSION_FAILED events that include specific error details, making it easier to debug deployment issues and understand why a service worker update didn't succeed.

These improvements enhance the reliability and debuggability of Angular's service worker implementation, making it easier for developers to diagnose and resolve issues in production applications.

TypeScript 5.9 support

Angular v20.2 now supports TypeScript 5.9. This means you'll be able to use the latest version of TypeScript in your Angular applications. You can check out the TypeScript 5.9 release notes to learn more about the new features.

Devtools

A new tab in the devtools allows to see the "transfer state" of your application if you use hydration.

Angular CLI

Vitest support

The experimental unit-test builder introduced in Angular v20 has been improved and now supports the headless mode for Vitest, which means that you can run your tests in a headless browser. To do so, you need to use the browser mode of the builder and add the "Headless" suffix to the browser name, like this:

"runner": "vitest",
"browsers": ["ChromiumHeadless"]

Rolldown chunk optimization

The experimental chunk optimization that has been around since Angular v18.1 now uses rolldown instead of rollup. Rolldown is a new tool, compatible with rollup, but written in Rust, which makes it faster. It is developed by the VoidZero team, the same team that now develops Vite. Rolldown is still experimental and less battle-tested than rollup, but as the chunk optimization option is itself experimental, I guess this is not a big deal, and we may see a tiny performance improvement in build times.

AI

A large part of the new features of the CLI are in the AI domain.

A new command lets you generate configuration files for your favorites AI tools:

ng g ai-config --tool=<your-favorite-ai-tool>

The supported tools are gemini, claude, copilot, windsurf, jetbrains, and cursor. For example --tool=claude generates a .claude/CLAUDE.md file in the directory containing the Angular best practices. ng new will also prompt for the AI tool to use when generating a new project.

The MCP server introduced in Angular v20.1 gained a few new features:

a search_documentation tool has been added to search the documentation from the CLI, using the same search engine (Algolia) as the documentation website. The LLM will use this if asked a question about Angular and return a list of entries with their titles and URLs, with the top entry directly fetched and displayed;
a get_best_practices tool, similar to the existing resource, in case resources are not available in your LLM;

The mcp command now also accepts options:

--local-only indicates to only use local tools (no network access, so the search_documentation is not available)
--read-only indicates to only use read-only tools (no write access, but for the moment all tools are read-only)
--experimental-tool <tool> indicates to use an experimental tool

Two new experimental tool have been added, and can be enabled with --experimental-tool:

a modernize tool, which helps you generate code or update your files to use the latest best practices and features. When used, it will tell the LLM which migration can be run and the LLM can determine which ones are useful and can then prompt you to run the migration. The current migrations listed are control-flow, self-closing-tags, inject, standalone, and the signal migrations (input, output, queries).
a find_examples tool, which helps the LLM to generate code by using a pool of examples. Only one simple example is available for now (a simple @if) but the feature allows to register your own examples in a directory, and then use the NG_MCP_EXAMPLES_DIR environment variable to let the MCP know about the location of the examples.

This next release will be v21, and will hopefully include signal forms. Stay tuned!

All our materials (ebook, online training and training) are up-to-date with these changes if you want to learn more!

What's new in Angular 20.1?

2025-07-09T00:00:00Z

Angular 20.1.0 is here!

One month after the huge v20 release, the Angular team delivers a new minor update. This release introduces devtools with signal dependency graphs, improvements in component testing with new binding helpers, and adds a lot of HTTP client options that can boost your Core Web Vitals scores. Plus, Angular takes its first steps into the AI-assisted development era with MCP server support.

Let's dive in.

Devtools

The devtools have been updated with some nice new features. You can now inspect the details of a route in the router tab, but most of the improvements are for signals.

We can now inspect a signal from the devtools and jump to its definition. But more importantly, we now have a new "Signal Graph" tab that shows the dependencies between signals in a graph, and flashing of nodes when a signal changes. It can be enabled in the devtools settings by switching on the "Enable signal graph (experimental)" option. You can then click on a component and on the "Show signal graph" button to see the graph of signals that are used in this component!

You then get a (still a bit rough) graph with signals and inputs in blue, computed signals in green, and effects in grey. It will probably be improved in the future, but it is already a nice way to visualize the dependencies between signals and to understand how they are used in your application. Some compiler magic (a TypeScript transformer) has been implemented to add a "debugName" to each signal, based on the variable name in the component, which is used in the graph to display the name of the signal.

Tests

It is now possible to create a component in a test with its bindings directly set.

Let's say you have a User component:

@Component({
  // ...
})
export class User {
  readonly userModel = input.required<UserModel>();
  readonly selected = output<true>();
  // ...

A common practice is to test this type of component with a wrapper component:

@Component({
  // ...
  template: `<app-user
    [userModel]="userModel()"
    (selected)="isSelected.set(true)"
  />`,
})
export class UserHost {
  readonly userModel = signal<UserModel>({
    /* ... */
  });
  readonly isSelected = signal(false);
}

// ...
it("should display a user", () => {
  const fixture = TestBed.createComponent(UserHost);
  // ....
});

This can now be simplified, thanks to inputBinding(), outputBinding() and twoWayBinding() that were introduced in v20 and to an evolution of the TestBed.createComponent method in v20.1:

it("should display a user", () => {
  const userModel = signal<UserModel>({
    /* ... */
  });
  const isSelected = signal(false);
  const fixture = TestBed.createComponent(User, {
    // 👇 directly bind inputs/outputs
    bindings: [
      inputBinding("userModel", userModel),
      outputBinding("selected", () => isSelected.set(true)),
    ],
  });
  // ....
});

This is a nice improvement, even if the "wrapper component" approach is still valid and can be useful in some cases, for example, when you want to test a component which uses ng-content or a directive that requires a host element.

Performances

The low-level set of instructions that the compiler generates for templates has been extended with DOM-only instructions, used when the compiler can safely determine that the element has no directives applied to it. Those DOM-only instructions are more efficient than the generic ones, even if this is hard to measure in practice.

A template like the following:

<figure>
  <img [src]="userImageUrl()" />
  <figcaption>{{ userModel().name }}</figcaption>
</figure>

used to be compiled into the following instructions:

if (renderFlags & RenderFlags.Create) {
  elementStart(0, "figure");
  {
    element(1, "img");
  }
  {
    elementStart(2, "figcaption");
    text(3);
    elementEnd();
  }
  elementEnd();
}
if (renderFlags & RenderFlags.Update) {
  advance();
  property("src", ctx.userImageUrl());
  advance(2);
  textInterpolate(ctx.userModel().name);
}

It is now compiled into the following instructions:

if (renderFlags & RenderFlags.Create) {
  domElementStart(0, "figure");
  {
    domElement(1, "img");
  }
  {
    domElementStart(2, "figcaption");
    text(3);
    domElementEnd();
  }
  domElementEnd();
}
if (renderFlags & RenderFlags.Update) {
  advance();
  domProperty("src", ctx.userImageUrl());
  advance(2);
  textInterpolate(ctx.userModel().name);
}

The elementStart, element, elementEnd, and property instructions still exist, but they are now used only when the component has dependencies.

Templates

The compiler now supports assignment operators in templates: +=, -=, *=, /=, %=, **=, &&=, ||= and ??= are now allowed.

The NgOptimizedImage directive now offers a decoding option, which can be set to async, sync, or auto (default). You can use async to decode the image off the main thread, or sync to decode it immediately (blocking). auto lets the browser decide the best strategy.

HTTP

The HttpClient gained a bunch of new options in v20.1:

timeout which indicates the maximum time to wait for a response. It can be set to a number of milliseconds. If the request takes longer than this time, it will be aborted.
cache (with the Fetch API only) which indicates if the request should use the browser cache. It can be set to default, no-store, reload, no-cache, force-cache or only-if-cached, see MDN for more details.
priority (with the Fetch API only) which indicates the priority of the request. It can be set to auto (default), high or low. It can be useful to improve your Core Web Vitals scores by distinguishing between high-priority requests that impact LCP and low-priority requests.
mode (with the Fetch API only) which indicates the mode of the request. It can be set to cors (default), no-cors, same-origin or navigate. This is used to determine if cross-origin requests lead to valid responses, and which properties of the response are readable, see MDN.
redirect (with the Fetch API only) which indicates how to handle redirects. It can be set to follow (default), error or manual.
credentials (with the Fetch API only) which indicates whether to include credentials in the request. It can be set to omit (default), same-origin or include. This is used to determine if cookies and HTTP authentication are included in the request, see MDN. This option is more flexible than the existing withCredentials option (which is still available and is equivalent to include) and should be preferred.
referrer (with the Fetch API only) which indicates the referrer of the request. It can be set to a URL, an empty string for no referrer or about:client. This is used to determine the referrer of the request, see MDN.
integrity (with the Fetch API only) which indicates the integrity of the request. It can be set to a hash of the response body. This is used to verify that the response has not been tampered with, see MDN.

Most of these options are not supported when using the XHR backend.

The HttpResource also supports all these options as well as keepalive (introduced in v20 for the HttpClient).

Router

The router loadChildren and loadComponent functions now run in the injection context of the route, allowing you to inject services within the functions.

Service worker

The Service Worker Push service SwPush now supports the notificationclose and the pushsubscriptionchange events, with the new notificationCloses and pushSubscriptionChanges observables (in addition of the existing notificationClicks observable).

Angular CLI

This is a fairly small release for the CLI.

A notable feature is the possibility to use base64 and dataurl loaders, in addition to the pre-existing text, binary, and file loaders. dataurl inlines the content as a data URL and base64 inlines the content as a Base64-encoded string.

This can be used to inline small assets in your application:

import contents from './assets/small-image.png' with { loader: 'dataurl' };

The experimental unit-test builder now allows to define some options (only for vitest):

setupFiles which are files that are loaded before the tests are run, allowing you to set up the test environment.
codeCoverageReporters which allows you to specify the code coverage reporters to use.

But the main feature of CLI v20.1 is the new ng mcp command, which allows you to start an MCP server, a hot topic in the AI community.

So let's talk about AI!

AI

Angular is fully embracing the AI trend. We now have a new documentation page explaining how to properly configure your favorite AI tool to help you with Angular development: Develop with AI. The page provides rules files for the most popular AI tools, such as Copilot, Cursor, VSCode, etc.

The CLI has also been updated and now includes an MCP server. MCP stands for "Model Control Protocol" and is the hot new protocol that allows LLMs to communicate with external tools and resources. This protocol was introduced by Anthropic last year and is now supported by many AI tools.

You can run:

ng mcp

which outputs the configuration you need to add to your AI tool:

To start using the Angular CLI MCP Server, add this configuration to your host:

{
  "mcpServers": {
    "angular-cli": {
      "command": "npx",
      "args": ["@angular/cli", "mcp"]
    }
  }
}

Exact configuration may differ depending on the host.

This means that you can now use the CLI to start an MCP server, then configure your favorite AI tool to connect to it. The MCP server is quite minimalist for now, as it offers only one resource (the best practice file mentioned above) and one tool (the ability to list the Angular projects and their options in your workspace).

In my experiment with Copilot and Claude Code, it seems that extending the context with the resources the MCP server provides does make a difference in the quality of the suggestions.

Summary

Most features of v20.1 are oriented towards improving the developer experience. We also saw a new RFC about the future of the animation package. We can expect movements in this area in the next releases and hopefully some movements in the signal forms area as well.

Stay tuned!

All our materials (ebook, online training and training) are up-to-date with these changes if you want to learn more!

What's new in Angular 20.0?

2025-05-28T00:00:00Z

Angular 20.0.0 is here!

It sounds a bit incredible that we are already at version 20, but here we are! This is a major release with a lot of new features, improvements and breaking changes. Let's dive into the details of this new version and also look at what to expect in Angular v21 👀.

TypeScript v5.8 and Node v20 required

Angular v20 now requires TypeScript v5.8 (it has been supported since v19.2). You can check out the TypeScript v5.8 release notes to learn more about the new features. Older versions of TypeScript are not supported anymore.

Angular v20 also requires Node v20. Angular v19 was the last version to support Node v18.

2025 Angular style guide

A major update of the Angular style guide has been released, with a lot of recommendations removed to focus on the most important ones.

You can check it out at angular.dev/style-guide.

The recommended naming convention for files has changed, with most of the suffixes being removed. A user component should now be named User, or UserCard, or UserPage (for example) instead of UserComponent. in a file named user.ts (or user-card.ts, or user-page.ts) instead of user.component.ts. The same applies to directives, pipes, etc. The CLI has been updated to use this new naming convention by default, as explained below.

The folder structure has also evolved, with the removal of the top-level app folder. The CLI does not comply with this new structure yet, but I imagine it will be the new default soon.

Among other notable changes, it is now recommended to use protected for properties that are only accessed in the template, and readonly for all the properties that are initialized by Angular, like input(), output(), etc.

It is also now official that [class.something] and [style.something] are the recommended way to bind classes and styles in templates over ngClass and ngStyle.

This new naming convention and style guide is a big change for Angular, and even if new projects will use it by default, existing projects will either have to migrate to it or keep using the old style guide (see the CLI section below for more details).

Signal APIs are stable

Signals are the future of Angular reactivity, and the Angular team has been working hard to stabilize the APIs around them.

Most of the APIs related to signals are now stable:

effect()
toSignal()
toObservable()
afterRenderEffect()
afterNextRender()
linkedSignal()
PendingTasks

Two developer preview APIs are being renamed.

The biggest change is that afterRender() has been renamed to afterEveryRender() and is now stable. Unlike stable APIs, the old name wasn't kept for backward compatibility, and no migration was provided.

TestBed.flushEffects(), which was introduced in v17 to trigger pending effects in tests, has been deprecated and should now be replaced with TestBed.tick(). This new method runs the entire synchronization process instead of manually triggering the effects in a way that would not happen in a running application. flushEffects had a special treatment and was kept around as deprecated because it was not visible on the docs that it was in developer preview 🤷.

Note that effect() lost its forceRoot option, which was not very useful, and toSignal() lost its rejectErrors option, which was deemed a not-so-good practice.

pendingUntilEvent(), the RxJS operator introduced in v19, has been promoted from experimental to developer preview.

Zoneless is now in developer preview

If signals are the future of Angular reactivity, zoneless change detection is the future of Angular change detection.

Zoneless is no longer experimental, but not yet stable. It is now in developer preview and, to reflect that, the provider has been renamed from provideExperimentalZonelessChangeDetection to provideZonelessChangeDetection. Similarly, provideExperimentalCheckNoChangesForDebug has been renamed to provideCheckNoChangesForDebug (check our article about Angular v18 to learn more about these providers).

The ng new --experimental-zoneless flag has also been renamed to --zoneless in the CLI and the CLI now asks if you want to enable it when creating a new project.

Deprecations, removals and breaking changes

As usual with major releases, Angular v20 comes with a few deprecations, removals, and breaking changes.

The structural directives ngIf, ngFor and ngSwitch are now officially deprecated in favor of the control flow syntax. Note that structural directives in general are not deprecated, but only the ngIf, ngFor, and ngSwitch ones. These directives will likely be removed in Angular v22. The control flow migration can help you migrate and you will be asked if you want to run it during ng update.

The fixture.autoDetectChanges() method previously accepted a boolean parameter, now deprecated due to limited utility. If you used fixture.autoDetectChanges(true), you can now just use fixture.autoDetectChanges(). fixture.autoDetectChanges(false) is now even throwing if used in a zoneless test.

TestBed.get() has finally been removed (it had been deprecated in Angular v9). An automatic migration will run when you ng update to replace these calls with TestBed.inject() if you still have some.

Probably not much used, but worth noting, the InjectFlags enum is also removed. As explained in our Angular v14.1 blog post, these flags were deprecated in v14.1 when most of the DI APIs like inject() started to accept an options object instead. You probably did not have the time to use it, but a migration is nonetheless run during ng update to take care of it if that was the case.

The DOCUMENT token moved from @angular/common to @angular/core. Here as well, a migration will rewrite the imports in your project if needed.

The @angular/platform-browser-dynamic package has been deprecated in favor of @angular/platform-browser, but here you'll have to manually update the imports as there is no schematics for now. You can then remove the dependency from your project.

Another package got deprecated but with no replacement @angular/platform-server/testing. It is now recommended to use e2e tests to check your SSR applications.

The HammerJS integration has been deprecated. HammerJS has not been updated for the past 8 years so the team is planning to remove all HammerJS entities from the framework in the future.

Another breaking change that may go unnoticed is the removal of the generated ng-reflect-* attributes by default. These attributes have been present in dev mode since v2.4 for historical debugging reasons (I think the old devtools used them). If you rely on this in your application, which is a bad idea, you can re-enable them in dev mode using provideNgReflectAttributes().

Templates

Angular v20 supports a few new things in templates.

Exponentiation is now supported in templates, using the ** operator.

<p>{{ 2 ** 3 }}</p>

Angular v19.2 introduced the support for template strings in expressions, and we now have the ability to use tagged template literals as well:

<p>{{ translate`app.title` }}</p>

void is now also supported in template expressions. This can be useful to ignore the return value of a function, for example for event listeners (as returning false prevents the default behavior):

<button (click)="void selectUser()">Select user</button>

in is supported as well in v20:

@if ('invoicing' in permissions) {
  <a routerLink="/invoices">Invoices</a>
}

Extended diagnostics

As a proof that structural directives are still alive, a new extended diagnostic has been added to check if you're using a structural directive without importing it: missingStructuralDirective.

If that's the case, you'll get the following error with strictTemplates enabled if you are using *ngTemplateOutlet without importing it for example:

[ERROR] NG8116: A structural directive `ngTemplateOutlet` was used in the template without a corresponding import in the component.
Make sure that the directive is included in the `@Component.imports` array of this component.

Another extended diagnostic has been added to check that a function is properly invoked when used in a track expression of a @for block. For example, @for (user of users; track getUserId) { throws the following error:

[ERROR] NG8115: The track function in the @for block should be invoked: getUserId(/* arguments */) [plugin angular-compiler]

A last one has been added to check if you are mixing nullish coalescing with boolean operations in templates. TypeSCript forces you to use parentheses in this case when using the nullish coalescing operator (??) and a boolean operator (&&, ||, etc.) in the same expression like a ?? b && c.

In templates, there was no such check before and it is now recommended to use parentheses to avoid confusion. You now need to write {{ a ?? (b && c) }} instead of {{ a ?? b && c }} for example, otherwise you'll get the following error:

[ERROR] NG8114: Parentheses are required to disambiguate precedence when mixing '??' with '&&' and '||'.

To disable these checks, you can add the following to your tsconfig.json file:

"angularCompilerOptions": {
  "extendedDiagnostics": {
    "checks": {
      "missingStructuralDirective": "suppress",
      "unparenthesizedNullishCoalescing": "suppress",
      "uninvokedTrackFunction": "suppress"
    }
  }
}

Host type checking

The type-checking has been improved in an area that was not type-checked before.

If you ever used the host metadata in a directive or component decorator (or the @HostBinding() and @HostListener() decorators), then you may have noticed this was not checked by the compiler. This is no longer the case in v20 if you use a new option of the compiler called typeCheckHostBindings (this is already configured in new CLI project):

"angularCompilerOptions": {
  "typeCheckHostBindings": true,

The compiler now checks that:

the left side of the host binding/listener is valid for the element on which the component/directive is applied to
the right side references something that exists in the component/directive class

For example, the following code errors as value does not exist on labels:

@Directive({
 selector: 'label',
 host: {
    '[value]': 'value()'
    // ☝️ [ERROR] NG8002: Can't bind to 'value' since it isn't a known property of 'label'
  }
}
export class FormLabel {

The type checker is smart enough to understand if the binding works with all elements declared in the selector.

It also checks the right side of the binding to see if it exists. So the following throws as well:

@Directive({
  selector: 'label',
  host: {
    '[class.text-danger]': 'isInvalid'
    // ☝️ [ERROR] NG9: Property 'isInvalid' does not exist on type 'FormLabel'.

Note that extended diagnostics are not running on these bindings for now, so it does not catch if a signal is not called for example.

Error handling

Some changes have been made to avoid letting errors slip through the cracks.

A new provideBrowserGlobalErrorListeners provider has been added in Angular v20. It allows to register global error listeners in the browser. This is useful to catch errors that are not caught by Angular. This provider is automatically added to the app.config.ts file when you create a new project with the CLI.

Note that the errors thrown in event listeners are now reported to the internal Angular error handler, which means that you may see errors in tests that were not reported before. You can fix them or use rethrowApplicationErrors: false in configureTestingModule as a last resort.

Dynamically created components

The createComponent() API (v14.2) allows to dynamically create components to manually insert them.

The function (and ViewViewContainerRef.createComponent) gained a few possible options in v20. You can specify the directives to apply to dynamically created components, as well as the input values you want to provide to the component (or its applied directives) using the brand new inputBinding() function. It is also possible to declare two-way bindings with twoWayBinding() and to listen to outputs with ``:

const user = createComponent(User, {
  bindings: [
    twoWayBinding("name", name)
  ],
  // ☝️ two-way binding with the signal `name`
  directives: [
    {
      type: CdkDrag,
      // ☝️ applies the Drag directive
      bindings: [
        inputBinding("cdkDragLockAxis", () => 'x')),
        // ☝️ binds its lock axis to 'x' (has to be a signal or a function)
        outputBinding<CdkDragEnd>('cdkDragEnded', event => console.log(event))
        // ☝️ listens to the end of the dragging action
      ]
    }
  ]
});

This is a step up from the current setInput that could be called on the created component, but that would set the input after the first change detection. We can also imagine that this could be used in other APIs like TestBed.createComponent() in the future?

Forms

Still no signal support in the forms APIs, but the Angular team is working on it. Check out our sneak peek of the new forms APIs below 😉.

The forms APIs are relatively quiet in v20, but we have two minor changes worth mentioning.

It is now possible to reset forms without emitting events with userForm.resetForm(undefined, { emitEvent: false }).

We also now have a markAllAsDirty() method on AbstractControl, which allows us to mark a control and all its descendants as dirty. The markAllAsTouched() method already existed but for some reason, markAllAsDirty() was not available until v20.

Router

Scroll options

It is now possible to pass options to ViewportScroller.scrollToAnchor()/scrollToPosition(). All native scroll options are supported, for example behavior: this.scroller.scrollToPosition([0, 10], { behavior: 'smooth' }).

Resolvers

A good news for those using resolvers in the router: they can now read the resolved data from the parent route:

provideRouter([
  {
    path: "users/:id",
    resolve: { user: userResolver },
    // ☝️ user resolver in the parent route
    children: [
      {
        path: "posts",
        resolve: { posts: postsResolver },
        // ☝️ route.data.user is now available in the posts resolver
        component: UserPosts,
      },
      // ...
    ],
  },
]);

Asynchronous redirects

When defining a redirect in the route configuration, the redirectTo option accepts a function that can now be asynchronous by returning a promise or an observable that resolves to a redirect. This is technically a breaking change as the returned type evolved.

Custom elements support

Developers writing Web Components out there will be pleased to know that it is now possible to use a custom element as the host of a RouterLink.

Http

Resource API changes

The resource APIs continue to evolve with the feedback from the RFCs, slowly shaping them into a more stable API that we will use to build future applications.

resource() had its query parameter renamed to params and rxResource() had its loader parameter renamed to stream. The reload method has been moved from the base Resource class to the WritableResource class which means only mutable resources can now be reloaded.

httpResource also received some changes in v20 (you can check out our previous article to refresh your memory):

the map option has been renamed parse;
the HTTP context can now be specified in the options;
the request must now always be reactive.

The last point means that you can no longer write httpResource<Array<UserModel>>('/users') but now have to use httpResource<Array<UserModel>>(() => '/users').

keepalive support

The HttpClient now supports the keepalive option when using the Fetch API (which is the case if you use the withFetch() option). When set to true, the browser will not abort the associated request if the page that initiated it is unloaded before the request is complete.

Profiling

A new enableProfiling() function has been added to @angular/core.

If called in your application, it will enable some profiling features in Angular that will help you to analyze the performance of your application. Angular internally uses the Performance API to tag the usage of some of the framework APIs (change detection, template, outputs, defer, etc.). You can then use the Chrome Devtools to record a performance profile of your application and analyze the time spent in Angular, using the custom track added by Angular:

This can be useful to identify why a specific page or the startup of an application is slow.

Devtools

The Angular Devtools now mark OnPush components as such in the component tree. Deferred blocks are now also displayed. The signal support is also improving and we should soon be able to see the signals tree in the devtools.

SSR

On the SSR side, the withI18nSupport() and withIncrementalHydration() APIs have been stabilized.

The schematics now generate a server based on Express v5, and the code is slightly different as you can see in our angular-cli-ssr-diff.

provideServerRendering() and provideServerRoutesConfig(serverRoutes) are now combined into a single provideServerRendering(withRoutes(serverRoutes)) function. provideServerRendering is now in @angular/ssr instead of @angular/platform-server. A migration will take care of this refactoring for you if you run ng update.

When generating a new application with the CLI the --server-routing option has been removed and the --ssr option now generates a server with routing support by default.

Angular CLI

As you can see in angular-cli-diff, the project generated by the CLI has changed a lot.

Let's dive into the changes.

Updated naming for 2025 style guide

As mentioned above, the Angular style guide has changed a lot. The CLI has been updated to use the new naming convention by default. The generated files when running ng g c user are now named user.ts instead of user.component.ts, user.html instead of user.component.html, and user.css instead of user.component.css, etc. The name of a component is now User instead of UserComponent. You can opt out of this behavior by using the --type=component option when generating a component, or by setting the type option to component in the CLI configuration file.

If you want to, you can generate a component template with the .ng.html extension by using ng g c user --ng-html or by setting the ngHtml option to true in the CLI configuration file (the option is disabled by default).

The same goes for:

directives: ng g d highlight will generate a highlight.ts file instead of highlight.directive.ts, and the class will be named Highlight instead of HighlightDirective, except if you use the --type=directive option.
same thing for services: ng g s user will generate a user.ts file instead of user.service.ts, and the class will be named User instead of UserService, except if you use the --type=service option.

For pipes, resolver, interceptors guards, and modules: the names are the same as previously but the separator in the file name becomes a dash instead of a dot by default.

For example, ng g p from-now will generate a from-now-pipe.ts file instead of from-now.pipe.ts, except if you use the --type-separator=. option The class will still be named FromNowPipe though.

To keep the same behavior as before, an automatic migration has been added to the CLI to configure angular.json to use the old naming convention:

"schematics": {
  "@schematics/angular:component": { "type": "component" },
  "@schematics/angular:directive": { "type": "directive" },
  "@schematics/angular:service": { "type": "service" },
  "@schematics/angular:guard": { "typeSeparator": "." },
  "@schematics/angular:interceptor": { "typeSeparator": "." },
  "@schematics/angular:module": { "typeSeparator": "." },
  "@schematics/angular:pipe": { "typeSeparator": "." },
  "@schematics/angular:resolver": { "typeSeparator": "." }
}

TypeScript configuration

There are two big changes in the TypeScript configuration.

The module option is now set to preserve instead of es2022 to reflect more accurately how modern bundlers work. This removes the need to set the esModuleInterop and moduleResolution options.

The other change is more notable: the generated tsconfig.json file now uses a "solution" style configuration with references to tsconfig.app.json and tsconfig.spec.json (instead of having the tsconfig.app.json and tsconfig.spec.json files extend the base tsconfig.json). This should greatly help tools and IDEs understand the project structure!

Simplified angular.json

A new project now directly uses the @angular/build package instead of @angular-devkit/build-angular. This removes the need to install this package and all the Webpack-related transitive dependencies and results in a big reduction in the node_modules installed (nearly 200Mb!).

If you're updating a CLI project, a migration will update your angular.json file to use the new builder if you aren't already using it.

The angular.json file has also been simplified a bit, with some options like outputPath, index, and scripts removed as they now have a sensible default value.

Browserslist configuration

The CLI has been using browserslist for a while now, and you can tweak the supported browsers by generating the browserslist file using ng generate config browserslist.

The generated configuration used to target the last 2 versions of each browser, which is a moving target and depends on the time of the build.

The Angular team changed its support policy and now targets the "widely available" baseline. It includes browsers released less than 30 months of the chosen date within Baseline's core browser set (Chrome, Edge, Firefox, Safari) and targets supporting approximately 95% of web users (see https://web.dev/baseline).

The CLI now generates a browserslist file with the following content for v20, targeting browsers released in the last 30 months:

Chrome >= 107
ChromeAndroid >= 107
Edge >= 107
Firefox >= 104
FirefoxAndroid >= 104
Safari >= 16
iOS >= 16

If you use a custom browserslist configuration with a different set of browsers, you will see a warning like this:

One or more browsers which are configured in the project's Browserslist configuration fall outside Angular's browser support for this version.
Unsupported browsers:
chrome 106, chrome 105

Sass package importers

Sass supports pkg: importers to import packages from package managers (see Sass blog post). The CLI now supports this feature as well when using Sass as a preprocessor, so you can write @use 'pkg:@angular/material' as mat; in your Sass files for example.

Ahead of Time testing and code coverage for templates

If you've been using Angular for a while, you may remember a time when we had both Ahead-of-Time (AoT) and Just-in-Time (JiT) compilation for our applications. Ivy came around with a faster compiler, allowing us to always use AoT compilation. The CLI introduced the support of AoT testing with the ng test command in v19.2, but it was not really usable at that time, mostly because the TestBed allows to overwrite component metadata and this was not compatible with AoT compilation.

This has been fixed, and you can now use AoT compilation for your tests! This is a great improvement for consistency, as it allows you to run your tests in the same mode as your production code.

To do so, you can add the "aot": true option to your angular.json file:

"test": {
  "builder": "@angular/build:karma",
  "options": {
    "aot": true,

Note that you may have to fix issues in your tests when switching to AoT compilation, as you may have forgotten some required inputs in your tests for example. There are still a few issues left with overrideComponent that you may run into as well.

Running tests with AoT compilation also provides code coverage for the templates, which is a nice addition and may help to catch some untested parts of your components.

It looks like the test times are roughly the same with AoT compilation.

Testing with Vitest 🚀

The CLI now supports running tests with Vitest, a fast and modern test framework that is based on Vite.

The Angular team is still looking for a good replacement for Karma and Vitest was at first discarded as an option when the team focused on Jest (v16) and Web Test Runner (in v17). These Jest and WTR integrations are still experimental, and have not been updated in a while.

In the meantime, Vitest has exploded in popularity in other ecosystems, and the Angular team decided to give it a try.

A new builder has been added to the CLI, named unit-test. You can use it by replacing the @angular/build:karma or @angular-devkit/build-angular:karma builders with @angular/build:unit-test in your angular.json file.

"test": {
  "builder": "@angular/build:unit-test",
  "options": {
    "tsConfig": "tsconfig.spec.json",
    "buildTarget": "::development",
    "runner": "vitest",
  }
}

With this configuration, you can remove all the karma and jasmine dependencies from your project and will need to install the vitest package instead.

Note the runner option which specifies "vitest" (but can also accept "karma"). With this builder, you no longer need to configure how the tests should run with polyfills, assets, etc. You must now use a "buildTarget" with one of your build configurations as a value. Note that in my example above, I used the development build configuration, which means that the tests will run with AoT compilation.

By default, Vitest runs in a Node environment, and uses jsdom to simulate a browser environment, which you'll need to install as a dev dependency.

If you are migrating a project from Karma/Jasmine to Vitest, you'll need to update your tests to use Vitest APIs instead of Jasmine ones. You shouldn't have to add imports for the Vitest APIs though, as the CLI configures them to be global. To make sure your IDE picks them up, replace the jasmine types in your tsconfig.spec.json file with vitest/globals:

"types": ["vitest/globals"]

You can also run your tests in a real browser environment. Vitest has a browser mode, which is still experimental but works well enough. You'll need to install the @vitest/browser package and can remove the JSDOM dependency from your project.

"runner": "vitest",
"browsers": ["chromium"], // can be "firefox", "webkit"

The browser will be downloaded automatically when you run your tests, using either playwright or WebdriverIO, as the CLI indicates in the error message below when you run ng test without having one of these packages installed:

The "browsers" option requires either "playwright" or "webdriverio"
to be installed within the project.
Please install one of these packages and rerun the test command.

Once Playwright or WebdriverIO is installed, you can run your tests in a real browser environment: the CLI will download the browsers automatically and run the tests in it 🚀.

The execution times are a bit slower than with Karma though for a complete run. But the watch mode is faster, as it only runs the tests that are affected by the changes, whereas Karma runs all the tests every time.

The watch mode is by default as with the current Karma builder, but it is automatically disabled on CI or if there is no interactive terminal, which is closer to what vitest does by default. This means you no longer have to add the --no-watch option to the ng test command to run the tests in CI.

Speaking of flags, there is a new one with this builder called --debug. The debug mode only works with vitest as a runner, and with jsdom or in browser mode using Playwright. It hooks the Node Inspector into the test runner to allow you to debug your tests by connecting to it with a debugger.

There are a few limitations with this new test runner as it is still experimental. For example, you can't define a "setup" file to set up your tests as you can with Karma which is usually very handy to add custom matchers or do some assertions after each test. But the unit-test builder allows you to define a providersFile option, which is a file that will be loaded before the tests are run, with whatever providers you want to add to the test bed. This is useful for setting up zoneless testing, as you can add provideZonelessChangeDetection() in this file:

import { provideZonelessChangeDetection } from "@angular/core/testing";

export default [provideZonelessChangeDetection()];

You can't specify a Karma config file or Vitest config file for now, which means that you can't run the tests in headless mode for example, or configure a custom reporter.

You can configure a reporter or code coverage exclusions directly in the angular.json file though:

"test": {
  "builder": "@angular/build:unit-test",
  "options": {
    "tsConfig": "tsconfig.spec.json",
    "buildTarget": "::development",
    "runner": "vitest",
    "reporter": ["html", "json"], // uses @vitest/ui
    "codeCoverage": true, // uses @vitest/coverage-v8
    "codeCoverageExclude": ["src/app/ignore.ts"]
  }
}

Automatic Chrome workspace folders

The vite server now automatically serves a com.chrome.devtools.json file that the Chrome Devtools automatically picks up (behind a flag for now, but it will be enabled by default in the future). This file contains the project location on your disk and allows to directly edit source files from the Devtools, with the changes being saved in the original files.

You can enable this feature in Chrome by following the docs here. When done, you'll see a new "Workspace" tab in the Source panel of the Devtools. You'll be asked to connect to the workspace, and then you'll see a file tree with all the files in your project. You can then open any file in the Devtools and edit it. When saving the file, it will be saved in the original file on your disk and the changes will be reflected in the application.

Sourcemaps without sources

The CLI can now generate sourcemaps without the sourcesContent field which contains the original source code. To do so, you can set the sourceMap option to:

"sourceMap": {
  "scripts": true,
  "styles": true,
  "sourcesContent": false
}

This can be useful if you want to deploy sourcemaps to production to have better error reporting that includes the original source names, but you don't want to expose the original source code to the users.

Angular joins the AI train

As AI is everywhere nowadays, Angular could not avoid joining the hype train. The Angular docs are now exposed in a text file for LLMs at the root of the repository following the llms-full.txt emerging convention. If added to your AI favorite tool's context, it should help generate better Angular code.

What to expect in Angular v21

The Angular team will probably communicate about these features soon, but I can't resist sharing two projects that they have been cooking behind the scenes!

Selectorless components 😲

The beginning of a new experiment started: selectorless components. In the future, we may be able to use components and directives without a selector in our templates and without having to add the imports array in our component metadata!

import { User } from './user/user';
// ☝️ TS import is still necessary

@Component({
  template: '<User [name]="name()" (selected)="selectUser()" />',
  // but no Angular imports are needed! 😲
})
export class App {

Components can be used in templates without a selector by using their class name directly. Same thing for directives, but they currently require an @ prefix:

<User @CdkDrag(cdkDragLockAxis="y") [name]="name()" (selected)="selectUser()" />

Pipes can also be used without a name:

import { FromNowPipe } from './from-now-pipe';

@Component({
  template: '<p>{{ date | FromNowPipe }}</p>'
})
export class App {

Super big warning: the syntax is far from being decided. Only the compiler part has been done in v20, so nothing of the above is testable for now but we can already see that it opens a lot of possibilities. A RFC should probably come soon.

Signal Forms

In parallel, some prototyping has been done for signal forms. Is it based on template forms or reactive forms? Nope, it looks like it is going to be a brand new third way to write forms in Angular. Let's say we have a userModel signal data we want to edit. Angular will provide a form() function to get a Field, a new class that owns the state of the form (valid, touched, etc).

This code below is only available in the prototyping branch, so don't expect to use it in v20 😉:

@Component({
  selector: "user-form",
  imports: [FieldDirective],
  // ☝️ new directive
  template: `
    <form>
      <label>Username: <input [field]="userForm.username" /></label>
      <!-- ☝️ used to bind fields -->
      <label>Name: <input [field]="userForm.name" /></label>
      <label>Age: <input type="number" [field]="userForm.age" /></label>
    </form>
  `,
})
class UserFormComponent {
  userModel = signal<UserModel>({ username: "", name: "", age: 0 });
  protected readonly userForm: Field<User> = form<User>(
    // ☝️ form() is a new function and returns a Field
    userModel,
    // data to edit
    (userPath: FieldPath<User>) => {
      disabled(userPath.username, () => true, "Username cannot be changed");
      required(userPath.name);
      error(userPath.age, ({ value }) => value() < 18, "Must be 18 or older");
    }
    // ☝️ schema that allows to define the dynamic behavior of fields (enabled/disabled)
    // and the validation, with provided and custom validators
  );
}

If you want to learn more, you can check out the current design doc which is really interesting or wait for the probably not very far RFC that will discuss all this.

Summary

That were a lot of new features in Angular v20!

v21 will hopefully bring us the first usable version of signal forms and/or this new selectorless syntax. Stay tuned!

All our materials (ebook, online training and training) are up-to-date with these changes if you want to learn more!

What's new in Angular 19.2?

2025-02-26T00:00:00Z

Angular 19.2.0 is here!

This is a minor release with some nice features: let's dive in!

Angular the documentary

This is not really linked to Angular v19.2, but it's worth mentioning that the Honeypot channel released a documentary retracing the history of Angular, with interviews of the Angular team members (old and new):

👉 Documentary on youtube

TypeScript 5.8 support

Angular v19.2 now supports TypeScript 5.8, which is still in RC but should be out soon. This means you'll be able to use the latest version of TypeScript in your Angular applications. You can check out the TypeScript 5.8 release notes to learn more about the new features.

resource() and rxResource() changes

Some changes happened in the recently introduced resource and rxResource APIs. resource was introduced in Angular 19.0 as an experimental API to handle asynchronous resources in Angular applications:

list(): ResourceRef<Array<UserModel> | undefined> {
  return resource({
    loader: async () => {
      const response = await fetch('/users');
      return (await response.json()) as Array<UserModel>;
    }
  });
}

Angular v19.2 adds the possibility to define a defaultValue option that will be used as the initial value of the resource or when the resource is in error (instead of undefined by default):

list(): ResourceRef<Array<UserModel>> {
 return resource({
    // 👇 used when idle, loading, or in error
    defaultValue: [],
    loader: async () => {
      const response = await fetch('/users');
      return (await response.json()) as Array<UserModel>;
    }
 });
}

Angular v19.2 also added the possibility to create resources with streamed response data. A streaming resource is defined with a stream option instead of a loader option. This stream function returns a promise of a signal (yes, I needed to read it twice as well). The signal value must be of type ResourceStreamItem: an object with a value or an error property. When the promise is resolved, the loader can continue to update that signal over time, and the resource will update its value and error every time the signal’s item changes.

You can build this stream yourself, using a WebSocket for example. We can also imagine that some libraries such as Firebase could provide a stream function that would be directly usable:

list(): ResourceRef<Array<UserModel> | undefined> {
 return resource({
    // firebaseCollection does not exist in real-life
    stream: async ({ abortSignal }) => await firebaseCollection('users', abortSignal)
 });
}

This stream feature had been leveraged by the rxResource API, and you can now have a stream of values by returning an observable that emits several times. The resource will be updated every time a new value is emitted, whereas only the first value was emitted when introduced in Angular v19.

readonly sortOrder = signal<'asc' | 'desc'>('asc');
readonly usersResource = rxResource({
  request: () => ({ sort: this.sortOrder() }),
  // 👇 stream that fetches the value now and every 10s
  loader: ({ request }) =>
    timer(0, 10000).pipe(
      switchMap(() => this.httpClient.get<Array<UserModel>>('/users', { params: { sort: request.sort } }))
 )
});

New httpResource() API!

The main feature of this release is the introduction of the httpResource API. This API allows you to easily create resources that fetch data from an HTTP endpoint.

We wrote a dedicated blog post to explain how to use it:

👉 A guide to HTTP calls with httpResource()

The official RFCs for Resource Architecture and Resource APIS are also out if you're curious.

Template strings in templates

The Angular compiler now supports template strings in templates:

<p>{{ `Hello, ${name()}!` }}</p>
<button [class]="`btn-${theme()}`">Toggle</button>

Here name and theme are signals that contain strings. You can even use pipes in the dynamic part of the template string:

<p>{{ `Hello, ${name() | uppercase}!` }}</p>

This is a nice addition and I hope we'll see arrow functions in templates soon!

Migration to self-closing tags

A migration has been added to convert void elements to self-closing tags. This is just a cosmetic change, and some of you may have already done it via angular-eslint and its prefer-self-closing-tags rule.

If that's not the case for you, you can run:

ng generate @angular/core:self-closing-tag

Forms validators

The Validators.required, Validators.minLength, and Validators.maxLength validators now work with Set in addition to Array and string:

const atLeastTwoElementsValidator = Validators.minLength(2);
// minLength error before v19.2
atLeastTwoElementsValidator(new FormControl("a")); // string
atLeastTwoElementsValidator(new FormControl(["a"])); // Array
// 👇 NEW in v19.2! minLength error as well with a Set
atLeastTwoElementsValidator(new FormControl(new Set(["a"]))); // Set

Animation package

The @angular/animations package is slowly being retired: there has been no major update since its author left the Angular team a few years ago, and it is not actively maintained anymore. The team has removed dependencies on it in most packages (and in Angular Material as well), which means that you now safely remove it from your project if you don't use it directly. To reflect that, the project skeleton generated by the CLI does not include it anymore in v19.2.

Angular CLI

AoT support for Karma, Jest, and WTR

It is now possible to run your tests with AOT compilation with Karma, Jest, and Web Test Runner, instead of the default JIT compilation that has been used so far. This is great as it can catch issues in your test components (missing required inputs, etc).

Sadly, some test features are not available with AOT compilation in tests. For example, TestBed.overrideComponent, TestBed.overrideTemplate, etc are not supported as they rely on JIT compilation. I really hope that we'll soon have new TestBed APIs that work with AOT compilation!

In the meantime, you can give it a try by adding the aot: true option in your angular.json configuration file.

Karma builder

The Karma application builder (introduced in v19) has been moved to the @angular/build package. This means you can now only use this dependency and get rid of the @angular-devkit/build-angular one.

SSR

provideServerRoutesConfig has been deprecated and renamed provideServerRouting, and its appShellRoute option has been replaced with a withAppShell option, to make the API similar to the other in Angular.

Before:

provideServerRoutesConfig(serverRoutes, { appShellRoute: "" });

After:

provideServerRouting(serverRoutes, withAppShell(AppComponent));

A note-worthy new feature: routes defined with a matcher are now supported by Angular SSR, allowing us to define their render mode. Note that it can only be Server or Client for these routes but not Prerender.

Summary

That's all for this release. The next one should be v20, and we hope to see some news on the "forms with signals" 🤞 Stay tuned!

All our materials (ebook, online training and training) are up-to-date with these changes if you want to learn more!

A guide to HTTP calls in Angular using httpResource()

2025-02-20T00:00:00Z

Angular v19.2 introduced a dedicated (and experimental) function to create resources that use HTTP requests: httpResource() in the @angular/common/http package.

This function uses HttpClient under the hood, allowing us to use our usual interceptors, testing utilities, etc.

The most basic usage is to call this function with a function that returns the URL from which you want to fetch data:

readonly usersResource = httpResource<Array<UserModel>>(() => '/users');

httpResource() returns an HttpResourceRef with the same properties as ResourceRef, the type returned by resource(), as it is built on top of it (check out our blog post about Angular v19.0 to learn more about resource()):

value is a signal that contains the deserialized JSON response body;
status is a signal that contains the resource status (idle, loading, error, resolved, etc.);
error is a signal that contains the error if the request fails;
isLoading is a signal that indicates if the resource is loading;
reload() is a method that allows you to reload the resource;
update() and set() are methods that allow you to change the value of the resource;
asReadonly() is a method that allows you to get a read-only version of the resource;
hasValue() is a method that allows you to know if the resource has a value;
destroy() is a method that allows you to stop the resource.

It also contains a few more properties specific to HTTP resources:

statusCode is a signal that contains the status code of the response as a number;
headers is a signal that contains the headers of the response as HttpHeaders;
progress is a signal that contains the download progress of the response as a HttpProgressEvent.

It is also possible to define a reactive resource by using a signal in the function that defines the URL. The resource will automatically reload when the signal changes:

readonly sortOrder = signal<'asc' | 'desc'>('asc');
readonly sortedUsersResource = httpResource<Array<UserModel>>(() => `/users?sort=${this.sortOrder()}`);

If you want to skip the reload, you can return undefined from the request function (as for resource()).

If you need more fine-grained control over the request, you can also pass an HttpResourceRequest object to the httpResource() function, or a function that returns an HttpResourceRequest object in case you want to make the request reactive.

This object must have a url property and can have other options like method (GET by default), params, headers, reportProgress, etc. If you want to make the request reactive, you can use signals in the url, params or headers properties.

The above example would then look like:

readonly sortedUsersResource = httpResource<Array<UserModel>>(() => ({
  url: `/users`,
  params: { sort: this.sortOrder() },
  headers: new HttpHeaders({ 'X-Custom-Header': this.customHeader() })
}));

You can of course send a body with the request, for example for a POST/PUT request, using the body property of the request object. Note that, as we create the resource in a method, we have to pass the injector in the options as a second argument:

injector = inject(Injector);
filterUserResource: HttpResourceRef<UserModel | undefined> | undefined;

filterUser() {
  this.filterUserResource = httpResource<UserModel>(
    () => ({
      url: `/users`,
      method: 'POST',
      body: {
        name: 'JB'
      }
    }),
    {
      injector: this.injector
    }
  );

Note that we will probably keep using the HttpClient for mutations.

In these options, you can also define:

defaultValue, a default value of the resource, to use when idle, loading, or in error;
an equal function that defines the equality of two values;
a map function that allows you to transform the response before setting it in the resource.

It is also possible to request something else than JSON, by using the httpResource.text(), httpResource.blob() or httpResource.arrayBuffer() functions.

Some of you may get a feeling of déjà vu with all this, as it’s quite similar to the TanStack Query library, I must insist that this is experimental and will probably evolve in the future. Let’s see what the RFC process will bring us!

Update: the RFCs are out for Resource Architecture and Resource APIS.

All our materials (ebook, online training and training) are up-to-date with these changes if you want to learn more!

What's new in Angular 19.1?

2025-01-15T00:00:00Z

Angular 19.1.0 is here!

This is a minor release with some nice features: let's dive in!

TypeScript 5.7 support

Angular v19.1 now supports TypeScript 5.7. This means that you can use the latest version of TypeScript in your Angular applications. You can check out the TypeScript 5.7 release notes to learn more about the new features.

Automatic removal of unused standalone imports

Since Angular v19.0, there is an extended diagnostic that warns you if you import a standalone component, or pipe, or directive, but don't actually use it (making this import unnecessary). Angular v19.1 goes further: it provides a schematic that removes all those unnecessary imports for you. You simply need to execute ng generate @angular/core:cleanup-unused-imports to clean all your imports.

NgComponentOutlet

You know it's not a big release when one of the most interesting feature is a new property on a not-very-often-used directive. But here it is: the ngComponentOutlet directive now has a componentInstance property, allowing to access the instance of the component created by the directive. The directive is now also exposed as ngComponentOutlet, allowing to reference it in templates:

<ng-container
  [ngComponentOutlet]="component"
  #myDynamicComponent="ngComponentOutlet"
/>

Devtools

The devtools now have a router graph to view the routes that are loaded in the application.

Some internal work has also been done to add a "tracing" service, that the framework calls to trace what triggers change detection. This could be leveraged by the devtools to provide more information about change detection in the future.

Another addition in v19.1 is the ability to inspect the signal graph of the application. Currently, it is a private debug function called ɵgetSignalGraph that you can use via window.ng.ɵgetSignalGraph() in the console if you enable the debug tools. We can safely bet that this will be exposed in the devtools in the future with a nice graph showing the signals and their dependencies.

Angular CLI

Templates HMR

As we hinted in our v19 blog post, the CLI now has HMR for templates enabled by default!

v19 enabled HMR for styles, and now it's also enabled for templates in v19.1, both for inline and external templates. As for the styles, this required some internal changes in the compiler. As it is still a fairly new feature, you may have to manually refresh the page sometimes or restart your server. The HMR feature itself can bail out and do a full rebuild, for example, if too many files were modified (currently 32). It can be disabled with --hmr=false or --live-reload=false in the serve command, or by using NG_HMR_TEMPLATES=0.

i18n subPath

It is now easier to specify a customized URL segment for internationalized applications, like /fr for French or /es for Spanish. It was already possible to use baseHref in the i18n configuration, but it was still necessary to manually put the generated files in the proper sub-directory yourself. The baseHref option is now deprecated in favor of subPath, which acts as a base href and the name of the folder where the localized version is built:

"locales": {
  "fr": {
    "subPath": "fr", // can be omitted if it's the same as the locale
    "translation": "src/i18n/messages.fr.json"
  },
  "es": {
    "subPath": "es",
    "translation": "src/i18n/messages.es.json"
  }

The generated files will be in dist/my-app/browser/fr and dist/my-app/browser/es.

SSR redirection to preferred locale

If your application supports several languages, the server will now redirect your users to their preferred locales, based on their browser settings. This leverages the Accept-Language header to determine the preferred locales (ranked by their quality value, for example, en-US;q=0.8,fr-FR;q=0.9) and redirect the user to the corresponding URL segment based on the supported locales. It tries to find the exact locales first, then the locales without the region, then falls back to first supported locale if none of the previous ones are supported. This works out of the box without needing to configure anything.

SSR preload lazy-loaded routes

The CLI now preloads lazy-loaded routes during server-side rendering, by adding modulepreload links in the generated HTML. This is limited to 10 modules and does not work when the chunk optimization option is enabled (see our blog post about Angular v18.1).

ng-packagr builder

The ng-packagr package is now available as a builder in the CLI (@angular/build:ng-packagr) and can now be used to build libraries. It is used by default when you create a library with ng generate library and removes the need to have the @angular-devkit/build-angular package installed as you can see in our angular-cli-library-diff Github repo that tracks changes in a generated library.

Speaking about repositories helping to track differences between CLI versions, we created a new one for the CLI when generating an application with the --ssr option: angular-cli-ssr-diff 🚀 (in addition to the one for libraries and the most popular one for basic CLI applications).

Warning about bad localize import

The CLI will now warn you if you import @angular/localize/init directly in your code:

Direct import of '@angular/localize/init' detected. This may lead to undefined behavior.

The proper way to add localize is to add it to your polyfills in angular.json (as ng add @angular/localize does).

Summary

That's all for this release, stay tuned!

All our materials (ebook, online training and training) are up-to-date with these changes if you want to learn more!

What's new in Angular 19.0?

2024-11-19T00:00:00Z

Angular 19.0.0 is here!

This is a major release with a lot of features. Components are now standalone by default and most of the new Signal APIs are stable!

We have been hard at work these past months to completely re-write our "Become a Ninja with Angular" ebook and our online workshop to use signals from the start! 🚀 The update is free if you already have it, as usual 🤗. I can't believe we have been maintaining this ebook and workshop for nearly 10 years. If you don't have it already, go grab it now!

TypeScript 5.6 support

Angular v19 now supports TypeScript 5.6. This means that you can use the latest version of TypeScript in your Angular applications. You can check out the TypeScript 5.6 release notes to learn more about the new features. TypeScript 5.4 is no longer supported.

Standalone by default

We no longer need to add standalone: true in the component/directive/pipe decorator, as it is now the default behavior!

A migration will take care of removing it for you when running ng update, and add standalone: false to your non-standalone entities if needed.

If you want to make sure all your components are standalone, you can use the new "strictStandalone": true option in the angularCompilerOptions. If that's not the case, you'll see:

TS-992023: Only standalone components/directives are allowed when 'strictStandalone' is enabled.

Unused imports in standalone components

A wonderful extended diagnostic has been added to the Angular compiler, allowing it to detect unused imports in standalone components!

This is a great addition, as it will help you to keep your components clean and tidy. If you forget to remove an import after refactoring your code, you'll see a message like this:

TS-998113: Imports array contains unused imports [plugin angular-compiler]

src/app/user/users.component.ts:9:27:
  9 │   imports: [UserComponent, UnusedComponent],
    ╵                            ~~~~~~~~~~~~~~~

A code action is provided to remove the unused import for you via the language service (but there is no automatic migration doing it for you, unfortunately).

You can disable the diagnostic if needed with:

"extendedDiagnostics": {
  "checks": {
    "unusedStandaloneImports": "suppress"
  }
}

Signal APIs are stable (well, most of them)

Most of the Signal APIs (and RxJS interoperability functions) are no longer in developer preview and can safely be used.

The input(), output(), model(), viewChild(), viewChildren(), contentChild, contentChildren(), takeUntilDestroyed(), outputFromObservable(), and outputToObservable() are now marked as stable.

Of course, migrating complete applications to these new APIs can be a bit of work. But you know what, the Angular team cooked some automatic migrations! 😍 We will talk about them in the next section.

effect went through some changes and is still in developer preview. toObservable (which uses an effect) and toSignal are still in developer preview as well.

All effects aren't handled the same way anymore. Angular distinguishes two kinds of effects:

component effects, which are created in components or directives;
root effects, which are created in root services, or with the forceRoot option.

Component effects now run during change detection (just before the actual change detection of their owning component) and not after it as it was the case before. This is a breaking change. You might thus see some changes in their behavior, for example when an effect is triggered by a change of a view query signal. To solve this case, a new afterRenderEffect function has been added. It is similar to effect, but its function runs after the rendering rather than before. Like afterRender and afterNextRender (check our blog post if you need a refresher), it can also specify what should be executed in each rendering phase but values are propagated from phase to phase as signals instead of as plain values. As a result, later phases may not need to execute if the values returned by earlier phases do not change. All these afterRender functions are still in developer preview.

Root effects are not tied to a component lifecycle and are usually used to synchronize the state of the application with the outside world (for example, to write it to the local storage). These effects don't run as part of the change detection but as a microtask (and can be triggered in tests using TestBed.flushEffects()).

Another notable change is that you can now write to signals in effects, without the need to specify the (now deprecated) option allowSignalWrites: true. The team found out that it was not preventing basic usages but was just making the code more verbose when really needed.

All in all, effects should be stabilized in the next release. However their usage is still not recommended for most cases, and it seems like they should be the last resort to solve a problem. That's why the framework introduced the new experimental functions linkedSignal, resource, and rxResource.

Linked signals with linkedSignal()

Angular v19 introduced a new (developer preview) concept called "linked signals". A linked signal is a writable signal, but it is also a computed signal, as its content can be reset thanks to a computation that depends on another signal (or several ones).

Imagine we have a component that displays a list of items received via an input, and we want our users to select one of them. By default, let’s say we want to select the first item of the list. But every time the list of items changes, the selected item may no longer be valid, so we want to reset the selected item to the first one.

We can imagine a component like this:

export class ItemListComponent {
 items = input.required<Array<ItemModel>>();
 selectedItem = signal<ItemModel | undefined>(undefined);

  pickItem(item: ItemModel) {
    this.selectedItem.set(item);
  }
}

Using an effect may come to mind to solve the selection problem:

constructor() {
  // ⚠️ This is not recommended
  effect(() => {
    this.selectedItem.set(this.items()[0]);
  });
}

Every time the list of items changes, the effect will be triggered and the first item will be selected.

There is a nice trick that I can show you before we dive into the now-recommended solution: we can use a computed value that returns… a signal!

export class ItemListComponent {
  items = input.required<Array<ItemModel>>();
  selectedItem = computed<WritableSignal<ItemModel | undefined>>(
    () => signal(this.items()[0])
  );

  pickItem(item: ItemModel) {
    this.selectedItem().set(item);
  }
}

As you can see, the computed value returns a signal that represents the selected item (whereas they usually return a value directly). Every time the list of items changes, the computed function is re-evaluated, and returns a new signal that represents the selected item. The downside of this solution is that we have to use selectedItem()() to read the value, or selectedItem().set() to update it, which is a bit ugly.

This is where we can use a linkedSignal:

export class ItemListComponent {
  items = input.required<Array<ItemModel>>();
  // ✅ This is recommended
  selectedItem: WritableSignal<ItemModel> = linkedSignal(() => this.items()[0]);

A linkedSignal is a WritableSignal, but its value can be reset thanks to a computation. If the items change, then the computation will be re-executed and the value of the signal will be updated with the result.

The computation can of course depend on several signals. Here selectedItem is reset when the items input changes, but also when the enabled input changes.

export class ItemListComponent {
  items = input.required<Array<ItemModel>>();
  enabled = input.required<boolean>();
  // recomputes if `enabled` or `items` change
  selectedItem = linkedSignal(() => (this.enabled() ? this.items()[0] : undefined));

Note that you can use the previous value of the source signal in the computation function if you need to. For example, if you want to access the previous items value to compare it with the new one, you can declare the linkedSignal with the source and computation options. In that case, the computation function receives the current and previous values of the source as parameters.

export class ItemListComponent {
  items = input.required<Array<ItemModel>>();
  selectedItem = linkedSignal</* source */ Array<ItemModel>, /* value */ ItemModel>({
    source: this.items,
    computation: (items, previous) => {
      // pick the item the user selected if it's still in the new item list
      if (previous !== undefined) {
        const previousChoice = previous.value; // previous.source contains the previous items
        if (items.map(item => item.name).includes(previousChoice.name)) {
          return previousChoice;
        }
      }
      return items[0];
    }
 });

Async resources with resource() and rxResource()

Most applications need to fetch data from a server, depending on some parameters, and display the result in the UI: resource aims to help with that.

This API is experimental, and will go through an RFC process soon: I would not advise you to use it yet.

The resource function takes an object with a mandatory loader function that returns a promise:

list(): ResourceRef<Array<UserModel> | undefined> {
  return resource({
  loader: async () => {
    const response = await fetch('/users');
      return (await response.json()) as Array<UserModel>;
    }
  });
}

This example doesn’t use the HTTP client, but the native fetch() function, which returns a promise. Indeed, the resource() function is not linked to RxJS, and can thus use any client that returns promises. rxResource, which we will discuss in a few seconds, is the alternative to resource that can be used with an Observable-based client. This is another example of Angular decoupling itself from RxJS, but still providing interoperability functions allowing you to use it smoothly.

The function returns a ResourceRef, an object containing:

an isLoading signal that indicates if the resource is loading;
a value signal that contains the result of the promise;
an error signal that contains the error if the promise is rejected;
a status signal that contains the status of the resource.

You can then use these signals in your template:

@if (usersResource.isLoading()) {
  <p>Loading...</p>
} @else {
  <ul>
  @for (user of usersResource.value(); track user.id) {
    <li>{{ user.name }}</li>
  }
  </ul>
}

The status signal can be:

ResourceStatus.Idle, the initial state;
ResourceStatus.Loading, when the promise is pending;
ResourceStatus.Error, when the promise is rejected;
ResourceStatus.Resolved, when the promise is resolved;
ResourceStatus.Reloading, when the resource is reloading;
ResourceStatus.Local, when the value is set locally.

The resource also has a reload method that allows you to reload the resource. In that case, its status will be set to ResourceStatus.Reloading.

But the reloading can also be automatic, thanks to the request option. When provided, the resource will automatically reload if one of the signals used in the request changes. Here, for example, the component has a sortOrder option that is used in the request:

sortOrder = signal<'asc' | 'desc'>('asc');
usersResource = resource({
  // 👇 The `sortOrder` signal is used to trigger a reload
  request: () => ({ sort: this.sortOrder() }),
  loader: async params => {
    // 👇 Params also contains the `abortSignal` to cancel the request
    // and the previous status of the resource
    // here we are only interested in the request
    const request = params.request;
    const response = await fetch(`/users?sort=${request.sort}`);
    return (await response.json()) as Array<UserModel>;
  }
});

If the sortOrder signal changes, the resource will automatically reload! You can also cancel the previous request if needed when the resource is reloaded using the abortSignal parameter of the loader (for example to implement a debounce). You can choose to ignore the reload request and thus keep the current value by returning undefined from the request function.

Last but not least, the returned ResourceRef is in fact writable. You can use its set or update methods to change the value of the resource (on the value or on the resource itself, both work). In that case, its status will be set to ResourceStatus.Local. If you’re only interested in reading the resource, you can use the asReadonly method to get a read-only version of the resource.

Finally, the ResourceRef has a destroy method that can be used to stop the resource.

Now, let’s see how we can use an observable-based resource instead of a promised-based one.

You can use the rxResource() function in that case. This function is really similar to resource(), but its loader must return an observable instead of a promise. This allows you to use our good old HttpClient service to fetch data from a server, using all your interceptors, error handling, etc:

sortOrder = signal<'asc' | 'desc'>('asc');
usersResource = rxResource({
  request: () => ({ sort: this.sortOrder() }),
  // 👇 RxJS powered loader
  loader: ({ request }) => this.httpClient.get<Array<UserModel>>('/users', { params: { sort: request.sort } })
});

Note that the rxResource() function is from the @angular/core/rxjs-interop package, where the resource() function is from @angular/core. Another noteworthy detail is that only the first value of the observable is taken into account, so you can’t have a stream of values.

Some of you may get a feeling of déjà vu with all this, as it’s quite similar to the TanStack Query library. I must insist that this is experimental and will probably evolve in the future. It will also probably be used by higher-level APIs or libraries. Let’s see what the RFC process will bring us!

Automatic migration for signals

Now that signal inputs, view queries and content queries are stable, why not refactor all our components to use them? That can be automated using the following migration:

ng generate @angular/core:signals
? Which migrations do you want to run? (Press <space> to select, <a> to toggle all, <i> to invert selection, and <enter> to proceed)
❯◉ Convert `@Input` to the signal-based `input`
 ◉ Convert `@Output` to the new `output` function
 ◉ Convert `@ViewChild`/`@ViewChildren` and `@ContentChild`/`@ContentChildren` to the signal-based `viewChild`/`viewChildren` and
`contentChild`/`contentChildren`

You can then choose which directory you want to migrate (all the application by default). The migration, by default, is conservative. If it can't migrate something without breaking the build, it will leave it as it is. But you can be more aggressive by passing the option --best-effort-mode as we'll see. For a complete list of options, run ng generate @angular/core:signals --help.

After the migration, a report is displayed, showing how many inputs/outputs/viewChildren/contentChildren have been migrated. If you picked the less aggressive option, some of them might not have been migrated, and you can re-run the migration with --insert-todos to add explanation comments in the code where the migration couldn't be done.

For example, an @Input used on a setter yields the following TODO:

// TODO: Skipped for migration because:
//  Accessor inputs cannot be migrated as they are too complex.

Another example that you'll encounter fairly often is when an @Input is used in a template inside an @if, the migration can't update it due to type-narrowing issues:

// TODO: Skipped for migration because:
//  This input is used in a control flow expression (e.g. `@if` or `*ngIf`)
//  and migrating would break narrowing currently.

These incompatibility reasons can then be migrated with the more aggressive option --best-effort-mode, but you'll probably have to fix some errors manually.

The migration works astonishingly well, and you can then enjoy the new Signal APIs! Of course, it does not refactor the code to use computed instead of ngOnChanges or other patterns that could be used with signals, but it's a good start and will save you a lot of time.

You should also be able to trigger the migration for a specific file or property from your IDE with the new version of the language service!

After running these migrations on a few projects, my advice would be to first run the outputs one, as it is fairly trivial.

Then you can run the queries one, which is a bit more complex but still quite safe (with a few possible incompatible cases). Finally, you can run the inputs one, which is the most complex and may require manual intervention.

ng generate @angular/core:signals --migrations=outputs --defaults
ng generate @angular/core:signals --migrations=queries --defaults
ng generate @angular/core:signals --migrations=inputs --defaults

You can then lint, build, and test your application to see if everything is still working as expected. You can then re-run the migration with --insert-todos to see the reasons why some fields have been skipped. Then you can re-run the migration with --best-effort-mode to try to migrate them anyway.

provideAppInitializer instead of APP_INITIALIZER

The APP_INITIALIZER token is now deprecated in favor of provideAppInitializer. This new function is a more elegant way to provide an initializer to your application.

Before v19, you would provide an initializer like this:

{
  provide: APP_INITIALIZER,
  useValue: () => inject(InitService).init(),
  multi: true
},

Now you need to use provideAppInitializer:

provideAppInitializer(() => inject(InitService).init())

ENVIRONMENT_INITIALIZER and PLATFORM_INITIALIZER Are also deprecated in favor of provideEnvironmentInitializer and providePlatformInitializer.

As usual, an automatic migration will take care of this for you when running ng update (you may have to refactor a bit if you want to have a nice function with inject as I used in the example above).

Templates

The @let syntax, introduced in Angular v18.1, is now stable.

Expressions in the template can now use the typeof operator, so you can write things like @if (typeof user === 'object') {.

The keyvalue pipe also has a new option. This pipe has been around for a long time and allows you to iterate over the entries of an object. But it, perhaps surprisingly, orders the entries by their key by default, as we explained in our Angular 6.1 blog post (back in 2018 😅). You could already pass a comparator function, but you can now pass null to disable the ordering:

@for (entry of userModel() | keyvalue: null; track entry.key) {
  <div>{{ entry.key }}: {{ entry.value }}</div>
}

Router

It is now possible to pass data to a RouterOutlet, making it easy to share data from a parent component to its nested children.

<router-outlet [routerOutletData]="userModel"></router-outlet>

Then in a child component, you can get the data via DI and the token ROUTER_OUTLET_DATA:

readonly userModel = inject<Signal<UserModel>>(ROUTER_OUTLET_DATA);

Note that, for the first time I believe, the value you get via DI is not a static value, but a signal! That means that every time userModel changes in the parent component, the signal in the child component will be updated as well.

Service worker

A few features have been added to the service worker support in Angular.

First, it is now possible to specify a maxAge for the entire application, via a new configuration option called applicationMaxAge. This allows us to configure how long the service worker will cache any requests. Within the applicationMaxAge, files will be served from the cache. Beyond that, all requests will only be served from the network. This can be particularly useful for the index.html file, to make sure a user returning several months later will get the latest version of the application and not an old cached version. You can define the applicationMaxAge in the ngsw-config.json file:

{
  "applicationMaxAge": "1d6h" // 1 day and 6 hours
}

Another new feature is the ability to define a refreshAhead delay for a specific data group. When the time before the expiration of a cached resource is less than this refreshAhead delay, Angular refreshes the resource. Fun fact: this feature was already implemented, but not publicly exposed.

{
  "dataGroups": [
    {
      "name": "api-users",
      "urls": ["/api/users/**"],
      "cacheConfig": {
        "maxAge": "1d",
        "timeout": "10s",
        "refreshAhead": "10m"
      }
    }
  ]
}

SSR

There are tons of changes in the Server-Side Rendering (SSR) part of Angular, both in the framework and in the CLI.

Event Replay is stable

The event replay feature, introduced in Angular v18, is now stable. The CLI will now generate the necessary withEventReplay() call for you when you create a new application with SSR.

Application stability

When working with SSR, Angular needs to know when the application is stable, meaning that all the asynchronous operations have been completed, in order to render the application to a string and send it to the client. Zone.js usually allows knowing this but in a zoneless application, you need to do it yourself.

Angular does the bulk of the work for you, by internally keeping track of the asynchronous operations it triggers (an HTTP request done via the HttpClient, for example), using a service called PendingTasks. It has been renamed from ExperimentPendingTasks and stabilized in v19, and an automatic migration will take care of this renaming for you during ng update.

You can also use PendingTasks in your application to track your own asynchronous operations. The service has an add method to manually create a task that you can later clean, but a run method has been added for convenience in v19, allowing you to directly pass an async function:

const userData = await inject(PendingTasks).run(() => fetch('/api/users'));
//☝️ Angular will wait for the promise to resolve
this.users.set(usersData);

A new (experimental) RxJS operator called pendingUntilEvent has also been added to the framework (in the @angular/core/rxjs-interop package): it allows marking an observable as important for the application stability until a first event is emitted:

this.users = toSignal(users$.pipe(pendingUntilEvent()));

Partial and incremental hydration

Building upon the event replay feature, and the @defer feature (check our blog post if you need a refresher), the Angular team has introduced a new feature called "incremental hydration".

With incremental hydration, deferred content is rendered on the server side (instead of rendering the defer placeholder), but skipped over during client-side hydration (it's left dehydrated, hence the "partial hydration" concept).

It means that the application is fully rendered, but some parts are not yet interactive when the application bootstraps. When a user interacts with a dehydrated component, Angular will download the necessary code and hydrate the component (and its perhaps dehydrated parent components) on the fly, then replay the events that happened while the component was dehydrated, leaving the impression that the component was already active 🤯.

This feature is in developer preview in v19, and can be activated with withIncrementalHydration():

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

The syntax to enable it is quite simple and uses the @defer block with an additional hydrate option to define the hydration condition. The possible hydration triggers are the same as the @defer conditions (that we explained in detail in the blog post mentioned above).

@defer(on timer(15s); hydrate on interaction) {
  <app-users />
} @placeholder {
  <span>Loading</span>
}

Until v19, the loading placeholder would be rendered in SSR. With the withIncrementalHydration() option, the UsersComponent will be rendered, but not hydrated on the client.

For example, the DOM will look like:

<app-users>
  <!-- Dehydrated content -->
  <h1>User</h1>
  <button jsaction="click:;">Refresh users</button>
  <!-- more content -->
</app-users>

When the user clicks on the button, Angular will download the necessary code for the UsersComponent, then hydrate it and replay the events that happened while the component was dehydrated (here, refreshing the list of users).

This is a powerful feature for those who are looking to improve the performance of their applications, and it highlights the flexibility of the control flow syntax in Angular.

Route configuration for hybrid rendering

Until now, an SSR application with pre-render was pre-rendering the pages with no parameters but ignored parameterized pages. In v19, after an RFC, the CLI team introduced a new feature called "hybrid rendering".

All this work is part of the ongoing effort to improve the SSR experience in Angular, which includes new APIs (App Engine APIs).

It is now possible to define the rendering mode per route of the application. Instead of adding options to the existing route configuration, the team decided to add a configuration file, dedicated to the server-side, which defines the rendering mode for each route.

Three rendering modes are available:

RenderMode.Prerender for pre-rendering the page at build time;
RenderMode.Server for rendering the page on the server;
RenderMode.Client for rendering the page on the client.

For example, let's say you have the following routes in your application:

const routes: Routes = [
  // Home component
  { path: '', component: HomeComponent },
  // About component
  { path: 'about', component: AboutComponent },
  // User component with a parameter
  { path: 'users/:id', component: UserComponent }
];

In v18, ng build generated a browser folder with index.html and about/index.html files. In v19, the same configuration throws with:

✘ [ERROR] The 'users/:id' route uses prerendering and includes parameters, but 'getPrerenderParams' is missing. Please define 'getPrerenderParams' function for this route in your server routing configuration or specify a different 'renderMode'.

This means there are 2 solutions. First, we can add a server routing configuration file, app.routes.server.ts.

This file is now generated in a project when using ng new --ssr --server-routing or ng add @angular/ssr --server-routing. The --server-routing option enables both the server routing configuration and the new App Engine APIs (all these APIs are in developer preview for now). It also uses a new option in angular.json called outputMode to define the output mode of the application:

server generates a server bundle, enabling server-side rendering (SSR) and hybrid rendering strategies. This mode is intended for deployment on a Node.js server or a serverless environment.
static generates a static output suitable for deployment on static hosting services or CDNs. This mode supports both client-side rendering (CSR) and static site generation (SSG).

ng add @angular/ssr --server-routing sets the outputMode to server by default. Note that the prerender and appShell options are no longer used if you define the outputMode.

Let's define the server routes configuration for the previous example:

export const serverRoutes: Array<ServerRoute> = [
  {
    path: '',
    renderMode: RenderMode.Prerender,
  },
  {
    path: 'about',
    renderMode: RenderMode.Server,
  },
  {
    path: '**',
    renderMode: RenderMode.Client,
  }
];

This file is then loaded in the app.config.server.ts file, using provideServerRoutesConfig(serverRoutes).

The server routes configuration doesn't need to define all the routes as you can see, with a possible "catch-all" route '**' to define a default behavior. If a route doesn't exist though, you'll get an error at build time:

✘ [ERROR] The 'unknown' server route does not match any routes defined in the Angular routing configuration (typically provided as a part of the 'provideRouter' call). Please make sure that the mentioned server route is present in the Angular routing configuration.

The second solution is to define a getPrerenderParams function, to prerender routes with parameters.

{
  path: 'users/:id',
  renderMode: RenderMode.Prerender,
  async getPrerenderParams(): Promise<Array<Record<string, string>>> {
    // API call to get the user IDs
    const userIds = await inject(UserService).getUserIds(); 
    // build an array like [{ id: '1' }, { id: '2' }, { id: '3' }]
    return userIds.map(id => ({ id }));
  }
},

This will prerender the users/:id route for each user ID found by the UserService, generating users/1/index.html, users/2/index.html, etc.

A really nice change is that server.ts is now used during prerendering, allowing access to locally defined API routes. server.ts is now also used by the Vite server during development! If needed you can disable it with the --no-server option, for example, to make a static build: ng build --output-mode static --no-server.

As you may not want to prerender all the user pages, you can also define a fallback option, that can be PrerenderFallback.Client (falls back to CSR), PrerenderFallback.Server (falls back to SSR), or PrerenderFallback.None (the server will not handle the request).

When using the RenderMode.Server mode, you can also define a status and headers options to customize the response:

{
  path: '404',
  renderMode: RenderMode.Server,
  status: 404,
  headers: {
    'Cache-Control': 'no-cache'
  }
}

You can also define which route should serve as the app shell of the application (see the App shell pattern in the Angular documentation), by setting the appShellRoute option: provideServerRoutesConfig(serverRoutes, { appShellRoute: 'shell' }).

The "App Engine APIs" mentioned earlier are a set of APIs that allow you to interact with the server-side rendering process, based on the new AngularAppEngine and its node version AngularNodeAppEngine. They are used in the generated server.ts file:

createNodeRequestHandler allows you to create a request handler for the server-side rendering process You can pass it the handler you want to use like an Express app, which is still the default used when using ng add @angular/ssr, or another like Fastify, Hono, etc. This should make it simpler to use a different server framework than Express.
writeResponseToNodeResponse allows you to write the response from your server of choice to the node response object.

All these functions aim to make the interactions easier between Node.js and the framework you picked to handle the requests to your Angular application. This should provide greater flexibility compared to the previous APIs, and make it easier to deploy Node.js applications, whatever the server framework you want to use. And you can build your own variants of AngularAppEngine to fit your needs for other platforms.

The CLI team also wants to make it easier to target other runtimes than Node.js. That's why a new option ssr.experimentalPlatform has been added, which lets you define the platform you want to target:

node (default) generates a bundle optimized for Node.js;
neutral generates a platform-neutral bundle suitable for environments like edge workers, and other serverless platforms that do not rely on Node.js APIs. As the option name indicates, this is an experimental feature.

Request and response via DI

It is now easy to access the request and response objects in your components during SSR, thanks to new DI tokens in @angular/core:

REQUEST to access the current HTTP request object;
REQUEST_CONTEXT to pass custom metadata or context related to the current request in server-side rendering;
RESPONSE_INIT to access the response initialization options;

Angular CLI

The CLI has also been released in version v19, with some notable features.

If you want to upgrade to 19.0.0 without pain (or to any other version, by the way), I have created a Github project to help: angular-cli-diff. Choose the version you're currently using (18.1.0 for example), and the target version (19.0.0 for example), and it gives you a diff of all files created by the CLI: angular-cli-diff/compare/18.1.0...19.0.0. It can be a great help along with the official ng update @angular/core @angular/cli command.

Let's see what's new in the CLI!

Better HMR by default

A ton of work has been done to improve the Hot Module Replacement (HMR) experience in Angular.

When using the application builder for ng serve, HMR is now enabled by default for styles! This means that when you change a style file (or inline style), the browser will update the styles without reloading the page and without rebuilding the application.

This is sooo nice to see, as you can now change the styles and see the results in real-time without losing the state of your application. For example, when working in a modal, you won't have to re-open it after each style change! Definitely a game-changer for day-to-day work.

The work done in the framework goes even further than that, and we should be able to have HMR that properly works for templates soon. It is in fact already possible to try it using NG_HMR_TEMPLATES=1 ng serve (this is experimental as you can guess).

When using this option, the templates will be reloaded, refreshing all component instances, without reloading the page, and the state of the application will be preserved!

Karma can run with esbuild!

Even if Karma is slowly dying, it is still the default testing solution in newly generated Angular CLI projects. The Karma integration in Angular was still relying on Webpack until now, which was a bit sad as all other builders were now using esbuild under the hood.

This is no longer the case as you can use esbuild with Karma as well!

To do so, a new option can be used in the Karma builder options in angular.json: builderMode. This option can have 3 different values:

browser which is the same as the current behavior, using Webpack under the hood
application which uses esbuild
detect which uses the same builder as ng serve

When using application, you can also remove the @angular-devkit/build-angular/plugins/karma webpack plugin from your karma.conf.js (if you have one).

Shifting to builderMode: application is quite a bit faster. On a project with thousands of tests, the full test suite was ~40% faster, cutting nearly a minute from the total time. In watch mode, the difference is also quite noticeable, shaving a few seconds on each re-run.

Zoneless experiment

A new option --experimental-zoneless has been added to the ng new command, generating a new project without Zone.js. Unit tests are also generated with the proper providers to make them work without Zone.js. You can check out our blog post on Angular 18.0 for more information on this experiment.

ng generate component

A new --export-default option has been added to the ng generate component command. It changes the component to use the default export syntax: export default class AdminComponent. This can be interesting for lazy-loaded components, as the loadComponent syntax then allows to write loadComponent: () => import('./admin/admin.component') instead of the usual loadComponent: () => import('./admin/admin.component').then(m => m.AdminComponent).

Sass deprecation warnings

It's now possible to silence the deprecation warnings coming from the Sass compiler:

"stylePreprocessorOptions": {
  "sass": {
    "silenceDeprecations": ["import"]
  }
},

It's also possible to throw an error if a deprecation warning is emitted with fatalDeprecations and to prepare for future deprecations with futureDeprecations. This feature is going to be really useful to all Sass users, as some APIs are getting deprecated and will be removed in Sass v3, so you may see a bunch of deprecation warnings appear.

Strict CSP

A new option has been added to the ng build command to enable a strict Content Security Policy (CSP) in the generated index.html file. This option applies the recommendations from this Web.dev article and enables automatic generation of a hash-based CSP based on scripts in the index.html file.

To enable this option, set the security.autoCsp configuration to true in your angular.json file.

Summary

Wow, that was a lot of new features in Angular v19!

v20 will probably continue to stabilize the signals APIs introduced these past months. We can also hope for more news about how the router and forms will integrate with signals. Stay tuned!

All our materials (ebook, online training and training) are up-to-date with these changes if you want to learn more!

What's new in Vue 3.5?

2024-09-05T00:00:00Z

Vue 3.5.0 is here!

The last minor release was v3.4.0 in December. Since then, we have seen quite a few patch releases, and some interesting new features.

Let's see what we have in this release!

Props destructuration

Props destructuration was introduced as an experiment in Vue 3.3 (as part of the reactive transform experiment) and is now stable in Vue 3.5.

So instead of:

const props = withDefaults(defineProps<{ name?: string }>(), { name: "Hello" });
watchEffect(() => console.log(props.name));

You can now write:

const { name = "Hello" } = defineProps<{ name?: string }>();
watchEffect(() => console.log(name));
// ☝️ This gets compiled to the same code as the previous example
// so we don't lose the reactivity of the props

You no longer need the propsDestructure: true flag in the compiler options to use this feature, so you can remove it if you have it. You can however disable this feature by setting propsDestructure: false in the compiler options, or even throw an error if you want to enforce the use of the previous syntax by setting propsDestructure: 'error'.

Read more about this feature in the RFC.

useTemplateRef

As you probably know, Vue lets you grab a reference to an element in a template, using the ref="key" syntax. The framework then populates a Ref named key in the setup of the component. For example, to initialize a chart, you usually write code looking that:

<canvas ref="chart"></canvas>

// 👇 special ref that Vue populates with the element in the template
const chart = ref<HTMLCanvasElement | null>(null); 
onMounted(() => new Chart(chart.value!, /* chart options */));

This API felt a bit awkward, as nothing was pointing out that this ref was "special" at first glance. It also forced developers to pass this ref around to composables. For example, if you wanted to build a useChart composable, you had to write it like this:

export function useChart(chartRef: Ref<HTMLCanvasElement | null>) {
  onMounted(() => new Chart(chartRef.value!, /* chart options */));
}

And then call it in your component by passing it the ref:

const chart = ref<HTMLCanvasElement | null>(null); 
useChart(chart);

Vue v3.5 introduces a new composable called useTemplateRef to grab a reference in the template:

// useTemplateRef expects the key of the element in the template
const chartRef = useTemplateRef<HTMLCanvasElement>('chart');
onMounted(() => new Chart(chartRef.value!, /* chart options */));

The type of chartRef is a read-only ShallowRef<HTMLCanvasElement | null>. In addition to a more explicit name and usage, the new function is usable directly inside a composable. This simplifies the pattern we saw above, as useChart can simply be written:

export function useChart(chartKey: string) {
  const chartRef = useTemplateRef<HTMLCanvasElement>(key);
  onMounted(() => new Chart(chartRef.value!, /* chart options */));
}

and then used in a component:

useChart('chart');

This is a nice improvement!

useId

A new composition function called useId has been added to generate a unique ID. This feature is probably already familiar to React developers or Nuxt developers who use the useId composable.

This can be useful when you need to generate an ID for an HTML element, for example when you use a label with an input, or for accessibility attributes:

<label :for="id">Name</label>
<input :id="id" />

As the component can be rendered many times, you need to ensure that the ID is unique. This is where useId comes in:

const id = useId();

useId guarantees that the generated ID is unique within the application. By default, Vue generates an ID with a prefix of v- followed by a unique number (that increments when new components are rendered). The prefix can be customized by using app.config.idPrefix. useId also guarantees that the ID is stable between server-side rendering and client-side rendering, to avoid mismatching errors.

Lazy hydration strategies

Asynchronous components, defined with defineAsyncComponent, can now control when they should be hydrated using a new hydrate option.

Vue provides four strategies for hydration in v3.5:

hydrateOnIdle(): the component will be hydrated when the browser is idle (you can specify a timeout if needed, as requestIdleCallback, which is used internally, allows).
hydrateOnVisible(): the component will be hydrated when it becomes visible in the viewport (implemented using an IntersectionObserver). Additional options supported by the IntersectionObserver API can be passed to the strategy, like rootMargin to define the margin around the viewport. So you can use hydrateOnVisible({ rootMargin: '100px' }) to hydrate the component when it is 100px away from the viewport.
hydrateOnInteraction(event): the component will be hydrated when the user interacts with the component with a defined event, for example hydrateOnInteraction('click'). You can also specify an array of events.
hydrateOnMediaQuery(query): the component will be hydrated when the media query matches. For example, hydrateOnMediaQuery('(min-width: 600px)') will hydrate the component when the viewport is at least 600px wide.

You can also define a define custom strategy if you want to.

Here is an example of how to use these strategies:

import { defineAsyncComponent, hydrateOnVisible } from 'vue'

const User = defineAsyncComponent({
  loader: () => import('./UserComponent.vue'),
 hydrate: hydrateOnVisible('100px')
});

data-allow-mismatch

Vue 3.5 now supports a new attribute called data-allow-mismatch, that can be added to any element to allow client/server mismatch warnings to be silenced for that element.

For example, if you have a component that renders the current date like this:

<div>{{ currentDate }}</div>

you might get a warning if the server and the client render the date at different times:

[Vue warn]: Hydration text content mismatch on <div> 
 - rendered on server: Jul 26, 2024
 - expected on client: Jul 27, 2024

You can silence this warning by adding the data-allow-mismatch attribute:

<div data-allow-mismatch="text">{{ currentDate }}</div>

The value of the attribute can be:

text to silence the warning for text content
children to silence the warning for children content
class to silence the warning for class mismatch
style to silence the warning for style mismatch
attribute to silence the warning for attribute mismatch

Better types

A few improvements have been made to help the tooling understand the Vue API better. For example, components that use expose will now have a more correct type.

An effort has also been made for directives. It is now possible to specify the allowed modifiers for a directive in the type definition:

// can be used as v-focus.seconds in the template
export const vFocus: Directive<
  HTMLInputElement,
  boolean,
  'seconds' /* 👈 New! only 'seconds' is allowed as modifier */
> = (el, binding) => {
  const secondsModifier = binding.modifiers.seconds; // autocompletion works here
  ...
}

The built-in directives have also been improved to leverage this new feature.

Another improvement concerns the computed function: you can now define a getter and a setter with different types (it was already working but TS was complaining):

const user = ref<UserModel>({ name: 'Cédric' });
const json = computed({
  get: () => JSON.stringify(user.value),
  // 👇 the setter receives a UserModel instead of a string
  set: (newUser: UserModel) => user.value = newUser;
}); // typed as ComputedRef<string, UserModel>
console.log(json.value); // 👈 a string
json.value = { name: 'JB' }; // 👈 no error

app.onUnmount()

It is now possible to register a callback that will be called when the app is unmounted (i.e when the app.unmount() method is called) This can be useful to clean up resources or to log something if you unmount your application, but it is even more useful for plugin developers.

Here is an example:

const myPlugin: Plugin = {
install (app: App) {
  function cleanupSomeSideEffect() { /* ...*/ }

  // Register the cleanup function to be called when the app is unmounted
  app.onUnmount(cleanupSomeSideEffect)
}

Watcher novelties

deep watch

The watch function had a deep option since the beginning. It allows watching deeply nested properties of a ref:

const obj = ref({ super: { nested: { prop: 1 } } });
watch(obj, () => {
  // called when the ref or one of its nested properties changes
  console.log('nested prop changed');
}, { deep: true });

You don't need it for a reactive object though, as watch will automatically watch deeply nested properties of a reactive object. In that case, deep can be set to false if you want to disable this behavior.

The novelty introduced in Vue 3.5 is that you can now use deep with a specific depth:

const obj = ref({ super: { nested: { prop: 1 } } });
watch(obj, () => {
  // called when the ref or the first level of its nested properties changes
  console.log('nested prop changed');
}, { deep: 1 }); // 👈 deep can now be a number

pause/resume

The watch and watchEffect can now be paused and resumed, in addition to being stopped.

Until now, you could only stop a watcher, which would prevent it from being called again:

const stop = watch(obj, () => {
  console.log('obj changed');
});
stop(); // 👈 stop the watcher

Now, you can pause and resume a watcher:

const { pause, resume, stop } = watch(obj, () => {
  console.log('obj changed');
});
pause(); // 👈 pause the watcher
resume(); // 👈 resume the watcher
stop(); // 👈 stop the watcher

onWatcherCleanup

A new API called onWatcherCleanup has been added to register a callback that will be called when a watch/watchEffect is cleaned up. This is similar to what the onCleanup parameter of watchers does, but it allows to use the cleanup function in functions called inside a watcher.

Before

// starts an interval, called in the watchEffect below
function startInterval(intervalTime, onCleanup) {
  const id = window.setInterval(() => console.log('hello'), intervalTime)
  // we use onCleanup here to clear the interval
  onCleanup(() => window.clearInterval(id));
}

const intervalTime = ref(1000);
watchEffect((onCleanup) => {
  console.log('Interval time changed', intervalTime.value);
  // we need to pass onCleanup to startInterval
  startInterval(intervalTime.value, onCleanup);
});

Now

function startInterval(intervalTime) {
  const id = window.setInterval(() => console.log('hello'), intervalTime)
  //👇 we can now use onWatcherCleanup
  onWatcherCleanup(() => window.clearInterval(id));
}

const intervalTime = ref(1000);
watchEffect(() => {
  console.log('Interval time changed', intervalTime.value);
  //👇 no need to pass onCleanup anymore
  startInterval(intervalTime.value);
});

onWatcherCleanup throws a warning if there is no current active effect. This warning can be silenced by passing a second parameter to onWatcherCleanup:

onWatcherCleanup(() => {
  // cleanup code
}, true /* 👈 no warning */);

A similar API has been introduced for the low level effect function, called onEffectCleanup.

Trusted types

Vue 3.5 now supports Trusted Types. It should work out of the box by default. This is done by automatically converting the strings generated by the compiler into TrustedHTML when they are used in a context where a Trusted Type is expected. v-html is not supported out-of-the-box, but can also be used if you declare a custom policy.

throwUnhandledErrorInProduction

A new option has been added to the app configuration to throw unhandled errors in production. This can be useful to catch errors that are currently not caught because the default behavior is to log them in the console.

const app = createApp(App);
app.config.throwUnhandledErrorInProduction = true;

With this option enabled, you'll easily catch errors when rendering your application in production. Note that the default is false to avoid breaking existing applications.

Teleport

deferred Teleport

It is now possible to add a defer attribute to Teleport to mark the component as deferred. When doing so, the target of the teleportation doesn't have to already exist: even if it appears later, the target can still be resolved. A deferred Teleport waits until all other DOM content in the same update cycle has been rendered before locating the target container.

So we can now use Teleport with targets located in other components (as long as they are mounted in the same tick), or even use Teleport and a target inside a Suspense (whereas you previously had to target a container outside of the Suspense component).

<template>
  <Suspense>
    <Teleport defer to="#target">...</Teleport>
    <div id="target"></div>
  </Suspense>
</template>

Teleport and Transition

It is now possible to use a Teleport component directly inside a Transition component, thus allowing to animate the appearance and the disappearance of an element in a different place in the DOM. This used to throw an error in Vue 3.4.

You can check out this playground from the PR author edison1105, showcasing this new feature.

Custom elements

Vue v3.5 adds a bunch of features for custom elements. As I don't personally use them, I'll just list the most notable here:

defineCustomElement now supports disabling ShadowDom by setting the shadowRoot option to false;
a useHost() composable has been added to get the host element and a useShadowRoot() composable has been added to get the shadow root of the custom element (which can be useful for CSS in JS);
emit now supports specifying event options, like emit('event', { bubbles: true });
expose is now available in custom elements;
custom elements can now define a configureApp method to configure the associated app instance, for example to use plugins like the router;

Developer experience

The Vue compiler will now emit a warning if you write invalid HTML nesting in your template (for example, a div inside a p):

warning: <div> cannot be child of <p>, according to HTML specifications. This can cause hydration errors or potentially disrupt future functionality.

We also have a new warning when a computed is self-triggering (i.e. it writes to one of its dependencies in its getter):

Computed is still dirty after getter evaluation
likely because a computed is mutating its own dependency in its getter.
State mutations in computed getters should be avoided.
Check the docs for more details: https://vuejs.org/guide/essentials/computed.html#getters-should-be-side-effect-free

This warning is not enabled by default, you need to set app.config.warnRecursiveComputed to true in your application configuration.

Performances

A whole lot of optimizations have been made around reactivity. The first notable one is that the reactivity system now uses a new algorithm to track dependencies. It now relies on version counting and doubly linked lists. If I'm not mistaken, this is really similar to what Preact did and explained in this really interesting article. This brings a few performance improvements (most notably around memory usage) and should make the reactivity system more predictable (computed values should now never be stale).

The other notable change is that array manipulation should also be faster, especially for large arrays.

News from the ecosystem

Vapor mode

Vapor (@vue/vapor) is making progress within its repository. You can play with it using the online REPL here.

Vue router

Vue Router 4.4.0 is out and offers the possibility to have typed routes!

This can be done manually by adding the types yourself to your project (for example in env.d.ts):

interface RouteNamedMap {
  // a route with no params, named 'users' and matching '/users'
 users: RouteRecordInfo<"users", "/users", Record<never, never>>;
  // a route with a param named 'id', named 'user' and matching '/user/:id'
 user: RouteRecordInfo<
    "user",
    "/users/:id",
 { id: string | number }, // raw parameters (allows to use the route with a number or a string)
 { id: string } // parameters we get with useRoute
 >;
}

declare module "vue-router" {
  interface TypesConfig {
 RouteNamedMap: RouteNamedMap;
 }
}

Then when you use a RouterLink or router.push, you get a nice auto-completion and type-checking:

<!-- 👇 you get an error if the route name has a typo -->
<!-- or if you define a parameter that does not exist or forget to define it -->
<RouterLink :to="{ name: 'users', params: { id: user.id } }">User</RouterLink>

Then when using useRoute, you get a typed route object:

// note the name of the route as a parameter
// which is necessary for TypeScript to know the type of the route
const route = useRoute('user'); 
console.log(route.params.id); // 👈 id is properly typed as a string!
console.log(route.params.other); // 👈 this throws an error

This is a nice addition even if manually defining the types is a bit cumbersome.

Note that if you are into file-based routing, you can use unplugin-vue-router which will automatically generate the types for you! The plugin is still experimental though.

create-vue

A new option has been added to create-vue to allow you to use the new Devtools plugin, a Vite plugin that allows you to use the Vue Devtools directly in the browser with an overlay.

npm create vue@latest my-app --devtools

Nuxt

Nuxt v3.12 is out and paves the way for Nuxt 4. You can try the changes using:

export default defineNuxtConfig({
 future: {
   compatibilityVersion: 4
 }
})

That's all for this release. Stay tuned for the next one!

Our ebook, online training and training are up-to-date with these changes if you want to learn more!

What's new in Angular 18.2?

2024-08-14T00:00:00Z

Angular 18.2.0 is here!

This is a minor release with some nice features: let's dive in!

Automatic flush in fakeAsync

In Angular v18.2 (and zone.js v0.15), the flush() function is now automatically called at the end of a fakeAsync() test.

Before this version, you had to call flush() yourself at the end of your test to flush all pending asynchronous tasks or discardPeriodicTasks() for periodic tasks. If you didn't do it, you would get the error 1 periodic timer(s) still in the queue.

The way to fix it was to call flush() or discardPeriodicTasks() at the end of your test:

it('should do something', fakeAsync(() => {
  // ...
  flush();
}));

This is no longer necessary, as Angular will do it for you (if you manually set the flush option to true with Angular v18.2/zone.js v0.14, and will be done by default by Angular in v19/zone.js v0.15).

it('should do something', fakeAsync(() => {
  // ...
  // no flush() or discardPeriodicTasks() required!
}, { flush: true }));

When zone.js v0.15 is released, you won't need to specify the flush option anymore, as it will be done automatically for you:

it('should do something', fakeAsync(() => {
  // ...
  flush();
}));

whenStable helper

A new helper method has been added to ApplicationRef to wait for the application to become stable. whenStable is really similar to the existing isStable method, but it returns a promise that resolves when the application is stable instead of an observable.

defaultQueryParamsHandling in router

It is now possible to specify the default query params handling strategy for all routes in the provideRouter() configuration.

provideRouter(routes, withRouterConfig({ defaultQueryParamsHandling: 'merge' }));

By default, Angular uses the replace strategy, but you can also use preserve or merge. Previously, you could only specify this strategy on a per-navigation basis (via RouterLink or router.navigate options).

Migrations

An optional migration has been added to migrate dependency injection done via the constructor to the inject function.

ng g @angular/core:inject

This will update your code from:

export class UserComponent {
  constructor(private userService: UserService) {}
}

to:

export class UserComponent {
  private userService = inject(UserService);
}

Note that you might have some compilation errors after this migration, most notably if you were using new UserComponent(userService) in your tests. There are a few options for this migration, and one can mitigate this issue:

path, the directory to run the migration. By default: .;
migrateAbstractClasses, whether to migrate the abstract classes or not (which may break your code and necessitate to manually fixing it). By default: false;
backwardsCompatibleConstructors: by default, constructors that are empty after the migration are deleted. This can lead to compilation errors like the one I'm mentioning above. To prevent that, you can generate backward-compatible constructors with this option (which looks like: constructor(...args: unknown[]);). By default: false;
nonNullableOptional: whether to cast the optional inject sites to be non-nullable or not. By default: false.

The migration is optional and the Angular team explicitly said that the constructor injection will still be supported in the future. However, it does indicate that the future of Angular might be to use the inject function.

Another optional migration has been added to convert standalone components used in routes to be lazy-loaded if that's not the case:

ng g @angular/core:route-lazy-loading

This will update your code from:

{
  path: 'users',
  component: UsersComponent
}

to:

{
  path: 'users',
  loadComponent: () => import('./users/users.component').then(m => m.UsersComponent)
}

The only option for this migration is the path.

Diagnostics

A new diagnostic has been added to catch uncalled functions in event bindings:

<button (click)="login">Log in</button>

throws: NG8111: Function in event binding should be invoked: login().

Another one was added to catch unused @let declaration (a new feature introduced in Angular 18.1): NG8112: @let user is declared but its value is never read.

Angular CLI

The application builder now supports attribute-based loader configuration

For example, an SVG file can be imported as text via:

// @ts-expect-error TypeScript cannot provide types based on attributes yet
import contents from './some-file.svg' with { loader: 'text' };

This overrides all other configurations (for example a loader defined in angular.json).

Summary

That's all for this release, stay tuned!

All our materials (ebook, online training and training) are up-to-date with these changes if you want to learn more!

What's new in Angular 18.1?

2024-07-10T00:00:00Z

Angular 18.1.0 is here!

This is a minor release with some nice features: let's dive in!

TypeScript 5.5 support

Angular v18.1 now supports TypeScript 5.5. This means that you can use the latest version of TypeScript in your Angular applications. You can check out the TypeScript 5.5 release notes to learn more about the new features: it's packed with new things! For example, it's no longer necessary to manually define type guards when filtering arrays, with the new inferred type predicate feature.

@let syntax

The main feature of this release is undoubtedly the new @let syntax in Angular templates. This new syntax (in developer preview) allows you to define a template variable in the template itself, without having to declare it in the component class.

The syntax is @let name = expression;, where name is the name of the variable (and can be any valid JavaScript variable name) and expression is the value of the variable. Let’s say our component has a count field defined in its class, then we can define a variable in the template like this:

@let countPlustwo = count + 2;
<p>{{ countPlustwo }}</p>

If the count value changes, then the countPlustwo value will be updated automatically. This also works with the async pipe (and the other ones, of course):

@let user = user$ | async;
@if (user) {
  <p>{{ user.name }}</p>
}

Note that you can't declare several variables (with @let or #) with the same name in the same template:

NG8017: Cannot declare @let called 'value' as there is another symbol in the template with the same name.

You also can't use a variable before its declaration:

NG8016: Cannot read @let declaration 'user' before it has been defined.

which prevents to use it like @let user = user() in case you thought about unwrapping a signal value into a variable of the same name.

This new feature can be handy when you want to use a value in several places in your template, especially if it is a complex expression. Sometimes you can create a dedicated field in the component class, but sometimes you can’t, for example in a for loop:

@for(user of users; track user.id) {
  <div class="name">{{ user.lastName }} {{ user.firstName }}</div>
  <div class="address">
    <span>{{ user.shippingAddress.default.number }}&nbsp;</span>
    <span>{{ user.shippingAddress.default.street }}&nbsp;</span>
    <span>{{ user.shippingAddress.default.zipcode }}&nbsp;</span>
    <span>{{ user.shippingAddress.default.city }}</span>
  </div>
}

This can be written more cleanly using @let 🚀:

@for(user of users; track user.id) {
  <div class="name">{{ user.lastName }} {{ user.firstName }}</div>
  <div class="address">
    @let address = user.shippingAddress.default;
    <span>{{ address.number }}&nbsp;</span>
    <span>{{ address.street }}&nbsp;</span>
    <span>{{ address.zipcode }}&nbsp;</span>
    <span>{{ address.city }}</span>
  </div>
}

afterRender/afterNextRender APIs

Angular v16.2 introduced two new APIs to run code after the rendering of a component: afterRender and afterNextRender. You can read more about them in our Angular 16.2 blog post.

In Angular v18.1, these APIs have been changed (they are still marked as experimental) to no longer need a phase parameter, which was introduced in Angular v17, as we explained in our Angular 17 blog post.

The phase parameter is now deprecated: we now pass to these functions an object instead of a callback, to specify the phases you want to use. You can still use the callback form with no phase, which is equivalent to using the MixedReadWrite mode. There are 4 phases available in the new object form: earlyRead, mixedReadWrite, read, and write. If you only need to read something, you can use the read phase. If you need to write something that affects the layout, you need to use write. For example, to initialize a chart in your template:

export class ChartComponent {
  @ViewChild('canvas') canvas!: ElementRef<HTMLCanvasElement>;

  constructor() {
    afterNextRender({
      write: () => {
        const ctx = this.canvas.nativeElement;
        new Chart(ctx, { type: 'line', data: { ... } });
      }
    });
  }
}

If your write callback depends on something you need to read first, you must use earlyRead to get the information you need before the write phase, and Angular will call the write callback with the value returned by the earlyRead callback:

afterRender({
  earlyRead: () => nativeEl.getBoundingClientRect(),
  //👇 The `rect` parameter is the value returned by the `earlyRead` callback
  write: (rect) => {
    otherNativeEl.style.width = rect.width + "px";
  },
});

This exists to avoid intermixing reads and writes if possible, and thus make things faster by avoiding "layout trashing". We previously had to call afterRender twice, once for the read and once for the write phase, but now we can do it in a single call, which is more efficient and cleaner.

The phase option still exists but is now deprecated. Even if these APIs are an experimental feature, the Angular team provided a migration schematics to update your code to the new syntax 😍.

toSignal equality function

As you may know, if you read our blog post about signals, a Signal can define its own equality function (it uses Object.is by default).

In Angular v18.1, the toSignal function now also accepts an equal parameter to specify the equality function to use in the signal it creates.

RouterLink with UrlTree

The RouterLink directive now accepts an UrlTree as input. This allows you to pass a pre-constructed UrlTree to the RouterLink directive, which can be useful in some cases.

Until now, we could pass either a string or an array to the RouterLink directive. For example, we could write:

<a [routerLink]="['/users', user.id]">User {{ user.name }}</a>

Now we can also use an UrlTree:

export class HomeComponent {
  userPath = inject(Router).createUrlTree(["/users", user.id]);
}

and in the template:

<a [routerLink]="userPath">User {{ user.name }}</a>

Note that when doing so, you can't define the queryParams, fragment, queryParamsHandling and relativeTo inputs of the RouterLink directive in the template. You have to define them in the UrlTree itself, or you'll see the following error:

Error: NG04016: Cannot configure queryParams or fragment when using a UrlTree as the routerLink input value.

Router browserUrl

The NavigationBehaviorOptions object, used for the options of the navigate/navigateByUrl of the Router service or the RedirectCommand object introduced in Angular v18 now accepts a browserUrl option. This option allows you to specify the URL that will be displayed in the browser's address bar when the navigation is done, even if the matched URL is different. This does not affect the internal router state (the url of the Router will still be the matched one) but only the browser's address bar.

const canActivate: CanActivateFn = () => {
  const userService = inject(UserService);
  const router = inject(Router);
  if (!userService.isLoggedIn()) {
    const targetOfCurrentNavigation = router.getCurrentNavigation()?.finalUrl;
    const redirect = router.parseUrl("/401");
    // Redirect to /401 internally but display the original URL in the browser's address bar
    return new RedirectCommand(redirect, {
      browserUrl: targetOfCurrentNavigation,
    });
  }
  return true;
};

Extended diagnostic for uncalled functions

A new extended diagnostic has been added to warn about uncalled functions in event bindings:

So for example:

<button (click)="addUser">Add user</button>

yields the following error (if you have strictTemplates enabled):

NG8111: Functions must be invoked in event bindings: addUser()

Angular CLI

faster builds with isolatedModules

TypeScript has an option called isolatedModules that warns you if you write code that can't be understood by other tools by just looking at a single file.

If you enable this option on your project, you should hopefully have no warnings, and you can get a nice boost in build performances, as CLI v18.1 will delegate the transpilation of your TS files into JS files to esbuild instead of the TypeScript compiler 🚀

On a rather large application, ng build went from 49s to 32s, just by adding isolatedModules: true in my tsconfig.json file 🤯.

isolatedModules will be enabled by default in the new projects generated by the CLI.

WASM support

The CLI now supports the usage of Web Assembly... in zoneless applications! The application can't use ZoneJS as the CLI needs to use native async/await to load WASM code and ZoneJS prevents that.

Anyway this can be interesting for some people, and you can write code like:

import { hash } from "./hash.wasm";

console.log(hash(myFile));

inspect option

We can note the addition of a --inspect option for ng serve/ng dev, only possible for SSR/SSG applications. This flag starts a debug process, by default on port 9229, allowing to attach a debugger to go through the code executed on the server. You can use Chrome Inspect, VS Code, or your favorite IDE to attach to the process (see the NodeJS docs). You can then add breakpoints into your code, and the debugger will stop when this code is executed on the server when you load the corresponding page in your browser. You can specify a different host or port if needed with ng serve --inspect localhost:9999 for example.

chunk optimizer

If you want to reduce the number of chunk files, an experimental optimization has been added to the build step. You may have noticed that since we shifted from webpack to esbuild as the underlying build tool, the number of generated chunks has increased quite a bit. This is because there is no real optimization done on chunks. So we sometimes end up with really small chunks when running ng build. Some build tools have options to specify a minimal size, but esbuild doesn't. That's why the CLI team is experimenting with an additional rollup pass to optimize the generated chunks and try to merge some of them or add some directly into the main bundle when it makes sense.

On one of our largest applications, it reduces by half the number of chunks, and the initial page now only needs to load 3 JS files instead of... 118 😲. It does add a bit of build time though.

To try this on your own application, you can run:

NG_BUILD_OPTIMIZE_CHUNKS=1 ng build

This is still experimental for now but will probably be enabled automatically in a future version, based on the initial file entry count and size.

Summary

That's all for this release, stay tuned!

All our materials (ebook, online training and training) are up-to-date with these changes if you want to learn more!

What's new in Angular 18.0?

2024-05-22T00:00:00Z

Angular 18.0.0 is here!

This is a major release with some nice features: let's dive in!

Control flow syntax is now stable!

The control flow syntax introduced in Angular 17 is no longer a developer preview feature and can safely be used. As it is now the recommended way to write templates, you should consider using it in your applications. You can easily migrate your applications using the provided schematics.

👉 To learn more, check out our dedicated blog post.

Since we wrote this blog post, two warnings have been added to catch potential issues in your templates with for loops.

As you know the track option is now mandatory in @for loops. A new warning has been added in development mode to warn you if you have duplicated keys used by the track option:

WARN: 'NG0955: The provided track expression resulted in duplicated keys for a given collection.
Adjust the tracking expression such that it uniquely identifies all the items in the collection.
Duplicated keys were:
key "duplicated-key" at index "0" and "1".'

This is a warning that you can see in the browser console or when running unit tests. It typically happens if you pick a property that is not unique in your collection.

Another warning has been added to catch potential issues with the tracking expression. If the tracking expression leads to the destruction and recreation of the complete collection, a warning will be displayed:

WARN: 'NG0956: The configured tracking expression (track by identity)
caused re-creation of the entire collection of size 20.
This is an expensive operation requiring destruction and subsequent creation of DOM nodes, directives, components etc.
Please review the "track expression" and make sure that it uniquely identifies items in a collection.'

This typically happens if you use the track item option and if you recreate all the collection items when there is a change. Note that the warning only applies if the repeated element is considered "expensive" to create, but the bar is currently set quite low (a text node with a binding is already considered expensive).

Defer syntax is stable

The @defer syntax is also stable. @defer lets you define a block of template that will be loaded lazily when a condition is met (with all the components, pipes, directives, and libraries used in this block lazily loaded as well).

👉 We wrote a detailed blog post about this feature if you want to learn more about it.

Signal standardization proposal

This is not an Angular v18 news, but as you may have heard, some of the most popular framework authors (included the Angular and Vue team for example) have been working on a proposal to standardize signals in the JavaScript language.

The proposal is at the first stage, so it might take a long time, probably at least several years, or even never happened.

You can deep dive into the proposal or into this interesting blog post to learn more about it.

TL;DR: new Signal.State() would be the equivalent of signal() in Angular. new Signal.Computed() would be the equivalent of computed(). There are no equivalents for effect: as all frameworks have slightly different needs, this is left out of the scope of the proposal, and frameworks can implement it as they see fit based on new Signal.subtle.Watcher().

Fun fact: the current Signal polyfill in the proposal is based on the Angular implementation!

Zoneless change detection

Angular v18 introduces a new way to trigger change detection. Instead of relying on ZoneJS to know when something has possibly changed, the framework can now schedule a change detection by itself.

To do so, a new scheduler has been added to the framework (called ChangeDetectionScheduler), and this scheduler is internally used to trigger change detection. This new scheduler is enabled by default in v18, even if you use ZoneJS. However, the goal is to progressively move away from ZoneJS and rely only on this new scheduler.

With this new scheduler, the framework no longer only relies on ZoneJS to trigger change detection. Indeed, the new scheduler triggers a change detection when a host or template listener is triggered, when a view is attached or removed, when an async pipe detects a new emission, when the markForCheck() method is called, when you set a signal value, etc. It does so by calling ApplicationRef.tick() internally.

Opting out of the new scheduler

The new scheduler is enabled by default in v18. This means that Angular gets notified of potential changes by ZoneJS (as it used to) and by the new scheduler (when a signal is set, an async pipe receives a new value, etc.). The framework then runs the change detection. This should not impact your application, as Angular will only run the change detection once even if notified by several sources. But if you want to opt out of the new scheduler, you can use the provideZoneChangeDetection() function with ignoreChangesOutsideZone set to true:

bootstrapApplication(AppComponent, {
  providers: [
    // this restores the behavior of Angular before v18
    // and ignores the new scheduler notifications
    provideZoneChangeDetection({ ignoreChangesOutsideZone: true })
  ]
});

Experimental zoneless change detection

But you can also try to only rely on this new scheduler, and no longer on ZoneJS, to trigger change detection. This is an experimental feature, and you can enable it by using the provider function provideExperimentalZonelessChangeDetection() in your application.

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

When doing so, the framework will no longer rely on ZoneJS to trigger change detection. So you can remove ZoneJS from your application if you want to (and if you have no dependencies that rely on it, of course). In that case, you can remove zone.js from the polyfills in your angular.json file.

It should work out of the box if all your components are OnPush and/or rely on signals! 🚀

I tried it on a small application fully written with signals and it worked like a charm. Of course, this is not something we will be able to do in all applications, but it's a nice step forward towards a zoneless Angular. In particular, if you use a component library that isn't ready for zoneless support, you'll have to wait until it is. If you want to prepare your application for this new feature, you can start by progressively moving your components to OnPush.

Testing

Note that the provideExperimentalZonelessChangeDetection function can also be used in tests, so you can test your application without ZoneJS, and make sure your components are correctly working with this new feature.

You can currently add the provider in each test, or globally to all your tests by adding it in the TestBed configuration, in the test.ts file of your application (this file is no longer generated in new projects, but you can add it back manually):

@NgModule({
  providers: [provideExperimentalZonelessChangeDetection()]
})
export class ZonelessTestModule {}

getTestBed().initTestEnvironment(
  [BrowserDynamicTestingModule, ZonelessTestModule],
  platformBrowserDynamicTesting()
);

Then, instead of relying on fixture.detectChanges() that triggers the change detection, you can simply use await fixture.whenStable() and let Angular trigger the change detection (as it would when running the application). This is because the ComponentFixture used by the framework in zoneless mode uses the "auto detect changes" strategy by default.

So, similarly to using OnPush in your components to prepare for the zoneless future, a good way to prepare your tests is to progressively replace detectChanges() with await fixture.whenStable() and enable "auto-detect changes" in your tests.

This is something that has been existing for quite some time in Angular. If you want to use it in your current tests, even without using provideExperimentalZonelessChangeDetection, you can either call fixture.autoDetectChanges() at the beginning of your test, or add the following provider to your test configuration:

providers: [
  { provide: ComponentFixtureAutoDetect, useValue: true }
]

We're probably going to update our ebook and the tests we provide in our online training to use this strategy.

Note that some testing features that use ZoneJS are not supported with provideExperimentalZonelessChangeDetection(), like fakeAsync and tick(). If you need to fake time in your tests, you can use the jasmine.clock APIs instead.

Debugging existing applications

If you want to check if your current application is ready for zoneless change detection, you can use provideExperimentalCheckNoChangesForDebug():

bootstrapApplication(AppComponent, {
  providers: [
    provideZoneChangeDetection({ eventCoalescing: true }), // or provideExperimentalZonelessChangeDetection()
    provideExperimentalCheckNoChangesForDebug({
      interval: 1000, // run change detection every second
      useNgZoneOnStable: true, // run it when the NgZone is stable as well
      exhaustive: true // check all components
    })
  ]
});

This will run a change detection every second and check if any component has been changed without triggering a change detection. If such a change is detected, a NG0100: ExpressionChangedAfterItHasBeenCheckedError error will be thrown in the console. This should allow you to track down the components that need to be updated to work with zoneless change detection.

Zone.js status

ZoneJS is still a dependency of Angular and will be for a while. It is now officially in maintenance mode, and will not ship new features, but will still be maintained for bug fixes and security issues.

Fallback for ng-content

<ng-content> is a powerful feature in Angular, but it has a cumbersome limitation: it can't have fallback content. This is no longer the case in Angular v18!

We can now add some content inside the <ng-content> tag, and this content will be displayed if no content is projected in the component.

For example, let's consider a CardComponent with a title and a content that can be projected:

<div class="card">
  <div class="card-body">
    <h4 class="card-title">
      <!-- 👇 If the title is not provided, we display a default title -->
      <ng-content select=".title">Default title</ng-content>
    </h4>
    <p class="card-text">
      <ng-content select=".content"></ng-content>
    </p>
  </div>
</div>

Now, if we use this component without providing a title, the default title will be displayed!

Forms events

The AbstractControl class (the base class for form controls, groups, arrays, and records) now has a new property called events.

This field is an observable that emits events when the control's value, status, pristine state, or touched state changes. It also emits when the form is reset or submitted.

For example, let's consider a form group for a user with a login and a password:

fb = inject(NonNullableFormBuilder);
userForm = this.fb.group({
  login: ['', Validators.required],
  password: ['', Validators.required]
});

  constructor() {
    this.userForm.events.subscribe(event => {
      if (event instanceof TouchedChangeEvent) {
        console.log('Touched: ', event.touched);
      } else if (event instanceof PristineChangeEvent) {
        console.log('Pristine: ', event.pristine);
      } else if (event instanceof StatusChangeEvent) {
        console.log('Status: ', event.status);
      } else if (event instanceof ValueChangeEvent) {
        console.log('Value: ', event.value);
      } else if (event instanceof FormResetEvent) {
        console.log('Form reset');
      } else if (event instanceof FormSubmitEvent) {
        console.log('Form submit');
      }
    });
  }

As you can see, several types of events can be emitted: TouchedChangeEvent, PristineChangeEvent, StatusChangeEvent, ValueChangeEvent, FormResetEvent and FormSubmitEvent.

If I enter a first character in the login field, the console will display:

Pristine: false
Value: Object { login: "c", password: "" }
Status: INVALID
Touched: true

All events also have a source property that contains the control that emitted the event (here the login control). The source contains the form itself for form reset and submission events.

Router and redirects

The redirectTo property of a route now accepts a function instead of just a string. Previously, we were only able to redirect our users to a static route or a route with the same parameters. The RedirectFunction introduced in v18 allows us to access part of the ActivatedRouteSnapshot to build the redirect URL. I say "part of" because the activated route is not fully resolved when the function is called. For example, the resolvers haven't run yet, the child routes aren't matched, etc. But we do have access to the parent route params or the query params for example, which was not previously possible. This function is also similar to guards, and is run in the environment injector: this means you can inject services if needed. The function can return a string or a UrlTree.

provideRouter([
  // ...
  {
    path: 'legacy-users',
    redirectTo: (redirectData) => {
      const userService = inject(UserService);
      const router = inject(Router);
      // You also have access to 'routeConfig', 'url', 'params', 'fragment',  'data',  'outlet', and 'title'
      const queryParams = redirectData.queryParams;
      // if the user is logged in, keep the query params
      if (userService.isLoggedIn()) {
        const urlTree = router.parseUrl('/users');
        urlTree.queryParams = queryParams;
        return urlTree;
      }
      return '/users';
    }
  }
])

A similar improvement has been made in guards. The GuardResult type returned by a guard has been augmented from boolean | UrlTree to boolean | UrlTree | RedirectCommand. A guard could already return an UrlTree to redirect the user to another route, but now it can also return a RedirectCommand to redirect the user to another route with a specific navigation behavior, as a RedirectCommand is an object with two properties: redirectTo (the UrlTree to navigate to) and navigationBehaviorOptions (the navigation behavior to use):

provideRouter([
  // ...
  {
    path: 'users',
    component: UsersComponent,
    canActivate: [
      () => {
        const userService = inject(UserService);
        return userService.isLoggedIn() || new RedirectCommand(router.parseUrl('/login'), {
          state: { requestedUrl: 'users' } 
        });
      }
    ],
  }
])

Resolvers can now also return a RedirectCommand. The first resolver to do so will trigger a redirect and cancel the current navigation.

withNavigationErrorHandler() has also been updated to be able to return a RedirectCommand.

HttpClientModule deprecation

Now that the ecosystem is moving towards standalone components, we're starting to see the deprecation of the first Angular modules. Starting with v18, HttpClientModule (and HttpClientTestingModule, HttpClientXsrfModule, and HttpClientJsonpModule) are deprecated.

As you probably know, you can now use provideHttpClient() (with options for XSRF or JSONP support) and provideHttpClientTesting() as a replacement.

But, as usual, the Angular team provides a schematic to help you migrate your application. When running ng update @angular/core, you'll be prompted to migrate your HTTP modules if you still have some in your application.

Internationalization

The utility functions offered by @angular/common to work with locale data have been deprecated in favor of the Intl API. It is no longer recommended to use getLocaleCurrencyCode(), getLocaleDateFormat(), getLocaleFirstDayOfWeek(), etc. Instead, you should use the Intl API directly, for example Intl.DateTimeFormat to work with locale dates.

Server-Side Rendering

We have two new features in Angular v18 that are related to Server-Side Rendering (SSR).

SSR and replay events

It is now possible to record user interactions during the hydration phase, and replay them when the application is fully loaded. As you may know, the hydration phase is the phase where the server-rendered HTML is transformed into a fully functional Angular application, where listeners are added to the existing elements.

But during this phase, the user can interact with the application, and these interactions are lost (if the hydration process is not fast enough).

So for some applications, it can be interesting to record these interactions and replay them when the application is fully loaded.

This used to be done via a project called preboot in Angular, but this project was no longer maintained. Instead of reviving preboot, the Angular team decided to implement this feature directly in the framework. But they did not start from scratch: in fact, they used something that already existed inside Google, in the Wiz framework. Wiz is not open-source, but it is widely used by Google for their applications (Google Search, Google Photos, etc.). You can read about the ambitions of the Wiz and Angular teams to "merge" the two frameworks in this blog post on angular.io. Wiz started to use the signals API from Angular (that's why Youtube is now using Signals), and now Angular is using the replay events feature from Wiz. That's why these two features are in a packages/core/primitives directory in the Angular codebase: they are part of Angular but are shared by the two frameworks.

To enable this feature, you can use the withEventReplay() (developer preview) function in your server-side rendering configuration:

providers: [
  provideClientHydration(withEventReplay())
]

When doing so, Angular will add a JS script at the top of your HTML page, whose job is to replay events that happened during the hydration phase. To do so, it adds a listener at the root of the document, and listens to a set of events that can happen on the page using event delegation. It does know which events it needs to listen to, as Angular collected them when rendering the page on the server. So for example, if you render a page that contains elements which have a (click) or a (dblclick) handler, Angular will add listeners for these events:

<script>window.__jsaction_bootstrap('ngContracts', document.body, "ng", ["click","dblclick"]);</script>

When the application is loaded and stable, the script then replays the events that happened during the hydration phase, thus triggering the same actions as the user did. Quite a nice feature, even if it is probably useful only for some applications.

SSR and Internationalization

The Angular SSR support is improving with each version. One year ago, Angular v16 introduced progressive hydration, as we explained in this blog post. There was one missing feature at the time: the internationalization support. Angular would skip the elements marked with i18n during SSR. This is now solved in v18! If your application uses the builtin i18n support of the framework, you can now use SSR. The support is in developer preview, and can be enabled with withI18nSupport().

Angular CLI

The CLI has also been released in version v18, with some notable features.

Performance improvements

The CLI now builds projects with a larger number of components faster. The commit mentions some really nice gains but I was not able to reproduce them in my experiments on large projects.

ng dev

The ng serve command is now aliased to ng dev (in addition to the existing ng s). This aligns with the Vite ecosystem, where the development server is usually started using npm run dev.

Speaking of commands, the ng doc command has been removed from the CLI in v18.

New build package

The Angular CLI now has a new package for building applications: @angular/build. It contains the esbuild/Vite builders, that were previously in the @angular-devkit/build-angular package. This allows the new package to only have Vite and ESBuild as dependencies, and not Webpack. The serve/build/extract-i18n builders are now in this new package. The @angular-devkit/build-angular package can still be used, as it provides an alias to the now-moved builders.

You'll notice that an optional migration can be run when updating your application to v18, to update your angular.json file to use the new package (where @angular-devkit/build-angular is replaced by @angular/build) and update your package.json accordingly (to add @angular/build and remove @angular-devkit/build-angular).

This will only be done if you don't use any Webpack-based builders in your applications, so the migration does nothing if you have tests using Karma for example (as they run using Webpack).

Less and PostCSS dependencies

The CLI supports Sass, Less, and PostCSS out of the box, and until now, these dependencies were installed in your node_modules when creating a new application (even if you were not using these dependencies).

Less and PostCSS are now optional dependencies for the new @angular/build package and need to be installed explicitly if you switch to the new package.

When you update your application to v18, these dependencies will be added automatically by ng update if you choose to switch to @angular/build (and if you're using them of course).

Native async/await in zoneless applications

ZoneJS has a particularity: it can't work with async/await. So you may not know it, but every time you use async/await in your application, your code is transformed by the CLI to use "regular" promises. This is called downleveling, as it transforms ES2017 code (async/await) into ES2015 code (regular promises).

As we are now able to build applications without ZoneJS (even if it is still experimental), the CLI doesn't downlevel async/await when zone.js is not in the application polyfills. This should make the build a tiny bit faster and lighter in that case.

New project skeleton updates

If you want to upgrade to v18 without pain (or to any other version, by the way), I have created a Github project to help: angular-cli-diff. Choose the version you're currently using (17.3.0 for example), and the target version (18.0.0 for example), and it gives you a diff of all files created by the CLI: angular-cli-diff/compare/17.3.0...18.0.0. It can be a great help along with the official ng update @angular/core @angular/cli command.

You'll notice that the assets folder has been replaced by a public folder in new projects. You'll also note that the app.config.ts file now contains the provideZoneChangeDetection() provider by default with the eventCoalescing option set to true (which avoids the change detection being triggered several times by ZoneJS when an event bubbles and is listened to by several template listeners).

Summary

That's all for this release. v19 will probably be dedicated to stabilizing the signals APIs introduced these past months. We should also see a new feature to declare variables in the template itself, using @let, as well as an option to switch to Intl-based internationalization. Stay tuned!

All our materials (ebook, online training and training) are up-to-date with these changes if you want to learn more!

What's new in Angular 17.3?

2024-03-13T00:00:00Z

Angular 17.3.0 is here!

This is a minor release with some nice features: let's dive in!

TypeScript 5.4 support

Angular v17.3 now supports TypeScript 5.4. This means that you can use the latest version of TypeScript in your Angular applications. You can check out the TypeScript 5.4 release notes to learn more about the new features.

New template compiler

Angular now uses a new template compiler! The work on this compiler started more than a year ago and has been done in parallel with the other features we saw in the previous releases to eventually pass all of the existing tests. It's now the case, and this new compiler is now the default in Angular 17.3.

This compiler is based on an intermediate representation of template operations, a common concept in compilers, for example in LLVM. This IR semantically encodes what needs to happen at runtime to render and change-detect the template. Using an IR allows for different concerns of template compilation to be processed independently, which was not the case with the previous implementation. This new compiler is easier to maintain and extend, so it is a great foundation for future improvements in the framework.

Note that the compiler emits the same code as the previous one, so you should not see any difference in the generated code.

output functions

A new (developer preview) feature was added to allow the declaration of outputs similarly to the input() function.

As for inputs, you can use the output() function to define an output:

ponySelected = output<PonyModel>();
// ^? OutputEmitterRef<PonyModel>

The output() function returns an OutputEmitterRef<T> that can be used to emit values. OutputEmitterRef is an Angular class, really similar to a simplified EventEmitter but that does not rely on RxJS (to limit the coupling of Angular with RxJS).

The function accepts a parameter to specify options, the only one available for now is alias to alias the output.

As with EventEmitter, you can use the emit() method to emit a value:

ponySelected = output<PonyModel>();
// ^? OutputEmitterRef<PonyModel>
select() {
  this.ponySelected.emit(this.ponyModel());
}

You can also declare an output without a generic type, and the OutputEmitterRef will be of type OutputEmitterRef<void>. You can then call emit() without a parameter on such an output.

OutputEmitterRef also exposes a subscribe method to manually subscribe to the output. This is not something you’ll do often, but it can be handy in some cases. If you manually subscribe to an output, you’ll have to manually unsubscribe as well. To do so, the subscribe method returns an OutputRefSubscription object with an unsubscribe method.

Two new functions have been added to the rxjs-interop package to convert an output to an observable, and an observable to an output.

Angular always had the capability of using observables other than EventEmitter for outputs. This is not something that is largely used, but it’s possible. The new outputFromObservable function allows you to convert an observable to an output:

ponyRunning$ = new BehaviorSubject(false);
ponyRunning = outputFromObservable(this.ponyRunning$);
// ^? OutputRef<boolean>

The outputFromObservable function returns an OutputRef<T>, and not an OutputEmitterRef<T>, as you can’t emit values on an output created from an observable. The output emits every event that is emitted by the observable.

startRunning() {
  this.ponyRunning$.next(true);
}

It is also possible to convert an output to an observable using the outputToObservable function if needed. You can then use .pipe() and all the RxJS operators on the converted output.

These interoperability functions will probably be rarely used. output(), on the other hand, will become the recommended way to declare outputs in Angular components.

HostAttributeToken

Angular has always allowed to inject the value of an attribute of the host element. For example, to get the type of an input, you can use:

@Directive({ 
  selector: 'input',
  standalone: true
})
class InputAttrDirective {
  constructor(@Attribute('type') private type: string) {
    // type would be 'text' if `<input type="text" />
  }
}

Since Angular v14, injection can be done via the inject() function as well, but there was no option to get an attribute value with it.

This is now possible by using a special class HostAttributeToken:

type = inject(new HostAttributeToken('type'));

Note that inject throws if the attribute is not found (unless you pass a second argument { optional: true }).

RouterTestingModule deprecation

The RouterTestingModule is now deprecated. It is now recommended to provideRouter() in the TestBed configuration instead.

New router types

The router now has new types to model the result of guards and resolvers.

For example, the CanActivate guard was declared like this:

export type CanActivateFn = (route: ActivatedRouteSnapshot, state: RouterStateSnapshot) => Observable<boolean | UrlTree> | Promise<boolean | UrlTree> | boolean | UrlTree;

This is because the guard can return a boolean to allow or forbid the navigation, or an UrlTree to trigger a redirection to another route. This result can be synchronous or asynchronous.

The signature has been updated to:

export type CanActivateFn = (route: ActivatedRouteSnapshot, state: RouterStateSnapshot) => MaybeAsync<GuardResult>;

GuardResult is a new type equal to boolean | UrlTree, and MaybeAsync<T> is a new generic type equal to T | Observable<T> | Promise<T>.

A resolver function now also returns a MaybeAsync<T>. You can keep using the older signatures but the new ones are more concise.

Angular CLI

Angular CLI v17.3 doesn't bring a lot of new features, but we can note that deployUrl is now supported in the application builder. It was initially marked as deprecated but was re-introduced after community feedback.

Summary

That's all for this release. The next stop is v18, where we should see some developer preview features becoming stable. Stay tuned!

All our materials (ebook, online training and training) are up-to-date with these changes if you want to learn more!

What's new in Angular 17.2?

2024-02-14T00:00:00Z

Angular 17.2.0 is here!

This is a minor release with some nice features: let's dive in!

Queries as signals

A new developer preview feature has been added to allow the use of queries as signals. viewChild(), viewChildren(), contentChild(), and contentChildren() functions have been added in @angular/core and return signals.

Let’s go through a few examples.

You can use viewChild to query the template:

// <canvas #chart></canvas>
canvas = viewChild<ElementRef<HTMLCanvasElement>>('chart');
// ^? Signal<ElementRef<HTMLCanvasElement> | undefined>

// <form></form> with FormsModule
form = viewChild(NgForm);
// ^? Signal<NgForm | undefined>

As you can see, the return type is a Signal containing the queried ElementRef<HTMLElement> or undefined, or the queried component/directive or undefined.

You can specify that the queried element is required to get rid of undefined:

canvas = viewChild.required<ElementRef<HTMLCanvasElement>>('chart');
// ^? Signal<ElementRef<HTMLCanvasElement>>

If the element is not found, you’ll have a runtime error:

'NG0951: Child query result is required but no value is available.
Find more at https://angular.io/errors/NG0951'

This error can also happen if you try to access the query result too soon, for example in the constructor of the component. You can access the query result in the ngAfterViewInit/ngAfterViewChecked lifecycle hooks, or in the afterNextRender/afterRender functions.

You can also use viewChildren to query multiple elements. In that case, you get a Signal containing a readonly array of elements, or an empty array if no element is found (we no longer need QueryList \o/): chart.component.ts

canvases = viewChildren<ElementRef<HTMLCanvasElement>>('chart');
// ^? Signal<ReadonlyArray<ElementRef<HTMLCanvasElement>>>

The functions accept the same option as @ViewChild and @ViewChildren, so you can specify the read option to query a directive or provider on an element.

As you can imagine, the same is possible for contentChild and contentChildren.

For example, if we want to build a TabsComponent that can be used like this:

<ns-tabs>
  <ns-tab title="Races" />
  <ns-tab title="About" />
</ns-tabs>

We can build a TabDirective to represent a tab:

@Directive({
  selector: 'ns-tab',
  standalone: true
})
export class TabDirective {
  title = input.required<string>();
}

then build the TabsComponent with contentChildren to query the directives:

@Component({
  selector: 'ns-tabs',
  template: `
    <ul class="nav nav-tabs">
      @for (tab of tabs(); track tab) {
        <li class="nav-item">
          <a class="nav-link">{{ tab.title() }}</a>
        </li>
      }
    </ul>
  `,
  standalone: true
})
export class TabsComponent {
  tabs = contentChildren(TabDirective);
  // ^? Signal<ReadonlyArray<TabDirective>>
}

As for the @ViewChild/@ViewChildren decorators, we can specify the descendants option to query the tab directives that are not direct children of TabsComponent:

tabs = contentChildren(TabDirective, { descendants: true });
// ^? Signal<ReadonlyArray<TabDirective>>

<ns-tabs>
  <div>
    <ns-tab title="Races" />
  </div>
  <ns-tabgroup>
    <ns-tab title="About" />
  </ns-tabgroup>
</ns-tabs>

As viewChild, contentChild can be required.

`model` signal

Signals also allow a fresh take on existing patterns. As you probably know, Angular allows a "banana in a box" syntax for two-way binding. This is mostly used with ngModel to bind a form control to a component property:

<input name="login" [(ngModel)]="user.login" />

Under the hood, this is because the ngModel directive has a ngModel input and a ngModelChange output.

So the banana in a box syntax is just syntactic sugar for the following:

<input name="login" [ngModel]="user.login" (ngModelChange)="user.login = $event" />

The syntax is, in fact, general and can be used with any component or directive that has an input named something and an output named somethingChange.

You can leverage this in your own components and directives, for example, to build a pagination component:

@Input({ required: true }) collectionSize!: number;
@Input({ required: true }) pageSize!: number;

@Input({ required: true }) page!: number;
@Output() pageChange = new EventEmitter<number>();

pages: Array<number> = [];

ngOnChanges(): void {
  this.pages = this.computePages();
}

goToPage(page: number) {
  this.pageChange.emit(page);
}

private computePages() {
  return Array.from({ length: Math.ceil(this.collectionSize / this.pageSize) }, (_, i) => i + 1);
}

The component receives the collection, the page size, and the current page as inputs, and emits the new page when the user clicks on a button.

Every time an input changes, the component recomputes the buttons to display. The template uses a for loop to display the buttons:

@for (pageNumber of pages; track pageNumber) {
  <button [class.active]="page === pageNumber" (click)="goToPage(pageNumber)">
    {{ pageNumber }}
  </button>
}

The component can then be used like:

<ns-pagination [(page)]="page" [collectionSize]="collectionSize" [pageSize]="pageSize"></ns-pagination>

Note that page can be a number or a signal of a number, the framework will handle it correctly.

The pagination component can be rewritten using signals, and the brand new model() function:

collectionSize = input.required<number>();
pageSize = input.required<number>();
pages = computed(() => this.computePages());

page = model.required<number>();
// ^? ModelSignal<number>;
goToPage(page: number) {
  this.page.set(page);
}

private computePages() {
  return Array.from({ length: Math.ceil(this.collectionSize() / this.pageSize()) }, (_, i) => i + 1);
}

As you can see, a model() function is used to define the input/output pair, and the output emission is done using the set() method of the signal.

A model can be required, or can have a default value, or can be aliased, as it is the case for inputs. It can’t be transformed though. If you use an alias, the output will be aliased as well.

If you try to access the value of the model before it has been set, for example in the constructor of the component, then you’ll have a runtime error:

'NG0952: Model is required but no value is available yet.
Find more at https://angular.io/errors/NG0952'

Defer testing

The default behavior of the TestBed for testing components using @defer blocks has changed from Manual to Playthrough.

Check out our blog post about defer for more details.

NgOptimizedImage

The NgOptimizedImage directive (check out our blog post about it) can now automatically display a placeholder while the image is loading, if the provider supports automatic image resizing.

This can be enabled by adding a placeholder attribute to the directive:

<img ngSrc="logo.jpg" placeholder />

The placeholder is 30px by 30px by default, but you can customize it. It is displayed slightly blurred to give a hint to the user that the image is loading. The blur effect can be disabled with [placeholderConfig]="{ blur: false }.

Another new feature is the ability to use Netlify as a provider, joining the existing Cloudflare, Cloudinary, ImageKit, and Imgix providers.

Angular CLI

define support

The CLI now supports a new option named define in the build target. It is similar to what the esbuild plugin of the same name does: you can define constants that will be replaced with the specified value in TS and JS code, including in libraries.

You can for example define a BASE_URL that will be replaced with the value of https://api.example.com:

"build": {
  "builder": "@angular-devkit/build-angular:application",
  "options": {
    "define": {
      "BASE_URL": "'https://api.example.com'"
    },

You can then use it in your code:

return this.http.get(`${BASE_URL}/users`);

TypeScript needs to know that this constant exists (as you don't import it), so you need to declare it in a d.ts file:

declare const BASE_URL: string;

This can be an alternative to the environment files, and it can be even more powerful as the constant is also replaced in libraries.

Bun support

You can now use Bun as a package manager for your Angular CLI projects, in addition to npm, yarn, pnpm and cnpm. It will be automatically detected, or can be forced with --package-manager=bun when generating a new project.

clearScreen option

A new option is now supported in the application builder to clear the screen before rebuilding the application.

"build": {
  "builder": "@angular-devkit/build-angular:application",
  "options": {
    "clearScreen": true
  },

You then only see the output of the current build, and not from the previous one.

Abbreviated build targets

The angular.json file now supports abbreviated build targets. For example, you currently have something like this in your project:

"serve": {
  "builder": "@angular-devkit/build-angular:dev-server",
  "configurations": {
    "development": {
      "buildTarget": "app:build:development"
    },

This means that ng serve uses the app:build:development target to build the application.

This can now be abbreviated to:

"serve": {
  "builder": "@angular-devkit/build-angular:dev-server",
  "configurations": {
    "development": {
      "buildTarget": "::development"
    },

PostCSS support

The application builder now supports PostCSS, a tool for transforming CSS with JavaScript plugins. You just have to add a postcss.config.json or .postcssrc.json file to your project and the CLI will pick it up.

JSON build logs

The CLI now supports a new option to output the build logs in JSON format. This can be useful to integrate the build logs in other tools.

NG_BUILD_LOGS_JSON=1 ng build

Summary

That's all for this release, stay tuned!

All our materials (ebook, online training and training) are up-to-date with these changes if you want to learn more!

What's new in Angular 17.1?

2024-01-17T00:00:00Z

Angular 17.1.0 is here!

This is a minor release with some nice features: let's dive in!

TypeScript 5.3 support

Angular v17.1 now supports TypeScript 5.3. This means that you can use the latest version of TypeScript in your Angular applications. You can check out the TypeScript 5.3 release notes to learn more about the new features.

Inputs as signals

In Angular v17.1, a new feature was added to allow the use of inputs as signals. This is a first step towards signal-based components. The framework team added an input() function in @angular/core.

@Component({
  standalone: true,
  selector: 'ns-pony',
  template: `
    @if (ponyModel(); as ponyModel) {
      <figure>
        <img [src]="imageUrl()" [alt]="ponyModel.name" />
        <figcaption>{{ ponyModel.name }}</figcaption>
      </figure>
    }
  `
})
export class PonyComponent {
  ponyModel = input<PonyModel>();
  imageUrl = computed(() => `assets/pony-${this.ponyModel()!.color}.gif`);
}

As you can see in the example above, the input() function returns a signal, that can be used in the template or in computed values (which would be the modern equivalent of ngOnChanges).

It can be undefined though, hence the @if in the template and the ! in the computed value.

If an input is mandatory, you can use the input.required() version of the function:

@Component({
  standalone: true,
  selector: 'ns-pony',
  template: `
    <figure>
      <img [src]="imageUrl()" [alt]="ponyModel().name" />
      <figcaption>{{ ponyModel().name }}</figcaption>
    </figure>
  `
})
export class PonyComponent {
  ponyModel = input.required<PonyModel>();
  imageUrl = computed(() => `assets/pony-${this.ponyModel().color}.gif`);
}

You can also provide a default value, an alias, and a transformer function. Here the ponySpeed field is aliased as speed, provided with a default value, and transformed to a number (even if the input is a string):

ponySpeed = input(10, {
  alias: 'speed',
  transform: numberAttribute
});

You can also use the signal as the source of an observable, to trigger an action when the input changes. For example, to fetch data from a server:

export class PonyComponent {
  ponyService = inject(PonyService);
  ponyId = input.required<number>();
  // entity fetched from the server every time the ponyId changes
  ponyModel = toSignal(toObservable(this.ponyId)
    .pipe(switchMap(id => this.ponyService.get(id))));
  imageUrl = computed(() => `assets/pony-${this.ponyModel()!.color}.gif`);
}

When coupled with the recent addition to the router called "Component Input Binding", where the router binds the route parameters to the inputs of a component, it can lead to an interesting pattern. Note that the input transform is necessary as the router parameters are strings:

ponyId = input.required<number, string>({
  transform: numberAttribute
});

This behavior is enabled via withComponentInputBinding in the router configuration:

provideRouter(
  [
    {
      path: 'pony/:ponyId',
      component: PonyComponent
    }
  ],
  withComponentInputBinding()
),

Zoneless change detection

The framework is making progress towards zoneless change detection. A new private API called ɵprovideZonelessChangeDetection was added to @angular/core. When you add this provider to your application, the framework no longer relies on Zone.js for change detection (and you can remove it from the application).

So how does it work? Every time an event is fired, an input is set, an output emits a value, an async pipe receives a value, a signal is set, markForCheck is called, etc., the framework notifies an internal scheduler that something happened. It then runs the change detection on the component marked as dirty. But this doesn't catch what Zone.js usually does: a setTimeout, a setInterval, a Promise, an XMLHttpRequest, etc.

But that shouldn't be a problem because the idea is that when a setTimeout, setInterval or XMLHttpRequest callback is triggered, and you want it to update the state of the application, you should do it by modifying a signal, which will in turn trigger change detection.

This is far from being complete, as the "private API" part suggests. However, it indicates that the framework is making progress towards zoneless change detection.

Router

The router now has an info option in the NavigationExtras that can be used to store information about the navigation. Unlike the state option, this information is not persisted in the session history. The RouterLink directive now supports this option as well:

<a [routerLink]="['/pony', pony.id]" [info]="{ ponyName: pony.name }">{{ pony.name }}</a>

Control flow migration

The control flow migration is still experimental but has been improved with a ton of bug fixes and new features. It now removes the useless imports from your component imports after the migration. It also now has a new option format to reformat your templates after the migration. The option is true by default, but can be turned off:

ng g @angular/core:control-flow --path src/app/app.component.html --format=false

INFINITE_CHANGE_DETECTION

This is not a new feature, but this bug fix is worth mentioning. Angular v17.1 fixes a bug for transplanted views, but this will also be useful for signals.

The framework now runs change detection while there are still dirty views to be refreshed in the tree. If too many loops are detected, the framework will throw an error: INFINITE_CHANGE_DETECTION.

This will remind the oldest Angular developers of the good old days of AngularJS, when we had to be careful with infinite digest loops 👴.

Angular v17.1 will throw this error if you have 100 loops in a row at the moment.

Angular CLI

Vite v5

The Angular CLI v17.1 now uses Vite v5 under the hood. Vite v5 was recently released, you can read more about it in the official blog post.

Application builder migration

If you haven't migrated to the new application builder yet, there is now a migration schematic to help you with that:

ng update @angular/cli --name=use-application-builder

Keyboard shortcuts in dev server

After running ng serve, you can now see in the terminal the following line:

Watch mode enabled. Watching for file changes...
  ➜  Local:   http://localhost:4200/
  ➜  press h + enter to show help

If you press 'h + enter', you will see the list of available keyboard shortcuts:

Shortcuts
press r + enter to force reload browser
press u + enter to show server url
press o + enter to open in browser
press c + enter to clear console
press q + enter to quit

Quite cool!

Running tests with Web Test Runner

An experimental builder is now available to run tests with Web Test Runner. It is very early stage, but you can try it out by replacing the karma builder with web-test-runner in the angular.json file:

"test": {
  "builder": "@angular-devkit/build-angular:web-test-runner",
}

You then need to install the @web/test-runner package, and here you go! Running ng test will now use Web Test Runner instead of Karma (and bundle the files with the application builder, which uses esbuild, and not Webpack as the current karma builder does).

A lot of options aren't available yet, so you can't change the browser for example (it only runs in Chrome for now), or define reporters, or use any kind of configuration.

In the future, we will be able to define a configuration file for Web Test Runner, use other browsers (WTR supports using Playwright to download and run tests in other browsers), etc.

This builder will probably be the default in the future, as Karma is now deprecated.

loader option

The application builder gained a new loader option. It allows defining the type of loader to use for a specified file extension. The file matching the extension can then be used within the application code via an import.

The available loaders that can be used are:

text which treats the content as a string
binary which treats the content as a Uint8Array
file which emits the file and provides the runtime location of the file
empty which considers the content to be empty and will not include it in bundles

For example, to inline the content of SVG files into the bundled application, you can use the following configuration in the angular.json file:

loader: {
    ".svg": "text"
}

Then an SVG file can be imported in your code with:

import content from './logo.svg';

TypeScript needs to be aware of the module type for the import to prevent type-checking errors during the build, so you'll need to add a type definition for the SVG file:

declare module "*.svg" {
  const content: string;
  export default content;
}

Output location

It is now possible to customize the output location of the build artifacts:

"outputPath": {
  "base": "dist/my-app",
  "browser": "",
  "server": "node-server",
  "media": "resources"
}

Retain special CSS comments

By default, the CLI removes comments from CSS files during the build. If you want to retain them because you use some tools that rely on them, you can now set the removeSpecialComments option to false in the optimization section of your angular.json file:

"optimization": {
  "styles": {
    "removeSpecialComments": false
  }
}

Allowed CommonJS dependencies

You can now specify * as a package name in the allowedCommonJsDependencies option to allow all packages in your build:

"allowedCommonJsDependencies": ["*"]

--no-browsers in tests

You can now use the --no-browsers option when running tests with the CLI. This will prevent the browser from opening when running tests, which can be useful if you are inside a container for example. This was already possible by setting the browsers option to [] in the karma.conf.js file, but not from the CLI command.

ng test --no-browsers

Summary

That's all for this release, stay tuned!

All our materials (ebook, online training and training) are up-to-date with these changes if you want to learn more!

What's new in Vue 3.4?

2023-12-29T00:00:00Z

Vue 3.4.0 is here!

The last minor release was v3.3.0 in May. Since then, we have seen a few patch releases, some coming with new features.

Let's see what we have in this release!

v-bind shorthand syntax

It is now possible to use a shorthand syntax for v-bind when the key and value have the same name!

<!-- before -->
<div v-bind:id="id"></div>
<-- or -->
<div :id="id"></div>

<!-- after -->
<div v-bind:id></div>
<-- or -->
<div :id></div>

Performances improvements for the reactivity system

Johnson Chu, the author of Volar, has done massive work to improve the performance of the reactivity system.

Let's consider a scenario where you have a computed A that depends on a computed B. In Vue v3.3, if B is re-evaluated, A is also re-evaluated, even if B has the same value as before. In Vue v3.4, A is not re-evaluated if B has the same value as before. This is also true for watch functions.

Other improvements have been made for Arrays mutations, for watchers that depend on multiple computed values, and more (as you can see in the PR description).

This should avoid a whole lot of unnecessary re-renders! 🚀 (and hopefully, don't introduce any regression 🤞).

`computed` previous value

You can now get the previous value in a computed, as the first parameter of the getter function.

const count = ref(0);
const double = computed((prev) => {
  console.log(prev);
  return count.value * 2
});
count.value++;
// logs 0

This can be useful if you want to manually compare object values. (computed internally uses Object.is to compare the previous and current values, which is not always what you want, see the PR description). This is especially useful with the new reactivity system improvements. In v3.4, a computed property will only trigger effects when its computed value has changed from the previous one. But in the case of a computed that return new objects, Vue thinks that the previous and current values are different. If you want to avoid triggering effects in that case, you can compare the previous and current values manually.

Performances improvements for the compiler

The Vue compiler has been improved to be faster. Evan rewrote the parser entirely, to avoid using regexes. The code generation has also been improved. They are now nearly 2 times faster!

This should not have a huge impact on your build times, as the Vue compiler is not the only step in the build process (you usually have the TypeScript compiler, the CSS preprocessor, etc.).

Support for import attributes

It is now possible to use import attributes in SFC (both in JS and TS):

import json from "./foo.json" with { type: "json" }

The support for using has also been added (new feature for explicit resource management in JS, see the proposal here).

watch `once`

The watch function gained a new option called once. When set to true, the watcher is removed after the first call.

watch('foo', () => {
  console.log('foo changed');
}, { once: true });

It was previously possible to achieve the same result by using the returned stop function:

const stop = watch('foo', () => {
  console.log('foo changed');
  stop();
});

Props validation

As you probably know, Vue provides a mechanism to validate props.

defineProps({
  min: {
    type: Number,
    required: true,
    validator: (value) => value >= 0,
  },
  max: {
    type: Number,
    required: true,
    validator: (value) => value >= 0,
  }
})

In the above example, the min and max props must be positive numbers. In Vue v3.4, the validator function is now called with a second argument containing all the props, allowing to validate the value against other props.

defineProps({
  min: {
    type: Number,
    required: true,
    validator: (value) => value >= 0,
  },
  max: {
    type: Number,
    required: true,
    validator: (value, props) => value >= props.min,
  }
})

Then if you try to use the component with max being lower than min, you will get a warning.

Invalid prop: custom validator check failed for prop "max".

SSR hydration mismatch warnings

When using SSR, the client-side hydration will now warn you with a message that includes the mismatching element. It was sometimes hard to find the mismatching element in the DOM, as the warning was in v3.3:

[Vue warn]: Hydration completed but contains mismatches.

In v3.4, the warning now contains the actual element (not only its tag name but the actual DOM element, so you can click on it), allowing us to see where it is in the DOM and why it failed.

[Vue warn]: Hydration text content mismatch in <h2>:
- Server rendered: Hello server
- Client rendered: Hello client

Vue now also warns you if you have a mismatch in classes, styles, or attributes!

You can enable this feature in production as well by using a feature flag in your Vite config called __VUE_PROD_HYDRATION_MISMATCH_DETAILS__:

export default defineConfig({
  plugins: [vue()],
  define: {
    __VUE_PROD_HYDRATION_MISMATCH_DETAILS__: true 
  }
});

MathML support

It is now possible to write templates using MathML (in addition to HTML and SVG)!

The template below displays a beautiful x²:

<template>
  <math>
    <mrow><msup><mi>x</mi><mn>2</mn></msup></mrow>
  </math>
</template>

defineModel

The defineModel function was introduced as an experimental API in v3.3, is now a stable API. It is now the recommended way to define custom v-models.

Compared to what we explained in our previous blog post, the local option has been removed (see this discussion if you want to know why). The model now automatically adapts based on whether the parent provides a v-model or not.

Another change it that it is now possible to handle modifiers. For example, if you want to handle the .number modifier, you can do:

const [count, countModifiers] = defineModel({
  set(value) {
    if (countModifiers?.number) {
      return Number(value);
    }
    return value;
  }
});
console.log(countModifiers?.number); // true if the .number modifier is used

You can type the modifiers by using defineModel<number, 'number'>({ ... }). The first type parameter is the type of the model value, and the second one is the type of the modifiers (which can be a union type if you want to handle several ones).

You can play with this demo to see how it works.

TypeScript improvements

An effort has been made to sanitize the types (which will be helpful for all libraries in the ecosystem).

A notable improvement for developers is that app.directive, used to register global directives, can now be properly typed:

app.directive<HTMLElement, string>('custom', {
  mounted(el, binding) {
    // el is correctly typed as HTMLElement
    // binding is correctly typed as string
  }
})

Deprecated features removed

The reactivity transform experiment has been removed. It had been deprecated in v3.3.0 (see our previous blog post).

Vnode hook events written like vnodeMounted have been deprecated in v3.3 (see our previous blog post) and they are now no longer supported. You should use the @vue: syntax instead, like @vue:mounted.

The v-is directive has also been removed.

News from the ecosystem

Vue 2 End of Life

Vue 2 has reached its end of life, and Evan wrote a blog post about it:

👉 https://blog.vuejs.org/posts/vue-2-eol

Vapor mode

Vapor (@vue/vapor) is making progress with a new repository.

For now, it introduces two work-in-progress packages: a new compiler and a new runtime. They only support the most basic features at the moment, and aren't easily usable. There is a playground in the repository if you want to try it out.

The biggest difference with Vue 3 is that Vapor generates a rendering function that does not rely on virtual DOM.

For example, the following component:

<script setup lang="ts">
import { ref, computed } from 'vue/vapor'

const count = ref(1)
const double = computed(() => count.value * 2)

const inc = () => count.value++
</script>

<template>
  <div>
    <h1 class="red">Counter</h1>
    <div>{{ count }} * 2 = {{ double }}</div>
    <button @click="inc">inc</button>
  </div>
</template>

generates the following render function:

function _sfc_render(_ctx) {
  const t0 = _template('<div><h1 class="red">Counter</h1><div> * 2 = </div><button>inc</button></div>');
  const n0 = t0();
  const { 0: [, { 1: [n3], 2: [n4] }] } = _children(n0);
  const n1 = _createTextNode(_ctx.count);
  const n2 = _createTextNode(_ctx.double);
  _prepend(n3, n1);
  _append(n3, n2);
  _on(n4, "click", (...args) => _ctx.inc && _ctx.inc(...args));
  _watchEffect(() => {
    _setText(n1, void 0, _ctx.count);
  });
  _watchEffect(() => {
    _setText(n2, void 0, _ctx.double);
  });
  return n0;
}

As you can see the render function is using a different strategy than Vue 3: it creates the static elements, then it creates the dynamic elements, and finally it updates the dynamic elements when needed using watchEffect.

You can check in the project's README the features that are supported and the ones that are not.

Vue Test Utils

VTU should now have better type-checking support for TypeScript users. For example wrapper.setProps({ foo: 'bar' }) will now correctly error if the component has no foo prop.

create-vue

create-vue now generates projects using Vite v5, which was recently released.

Nuxt

Nuxt v3.9 is out as well, with the support of Vue 3.4. It brings a lot of new features and experiments: you can read more in the official blog post.

That's all for this release. Stay tuned for the next one!

Our ebook, online training and training are up-to-date with these changes if you want to learn more!

What's new in Angular 17?

2023-11-09T00:00:00Z

Angular v17 is here!

For French-speaking people, I talked about the release on the Angular Devs France YouTube channel.

This is a major release packed with features: let's dive in!

angular.dev

The Angular team has been cranking it communication-wise lately, with a live event to unveil the new features of Angular v17, and a new website called angular.dev, which will be the future official website. It features the same documentation but with a new interactive tutorial, and a playground to try Angular without installing anything (as Vue or Svelte do as well).

Angular also has a new logo that you can see at the top of this post!

Control flow syntax

Even if it is only a "developer preview" feature, this is a big one! Angular templates are evolving to use a new syntax for control flow structures.

We wrote a dedicated blog post about this feature:

👉 Angular Control Flow Syntax

An experimental migration allows you to give it a try in your project. The syntax should become stable in v18, and be the recommended way to write templates at that point.

Deferrable views

Another big feature is the introduction of deferrable views using @defer in templates.

We wrote a dedicated blog post about this feature:

👉 Angular Deferrable Views

This is a "developer preview" feature as well and should become stable in v18. It's probably going to be less impactful than the control flow syntax, but it's still interesting to have a way to easily lazy-load parts of a template.

Signals are now stable!

The Signals API is now marked as stable 🎉. Except effect(), and the RxJS interoperability functions toSignal and toObservable which might change and are still marked as "developer preview".

The API has not changed much since our blog post about Signals, but some notable things happened.

mutate has been dropped

mutate() has been dropped from the API. You were previously able to write something like:

users.mutate(usersArray => usersArray.push(newUser));

And you'll now have to write:

users.update(usersArray => [...usersArray, newUser]);

The mutate() method was introducing some issues with other libraries, and was not worth the trouble as it can be replaced by update() quite easily.

template diagnostic

A new compiler diagnostic is available to help you spot missing signal invocations in your templates.

Let's say you have a count signal used in a template, but forgot the ():

<div>{{ count }}</div>

throws with:

NG8109: count is a function and should be invoked: count()

flushEffects

A new method is available (as a developer preview) on the TestBed class to trigger pending effects: flushEffects

TestBed.flushEffects();

This is because effect timing has changed a bit: they are no longer triggered by change detection but scheduled via the microtask queue (like setTimeout() or Promise.resolve()). So while you could previously trigger them by calling detectChanges() on the fixture, you now have to call TestBed.flushEffects().

afterRender and afterNextRender phases

The afterRender and afterNextRender functions introduced in Angular v16.2 can now specify a phase option. Angular uses this phase to schedule callbacks to improve performance. There are 4 possible values, and they run in the following order:

EarlyRead (when you need to read the DOM before writing to the DOM)
Write (needed if you want to write to the DOM, for example, to initialize a chart using a third-party library)
MixedReadWrite (default, but should be avoided if possible to use a more specific phase)
Read (recommended if you only need to read the DOM)

I think we should be able to use Read and Write in most cases. EarlyRead and MixedReadWrite degrade performances, so they should be avoided if possible.

export class ChartComponent {
  @ViewChild('canvas') canvas!: ElementRef<HTMLCanvasElement>;

  constructor() {
    afterNextRender(() => {
      const ctx = this.canvas.nativeElement;
      new Chart(ctx, { type: 'line', data: { ... } });
    }, { phase: AfterRenderPhase.Write });
  }
}

Performances

The internal algorithm changed to use a ref-counting mechanism instead of a mechanism based on bi-directional weak references. It should be more performant than it was in many cases.

It's also worth noting that the change detection algorithm has been improved to be more efficient when using Signals. Previously, when reading a signal in a template, Angular was marking the component and all its ancestors as dirty when the signal was updated (as it currently does with when OnPush components are marked for check). It's now a bit smarter and only marks the component as dirty when the signal is updated and not all its ancestors. It will still check the whole application tree, but the algorithm will be faster because some components will be skipped.

We don't have a way to write pure signal-based components yet, with no need for ZoneJS, but it should be coming eventually!

styleUrls as a string

The styleUrls and styles properties of the @Component decorator can now be a string instead of an array of strings. A new property called styleUrl has also been introduced.

You can now write:

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

View Transitions router support

The View Transitions API is a fairly new browser API that allows you to animate the transition between two views. It is only supported in recent versions of Chrome, Edge, and Opera (see caniuse.com stats) but not in Firefox yet. It works by taking a screenshot of the current view and animating it to the new view.

I'm not very familiar with this API, but there is a great article about it on developer.chrome.com and cool demos on this site (open it with a browser that supports this API of course).

Angular v17 adds support for this API in the router. This is an experimental feature, and you'll have to enable it by using withTransitionViews():

bootstrapApplication(AppComponent, { 
  providers: [{ provideRouter(routes, withTransitionViews()) }] 
});

By default, you get a nice fade-in/fade-out transition between views when navigating from one route to another. You can customize the animation using CSS, animate the whole view or skip part of it, or indicate which DOM elements are in fact the same entities in the old and new views: the browser will then do its best to animate between the states.

It is possible to skip the initial transition by using the skipInitialTransition option:

bootstrapApplication(AppComponent, { 
  providers: [{ provideRouter(routes, withTransitionViews({ skipInitialTransition: true })) }] 
});

More advanced scenarios require to add/remove CSS classes to the views, so the router also lets you run an arbitrary function when the transition is done if you use the onViewTransitionCreated option to define a callback.

Http

The fetch backend (introduced in Angular v16.1) has been promoted to stable.

When using SSR, it is now possible to customize the transfer cache, using withHttpTransferCacheOptions(options). The options can be:

filter: a function to filter the requests that should be cached
includeHeaders: the list of headers to include (none by default)
includePostRequests: whether or not to cache POST requests (by default only GET and HEAD requests are cached)

For example:

bootstrapApplication(AppComponent, { 
  providers: [provideHttpClient({
    withHttpTransferCacheOptions({ includePostRequests: true })
  })
});

Devtools

The devtools received some love as well, and they now allow you to inspect the dependency injection tree.

Animations

No new feature for this part of Angular, but it is now possible to lazy-load the animations package. In a standalone application, you can use provideAnimationsAsync() instead of using provideAnimations() and the necessary code for animations will be loaded asynchronously.

The application should work the same, but you should see an extra chunk appear when building the application. That's a few kilobytes of JavaScript that you don't have to load upfront 🚀.

You can disable animations by providing 'noop' as the value of provideAnimationsAsync():

bootstrapApplication(AppComponent, { 
  providers: [provideAnimationsAsync('noop')] 
});

Performances

In dev mode, you'll now get a warning if you load an oversized image or if an image is the "Largest Contentful Paint element" in the page and is lazy-loaded (which is a bad idea, see the explanations here).

For example:

An image with src image.png has intrinsic file dimensions much larger than its 
rendered size. This can negatively impact application loading performance. 
For more information about addressing or disabling this warning, see  
https://angular.io/errors/NG0913

You can configure this behavior via dependency injection, for example, if you want to turn off these warnings:

{
  provide: IMAGE_CONFIG, useValue:
  {
    disableImageSizeWarning: false,
    disableImageLazyLoadWarning: false
  }
}

TypeScript 5.2 and Node.js v18

It's worth noting that Angular now requires TypeScript 5.2 and Node.js v18. Support for older versions has been dropped.

Angular CLI

A lot happened in the CLI!

👉 Check out our dedicated blog post about the CLI v17 for more details.

Summary

That's all for this release, stay tuned!

All our materials (ebook, online training and training) are up-to-date with these changes if you want to learn more!

What's new in Angular CLI 17.0?

2023-11-09T00:00:00Z

Angular CLI 17.0.0 is out!✨

If you want to upgrade to 17.0.0 without pain (or to any other version, by the way), I have created a Github project to help: angular-cli-diff. Choose the version you're currently using (16.2.0 for example), and the target version (17.0.0 for example), and it gives you a diff of all files created by the CLI: angular-cli-diff/compare/16.2.0...17.0.0. It can be a great help along with the official ng update @angular/core @angular/cli command. You have no excuse for staying behind anymore!

Let's see what we've got in this release.

Standalone applications with Vite by default!

The --standalone flag is now the default behavior of the CLI. This means generating a new project with ng new now uses standalone components by default, and that the ng generate component/pipe/directive command now generates standalone components/pipes/directives.

Another notable change to ng new is that the routing is now enabled by default.

But the most important change is that the CLI now uses Vite out-of-the-box! A new builder called application has been introduced, and is used when generating a new project. This builder has a very similar configuration to the browser builder, so the migration is quite easy if you want to use Vite in an existing project You have to change the builder from browser to application in the angular.json file, rename the main property to browser, and remove a few options from the development configuration (buildOptimizer, vendorChunk).

Once migrated, the ng serve command will use Vite instead of Webpack. Build time should be faster, especially for cold starts (I saw 2-3x times improvement on my machine). There is no HMR by default yet, but the global style changes are detected and applied automatically without reloading the page.

Note that the output of the ng build Vite-based command is now in dist/my-project/browser instead of dist/my-project.

The browser-esbuilder builder still exists, but will be removed in the future. You should use the application builder instead.

ng new --ssr

A new flag --ssr has been added to the ng new command to generate a new project with SSR enabled out of the box.

It generates a project similar to what you usually get and then runs the @angular/ssr schematics (you can also use the schematics directly on an existing project with ng add @angular/ssr). @angular/ssr is a new package and replaces the Angular Universal package. If you were using the Angular Universal package, ng update migrates your configuration to use @angular/ssr automatically.

This schematic does the following:

adds the @angular/ssr package
adds the @angular/platform-server package
adds the express and @types/express packages
adds the main.server.ts file (entry point for the application when running on the server)
adds the app.config.server.ts file (providers for the application when running on the server)
adds the tsconfig.server.json file
adds the server.ts file (the Express server, responsible for serving the application)

It updates the angular.json configuration to add the following options to the build target:

"server": "src/main.server.ts",
"prerender": true,
"ssr": {
  "entry": "server.ts"
}

and adds the provideClientHydration() to the (browser) application providers, to have a smooth transition between the server and the client. This is a new feature of Angular v16, and we talked about it in our article about the v16 release.

When running ng build, the CLI will now build the server bundle (in dist/my-project/server) and the client bundle (in dist/my-project/browser). You can then run the generated server with:

node dist/my-project/server/main.server.mjs

This starts an Express server on port 4000 by default, which serves the rendered pages.

The rendered pages are in the browser folder, and are named ${page}/index.html:

dist/my-project/browser/index.html
dist/my-project/browser/login/index.html
dist/my-project/browser/register/index.html

If you use localize in your application, the CLI will also build the localized bundles (in dist/my-project/server/${lang}).

The prerendering mechanism should be quite accurate now, as it uses the Angular router under the hood to navigate to each route and render it (routes with parameters or redirections are skipped). When prerendering is enabled, the CLI generates a prerendered-routes.json file that contains all the prerendered routes. This is useful if you deploy on the cloud as this file is usually recognized by providers to serve these files as static.

{
  "routes": [
    "/",
    "/login",
    "/register"
    ...
  ]
}

You can disable the auto-discovery of routes by setting the discoverRoutes option to false in the angular.json file. You can also provide your own list of routes in this file by defining routeFiles:

"ssr": {
  "discoverRoutes": false,
  "routeFiles": "ssg-routes.txt"
}

This file must contain a list of routes that you want to render (and can contain parameterized routes).

When running ng serve, the CLI serves the application via Vite, and only pre-renders the requested page (the one you're currently on).

You can also use a new option to CommonEngine called enablePerformanceProfiler to trace the performance of each step of the rendering:

const commonEngine = new CommonEngine({
  enablePerformanceProfiler: true
});

When using SSR, it is recommended to use the Fetch version of the HTTP client, by using provideHttpClient(withFetch()) (as introduced in Angular v16.1). This is for performance and compatibility reasons.

NG02801: Angular detected that `HttpClient` is not configured to use `fetch` APIs. It's strongly recommended to enable `fetch` for applications that use Server-Side Rendering for better performance and compatibility. To enable `fetch`, add the `withFetch()` to the `provideHttpClient()` call at the root of the application.

Functional HTTP interceptors by default

The CLI now generates functional interceptors by default, without the need to specify --functional anymore. Class-based interceptors are still available with the --no-functional option, but you're now encouraged to use the functional ones.

Summary

That's all for the CLI v17.0 release! You'll find more interesting features in our article about the framework v17.0.0 release.

All our materials (ebook, online training and training) are up-to-date with these changes if you want to learn more!

A guide to Angular Deferrable Views with @defer

2023-11-02T00:00:00Z

With the introduction of the Control flow syntax, the Angular team has also introduced a new way to load components lazily (as a developer preview for now). We already have lazy-loading in Angular, but it is mainly based on the router.

Angular v17 adds a new way to load components lazily, using the @defer syntax in your templates.

@defer lets you define a block of template that will be loaded lazily when a condition is met (with all the components, pipes, directives, and libraries used in this block lazily loaded as well). Several conditions can be used. For example, it can be "as soon as possible (no condition)", "when the user scrolls to that section", "when the user clicks on that button" or "after 2 seconds".

Let's say your home page displays a "heavy" ChartComponent that uses a charting library and some other dependencies, like a FromNow pipe:

@Component({
  selector: 'ns-chart',
  template: '...',
  standalone: true,
  imports: [FromNowPipe],
})
export class ChartComponent {
  // uses chart.js
}

This component is used in the home page:

import { ChartComponent } from './chart.component';

@Component({
  selector: 'ns-home',
  template: `
    <!-- some content -->
    <ns-chart />
  `,
  standalone: true,
  imports: [ChartComponent]
})
export class HomeComponent {
  // ...
}

When the application is packaged, the ChartComponent will be included in the main bundle:

+------------------------+
| main-xxxx.js  -  300KB |
+------------------------+
| home.component.ts      |
| chart.component.ts     |
| from-now.pipe.ts       |
| chart.js               |
+------------------------+

Let's say that the component is not visible at first on the home page, maybe because it is at the bottom of the page, or because it is in a tab that is not active. It makes sense to avoid loading this component eagerly because it would slow down the initial loading of the page.

With @defer, you can load this component only when the user really needs it. Just wrapping the ChartComponent in a @defer block will do the trick:

import { ChartComponent } from './chart.component';

@Component({
  selector: 'ns-home',
  template: `
    <!-- some content -->
    @defer (when isVisible) {
      <ns-chart />
    }
  `,
  standalone: true,
  imports: [ChartComponent]
})

The Angular compiler will rewrite the static import of the ChartComponent to a dynamic import (() => import('./chart.component')), and the component will be loaded only when the condition is met. As the component is now imported dynamically, it will not be included in the main bundle. The bundler will create a new chunk for it:

+------------------------+
| main-xxxx.js  -  100KB |
+------------------------+       +-------------------------+
| home.component.ts      |------>| chunk-xxxx.js - 200KB   |
+------------------------+       +-------------------------+
                                 | chart.component.ts      |
                                 | from-now.pipe.ts        |
                                 | chart.js                |
                                 +-------------------------+

The chunk-xxxx.js file will only be loaded when the condition is met, and the ChartComponent will be displayed.

Before talking about the various kinds of conditions that can be used with @defer, let's see how to use another interesting feature: displaying a placeholder until the deferred block is loaded.

`@placeholder`, `@loading`, and `@error`

You can define a placeholder template with @placeholder that will be displayed until the loading condition is met. Then, while the block is loading, you can display a loading template with @loading. If no @loading block is defined, the placeholder stays there until the block is loaded. You can also define an error template with @error that will be displayed if the block fails to load.

@defer (when show) {
  <ns-chart />
}
@placeholder {
  <div>Something until the loading starts</div>
}
@loading {
  <div>Loading...</div>
}
@error {
  <div>Something went wrong</div>
}

When using server-side rendering, only the placeholder will be rendered on the server (the defer conditions will never trigger).

`after` and `minimum`

As the @defer block loading can be quite fast, there is a risk that the loading block is displayed and hidden too quickly, causing a "flickering" effect.

To avoid this, you can use the after option to specify after how many milliseconds the loading should be displayed.

If the block takes less than this delay to load, then the @loading block is never displayed.

You can also use the minimum option to specify a minimum duration for the loading. If the loading is faster than the minimum duration, then the loading will be displayed for the minimum duration (this only applies if the loading is ever displayed).

You can of course combine all these options:

@defer (when show) {
  <ns-chart />
}
@placeholder {
  <div>Something until the loading starts</div>
}
@loading (after 500ms; minimum 500ms) {
  <div>Loading...</div>
}

You can also specify a minimum duration for the placeholder. It can be useful when the loading condition is immediate (for example, when no condition is specified). In that case, the placeholder will be displayed for the minimum duration, even if the block is loaded immediately, to avoid a "flickering" effect.

@defer (when show) {
  <ns-chart />
}
@placeholder (minimum 500ms) {
  <div>Something until the loading starts</div>
}
@loading (after 500ms; minimum 500ms) {
  <div>Loading...</div>
}

Conditions

Several conditions can be used with @defer, let's see them one by one.

No condition or `on idle`

The simplest condition is to not specify any condition at all: in this case, the block will be loaded when the browser is idle (the loading is scheduled using requestIdleCallback).

@defer {
  <ns-chart />
}

This is equivalent to using the on idle condition:

@defer (on idle) {
  <ns-chart />
}

Simple boolean condition with `when`

You can also use a boolean condition to load a block of the template with when. Here, we display the defer block only when the show property of the component is true:

@defer (when show) {
  <ns-chart />
}

Note that this is not the same as using *ngIf on the block, as the block will not be removed even if the condition becomes false later.

on `immediate`

The on immediate condition triggers the loading of the block immediately. It does not display a placeholder, even if one is defined.

on `timer`

The on timer condition triggers the loading of the block after a given duration, using setTimeout under the hood.

@defer (on timer(2s)) {
  <ns-chart />
}

on `hover`

Other conditions are based on user interactions. These conditions can specify the element of the interaction using a template reference variable, or none to use the placeholder element. In the latter case, the placeholder element must exist and have a single child element that will be used as the element of the interaction.

The on hover condition triggers the loading of the block when the user hovers the element. Under the hood, it listens to the mouseenter and focusin events.

<span #trigger>Hover me</span>

@defer (on hover(trigger)) {
  <ns-chart />
}

or using the placeholder element:

@defer (on hover) {
  <ns-chart />
}
@placeholder {
  <span>Hover me</span>
}

on `interaction`

The on interaction condition triggers the loading of the block when the user interacts with the element. Under the hood, it listens to the click and keydown events.

on `viewport`

The on viewport condition triggers the loading of the block when the element becomes visible in the viewport. Under the hood, it uses an intersection observer.

Multiple conditions

You can also combine multiple conditions using a comma-separated list:

<!-- Loads if the user hovers the placeholder, or after 1 minute -->
@defer (on hover, timer(60s)) {
  <ns-chart />
}
@placeholder {
  <span>Something until the loading starts</span>
}

Prefetching

@defer allows you to separate the loading of a component from its display. You can use the same conditions we previously saw to load a component using prefetch, and then display it with another condition.

For example, you can prefetch the lazy-loaded content on idle and then display it on interaction:

@defer (on interaction; prefetch on idle) {
  <ns-chart />
}
@placeholder {
  <button>Show me</button>
}

Note that the @loading block will not be displayed if the deferred block is already prefetched when the loading condition is met.

How to test deferred loading?

When a component uses defer blocks in its template, you'll have to do some extra work to test it.

The TestBed API has been extended to help you with that. The configureTestingModule method now accepts a deferBlockBehavior option. By default, this option is set to DeferBlockBehavior.Manual, which means that you'll have to manually trigger the display of the defer blocks. But let's start with the other option instead.

You can change this behavior by using DeferBlockBehavior.Playthrough. Playthrough means that the defer blocks will be displayed automatically when a condition is met, as they would when the application runs in the browser.

beforeEach(() => {
  TestBed.configureTestingModule({
    deferBlockBehavior: DeferBlockBehavior.Playthrough
  });
});

In that case, the defer blocks will be displayed automatically when a condition is met, after calling await fixture.whenStable().

So if we test a component with a deferred block that is visible after clicking on a button, we can use:

// Click the button to trigger the deferred block
fixture.nativeElement.querySelector('button').click();
fixture.detectChanges();

// Wait for the deferred block to render
await fixture.whenStable();

// Check its content
const loadedBlock = fixture.nativeElement.querySelector('div');
expect(loadedBlock.textContent).toContain('Some lazy-loaded content');

If you want to use the DeferBlockBehavior.Manual behavior, you'll have to manually trigger the display of the defer blocks. To do so, the fixture returned by TestBed.createComponent now has an async getDeferBlocks method that returns an array of DeferBlockFixture objects. Each of these fixtures has a render method that you can call to display the block in a specific state, by providing a DeferBlockState parameter.

DeferBlockState is an enum with the following values:

DeferBlockState.Placeholder: display the placeholder state of the block
DeferBlockState.Loading: display the loading state of the block
DeferBlockState.Error: display the error state of the block
DeferBlockState.Complete: display the defer block as if the loading was complete

This allows a fine-grained control of the state of the defer blocks. If we want to test the same component as before, we can do:

const deferBlocks = await fixture.getDeferBlocks();
// only one defer block should be found
expect(deferBlocks.length).toBe(1);

// Render the defer block
await deferBlocks[0].render(DeferBlockState.Complete);

// Check its content
const loadedBlock = fixture.nativeElement.querySelector('div');
expect(loadedBlock.textContent).toContain('Some lazy-loaded content');

All our materials (ebook, online training and training) are up-to-date with these changes if you want to learn more!

Angular templates got better - the Control Flow syntax

2023-10-11T00:00:00Z

Angular v17 introduces a new "developer preview" feature called "control flow syntax". This feature allows you to use a new template syntax to write control flow statements, like if/else, for, and switch, instead of using the built-in structural directives (*ngIf, *ngFor, and *ngSwitch).

To understand why this was introduced, let's see how structural directives work in Angular.

Structural directives under the hood

Structural directives are directives that change the structure of the DOM by adding, removing, or manipulating elements. They are easy to recognize in Angular because they begin with an asterisk *.

But how do they really work?

Let's take a simple template with ngIf and ngFor directives as an example:

<h1>Ninja Squad</h1>
<ul *ngIf="condition">
  <li *ngFor="let user of users">{{ user.name }}</li>
</ul>

If you read the chapter of our ebook about the Angular compiler, you know that the framework generates JavaScript code from this template. And maybe you imagine that *ngIf gets converted to a JavaScript if and *ngFor to a for loop like:

createElement('h1');
if (condition) {
  createElement('ul');
  for (user of users) {
    createElement('li');
  }
}

But Angular does not work exactly like that: the framework decomposes the component's template into "views". A view is a fragment of the template that has static HTML content. It can have dynamic attributes and texts, but the HTML elements are stable.

So our example generates in fact three views, corresponding to three parts of the template:

Main view:

    <h1>Ninja Squad</h1>
    <!-- special comment -->

NgIf view:

<ul>
  <!-- special comment -->
</ul>

NgFor view:

<li>{{ user.name }}</li>

This is because the * syntax is in fact syntactic sugar to apply an attribute directive on an ng-template element. So our example is the same as:

<h1>Ninja Squad</h1>
<ng-template [ngIf]="condition">
<ul>
  <ng-template ngFor [ngForOf]="users" let-user>
    <li>{{ user.name }}</li>
  </ng-template>
</ul>
</ng-template>

Here ngIf and ngFor are plain directives. Each ng-template then generates a "view". Each view has a static structure that never changes. But these views need to be dynamically inserted at some point. And that's where the  comes into play.

Angular has the concept of ViewContainer. A ViewContainer is like a box where you can insert/remove child views. To mark the location of these containers, Angular uses a special HTML comment in the created DOM.

That's what ngIf actually does under the hood: it creates a ViewContainer, and then, when the condition given as input changes, it inserts or removes the child view at the location of the special comment.

This view concept is quite interesting as it will allow Angular to only update views that consume a signal in the future, and not the whole template of a component! Check out out our blog post about the Signal API for more details.

Custom structural directives

You can create your own structural directives if you want to. Let's say you want to write a *customNgIf directive. You can create a directive that takes a condition as an input and injects a ViewContainerRef (the service that allows to create the view) and a TemplateRef (the ng-template on which the directive is applied).

import { Directive, DoCheck, EmbeddedViewRef, Input, TemplateRef, ViewContainerRef } from '@angular/core';

@Directive({
  selector: '[customNgIf]',
  standalone: true
})
export class CustomNgIfDirective implements DoCheck {
  /**
   * The condition to check
   */
  @Input({ required: true, alias: 'customNgIf' }) condition!: boolean;

  /**
   * The view created by the directive
   */
  conditionalView: EmbeddedViewRef<any> | null = null;

  constructor(
    /**
     * The container where the view will be inserted
     */
    private vcr: ViewContainerRef,
    /**
     * The template to render
     */
    private tpl: TemplateRef<any>
  ) {}

  /**
   * This method is called every time the change detection runs
   */
  ngDoCheck() {
    // if the condition is true and the view is not created yet
    if (this.condition && !this.conditionalView) {
      // create the view and insert it in the container
      this.conditionalView = this.vcr.createEmbeddedView(this.tpl);
    } else if (!this.condition && this.conditionalView) {
      // if the condition is false and the view is created
      // destroy the view
      this.conditionalView.destroy();
      this.conditionalView = null;
    }
  }
}

This works great! And as you can see, it lets developers like us create powerful structural directives if we want to: the built-in directives offered by Angular are not special in any way.

But this approach has some drawbacks: for example, it is a bit clunky to have an else alternative with *ngIf:

<div *ngIf="condition; else elseBlock">If</div>
<ng-template #elseBlock><div>Else</div></ng-template>

elseBlock is another input of the NgIf directive, of type TemplateRef, that the directive will display if the condition is falsy. But this is not very intuitive to use, so we often see this instead:

<div *ngIf="condition">If</div>
<div *ngIf="!condition">Else</div>

The structural directives are also not perfect type-checking-wise. Even if Angular does some magic (with some special fields called ngTemplateGuard in the directives to help the type-checker), some cases are too tricky to handle. For example, the "else" alternative of *ngIf is not type-checked:

<div *ngIf="!user; else userNotNullBlock">No user</div>
<ng-template #userNotNullBlock>
  <div>
    <!-- should compile as user is not null here -->
    <!-- but it doesn't -->
    {{ user.name }}
  </div>
</ng-template>

NgSwitch is even worse, as it consists of 3 separate directives NgSwitch, NgSwitchCase, and NgSwitchDefault. The compiler has no idea if the NgSwitchCase is used in the right context.

<!-- user.type can be `'user' | 'anonymous'` -->
<ng-container [ngSwitch]="user.type">
  <div *ngSwitchCase="'user'">User</div>
  <!-- compiles even if user.type can't be 'admin' -->
  <div *ngSwitchCase="'admin'">Admin</div>
  <div *ngSwitchDefault>Unknown</div>
</ng-container>

It's also worth noting that the * syntax is not very intuitive for beginners. And structural directives depend on the ngDoCheck lifecycle hook, which is tied to zone.js. In a future world where our components use the new Signal API and don't need zone.js anymore, structural directives would still force us to drag zone.js in our bundle.

So, to sum up, structural directives are powerful but have some drawbacks. Fixing these drawbacks would require a lot of work in the compiler and the framework.

That's why the Angular team decided to introduce a new syntax to write control flow statements in templates!

Control flow syntax

The control flow syntax is a new syntax introduced in Angular v17 to write control flow statements in templates.

The syntax is very similar to some other templating syntaxes you may have met in the past, and even to JavaScript itself. There have been some debates and polling in the community about the various alternatives, and the @-syntax proposal won.

With the control flow syntax, our previous template with *ngIf and *ngFor can be rewritten as:

<h1>Ninja Squad</h1>
@if (condition) {
  <ul>
    @for (user of users; track user.id) {
      <li>{{ user.name }}</li>
    }
  </ul>
}

This syntax is interpreted by the Angular compiler and creates the same views as the previous template, but without the overhead of creating the structural directives, so it is also a tiny bit more performant (as it uses brand new compiled instructions under the hood in the generated code). As this is not directives, the type-checking is also much better.

And, cherry on the cake, the syntax is more powerful than the structural directives!

The drawback is that this syntax uses @, { and } characters with a special meaning, so you can't use these characters in your templates anymore, and have to use equivalent HTML entities instead (\@ for @, \{ for {, and \} for }).

If statement

As we saw above, a limitation of NgIf is that it is a bit clunky to have an else alternative. And we can't have an else if alternative at all.

That's no longer a problem with the control flow syntax:

@if (condition) {
  <div>condition is true</div>
} @else if (otherCondition) {
  <div>otherCondition is true</div>
} @else {
  <div>condition and otherCondition are false</div>
}

You can still store the result of the condition in a variable if you want to, which is really handy when used with an async pipe for example:

@if (user$ | async; as user) {
  <div>User is {{ user.name }}</div>
} @else if (isAdmin$ | async) {
  <div>User is admin</div>
} @else {
  <div>No user</div>
}

For statement

With the control flow syntax, a for loop needs to specify a track property, which is the equivalent of the trackBy function of *ngFor. Note that this is now mandatory, whereas it was optional with *ngFor. This is for performance reasons, as the Angular team found that very often, developers were not using trackBy when they should have.

<ul>
  @for (user of users; track user.id) {
    <li>{{ user.name }}</li>
  }
</ul>

As you can see, this is a bit easier to use than the trackBy function of *ngFor which requires to write a function. Here we can directly specify the property of the item that is unique, and the compiler will generate the function for us. If you don't have a unique property, you can still use a function or just use the loop variable itself (which is equivalent to what *ngFor currently does when no trackBy is specified).

One of the very useful additions to the control flow syntax is the handling of empty collections. Previously you had to use an *ngIf to display a message if the collection was null or empty and then use *ngFor to iterate over the collection.

With the control flow syntax, you can do it with an @empty clause:

<ul>
  @for (user of users; track user.id) {
    <li>{{ user.name }}</li>
  } @empty {
    <li>No users</li>
  }
</ul>

We can still access the variables we used to have with *ngFor:

$index to get the index of the current item
$first to know if the current item is the first one
$last to know if the current item is the last one
$even to know if the current item is at an even index
$odd to know if the current item is at an odd index
$count to get the length of the collection

Unlike with *ngFor, you don't have to alias these variables to use them, but you still can if you need to, for example when using nested loops.

<ul>
  @for (user of users; track user.id; let isOdd = $odd) {
    <li [class.grey]="isOdd">{{ $index }} - {{ user.name }}</li>
  }
</ul>

It is also worth noting that the control flow @for uses a new algorithm under the hood to update the DOM when the collection changes. It should be quite a bit faster than the algorithm used by *ngFor, as it does not allocate intermediate maps in most cases. Combined with the required track property, for loops should be way faster in Angular applications by default.

Switch statement

This is probably where the new type-checking shines the most, as using an impossible value in a case will now throw a compilation error!

@switch (user.type) {
  @case ('user') {
    <div>User</div>
  } @case ('anonymous') {
    <div>Anonymous</div>
  } @default {
    <div>Other</div>
  }
}

Note that the switch statement does not support fall-through, so you can't have several cases grouped together. It also does not check if all cases are covered, so you won't get a compilation error if you forget a case. (but I hope it will, add a 👍 on this issue if you want this as well!).

It's also noteworthy that the @switch statement uses strict equality (===) to compare values, whereas *ngSwitch used to use loose equality (==). Angular v17 introduced a breaking change, and *ngSwitch now uses strict equality too, with a warning in the console during development if you use loose equality:

NG02001: As of Angular v17 the NgSwitch directive 
uses strict equality comparison === instead of == to match different cases. 
Previously the case value "1" matched switch expression value "'1'", 
but this is no longer the case with the stricter equality check.
Your comparison results return different results using === vs. ==
and you should adjust your ngSwitch expression and / or values
to conform with the strict equality requirements.

The future of templating 🚀

The control flow syntax is a new "developer preview" feature introduced in Angular v17, and will probably be the recommended way to write templates in the future (the plan is to make it stable in v18 once it has been battle-tested).

It doesn't mean that structural directives will be deprecated, but the Angular team will likely focus on the control flow syntax in the future and push them forward as the recommended solution.

We will even have an automated migration to convert structural directives to control flow statements in existing applications. The migration is available in Angular v17 as a developer preview. If you want to give it a try, run:

ng g @angular/core:control-flow

This automatically migrates all your templates to the new syntax! You can also run the migration against a single file with the --path option:

ng g @angular/core:control-flow --path src/app/app.component.html

Even though the new control flow is experimental, v17 comes with a mandatory migration needed to support this new control flow syntax, which consists in converting the @, { and } characters used in your templates to their HTML entities. This migration is run automatically when you update the app with ng update.

The future of Angular is exciting!

All our materials (ebook, online training and training) are up-to-date with these changes if you want to learn more!

What's new in Angular 16.2?

2023-08-09T00:00:00Z

Angular 16.2.0 is here!

This is a minor release with some nice features: let's dive in!

Binding inputs of NgComponentOutlet

It used to be cumbersome to pass input data to a dynamic component (you could do it, but you needed to use a provider and inject it). It's now way easier:

@Component({
  selector: 'app-user',
  standalone: true,
  template: '{{ name }}'
})
export class UserComponent {
  @Input({ required: true }) name!: string;
}

Then to dynamically insert the component with inputs:

@Component({
  selector: 'app-root',
  standalone: true,
  imports: [NgComponentOutlet],
  template: '<div *ngComponentOutlet="userComponent; inputs: userData"></div>'
})
class AppComponent {
  userComponent = UserComponent;
  userData = { name: 'Cédric' }
}

afterRender and afterNextRender

The afterRender and afterNextRender lifecycle hooks have been added to the framework as developer preview APIs. They are parts of the Signal API, see the RFC discussion.

They allow to run code after the component has been rendered the first time (afterNextRender), or after every render (afterRender).

The first one is useful to run code that needs to access the DOM, like calling a third-party library like we currently do in ngAfterViewInit. But, unlike ngAfterViewInit and other lifecycle methods, these hooks do not run during server-side rendering, which makes them easier to use for SSR applications.

You can now write:

import { Component, ElementRef, ViewChild, afterNextRender } from '@angular/core';

@Component({
  selector: 'app-chart',
  standalone: true,
  template: '<canvas #canvas></canvas>'
})
export class ChartComponent {
  @ViewChild('canvas') canvas!: ElementRef<HTMLCanvasElement>;

  constructor() {
    afterNextRender(() => {
      const ctx = this.canvas.nativeElement;
      new Chart(ctx, { type: 'line', data: { ... } });
    });
  }
}

RouterTestingHarness

The RouterTestingHarness, introduced in v15.2 (check out our blog post), now exposes the underlying fixture, allowing to use its methods and properties and making it compatible with testing libraries that expect a fixture (like ngx-speculoos).

Devtools

Some preliminary work has been done in the framework to trace what is injected in an application in dev mode. This will be used in the future to improve the devtools experience, by providing a way to see what is injected in a component, and where it comes from.

Angular CLI

The CLI has been updated to v16.2.0 as well, with a few new features:

the esbuild builder now adds preload hints based on its analysis of the application initial files
the esbuild builder can now build the server bundle
the esbuild builder now has experimental support for serving the application in SSR mode with the Vite-based dev-server

Summary

That's all for this release, stay tuned!

All our materials (ebook, online training and training) are up-to-date with these changes if you want to learn more!

What's new in Angular 16.1?

2023-06-14T00:00:00Z

Angular 16.1.0 is here!

This is a minor release with some nice features: let's dive in!

TypeScript 5.1 support

Angular v16.1 now supports TypeScript 5.1. This means that you can use the latest version of TypeScript in your Angular applications. You can check out the TypeScript 5.1 release notes to learn more about the new features.

Transform input values

Angular v16.1 introduces a new transform option in the @Input decorator. It allows transforming the value passed to the input before it is assigned to the property. The transform option takes a function that takes the value as input and returns the transformed value. As the most common use cases are to transform a string to a number or a boolean, Angular provides two built-in functions to do that: numberAttribute and booleanAttribute in @angular/core.

Here is an example of using booleanAttribute:

@Input({ transform: booleanAttribute }) disabled = false;

This will transform the value passed to the input to a boolean so that the following code will work:

<my-component disabled></my-component>
<my-component disabled="true"></my-component>
<!-- Before, only the following was properly working -->
<my-component [disabled]="true"></my-component>

The numberAttribute function works the same way but transforms the value to a number.

@Input({ transform: numberAttribute }) value = 0;

It also allows to define a fallback value, in case the input is not a proper number (default is NaN):

@Input({ transform: (value: unknown) => numberAttribute(value, 42) }) value = 0;

This can then be used like this:

<my-component value="42"></my-component>
<my-component value="not a number"></my-component>
<!-- Before, only the following was properly working -->
<my-component [value]="42"></my-component>

Fetch backend for the Angular HTTP client

The HTTP client has a new backend implementation based on the Fetch API.

This is an experimental and opt-in feature, that you can enable with:

provideHttpClient(withFetch());

It does not support the progress reports on uploads, and of course, requires a browser that supports the Fetch API. The fetch API is also experimental on Node but available without flags from Node 18 onwards.

This is mainly interesting for server-side rendering, as the XHR implementation is not supported natively in Node and requires a polyfill (which has some issues).

Angular CLI

The CLI now has a --force-esbuild option that allows forcing the usage of esbuild for ng serve. It allows trying the esbuild implementation without switching the builder in angular.json (and keeping the Webpack implementation for the ng build command).

The esbuild builder has been improved. It now pre-bundles the dependencies using the underlying Vite mechanism, uses some persistent cache for the TypeScript compilation and Vite pre-bundling, and shows the estimated transfer sizes of the built assets as the Webpack builder does.

Summary

That's all for this release, stay tuned!

All our materials (ebook, online training and training) are up-to-date with these changes if you want to learn more!

What's new in Vue 3.3?

2023-05-15T00:00:00Z

Vue 3.3.0 is here!

The last minor release was v3.2.0 in August 2021! Since then, we have seen a lot of patch releases, some coming with new features.

Originally, the v3.3 release was supposed to bring Suspense and the Reactivity Transform APIs out of their experimental state.

Is that the case? Let's see what we have in this release (and some interesting bits from the 47 patches since v3.2.0)!

Hello Reactivity Transform, and goodbye!

During the last year and a half, the Vue team pursued its experiments with ref sugar (see our previous blog post to catch up).

Currently, without ref sugar, you write code like this:

import { ref, computed, watchEffect } from 'vue';
const quantity = ref(0);
const total = computed(() => quantity.value * 10);
watchEffect(() => console.log(`New total ${total.value}`));

Note the .value that you need to access the value of the quantity or total ref. If you use the Composition API, you're used to it.

The reactivity transform experiment introduced new compiler macros like $ref() and $computed(). When using these, the variable becomes reactive:

import { watchEffect } from 'vue';
const quantity = $ref(0);
const total = $computed(() => quantity * 10);
watchEffect(() => console.log(`New total ${total}`));

And .value was no longer necessary with this syntax!

But it turns out that this experiment is not quite as perfect as hoped initially. It introduced another way to do the same thing, with quite a bit of "magic", additional pitfalls, and complexity.

So in the end, this experiment is now officially... dropped!

As some teams already started to use it, it will not be removed right away. The plan is to phase these APIs out in a different package, add deprecation warnings in core, and eventually remove them in v3.4.

It doesn't mean that the team is not thinking about Vue how can be improved. Some new ideas will probably be shared publicly soon.

And a part of the reactivity transform experiment is going to stay: the defineProps destructuration. It's the part I really liked, so I'm quite happy about it 🤓.

defineProps destructuration

defineProps is the way to declare your props in the script setup syntax (see our article about script setup).

The syntax plays well with TypeScript, but the declaration of default values was a bit painful:

const props = withDefaults(defineProps<{ name?: string }>(), { name: 'Hello' })
console.log(props.name);

You also can't destructure the props directly, as it loses the reactivity.

With this new release, you can now give default values while destructuring the props and keeping the reactivity!

const { name = 'Hello' } = defineProps<{ name?: string }>()
console.log(name);

If you try to use a destructured prop directly inside a watcher (or to toRef), Vue will issue a warning and indicate to use a getter function instead:

watch(name, () => {});
// "name" is a destructured prop and should not be passed directly to watch().
// Pass a getter () => name instead.

To help with this pattern, a new toValue helper function has been added to convert refs and getters to values:

const v1 = toValue(ref('hello')); // 'hello'
const v2 = toValue(() => 'hello'); // 'hello'

If you want to give it a try, you'll need to enable the propsDestructure option in your bundler config. For example, in Vite:

plugins: [
  vue({
    script: {
      propsDestructure: true
    }
  })

TypeScript improvements

The TypeScript support of defineProps and other macros has been massively improved, as pretty much all built-in types are now supported (Extract, Exclude, Uppercase, Parameters, etc.). It also can now refer to types and interfaces imported from other files (whereas it was only resolving local types previously).

defineEmits has also been improved, as it now supports a shorter TS declaration. In Vue v3.2, we used to write the type like this:

const emit = defineEmits<{
  (e: 'selected', value: number): void;
}>();
// emit('selected', 14)

There is now a simplified syntax in Vue v3.3. You can use an interface with the events as keys, and the arguments as tuples:

const emit = defineEmits<{
  selected: [value: number]
}>();

Vue 3.3 also allows writing TypeScript directly in templates. It can be handy to hint to Volar that a variable is not null, or of a particular type:

<div>
  <h2>Welcome {{ (user!.name as string).toLowerCase() }}</h2>
</div>

Generic components

script setup components can now have a generic parameter, which works like a generic <T> in TypeScript:

<script setup lang="ts" generic="T">
defineProps<{ value: T, items: Array<T> }>()
</script>

Volar is then capable to throw an error if value is a string and items an array of numbers for example.

Component name inference

When using the script setup syntax, the SFC compiler now infers the component name based on the file name.

So a component declared in a file named Home.vue will automatically have the name Home since v3.2.34.

defineOptions macro

A new macro (a compile-time helper like defineProps and defineEmits) has been introduced to help declare the options of a component. This is available only in script setup component, and can be handy to declare a few things like the name of a component, if the inferred name is not good enough or to set the inheritAttrs option:

defineOptions({ name: 'Home', inheritAttrs: true });

defineSlots macro

Another macro called defineSlots (and a slots option if you're using defineComponent) has been added to the framework to help declare typed slots. When doing so, Volar will be able to check the slot props of a component. Let's say an Alert component has a default slot that exposes a close function:

defineSlots<{
  default: (props: { close: () => void }) => void;
}>();

If the Alert component is not used properly, then Volar throws an error:

<Alert><template #default="{ closeAlert }">...</template></Alert>
// error TS2339: Property 'closeAlert' does not exist on type '{ close: () => void; }'.

The returning value of defineProps can be used and is the same object as returned by useSlots.

experimental defineModel macro

When you have a custom form component that just wants to bind the v-model value to a classic input, the prop/event mechanic we saw can be a bit cumbersome:

<template>
  <input :value="modelValue" @input="setValue($event.target.value)" />
</template>

<script setup lang="ts">
defineProps<{ modelValue: string }>();
const emit = defineEmits<{ 'update:modelValue': [value: string] }>();
function setValue(pickedValue) {
  emit('update:modelValue', pickedValue);
}
</script>

It is now possible to simplify this component, by using the defineModel (experimental) macro:

<template>
  <input v-model="modelValue" />
</template>
<script setup lang="ts">
  const modelValue = defineModel<string>();
</script>

defineModel also accepts a few options:

required: true indicates that the prop is required
default: value lets specify a default value
local: true indicates that the prop is available and mutable even if the parent component did not pass the matching v-model

A useModel helper is also available if you don't use script setup.

Note that this feature is experimental and opt-in. For example, in Vite:

plugins: [
  vue({
    script: {
      defineModel: true
    }
  })

default value for toRef

It is now possible to define a default value when using toRef():

const order = { quantity: undefined }
const quantity = toRef(order, 'quantity', 1); // quantity is 1

Note that this works only if the value is undefined.

isShallow

A new utility function called isShallow is now available. It allows checking if a variable is deeply reactive (created with ref or reactive) or "shallow" (created with shallowRef or shallowReactive).

v-for and ref

Vue 3 now behaves like Vue 2 used to behave when using ref inside v-for: it populates an array of refs.

<script setup>
import { ref } from 'vue'
const divs = ref([])
</script>

<template>
  <div v-for="i of 3" ref="divs">{{ i }}</div>
  <!-- divs is populated with an array of 3 refs -->
  <!-- one for each HTMLDivElement created -->
  <div>{{ divs }}</div>
</template>

aliases for vnode hook events

Vue allows you to listen for lifecycle events in templates, both for elements and components. The syntax in Vue 3 is @vnodeMounted for example. In Vue v3.3, it is now possible to use @vue:mounted instead, which is a bit more understandable. @vnode hooks are now deprecated.

<script setup>
import { ref } from 'vue'

const isMounted = ref(false)
const onDivMounted = () => isMounted.value = true

const condition = ref(false)
setTimeout(() => condition.value = true, 3000)
</script>

<template>
  <div>isMounted: {{ isMounted }}</div>
  <div @vue:mounted="onDivMounted()" v-if="condition">Hello</div>
</template>

You can try this example in this online demo.

suspensible Suspense

Suspense is still experimental but gained a new prop called suspensible.

The prop allows the suspense to be captured by the parent suspense. That can be useful if you have nested Suspense components, as you can see in the PR explanation.

console available in templates

A small (but useful when debugging) improvement in templates is the possibility to directly use console:

<input @input="console.log($event.target.value)">

To conclude, let's see what happened in the ecosystem recently.

create-vue

Since Vue v3.2, the Vue team started a new project called create-vue, which is now the recommended way to start a Vue project. You can use it with

npm init vue@next

create-vue is based on Vite v4, and officially replaces Vue CLI.

If you missed it, create-vue recently added the support of Playwright in addition to Cypress for e2e tests! It now also supports TypeScript v5 out of the box.

Router

Vue v3.3 introduced a new function on the object returned by createApp: runWithContext. The function allows using inject with the app as the active instance, and get the value provided by the app providers.

const app = createApp(/* ... */);
app.provide('token', 1);
app.runWithContext(() => inject('token'));

If I mention this in the router section, it's because it unlocks the possibility to use inject in global navigation guards if you use Vue v3.3 and the router v4.2!

router.beforeEach((to, from) => {
  console.log(inject('token'));
});

Pinia

Pinia is a state-management library from the author of vue-router Eduardo "@posva". It was meant as an experiment for Vuex v5, but it turns out to be very good, and it's now the official recommendation for state-management library in Vue 3 projects.

The project moved into the vuejs organization, and there will be no Vuex version 5. Pinia is a really cool project, with a great composition API and TS support, and one of the cutest logos you've ever seen.

We added a complete chapter in our ebook to explain how Pinia works if you're interested 🤓.

Eduardo also released VueFire, the official Firebase bindings for Vue 3. With this library, you can add Firebase to your Vue or Nuxt projects in a few minutes.

Nuxt

After a long development, Nuxt v3 is now stable! It is a really amazing solution and the Nuxt team has been hard at work to provide a great development experience (with some dark magic under the hood). Give it a try if you're looking for a meta-framework on top of Vue (for example if you need SSR or SSG for your project).

Volar

Volar reached v1.0 recently after a very intense period of development these past months. The TypeScript support is now better than ever, making it a no-brainer to use in your projects.

Vue Test utils

The testing library has a few typings improvements coming in the v2.4 release, and now supports SSR testing via renderToString since v2.3.

Vue 3 in 2023

The Vue team plans to release more frequent minor releases than in the past, so we can expect Vue v3.4 soon. The next releases will be focused on bug fixes and small improvements in the first quarter of the year. Then there should be some improvements for the SSR support in Q2. Finally, the second half of the year should see the first alpha of Vapor. We should hopefully also see Suspense finally getting out of its experimental state.

Vue Vapor is an alternative compilation mode to get better performances. It's not public yet, but we already know that it is inspired by what Solidjs does, as the reactivity system of Vue and Solid are fairly similar. The idea is to compile a script setup component differently when the "Vapor" mode is enabled, resulting in a lighter rendering code (not using VDOM).

Let's say we have a classic Counter component:

<script setup lang="ts">
  let count = ref(0)
</script>
<template>
  <div>
    <button @click="count++">{{ count }}</button>
  </div>
</template>

In the current Vue 3 compilation mode, the template is compiled into a function that produces VDOM which is then diffed and rendered (check out the "Under the hood" chapter of our ebook if you want to learn more). In Vapor mode, the template is compiled into a function that only updates what's necessary in the DOM.

import { ref, effect } from 'vue';
import { setText, template, on } from 'vue/vapor';

let t0 = template('<div><button>');

export default () => {
  const count = ref(0); 
  let div = t0();
  let button = div.firstChild;
  let button_text;
  effect(() => {
    // This is the only part that is executed at runtime when the counter value changes
    setText(button, button_text, count.value);
  });
  on(button, 'click', () => count.value++);
  return div;
}

This "Vapor" mode will be opt-in at the component level, probably for "leaf" components first. To switch a component to Vapor, the current idea is to import it with a .vapor.vue extension:

<script setup lang="ts">
  // 👇 compiles the User component in Vapor mode
  // you get an error if the component is not "Vapor" compatible
  import User from './User.vapor.vue'
</script>
<template>
  <User />
</template>

We'll be able to enable it for a whole application in the future. The current idea is to call a different createApp function from vue/vapor:

import { createApp } from 'vue/vapor'
import App from './App.vapor.vue'
createApp(App).mount('#app')

When enabled for a full application, the VDOM implementation could be completely dropped from the resulting bundle! We can't wait to try this!

That's all for this release. Stay tuned for the next one!

Our ebook, online training and training are up-to-date with these changes if you want to learn more!

What's new in Angular 16?

2023-05-03T00:00:00Z

Angular 16.0.0 is here!

This is a major release packed with features: let's dive in!

Angular Signals

As you may have heard, all the hype around Angular is about the addition of Signals to the framework. As this is a big change that will shape how we build Angular applications in the future, we wrote an introduction to Signals, to cover what you can do with them in v16 and what to expect in the future:

👉 Angular Signals

Note that Signals are released as a developer preview in v16 and the API may change in the future.

As Signals are progressing, Angular now allows configuring ZoneJS explicitly with provideZoneChangeDetection:

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

This opens the door to zoneless applications in the near future, where developers could choose to not include ZoneJS in their application.

Required inputs

Angular v16 added the possibility to mark an input as required, with @Input({ required: true}):

@Input({ required: true }) user!: UserModel;

In that case, if the parent component does not pass the input, then the compiler will throw an error.

This has been a long-awaited feature, we're happy to see this land in Angular!

Server-Side Rendering and progressive hydration

Angular has been supporting Server-Side Rendering (SSR) for a while now, but it was a bit limited as it was only possible to render the whole application on the server, and then re-render it on the client when the JavaScript bundle was loaded. This was resulting in a flickering when the application loaded, as the DOM was completely wiped out before being re-rendered.

Angular v16 introduces "progressive hydration", which allows rendering the application on the server, and then progressively hydrate it on the client.

This means that the server-rendered DOM is not wiped out anymore, and the client-side rendering is done progressively, which results in a much smoother experience for the user.

To enable these new behaviors, you simply add provideClientHydration() to your providers:

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

The HttpClient has also been updated to be able to store the result of a request done on the server, and then reuse it on the client during the hydration process! The behavior is enabled by default if you use provideClientHydration(), but can be disabled with provideClientHydration(withNoHttpTransferCache()). You can also disable the DOM reuse with withNoDomReuse().

Note that this is a developer preview, and the API may change in the future. There are also a few pitfalls to be aware of. For example, the HTML must be valid when generated on the server (whereas the browser is more forgiving). The DOM must also be the same on the server and the client, so you can't manipulate the server-rendered DOM before sending it to the client. If some parts of your templates don't produce the same result on the server and the client, you can skip them by adding ngSkipHydration to the element or component. i18n is also not supported yet, but that should come soon.

When running in development mode, the application will output some stats to the console to help you debug the hydration process:

Angular hydrated 19 component(s) and 68 node(s), 1 component(s) were skipped

You can easily give this a try by using Angular Universal. In the long term, this will probably be part of the CLI directly.

DestroyRef

Angular v16 introduces a new DestroyRef class, which has only one method called onDestroy.

DestroyRef can be injected, and then used to register code that should run on the destruction of the surrounding context.

const destroyRef = inject(DestroyRef);
// register a destroy callback
destroyRef.onDestroy(() => doSomethingOnDestroy());

For example, it can be used to execute code on the destruction of a component or directive (as we do now with ngOnDestroy). But this is more useful for cases where you want to execute code when a component is destroyed, but you don't have access to the component itself, for example when defining a utility function.

This is exactly what Angular uses internally to implement takeUntilDestroyed, the new RXJS operator introduced in our Signals blog post.

provideServiceWorker

One of the last modules that needed to be transitioned to a standalone provider function was ServiceWorkerModule. It is now done with provideServiceWorker:

bootstrapApplication(AppComponent, {
  providers: [provideServiceWorker('ngsw-worker.js', { enabled: !isDevMode() })]
});

It, of course, accepts the same options as the ServiceWorkerModule. Running ng add @angular/pwa will now add provideServiceWorker to your providers if your application is a standalone one.

TypeScript 5.0 support

Angular v16 now supports TypeScript 5.0. This means that you can use the latest version of TypeScript in your Angular applications. You can check out the TypeScript 5.0 release notes to learn more about the new features.

One important point is that TypeScript now supports the "official" decorator specification. Their "experimental decorators" (based on a much older specification) are still supported but are now considered legacy. One of the differences between these two specifications is that the legacy one supports decorators on parameters, which is used by Angular for dependency injection (with @Optional, @Inject, etc.), and the new one doesn't.

It is now possible to use the new decorator specification in Angular, but it requires a few changes in your code, as you can't use decorators on parameters anymore. This can usually be worked around by using the inject() function from @angular/core. There is no rush to use the new decorators instead of the "legacy" ones, but it's something to keep in mind as I wouldn't be surprised if we have to migrate away from experimentalDecorators in the future

Styles removal opt-in

Angular v16 introduces a new opt-in feature to remove the styles of a component when its last instance is destroyed.

This will be the default behavior in the future, but you can already opt in with:

{ provide: REMOVE_STYLES_ON_COMPONENT_DESTROY, useValue: true }

Router

Angular v15.2 deprecated the usage of class-based guards and resolvers (check out our blog post for more details). In Angular v16, a migration will run to remove the guard and resolver interfaces from your code (CanActivate, Resolve, etc.).

To help with the conversion, the router now offers helper functions to convert class-based entities to their function-based equivalent:

mapToCanActivate
mapToCanActivateChild
mapToCanDeactivate
mapToCanMatch
mapToResolve

For example, you can now write:

{ path: 'admin', canActivate: mapToCanActivate([AdminGuard]) };

RouterTestingModule is also getting phased out, and will probably be deprecated and removed in the future. It is not needed anymore, because Angular v16 now provides MockPlatformLocation in BrowserTestingModule by default, which was the main reason to use RouterTestingModule in the first place.

You can now directly use RouterModule.forRoot([]) or providerRouter([]) in your tests.

Last but not least, the router now offers the possibility to bind parameters as inputs.

To do so, you need to configure the router with withComponentInputBinding:

provideRouter(routes, withComponentInputBinding())

With this option, a component can declare an input with the same name as a route parameter, query parameter or data, and Angular will automatically bind the value of the parameter or data to this input.

export class RaceComponent implements OnChanges {
  @Input({ required: true }) raceId!: string;

We can then use this input as a regular input, and react to its change with ngOnChanges or by using a setter for this input:

constructor(private raceService: RaceService) {}

ngOnChanges() {
  this.raceModel$ = this.raceService.get(this.raceId);
}

Angular CLI

Check out our dedicated blog post about the CLI for more details.

Summary

That's all for this release, stay tuned!

All our materials (ebook, online training and training) are up-to-date with these changes if you want to learn more!

Ninja Squad Blog

What's new in Angular 21.2?

Templates

Arrow functions

Exhaustive @switch checks

ChangeDetectionStrategy.Eager

Resource snapshot

Signal Forms

FormRoot directive and submission option

focus and registerAsBinding

transformedValue for custom controls

Nullable number inputs

SignalFormControl for incremental migration

Reactive validateStandardSchema()

Warning for rendered hidden fields

Animations

Router

canMatch now gets a partial route snapshot

DevTools

Angular CLI

Unit tests

Prettier

Summary

What's new in Angular 21.1?

Signal Forms

Control flow

Template spread operator

Router

Debugging stability

Vitest

AI

Summary

What's new in Angular 21.0?

Signal Forms (experimental)

Zoneless by default 🚀

Core

Forms

Http

Router

Templates

Compiler

Styles encapsulation

Vitest is the new default

ng serve

Tailwind schematic

Style guide 2016

ng version

Accessibility

AI

Summary

Angular tests with Vitest browser mode

Retried assertions

Locators, their interactivity and assertion API

Angular Signal Forms - Part 2

Custom validation with validate() and validateTree()

Extracting and applying schemas with apply()

Asynchronous validation with validateAsync() and validateHttp()

Server errors

Dynamic behavior

Debouncing form updates with debounce()

Custom form components with FormValueControl and FormCheckboxControl

Sub forms

Conclusion

What's next?

Angular Signal Forms - Part 1

Creating a form with form()

Submitting the form with submit()

Adding validation with built-in validators

Standard schema validation with validateStandardSchema()

What's Next?

What's new in Angular 20.3?

Vulnerability fix in platform-server and ssr

Extended diagnostics

Angular CLI

What's new in Angular 20.2?

Zoneless is stable!

New animations support

Templates

ARIA bindings

Alias in @else if blocks

Exhaustive `@switch` checks

`FormRoot` directive and `submission` option

focus and `registerAsBinding`

`transformedValue` for custom controls

`SignalFormControl` for incremental migration

Reactive `validateStandardSchema()`

`canMatch` now gets a partial route snapshot

Custom validation with `validate()` and `validateTree()`

Extracting and applying schemas with `apply()`

Asynchronous validation with `validateAsync()` and `validateHttp()`

Debouncing form updates with `debounce()`

Custom form components with `FormValueControl` and `FormCheckboxControl`

Creating a form with `form()`

Submitting the form with `submit()`

Standard schema validation with `validateStandardSchema()`

Alias in `@else if` blocks