{"id":31926,"date":"2025-12-02T10:45:22","date_gmt":"2025-12-02T09:45:22","guid":{"rendered":"https:\/\/www.angulararchitects.io\/blog\/whats-new-in-angular-21-signal-forms-zone-less-vitest-angular-aria-cli-with-mcp-server\/"},"modified":"2025-12-09T10:11:02","modified_gmt":"2025-12-09T09:11:02","slug":"whats-new-in-angular-21-signal-forms-zone-less-vitest-angular-aria-cli-with-mcp-server","status":"publish","type":"post","link":"https:\/\/www.angulararchitects.io\/en\/blog\/whats-new-in-angular-21-signal-forms-zone-less-vitest-angular-aria-cli-with-mcp-server\/","title":{"rendered":"What\u2019s new in Angular 21?"},"content":{"rendered":"

Angular 21, released at the end of 2025, brings several new features: Signal Forms as a reactive form API, Zone-less as the new standard model for change detection, vitest as a modern test environment, a set of ARIA directives for accessible components, and an enhanced MCP server for AI-supported development.<\/p>\n

This article provides an overview of these features using examples. <\/p>\n

\ud83d\udcc2 Source Code<\/a><\/p>\n

Signal Forms<\/h2>\n

The currently experimental Signal Forms allow for efficient form design based on signals. This new API is similarly lightweight to template-driven forms, while offering the power of reactive forms. Furthermore, it enables the very simple creation of compound forms ("Form Groups") and repeating groups ("Form Arrays"):<\/p>\n

\"Example<\/p>\n

The implementation is based on a Signal with the desired form structure. For this signal, the form<\/code> function generates a so-called FieldTree<\/code>, which enables data binding to the form:<\/p>\n

@Component([\u2026])\nexport class FlightSearchComponent {\n  filter = signal({\n    from: 'Graz',\n    to: 'Hamburg',\n    details: {\n      maxLayovers: 0,\n      maxPrice: 200\n    },\n    layovers: [\n      { airport: '', minDuration: 0}\n    ] as Layover[]\n  });\n\n  filterForm = form(this.filter, (path) => {\n    required(path.from);\n    minLength(path.from, 3);\n\n    required(path.to);\n    minLength(path.to, 3);\n\n    const allowed = ['Graz', 'Hamburg', 'Paris'];\n    validateAirport(path.from, allowed);\n  });\n\n  addLayover(): void {\n    this.filter.update(filter => ({\n      ...filter,\n      layovers: [\n        ...filter.layovers,\n        {\n          airport: '',\n          minDuration: 0\n        }\n      ]\n    }));\n  }\n\n  search(): void {\n    const { from, to } = this.filterForm().value();\n\n    \/\/ Alternative\n    \/\/ const from = this.filterForm.from().value();\n    \/\/ const to = this.filterForm.to().value();\n    [\u2026]\n  }\n\n}<\/code><\/pre>\n
Technically, a FieldTree<\/code> is a signal that represents the state of a form section -- an object, an array or a single property that is bound to a field. It manages information like value<\/code>, dirty<\/code>, and errors<\/code>. For each nested property, such as maxLayovers<\/code> and maxPrice<\/code>, it contains another FieldTree<\/code>.<\/p>\n
The directive field<\/code> binds a FieldTree<\/code> to an input field:<\/p>\n
<form>\n    <input [field]="filterForm.from" \/>\n    <div>{{ filterForm.from().errors() | json }}<\/div>\n\n    <input [field]="filterForm.to" \/>\n    <div>{{ filterForm.to().errors() | json }}<\/div>\n\n    <!-- "Field Group" -->\n    <input\n      [field]="filterForm.details.maxLayovers"\n      type="number"\n    \/>\n    <input\n      [field]="filterForm.details.maxPrice"\n      type="number"\n    \/>\n\n    <!-- "Field Array" -->\n    @for (layover of filterForm.layovers; track $index) {\n        <input [field]="layover.airport" \/>          \n        <input\n            [field]="layover.minDuration"\n            type="number"\n        \/>\n    }\n    [\u2026]\n<\/form><\/code><\/pre>\n
For improved readability, the form markup shown has been reduced to the essential parts. The optional second parameter of form<\/code> accepts a schema that primarily contains validation rules. Signal Forms comes with the usual rules such as required<\/code> and minLength<\/code>. Custom validation rules can be implemented using the validate<\/code> function:<\/p>\n
function validateAirport(path: SchemaPath<string>, allowed: string[]) {\n  validate(path, (ctx) => {\n    if (allowed.includes(ctx.value())) {\n      return null;\n    }\n    return {\n      kind: 'airport_not_supported',\n      allowed,\n      actual: ctx.value(),\n    };\n  });\n}<\/code><\/pre>\n
In addition to validation rules, a schema can define debouncing or specify when certain fields should be deactivated.<\/p>\n
More on Signal Forms<\/h2>\n
Please find more information on Signal Forms in my article "All About Angular's new Signal Forms"<\/a>:<\/p>\n
<\/a><\/p>\n
Zone-less by Default<\/h2>\n
From the very beginning, Zone.js has been the foundation for change detection in Angular. This library, included with the framework, uses monkey patching to modify existing browser objects such as window<\/code>, document<\/code>, and Promise<\/code>. This allows it to determine when an event handler has been executed. After an event handler ran, Zone.js notifies the framework, which then checks the components for changes.<\/p>\n
Zone.js also has some disadvantages. These include the overhead of around 30 KB (compressed), which is usually negligible for business applications. More serious, however, is the intervention in existing browser objects, as this complicates troubleshooting and leads to less traceable stack traces. Furthermore, there is a risk that Zone.js will trigger change detection too frequently - it has no knowledge of whether the current event handler has actually modified bound data.<\/p>\n
The new zone-less change detection no longer requires Zone.js. To inform Angular about changes to bound properties, signals or observables must now be bound. The latter is done as usual via the async<\/em> pipe. The objects managed by these reactive data structures should also be immutable so that Angular, in OnPush<\/em> mode, can recognize which subcomponents need to be checked.<\/p>\n
Since Angular 21, Zone-less change detection is on by default. If you want to stick with Zone.js, add provideZoneChangeDetection to your providers when bootstrapping:<\/p>\n
\/\/ switching back to Zone-full CD\nbootstrapApplication(AppComponent, {\n  providers: [\n    provideZoneChangeDetection()\n  ],\n});<\/code><\/pre>\n
In this case, you also have to add zone.js<\/code> to the polyfills in your angular.json<\/code>.<\/p>\n
Generally, Zone-less should work wherever OnPush<\/code> works. Nevertheless, it's advisable to thoroughly test the application in the new mode. Challenges might arise with third-party components that rely on the original behavior. In such cases, it's necessary to switch to a newer version (or wait for one).<\/p>\n
Vitest: Migration and Fake Timer<\/h2>\n
The Angular team has been searching for a successor to the deprecated unit testing tool Karma for some time. They have now chosen the popular vitest<\/a>. New projects are automatically set up with the new, dedicated unit test builder (@angular\/build:unit-test).<\/p>\n
Karma support remains available for existing projects. An experimental schematic is available for automated migration:<\/p>\n
ng g @schematics\/angular:refactor-jasmine-vitest<\/code><\/pre>\n
The new vitest-based unit tests always run zone-less. Hence, ideally, the application should also be migrated to Zone-less when using vitest. Since most calls remain unchanged, existing knowledge about Angular testing can be transferred almost directly.<\/p>\n
However, a few things need to be changed. For example, the setup of spies changes slightly. spyOn<\/code> is now, for instance, a method in the vi<\/code> object:<\/p>\n
vi.spyOn(flightService, 'find');<\/code><\/pre>\n
Depending on the configuration, vi<\/code> is either globally available or must be imported separately:<\/p>\n
import { vi } from 'vitest';<\/code><\/pre>\n
Spies in vitest<\/code> delegate to the observed implementation by default - the call .and.callThrough()<\/code> known from Jasmine is omitted. The object returned by spyOn<\/code> also has a slightly different form, although the basic functionality remains unchanged. A mock implementation can thus be set up, for example, as follows:<\/p>\n
vi.spyOn(flightService, 'find')\n    .mockImplementation((_from, _to) => of([]));<\/code><\/pre>\n
In addition to these minor adjustments, vitest also brings a whole amount of new features familiar from Jest. These include snapshot testing, extensive import mocking capabilities, and parallel test execution.<\/p>\n
As Vitest always runs Zone-less in Angular, the notorious Zone.js testing utilities - including fakeAsync<\/code> and tick<\/code> cannot be used anymore. Affected tests must now be structured differently. For example, the test might replace asynchronous routines with synchronous mocks. This approach is also known from testing the HttpClient<\/code>.<\/p>\n
Those who still want to "fast-forward" time can use the fake timers offered by vitest:<\/p>\n
import { TestBed } from '@angular\/core\/testing';\nimport { debounceTime, Subject } from 'rxjs';\nimport { vi } from 'vitest';\nimport { toSignal } from '@angular\/core\/rxjs-interop';\n\ndescribe('simulated input', () => {\n  beforeEach(() => {\n    vi.useFakeTimers();\n  });\n\n  it('is updated after debouncing', async () => {\n    await TestBed.runInInjectionContext(async () => {\n      const input = createInput();\n      input.set('Hallo');\n      await vi.runAllTimersAsync();\n      expect(input.value()).toBe('Hallo');\n    });\n  });\n});\n\n\/\/ Simulates debounced input\nfunction createInput() {\n  const input = new Subject<string>();\n  const inputSignal = toSignal(input.pipe(debounceTime(300)), {\n    initialValue: '',\n  });\n  return {\n    value: inputSignal,\n    set(value: string) {\n      input.next(value);\n    },\n  };\n}<\/code><\/pre>\n
The function beforeEach<\/code> function activates the fake timers for each test case in the suite. After the content is set, the timers for debouncing must be resolved before the test can read the new value. This is done using runAllTimersAsync<\/code>.<\/p>\n
Unlike its synchronous alternative, runAllTimers<\/code>, runAllTimersAsync<\/code> not only resolves all timers but also waits for the microtasks they trigger. Examples of these are microtasks that arise from Promises in the timer callback.<\/p>\n
Browser Mode in Vitest<\/h2>\n
Unlike Karma, vitest doesn't run in the browser by default, but directly in Node.js. The CLI integration simulates the DOM using the packages happy-dom<\/code> or jsdom<\/code>. One of these must be installed. If both are present, happy-dom<\/code> takes precedence. While such tests are somewhat faster, they also run in an artificial environment.<\/p>\n
Therefore, vitest also offers a browser mode. In this mode, a provider is used for communication with the browser. The vitest team recommends the Playwright-based provider, especially since it accelerates execution through parallelization:<\/p>\n
npm install @vitest\/browser-playwright -D<\/code><\/pre>\n
To activate browser mode, the browsers to be used must be entered in the angular.json<\/code> file:<\/p>\n
"test": {\n  "builder": "@angular\/build:unit-test",\n  "options": {\n    "browsers": ["Chromium"]\n  },\n  "configurations": {\n    "ci": {\n      "browsers": ["ChromiumHeadless"]\n    }\n  }\n}<\/code><\/pre>\n
The shown example is using Chromium. Additionally, for execution on the build server, it includes a ci<\/code> configuration that uses the headless version of Chrome. To interact with the page, vitest provides a page<\/code> object for browser mode:<\/p>\n
import { page } from 'vitest\/browser';\n[\u2026]\n\nit('should have a disabled search button w\/o params', async () => {\n\n  await page.getByLabelText('from').fill('');\n  await page.getByLabelText('to').fill('');\n\n  const button = page.getByRole('button', { name: 'search' }).element() \n          as HTMLButtonElement;\n\n  const disabled = button.disabled;\n\n  expect(disabled).toBeTruthy();\n});<\/code><\/pre>\n
Aria properties are used to retrieve elements from the page. For example, the getByLabelText('from')<\/code> method searches for an element with the attribute aria-label="from"<\/code>, and getByRole('button', { name: 'search' })<\/code> references a button with aria-label="search"<\/code>. The name<\/code> parameter here refers to the aria-label<\/code> attribute, not the name<\/code> attribute.<\/p>\n
As the discussed example shows, the objects retrieved via page<\/code> allow the simulation of user actions. They have methods such as fill<\/code> for this purpose. Other methods not shown here include clear<\/code> (clearing the field content), click<\/code>, dblClick<\/code>, hover<\/code>, and unhover<\/code>. Additional user actions are enabled by the userEvent<\/code> object in the vitest\/browser<\/code> package.<\/p>\n
When ng test<\/em> is run in browser mode, the CLI opens the configured browser(s) and executes the tests within it:<\/p>\n
\"Vitest<\/p>\n
The middle section displays the component being tested during test execution. Afterwards, the DOM in this area is reset so that subsequent tests can run without interference. However, when debugging, for example using a breakpoint in the browser's developer tools, the current state is visible there. This can be useful for troubleshooting.<\/p>\n
More on Testing<\/h2>\n
Please find more information on Testing in our Professional Angular Testing workshop<\/a>:<\/p>\n
<\/a><\/p>\n
Angular Aria<\/h2>\n
The new @angular\/aria package introduces accessible Directives that implement WAI-ARIA<\/a> patterns. Out of the box, they support keyboard navigation, ARIA attributes, focus management, and screen reader integration. These directives are not intended for direct use in applications, but rather as a foundation for custom component libraries with their own unique design.<\/p>\n
The following image shows an overview of the directives offered in version 21 on the left, and a tree view next to it. Since these directives are intentionally unstyled (headless), the styling from angular.dev<\/em> has been applied to them:<\/p>\n
\"Overview<\/p>\n
The next listing, that has been slightly simplified and taken from the documentation,  implements a grid:<\/p>\n
<table ngGrid class="basic-data-table">\n  <thead>\n    <tr ngGridRow>\n      <th ngGridCell>\n        <input\n          ngGridCellWidget\n          aria-label="Select all rows"\n          type="checkbox"\n          [checked]="allSelected()"\n          (change)="updateSelection($event)"\n          #headerCheckbox\n        \/>\n      <\/th>\n      <th ngGridCell>ID<\/th>\n      <th ngGridCell>Task<\/th>\n      <th ngGridCell>Priority<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    @for (task of data(); track task.taskId) {\n    <tr ngGridRow>\n      <td ngGridCell>\n        <input\n          ngGridCellWidget\n          aria-label="Select row {{$index + 1}}"\n          type="checkbox"\n          [(ngModel)]="task.selected"\n        \/>\n      <\/td>\n      <td ngGridCell>{{task.taskId}}<\/td>\n      <td ngGridCell>{{task.summary}}<\/td>\n      <td ngGridCell>{{task.priority}}<\/td>\n    <\/tr>\n    }\n  <\/tbody>\n<\/table><\/code><\/pre>\n
Here is what this grid looks like:<\/p>\n
\"Angular<\/p>\n
The following directives work together to implement this grid: Grid<\/em>, GridRow<\/em>, GridCell<\/em>, GridCellWidget<\/em>. This rather long code example for a simple grid underscores that the directives provided are intended as flexible building blocks for your own reusable components.<\/p>\n
Improved MCP server in Angular CLI<\/h2>\n
Version 21 also expands the MCP server integrated into the CLI. It now includes the following tools to assist with AI-assisted programming (Vibe Coding):<\/p>\n