Angular v22: The Signal-First
Future Is Here

Overview: What's New in Angular v22

Let's go through each feature in depth — what it does, why it matters, and how to use it today.

1. Signal Forms — Production-Ready Reactive Forms

The biggest feature in Angular v22 is the graduation of Signal Forms from developer preview to stable. After months of refinement — including lazy field initialization, generic union support, debounced async validation, parse error signals, configurable submit behavior, and custom control reset propagation — Signal Forms are now ready for production workloads.

Signal Forms replace both template-driven and reactive forms with a unified, signal-based API. Instead of FormControl, FormGroup, and FormArray classes, you get reactive field primitives backed by Angular Signals — meaning automatic, granular change detection without zone.js polling.

Before (Reactive Forms)

export class LoginComponent {
  form = new FormGroup({
    email: new FormControl('', [Validators.required, Validators.email]),
    password: new FormControl('', [Validators.required, Validators.minLength(8)]),
  });

  get email() { return this.form.get('email'); }

  onSubmit() {
    if (this.form.valid) {
      this.authService.login(this.form.value);
    }
  }
}

After (Signal Forms)

import { signalForm, formField } from '@angular/forms';

export class LoginComponent {
  form = signalForm({
    email: formField('', { validators: [required, email] }),
    password: formField('', { validators: [required, minLength(8)] }),
  });

  // Form state is reactive via Signals
  emailError = computed(() => {
    const field = this.form.controls.email;
    if (field.touched() && field.invalid()) {
      return field.getError('email') ?? 'Invalid email';
    }
    return null;
  });

  onSubmit() {
    if (this.form.valid()) {
      this.authService.login(this.form.value());
    }
  }
}

Key differences: Signal Forms track validity, touched, dirty, and errors through Signals rather than observable streams. There's no .get() with string paths — you access fields as typed properties. The schema definition is compact and composable, supporting nested groups, dynamic arrays, and union types natively.

Signal Forms vs Reactive Forms — Feature Comparison

2. Angular Aria — First-Class Accessibility

Angular v22 ships Angular Aria as a stable module — a comprehensive set of accessibility primitives that make WCAG compliance a built-in framework feature rather than a third-party concern.

Angular Aria includes directives for:

• ARIA attribute management — automatic ARIA role, state, and property bindings based on component semantics
• Keyboard navigation — standardized focus management, tab order, and keyboard event handling (arrow keys, Enter, Escape patterns)
• Screen reader announcements — live region notifications for dynamic content changes without moving focus
• Focus trapping — for modals, dialogs, and overlays with inert background support
• aria-invalid support — automatic synchronization with form field validation state

import { AriaModule } from '@angular/aria';

@Component({
  selector: 'app-modal',
  standalone: true,
  imports: [AriaModule],
  template: `
    <div role="dialog" ariaModal ariaLabelledBy="modal-title">
      <h2 id="modal-title">Confirm</h2>
      <p>Are you sure you want to delete this item?</p>
      <div class="actions" ariaKeyboardNav>
        <button (click)="confirm()">Delete</button>
        <button (click)="cancel()">Cancel</button>
      </div>
    </div>
  `
})
export class ConfirmModalComponent {}

The ariaKeyboardNav directive handles arrow key navigation among focusable children, which is essential for toolbars, menu bars, tab lists, and radio groups. Combined with ariaModal for focus trapping and ariaLiveAnnouncer for dynamic updates, Angular Aria eliminates the need for third-party accessibility wrappers like Reach UI or Radix.

3. httpResource — Declarative Signal-Based Data Fetching

httpResource and its sibling rxResource represent a paradigm shift in how Angular applications fetch and manage remote data. Instead of managing request lifecycle manually with subscriptions, loading flags, and error states, you declare the data dependency as a Signal — Angular handles the rest.

import { httpResource } from '@angular/common/http';

@Component({
  selector: 'app-user-profile',
  template: `
    @if (user.isLoading()) {
      <p>Loading...</p>
    } @else if (user.error()) {
      <p>Error: {{ user.error() }}</p>
    } @else {
      <h2>{{ user.value().name }}</h2>
      <p>{{ user.value().email }}</p>
    }
  `
})
export class UserProfileComponent {
  userId = input<number>();

  // Declarative — httpResource reacts when userId changes
  user = httpResource<User>(() => `/api/users/${this.userId()}`, {
    defaultValue: { name: '', email: '' }
  });
}

httpResource returns an object with three reactive properties: value (the data Signal), isLoading (a boolean Signal), and error (an error Signal). When the request URL changes (e.g., the userId input updates), the resource automatically re-fetches and transitions through loading → success/error states.

Dependent Resource Chaining with chain()

Real applications rarely fetch a single resource. httpResource.chain() lets you express dependent data fetching without nested subscriptions or manual coordination:

// Team details load automatically after selectedTeamId is known
team = httpResource<Team>(() => `/api/teams/${this.selectedTeamId()}`);

// Team members load when team data is available
teamMembers = this.team.chain(
      (team) => `/api/teams/${team.id}/members`,
      { defaultValue: [] as Member[] }
    );

// Team members' tasks load from members
teamTasks = this.teamMembers.chain(
  (members) => `/api/tasks?assigneeIds=${members.map(m => m.id).join(',')}`,
  { defaultValue: [] as Task[] }
);

Each chain() call creates a derived resource that automatically invalidates and re-fetches when its parent resource changes. The chain handles race conditions — if a parent re-fetches before a child resolves, the stale child request is cancelled automatically.

For Observable-based data sources, rxResource provides the same declarative API over arbitrary RxJS observables — useful for WebSocket streams, event emitters, or legacy service integrations.

4. OnPush as Default Change Detection

Starting in Angular v22, components with no explicit changeDetection setting default to ChangeDetectionStrategy.OnPush. This is a breaking change that aligns Angular with modern reactive patterns.

To preserve the old behavior, explicitly set:

@Component({
  selector: 'app-legacy',
  changeDetection: ChangeDetectionStrategy.Eager,  // was Default
  template: `...`
})
export class LegacyComponent {}

The ng update schematic automatically identifies components that relied on the old default and adds ChangeDetectionStrategy.Eager where needed. However, the long-term direction is clear: pair OnPush with Signals for optimal performance. Signals naturally trigger change detection only in the components that consume them, making zone.js increasingly optional.

If you've been using Signals, computed, and effect in your Angular 21 codebase, this change is transparent — your components already behave like OnPush because signal reads in templates are tracked and re-rendered granularly. The difference is now enforced at the component level, catching components that mutated state directly without going through Signals or immutables.

5. Fetch API as Default HttpClient

Angular v22 flips the default HTTP backend from XMLHttpRequest (XHR) to the modern Fetch API. The HttpClient now uses FetchBackend by default, bringing streaming response support, better error handling, and improved performance characteristics.

withFetch() is now deprecated — it was previously required to opt into the Fetch backend, but it's now the default and can be safely removed. If you need the XHR backend (e.g., for upload progress reporting), opt in explicitly:

// Default in v22 — Fetch is used automatically
provideHttpClient()

// Opt into XHR if you need upload progress callbacks
provideHttpClient(withXhr())

The schematics migration adds withXhr() automatically where provideHttpClient was previously called without arguments, preserving backward compatibility. New projects should remove withFetch() from their provider configuration.

Other HTTP improvements in v22:

• Split progress reporting — reportUploadProgress and reportDownloadProgress replace the old reportProgress option (now deprecated)
• Transfer cache for SSR — httpResource integrates with the transfer cache to avoid redundant HTTP calls during hydration, improving SSR performance significantly
• Max buffer size for fetch on SSR — prevents memory exhaustion on large streaming responses
• JSONP deprecated — HttpClient.jsonp and HttpClientJsonpModule are deprecated in favor of standard HTTP

6. TypeScript 6.0+ and Node.js 22+ Required

Angular v22 drops support for TypeScript 5.x (including TS 5.8 and 5.9) and Node.js 20. You must upgrade to:

• TypeScript 6.0 or higher
• Node.js 22 LTS or higher (Node 26 is also supported)

This enables Angular to leverage TS 6.0's improved type inference, const type parameters, and the new using declarations for resource management. The compiler-cli also adds explicit support for Node.js 26's new APIs.

The ng update schematic adds "strictTemplates": true to your tsconfig and disables the nullishCoalescingNotNullable and optionalChainNotNullable diagnostics that the TS 6.0 upgrade may trigger on existing templates. You can disable these manually if needed.

7. Other Notable Changes

@Service Decorator

A new dedicated @Service decorator for injectable services provides better factory function type safety and marks the service as injectable with a clearer intent than the generic @Injectable({ providedIn: 'root' }) pattern. The decorator is marked as stable in v22.

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

@Service()
export class UserService {
  constructor(private http: HttpClient) {}

  getUsers(): Signal<ResourceState<User[]>> {
    return httpResource(() => '/api/users');
  }
}

injectAsync

A new injectAsync helper function enables asynchronous dependency injection — useful for lazy-loading services, dynamic providers, or dependencies that require async initialization.

Router Changes

paramsInheritanceStrategy now defaults to 'always', meaning route parameters are inherited from all parent routes. provideRoutes() has been removed — use provideRouter() or the ROUTES multi token. Component input binding gains options for unmatched input behavior.

Incremental Hydration Default

Angular v22 enables incremental hydration by default for server-side rendered applications. Instead of hydrating the entire page at once, the framework hydrates components as they become visible or interactive — reducing Time to Interactive (TTI) significantly.

Removed APIs

• ComponentFactoryResolver and ComponentFactory — pass component classes directly to ViewContainerRef.createComponent()
• createNgModuleRef — use createNgModule instead
• ChangeDetectorRef.checkNoChanges — use fixture.detectChanges() in tests
• provideRoutes() — use provideRouter() or ROUTES multi token
• Hammer.js integration — removed entirely; use your own gesture library
• getAngularLib/setAngularLib — use getAngularJSGlobal/setAngularJSGlobal
• ServerXhr in @angular/platform-server — deprecated, use standard fetch APIs

Angular Aria in the Changelog

While Angular Aria was developed over several releases, v22 finalises it as a stable, documented module. The changelog also notes an important fix: ARIA property bindings are no longer renamed to attributes (commit f008045ded), ensuring that dynamic ARIA bindings in templates work correctly without unexpected attribute expansions.

Migration Guide: Angular 21 → 22

Here's the step-by-step migration checklist for upgrading from Angular 21 to 22:

1. Update Node.js to v22 LTS or higher
2. Update TypeScript to v6.0+: npm install typescript@~6.0
3. Run the update schematics: ng update @angular/core@22 @angular/cli@22 — this handles:
   • Adding ChangeDetectionStrategy.Eager where needed
   • Migrating provideRoutes() → provideRouter()
   • Updating provideHttpClient configuration
   • Enabling strictTemplates and disabling nullable diagnostics
   • Adding withXhr() for upload progress users
4. Replace ComponentFactory usages: pass component classes directly to ViewContainerRef.createComponent()
5. Review form validation: min and max validators no longer accept string values — use numbers or null
6. Remove withFetch() from provider config (it's now the default)
7. Test with OnPush: if any components relied on the old default change detection for mutable updates, add explicit ChangeDetectionStrategy.Eager or migrate to Signals
8. Verify template compatibility: data- prefixed attributes no longer bind inputs/outputs; in variables throw in template expressions; duplicate selectors trigger compile-time errors

FAQ

Should You Upgrade to Angular v22?

Yes — for most projects. The signal-first direction is clearly Angular's future, and v22 offers a stable foundation for that transition. Key considerations:

• New projects: Start with v22. Signal Forms and httpResource are stable and represent the recommended patterns going forward.
• Existing Angular 18-21 projects: The migration is well-automated. The schematics handle the breaking changes. The biggest manual effort is removing ComponentFactory usages, which were deprecated since v14.
• Large enterprise codebases: Plan the upgrade over a sprint. The OnPush default change may uncover components that relied on mutation-based change detection — identify those first with a dry run of the schematics.

I've been building Angular applications since Angular 2 (2016) and have migrated codebases from v2 through v21. The v22 upgrade is one of the smoothest major transitions yet — the schematics are comprehensive, and the signal-first architecture genuinely improves developer experience and application performance. If you need help planning or executing the migration, reach out.