🏗️ Framework (angular/angular)

Core & Reactivity

a) 🔥 Default change detection is now OnPush - PR

Components without an explicit changeDetection property now default to OnPush instead of the old Default (now renamed to Eager).

// Before Angular 22 — this was implicitly ChangeDetectionStrategy.Default
@Component({
  selector: ‘app-dashboard’,
  template: `<h1>{{ title }}</h1>`,
})
export class DashboardComponent {
  title = ‘Dashboard’;
}

// Angular 22 — same code is now implicitly OnPush
// If you need the old behavior:
@Component({
  selector: ‘app-dashboard’,
  changeDetection: ChangeDetectionStrategy.Eager, // ← new name for “Default”
  template: `<h1>{{ title }}</h1>`,
})
export class DashboardComponent {
  title = ‘Dashboard’;
}

b) Signal-native debouncing with debounced() - PR

Angular added a debounced() function that takes a signal and a wait time, and returns a Resource.

protected readonly searchInput = signal(’‘);

// Debounced — settles after 500ms of no typing
protected readonly debouncedSearch = debounced(() => this.searchInput(), 500);

The resource gives you .value(), .status(), .isLoading(), and .error() — loading states come for free. I wrote a full deep-dive on this: check out my Debounced Signals in Angular 22 article.

c) Nested leave animations scoped to component boundaries - PR

Leave animations are no longer limited to just the element being removed. They now propagate to nested elements within the same component boundary. If you have a parent element with :leave and child elements with their own animations, the children will now animate out properly before the parent is removed.

This is a breaking change if you relied on the old behavior where nested leave animations were silently ignored.

d) Special return statuses for resource params - PR

Resources now support special return statuses from their params function. Instead of always returning params (which triggers a load), you can now return undefined to put the resource in an idle state — meaning it won’t fetch until valid params are available.

type UserSearchParams = { query: string };

@Component({
  selector: ‘app-user-search’,
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `
    <input (input)=”searchQuery.set($any($event.target).value)” placeholder=”Search users...” />

    @switch (users.status()) {
      @case (’idle’) { <p>Type something to search</p> }
      @case (’loading’) { <p>Searching...</p> }
      @case (’resolved’) {
        @for (user of users.value(); track user.id) {
          <p>{{ user.name }}</p>
        }
      }
      @case (’error’) { <p>Something went wrong</p> }
    }
  `,
})
export class UserSearchComponent {
  protected readonly searchQuery = signal(’‘);

  protected readonly users = httpResource<User[]>(() => {
    const query = this.searchQuery();

    // Return undefined → resource stays idle, no request fired
    if (query.length < 2) return undefined;

    return `/api/users?q=${encodeURIComponent(query)}`;
  });
}

The idle status is new — before this, a resource would always be in loading, resolved, or error. Now you can distinguish between “hasn’t started yet” and “currently fetching.”

Learn more about Angular resources here.

e) TestBed.getLastFixture() - PR

A new testing utility that returns the last created ComponentFixture. Originally introduced as TestBed.getFixture() in next.0, it was renamed to TestBed.getLastFixture() in next.4 for clarity.

it(’should render the component’, () => {
  TestBed.configureTestingModule({
    imports: [MyComponent],
  });

  const fixture = TestBed.createComponent(MyComponent);
  
  // Later in the test, if you need the fixture again:
  const sameFixture = TestBed.getLastFixture();
  expect(sameFixture).toBe(fixture);
});

f) Customizable @defer idle behavior - PR & PR

Two related changes that give you more control over @defer blocks with idle triggers:

1. IdleRequestOptions support — you can now customize the idle service behavior

2. Optional timeout for idle triggers — set a maximum wait time for idle-triggered defer blocks

// You can now configure idle behavior with timeout
@defer (on idle; timeout 5000) {
  <app-heavy-widget />
}

This is useful when you want a defer block to load during idle time but don’t want to wait forever if the browser stays busy.

g) Exhaustive type checking for @switch - PR

The @switch control flow now supports exhaustive type checking with other expressions. The compiler can verify that all possible values of a union type are handled:

type Status = ‘active’ | ‘inactive’ | ‘pending’;

@Component({
  template: `
    @switch (status()) {
      @case (’active’) { <span>Active</span> }
      @case (’inactive’) { <span>Inactive</span> }
      @case (’pending’) { <span>Pending</span> }
    }
  `,
})
export class StatusComponent {
  status = input.required<Status>();
}

h) ⚠️ createNgModuleRef removed - PR

The deprecated createNgModuleRef function has been removed. Use createNgModule instead:

// No more createNgModuleRef
const moduleRef = createNgModule(MyModule, injector);

i) ⚠️ ChangeDetectorRef.checkNoChanges removed - PR

ChangeDetectorRef.checkNoChanges has been removed from the public API. In tests, use fixture.detectChanges() instead.

j) ⚠️ AnimationCallbackEvent.animationComplete signature changed - PR

The animationComplete callback signature on AnimationCallbackEvent has been enhanced. If you’re using this API directly, check the new signature.

// strictly typed as VoidFunction
type AnimationCallbackEvent = {
  target: Element;
  animationComplete: VoidFunction;
};

k) Migration schematic: ChangeDetectionStrategy.Eager - PR

Since the default changed to OnPush, Angular provides a migration schematic that automatically adds ChangeDetectionStrategy.Eager to components that previously relied on the implicit Default strategy. Run it during ng update.

l) De-duplicate host directives - PR

If the same directive appears multiple times in a host directive chain (through inheritance or composition), it’s only applied once. Before this, duplicates could cause unexpected double-initialization or conflicting behavior.

@Directive({ host: { class: ‘tooltip’ } })
export class TooltipDirective {}

// Both BaseCard and FancyCard declare TooltipDirective as a host directive
@Component({
  selector: ‘app-base-card’,
  hostDirectives: [TooltipDirective],
  template: `<ng-content />`,
})
export class BaseCardComponent {}

@Component({
  selector: ‘app-fancy-card’,
  hostDirectives: [TooltipDirective], // duplicate — now de-duplicated automatically
  template: `<ng-content />`,
})
export class FancyCardComponent extends BaseCardComponent {}

m) ⚠️ Drop support for TypeScript 5.9 - PR

Angular 22 now requires TypeScript 6.0 or later. TypeScript 5.9 and older are no longer supported. Make sure to update your TypeScript dependency when upgrading.

n) ⚠️ ComponentFactoryResolver & ComponentFactory removed - PR

ComponentFactoryResolver and ComponentFactory have been completely removed from the API surface. These were deprecated long ago in favor of passing component classes directly.

// Before ❌ — using the factory pattern
const factory = this._resolver.resolveComponentFactory(MyComponent);
const componentRef = viewContainerRef.createComponent(factory);

// After ✅ — pass the component class directly
const componentRef = viewContainerRef.createComponent(MyComponent);

// Or use the standalone function:
const componentRef = createComponent(MyComponent, { environmentInjector });

If you’re still using ComponentFactoryResolver anywhere — in dynamic component loading, lazy modules, or testing utilities — this is the migration you need to make.

o) Bootstrap via ApplicationRef with config - PR

ApplicationRef.bootstrap() now accepts a configuration object as its second argument. The type has been tightened — it no longer accepts any, so you need to pass a proper non-nullable element.

// Before — second arg was loosely typed as `any`
appRef.bootstrap(AppComponent, document.getElementById(’app’));

// Angular 22 — stricter typing, element must be non-nullable
const rootEl = document.getElementById(’app’);
if (rootEl) {
  appRef.bootstrap(AppComponent, rootEl);
}

This is a breaking change if you were passing a potentially nullable element without checking first.

p) Synchronous Values for Stream Resources - PR

Stream resources (resource() with a stream loader) previously required the loader to return a PromiseLike<Signal<ResourceStreamItem<T>>>. That async requirement meant the resource always started in a loading state — even when the data was available immediately.

This was a real problem for SSR scenarios. When you’re trying to cache resource values in TransferState, the resource needs to set its value synchronously. Otherwise, it enters loading state on the client, which destroys the server-hydrated DOM before the value arrives.

The ResourceStreamingLoader type now accepts three return types:

// New type signature
type ResourceStreamingLoader<T, R> = (
  param: ResourceLoaderParams<R>
) => Signal<ResourceStreamItem<T>>       // ← NEW: synchronous
   | PromiseLike<Signal<ResourceStreamItem<T>>>  // existing async
   | undefined;                                   // ← NEW: skip loading

What this enables:

@Component({
  template: `
    @if (weather.value(); as data) {
      <p>{{ data.temperature }}°C in {{ data.city }}</p>
    }
  `
})
export class WeatherComponent {
  private _city = input.required<string>();
  private _cache = inject(TransferStateCache);

  weather = resource({
    params: this._city,
    stream: ({ params: city }) => {
      // Check cache first — returns synchronously if cached
      const cached = this._cache.get<WeatherData>(`weather-${city}`);
      if (cached) {
        // Resource is immediately 'resolved', no loading flicker
        return signal({ value: cached });
      }

      // Fall back to async fetch
      return this._fetchWeather(city);
    },
  });

  private async _fetchWeather(
    city: string
  ): Promise<Signal<ResourceStreamItem<WeatherData>>> {
    const response = await fetch(`/api/weather?city=${city}`);
    const data: WeatherData = await response.json();
    return signal({ value: data });
  }
}

The key win: rxResource with synchronous observables (like of(value)) now resolves immediately after a tick instead of requiring await appRef.whenStable(). This makes SSR hydration seamless — the client picks up the cached value without any loading state flash.

q) Support Bootstrapping Under Shadow Roots - PR

Angular applications can now be bootstrapped inside a Shadow DOM root. Previously, bootstrapApplication assumed it was working with the document’s root — which broke when you tried to embed an Angular app inside a web component’s shadow root.

This is a big deal for micro-frontend architectures and web component integration scenarios:

// Bootstrap Angular inside a shadow root
const shadowRoot = hostElement.attachShadow({ mode: 'open' });

const appDiv = document.createElement('div');
appDiv.id = 'angular-app';
shadowRoot.appendChild(appDiv);

bootstrapApplication(AppComponent, {
  ...appConfig,
  // Angular now correctly scopes to the shadow root
  // instead of assuming document-level access
});

This means Angular can coexist with other frameworks on the same page without style or DOM conflicts, each living in its own shadow boundary. If you’re building micro-frontends or embedding Angular widgets in non-Angular pages, this removes a significant barrier.

r) The New @Service Decorator - PR

This is a big one. Angular now has a dedicated @Service decorator that’s purpose-built for the most common use case: defining a singleton service available across your entire app.

@Injectable has been around since Angular 2, and it carries a lot of historical baggage. Most developers just want to create a service that’s providedIn: 'root', uses inject() for dependencies, and doesn’t need the complex provider configurations (useClass, useValue, useFactory, etc.). Yet every time, you have to write @Injectable({ providedIn: 'root' }) — boilerplate that adds noise without adding value.

@Service fixes this by making the common case the default. Here’s what’s different:

1. providedIn: 'root' by default. No configuration needed for the 90% case. If you want to provide the service yourself, set autoProvided: false.

2. No constructor-based injection. Only the inject() function is supported. This aligns with where Angular has been heading for a while now.

3. Simplified factory support. Instead of the complex useClass/useValue/useExisting/useFactory signature from @Injectable, @Service supports a single factory function.

// Before: @Injectable with boilerplate ❌
import { Injectable, inject } from '@angular/core';
import { HttpClient } from '@angular/common/http';

@Injectable({ providedIn: 'root' })
export class PostService {
  private readonly _httpClient = inject(HttpClient);

  getUserPosts(userId: string) {
    return this._httpClient.get<Post[]>(`/api/posts/${userId}`);
  }
}

// After: @Service — clean and intentional ✅
import { Service, inject } from '@angular/core';
import { HttpClient } from '@angular/common/http';

@Service()
export class PostService {
  private readonly _httpClient = inject(HttpClient);

  getUserPosts(userId: string) {
    return this._httpClient.get<Post[]>(`/api/posts/${userId}`);
  }
}

The difference looks small in a single file, but across a codebase with hundreds of services, the intent becomes much clearer. @Service() says “this is a singleton service” without any ceremony.

When you don’t want automatic root-level providing — say, for a service scoped to a specific component or route — you opt out explicitly:

@Service({ autoProvided: false })
export class PanelStateService {
  private readonly _isOpen = signal(false);

  readonly isOpen = this._isOpen.asReadonly();

  toggle(): void {
    this._isOpen.update((open) => !open);
  }
}

And if you need a custom factory (the equivalent of useFactory in @Injectable):

@Service({
  factory: () => {
    const config = inject(AppConfig);
    const http = inject(HttpClient);
    return new ApiService(config.apiBaseUrl, http);
  },
})
export class ApiService {
  constructor(
    private readonly _baseUrl: string,
    private readonly _http: HttpClient
  ) {}

  get<T>(path: string) {
    return this._http.get<T>(`${this._baseUrl}${path}`);
  }
}

One thing worth noting: @Service enforces inject()-only dependency resolution. If you try to use constructor parameters for DI, the compiler will throw a SERVICE_CONSTRUCTOR_DI error. This is intentional — the Angular team is pushing the ecosystem toward inject() as the standard pattern, and @Service draws that line clearly.

@Injectable isn’t going anywhere. It’s still fully supported for cases that need its flexibility. But for new services, @Service is the cleaner, more opinionated choice.

s) Testability Now Uses PendingTasks for Stability - PR

Angular’s Testability service — the one that powers whenStable() for tools like Protractor and E2E testing frameworks — has been updated to use PendingTasks as its stability indicator. This is a significant step toward making the testing infrastructure work seamlessly in zoneless applications.

Here’s the backstory. Angular’s stability concept has historically been tied to Zone.js. The Testability.isStable() method checked whether the NgZone was stable and had no pending macrotasks. That worked fine when Zone.js was the only game in town, but it completely broke for zoneless apps — there was no Zone to check.

Meanwhile, Angular has been building PendingTasks as a zone-agnostic way to track async work. The Router and HttpClient already contribute to PendingTasks. This commit connects the dots: Testability now checks PendingTasks in addition to Zone stability.

The behavior depends on your setup:

• Zoneless apps (no Zone.js present): PendingTasks is used automatically. whenStable() resolves when there are no pending tasks — no configuration needed.

• Zone.js apps: The old Zone-based stability check still works by default. You can opt into PendingTasks-based stability through provideProtractorTestingSupport().

// Zoneless app — PendingTasks stability works automatically ✅
export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(routes),
    provideHttpClient(),
    provideExperimentalZonelessChangeDetection(),
    // whenStable() now works correctly without Zone.js
  ],
};

// Zone.js app — opt into PendingTasks stability explicitly
import { provideProtractorTestingSupport } from '@angular/platform-browser';

export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(routes),
    provideHttpClient(),
    provideProtractorTestingSupport({
      usePendingTasksForStability: true,
    }),
  ],
};

The isStable() method now evaluates three conditions instead of two:

// Internal logic (simplified)
isStable(): boolean {
  return (
    this._isZoneStable &&
    !this._ngZone.hasPendingMacrotasks &&
    (!this._usePendingTasks || !this.pendingTasksInternal.hasPendingTasks)
  );
}

What this means for you in practice: if you’re migrating to zoneless and your E2E tests use whenStable() (directly or through a testing framework), they’ll now work correctly. The Router navigation, HttpClient requests, and any custom PendingTasks usage will all be tracked as part of application stability.

t) injectAsync — lazy-load and inject services on demand - PR

Here’s the thing about lazy loading in Angular: we’ve had lazy routes for ages, but lazy-loading services has always been awkward. You’d typically need to grab an EnvironmentInjector, dynamically import the service class, then manually call injector.get(). It worked, but it wasn’t ergonomic.

injectAsync is a new helper function exported from @angular/core that streamlines this pattern. It returns a function that, when called, resolves to an instance of the lazily-loaded service — fully wired through DI.

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

@Component({
  selector: 'app-dashboard',
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `
    <button (click)="loadChart()">Show Chart</button>
  `,
})
export class DashboardComponent {
  // Returns a function: () => Promise<ChartService>
  private _chartService = injectAsync(
    () => import('./chart.service').then((m) => m.ChartService),
  );

  async loadChart(): Promise<void> {
    const chartService = await this._chartService();
    chartService.render();
  }
}

u) SSR resource caching - PR

Angular’s resource() and rxResource() now support a new id option that enables automatic caching through TransferState. This is the missing piece for SSR + signals: data fetched on the server gets serialized into the HTML, and when the client hydrates, the resource resolves synchronously from the cache instead of making a redundant network request.

Here’s the problem this solves. Without caching, your SSR flow looks like:

1. Server renders → resource fetches data → HTML sent to client

2. Client hydrates → resource fetches the same data again → flash of loading state

With the id option, step 2 becomes: client hydrates → resource reads from TransferState → instant resolution, no network call, no loading flicker.

import { resource } from '@angular/core';
import { inject } from '@angular/core';

@Component({
  selector: 'app-product-detail',
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `
    @if (product.status() === 'resolved') {
      <h1>{{ product.value().name }}</h1>
      <p>{{ product.value().description }}</p>
    }
  `,
})
export class ProductDetailComponent {
  private _productId = input.required<string>();
  private _http = inject(HttpClient);

  product = resource({
    params: () => ({ id: this._productId() }),
    loader: ({ params }) =>
      firstValueFrom(this._http.get<Product>(`/api/products/${params.id}`)),
    id: 'product-detail', // ← enables TransferState caching
  });
}

The id is a string added to BaseResourceOptions. It serves as the TransferState key. When the resource resolves on the server, the value is written to TransferState under that key. On the client, if a matching key exists in TransferState, the resource skips the loader entirely and resolves synchronously with the cached value.

This also works with rxResource():

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

export class DashboardComponent {
  private _http = inject(HttpClient);

  metrics = rxResource({
    stream: () => this._http.get<DashboardMetrics>('/api/metrics'),
    id: 'dashboard-metrics',
  });
}

This is different from HttpClient‘s transferCache option (which caches HTTP responses at the interceptor level). The id option works at the resource level, meaning it caches the final resolved value regardless of how you fetched it — HTTP, WebSocket, IndexedDB, whatever your loader does.

One thing to note: you need provideClientHydration() in your app config for TransferState to work. If you’re already using SSR with hydration, you likely have this set up.

Templates & Compiler

a) Support comments in HTML elements - PR

Angular’s template parser now supports HTML comments inside elements.

<!-- This now works as expected everywhere in templates -->
<p>Subscribe to codigotipado!</p>

b) ⚠️ Compile-time diagnostic for duplicate selectors (NG8023) - PR

Angular now throws a compile-time error when multiple components or directives share the same selector within the same scope. Before this, the behavior was undefined — sometimes one would win, sometimes you’d get subtle bugs that were painful to track down.

The new diagnostic NG8023 catches this at build time:

// This now throws NG8023 at compile time
@Component({
  selector: ‘app-card’,
  template: `<p>Card A</p>`,
})
export class CardAComponent {}

@Component({
  selector: ‘app-card’, // Duplicate selector!
  template: `<p>Card B</p>`,
})
export class CardBComponent {}

error NG8023: Multiple components match node with selector "app-card".

If you have duplicate selectors in your codebase, you’ll need to rename one of them. This is a breaking change, but honestly it’s catching a bug you already had.

c) Warning for @defer prefetch without main trigger - PR

The compiler now emits a warning when you use prefetch on a @defer block without specifying a main trigger. This catches a common mistake — if there’s no trigger to actually load the deferred content, the prefetch is pointless.

<!-- ⚠️ Warning: prefetch without a main trigger does nothing -->
@defer (prefetch on idle) {
  <app-heavy-widget />
}

<!-- ✅ Correct: has both a trigger and a prefetch strategy -->
@defer (on viewport; prefetch on idle) {
  <app-heavy-widget />
}

This is a compile-time warning, not an error — your app will still build. But it’s a strong hint that something’s off in your defer configuration.

d) ⚠️ Safe Navigation Now Correctly Narrows Nullables - PR

This one's been a long time coming. Since 2020, Angular's safe navigation operator (?.) in templates didn't actually narrow types the way TypeScript does in regular code. That meant you couldn't rely on ?. checks to eliminate null | undefined from subsequent expressions — the type system just ignored the narrowing.

BREAKING CHANGE: This will trigger nullishCoalescingNotNullable and optionalChainNotNullable diagnostics on existing projects. If you're seeing a flood of new warnings after updating, you can temporarily disable those two diagnostics in your tsconfig.json:

// tsconfig.json
{
  "angularCompilerOptions": {
    "extendedDiagnostics": {
      "checks": {
        "nullishCoalescingNotNullable": "suppress",
        "optionalChainNotNullable": "suppress"
      }
    }
  }
}

Or, if you want to disable narrowing entirely (not recommended long-term):

{
  "angularCompilerOptions": {
    "strictSafeNavigationTypes": false
  }
}

Here’s what this actually means in practice:

// Before: Angular didn't narrow after ?. — this compiled fine even though it's redundant
@Component({
  template: `
    @if (user?.name) {
      <!-- user.name was still typed as string | undefined here -->
      {{ user?.name ?? 'fallback' }}  <!-- no warning, even though ?? is unnecessary -->
    }
  `
})

// After ✅: Angular correctly narrows — you'll get a warning about the unnecessary ??
@Component({
  template: `
    @if (user?.name) {
      <!-- user.name is now correctly narrowed to string -->
      {{ user.name }}  <!-- clean, no need for ?. or ?? -->
    }
  `
})

The ng update migration (covered below in Migrations) will automatically disable these diagnostics so you can update without being blocked, then fix them at your own pace.

e) ⚠️ Optional chaining now returns undefined instead of null - PR

This is a big one. Angular’s template compiler has historically treated the safe navigation operator (?.) differently from standard JavaScript/TypeScript. In vanilla JS, foo?.bar returns undefined when foo is nullish. But Angular templates used to return null. That inconsistency has been a source of subtle bugs for years — particularly when comparing values in templates or passing them to functions that distinguish between null and undefined.

Angular expressions with optional chaining now correctly return undefined, aligning template behavior with the JavaScript specification.

<!-- Given: user: { address?: { city?: string } } = {} -->

<!-- Before: this evaluated to null ❌ -->
<!-- After: this evaluates to undefined ✅ (matching JS behavior) -->
{{ user?.address?.city }}

<!-- This matters when you do strict comparisons -->
@if (user?.address?.city === undefined) {
  <p>No city provided</p>
}

Migration path: If you have code that explicitly checks for null from optional chaining results, you’ll need to update those checks. The Angular team provides two escape hatches:

1. $null() magic function — wrap any expression to preserve the old behavior:

<!-- Opt-out: preserves legacy null-returning behavior -->
{{ $null(user?.address?.city) }}

2. legacyOptionalChaining compiler option — a project-wide flag in tsconfig.json:

{
  "angularCompilerOptions": {
    "legacyOptionalChaining": true
  }
}

The legacyOptionalChaining flag is meant as a temporary migration aid. It won’t stick around forever — plan to remove it once you’ve audited your templates.

What’s interesting is how the linker handles backward compatibility: libraries compiled with Angular < 22 automatically get the legacy behavior applied, so you don’t need to worry about third-party packages breaking.

f) Node.js 26.0.0 support - PR

g) External TCBs with copied content in specific mode - PR

Enables better type-checking accuracy when working with templates in external files.

Forms

Signal Forms got a lot of love in this release. Learn more about Angular Signal Forms here.

a) debounce() with ‘blur’ option - PR

The debounce() rule in Signal Forms now supports a 'blur' mode. Instead of debouncing by time, validation only fires when the field loses focus:

import { form, debounce, validateAsync } from ‘@angular/forms/signals’;

const myForm = form(data, (path) => {
  // Validation fires only when the user leaves the field
  debounce(path.username, ‘blur’);

  validateAsync(path.username, {
    params: (ctx) => ({ username: ctx.value() }),
    factory: (params) => httpResource(() => `/api/check-username?u=${params.username}`),
    onSuccess: (result) => (result.taken ? { usernameTaken: true } : null),
  });
});

This is perfect for fields where partial values are meaningless — IBANs, coupon codes, usernames. No point validating “Lond” against an API when the user clearly isn’t done typing.

b) reloadValidation() for Signal Forms - PR

You can now manually trigger async validation on a signal form field with reloadValidation(). This is useful when external state changes and you need to re-validate without the user modifying the field — think of a coupon code field that should re-validate when the cart contents change.

import { form, validateAsync, reloadValidation } from ‘@angular/forms/signals’;

@Component({
  selector: ‘app-checkout’,
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `
    <input [formField]=”couponField” placeholder=”Coupon code” />
    @if (couponField.errors()?.invalidCoupon) {
      <span>This coupon is no longer valid for your cart</span>
    }
    <button (click)=”onCartChanged()”>Recalculate</button>
  `,
})
export class CheckoutComponent {
  private readonly _cartService = inject(CartService);

  protected readonly data = signal({ coupon: ‘’ });

  protected readonly checkoutForm = form(this.data, (path) => {
    validateAsync(path.coupon, {
      params: (ctx) => ({ code: ctx.value(), cartTotal: this._cartService.total() }),
      factory: (params) =>
        httpResource(() => `/api/validate-coupon?code=${params.code}&total=${params.cartTotal}`),
      onSuccess: (result) => (result.valid ? null : { invalidCoupon: true }),
    });
  });

  protected get couponField() {
    return this.checkoutForm.controls.coupon;
  }

  onCartChanged(): void {
    // Cart changed — re-validate the coupon without the user touching the field
    reloadValidation(this.checkoutForm.controls.coupon);
  }
}

c) Debounce option for validateAsync and validateHttp - PR

Async validators now accept a debounce configuration directly, so you don’t always need a separate debounce() rule:

// validateAsync with built-in debounce
validateAsync(path.city, {
  debounce: 500,
  params: (ctx) => ({ city: ctx.value() }),
  factory: (params) => httpResource(() => `/api/validate-city?name=${params.city}`),
  onSuccess: (result) => (result.valid ? null : { invalidCity: true }),
});

// validateHttp with built-in debounce — same pattern
validateHttp(path.email, {
  debounce: 300,
  request: (ctx) => `/api/check-email?email=${encodeURIComponent(ctx.value())}`,
  onSuccess: (response) => (response.available ? null : { emailTaken: true }),
});

Before this, you had to pair every async validator with a separate debounce() call. Now it’s a single declaration. The debounce option accepts a number (milliseconds) or 'blur' — same as the standalone debounce() rule.

d) FieldState.getError() - PR

A new convenience method to retrieve a specific error from a field’s validation state:

const emailError = fieldState.getError(’email’);
// Returns the error value or undefined

e) Support binding number | null to <input type="text"> - PR

Signal Forms now properly handle binding number | null values to text inputs. Before this, you’d get type errors or unexpected behavior when a numeric field could be null.

type ProductForm = {
  name: string;
  price: number | null;  // nullable numeric field
  discount: number | null;
};

const data = signal<ProductForm>({
  name: ‘Widget’,
  price: 29.99,
  discount: null, // no discount yet
});

const productForm = form(data, (path) => {
  validate(path.name, required);
});

<!-- This now works without type errors -->
<input type=”text” [formField]=”productForm.controls.price” />
<input type=”text” [formField]=”productForm.controls.discount” />

When the value is null, the input displays empty. When the user types a number, it’s parsed back to number. Clean round-trip for nullable numeric fields.

f) ngNoCva opt-out for ControlValueAccessors - PR

A new ngNoCva attribute lets you opt out of ControlValueAccessor binding on specific elements. This is useful when you have a custom form control but don’t want Angular’s CVA machinery to interfere with certain child elements.

<!-- This input won’t get a ControlValueAccessor attached -->
<input ngNoCva type=”text” />

g) Template & reactive support for FVC - PR

Form Validation Controls (FVC) now work with both template-driven and reactive forms approaches, expanding the interop surface between Signal Forms and the existing form systems.

// Template-driven: FVC works with ngModel
@Component({
  selector: ‘app-profile’,
  changeDetection: ChangeDetectionStrategy.OnPush,
  imports: [FormsModule, SignalFormsModule],
  template: `
    <input [(ngModel)]=”name” [formValidation]=”nameValidation” />
    @if (nameValidation.errors()?.required) {
      <span>Name is required</span>
    }
  `,
})
export class ProfileComponent {
  protected name = ‘’;
  protected readonly nameValidation = fieldValidation(/* ... */);
}

// Reactive: FVC works with FormControl
@Component({
  selector: ‘app-settings’,
  changeDetection: ChangeDetectionStrategy.OnPush,
  imports: [ReactiveFormsModule, SignalFormsModule],
  template: `
    <input [formControl]=”emailControl” [formValidation]=”emailValidation” />
  `,
})
export class SettingsComponent {
  protected readonly emailControl = new FormControl(’‘);
  protected readonly emailValidation = fieldValidation(/* ... */);
}

h) ⚡ Lazily instantiate signal form fields - PR

A performance improvement that defers the instantiation of signal form fields until they’re actually needed. For large forms with many fields, this reduces the initial creation cost.

i) Shim Legacy NG_VALIDATORS into parseErrors for CVA Mode - PR

Signal Forms CVA (ControlValueAccessor) interop mode now properly bridges legacy NG_VALIDATORS into the new parseErrors system. If you have existing custom validators registered through the legacy NG_VALIDATORS token, they’ll now work correctly when used alongside Signal Forms CVA mode.

This is about backward compatibility. As the Angular team builds out Signal Forms, they need to ensure that existing form infrastructure doesn’t break. This shim means you can incrementally adopt Signal Forms without rewriting all your custom validators at once:

// Your existing validator directive still works with Signal Forms CVA mode
@Directive({
  selector: '[appCustomValidator]',
  providers: [
    {
      provide: NG_VALIDATORS,
      useExisting: CustomValidatorDirective,
      multi: true,
    },
  ],
})
export class CustomValidatorDirective implements Validator {
  validate(control: AbstractControl): ValidationErrors | null {
    return control.value?.length > 10 ? { tooLong: true } : null;
  }
}

// These legacy validators now correctly surface in Signal Forms' parseErrors
// No migration needed — the shim handles the bridging automatically

j) 🎉 Signal forms APIs graduate to public API - PR

This is the big one. Signal-based forms — which have been in developer preview — are now part of Angular's stable public API. This means the APIs are subject to Angular's semantic versioning guarantees and won't have breaking changes outside major versions.

Read full guide about Angular Signal Forms here.

k) ⚡ Performance: shallow array equality for reactivity - PR

Signal forms now use shallow array equality checks when determining whether reactive values have changed. Previously, any mutation to an array (even if the contents were identical) would trigger downstream recomputation. Now, if the array elements are the same by reference, the signal won’t notify dependents.

This reduces unnecessary change detection cycles in forms with array-based controls (like dynamic field lists or multi-select values).

l) ⚡ Performance: shortcut deepSignal writes if value is unchanged - PR

When writing to a deep signal (nested form state), the framework now short-circuits if the new value is identical to the current one. No notification, no recomputation, no template re-render. This is a targeted optimization for forms where programmatic resets or patches might write the same value back.

m) ⚠️ min and max validation rules no longer accept strings - PR

The min and max validation rules in signal forms no longer accept string values. Bound values must be number | null.

// Before — strings were silently accepted ❌
this._fb.field(0, { validators: [min('5')] });

// After — must be number or null ✅
this._fb.field(0, { validators: [min(5)] });

If you were passing string values (perhaps from template bindings), you’ll need to parse them to numbers first.

HTTP

a) ⚠️ FetchBackend is now the default HTTP backend - PR

provideHttpClient() now uses FetchBackend by default instead of HttpXhrBackend. The Fetch API is more modern, supports streaming, and aligns with where the web platform is heading.

What this means:

• Upload progress reports are no longer available by default (Fetch API limitation)

• If you need upload progress, use withXhr():

// Before (Angular 21) — XHR was the default
provideHttpClient()

// Angular 22 — Fetch is the default. Same call, different backend.
provideHttpClient()

// If you need XHR (for upload progress):
provideHttpClient(withXhr())

There’s a migration schematic that adds withXhr() where needed. withFetch() is now deprecated since Fetch is the default — you can safely remove it.

b) reportUploadProgress & reportDownloadProgress replace reportProgress - commit 7c8c334

The monolithic reportProgress option on HTTP requests is now deprecated. In its place, two granular options give you explicit control over which direction of progress you want to track:

// Before — reported both upload AND download progress ❌ (deprecated)
this._http.post('/upload', formData, {
  reportProgress: true,
  observe: 'events',
});

// After — explicit about what you're tracking ✅
this._http.post('/upload', formData, {
  reportUploadProgress: true,
  observe: 'events',
});

// Or for downloads:
this._http.get('/large-file', {
  reportDownloadProgress: true,
  observe: 'events',
});

// Or both:
this._http.post('/upload-with-response', formData, {
  reportUploadProgress: true,
  reportDownloadProgress: true,
  observe: 'events',
});

This split makes intent clearer and avoids the overhead of tracking progress in a direction you don’t care about. Most file upload UIs only need upload progress; most download UIs only need download progress. Now you can be explicit.

Router

a) withComponentInputBinding options - PR

withComponentInputBinding() now accepts an optional config to control which router sources bind to your component inputs:

// Disable query param binding — only path params and route data bind
provideRouter(routes, withComponentInputBinding({ queryParams: false }));

Before this, it was all or nothing. Now you can prevent query parameters from overriding your component inputs — which is a real hygiene improvement since query params are user-controlled. I wrote a full article about this one: Selective Component Input Binding in Angular 22.

b) browserUrl input support for router links - PR

Router links now support a browserUrl input that lets you display a different URL in the browser’s address bar than the actual route being navigated to. This was already possible with router.navigateByUrl() via NavigationBehaviorOptions, but now it works declaratively in templates.

@Component({
  selector: ‘app-product-list’,
  changeDetection: ChangeDetectionStrategy.OnPush,
  imports: [RouterLink],
  template: `
    @for (product of products(); track product.id) {
      <!-- Navigates to /products/42/details internally,
           but the browser shows /products/cool-widget -->
      <a
        [routerLink]=”[’/products’, product.id, ‘details’]”
        [browserUrl]=”’/products/’ + product.slug”
      >
        {{ product.name }}
      </a>
    }
  `,
})
export class ProductListComponent {
  products = input.required<Product[]>();
}

The browserUrl input accepts a string or UrlTree. This is useful for SEO-friendly URLs, vanity URLs, or when your internal route structure doesn’t match the URL you want users to see and share. It works on both <a> elements and non-anchor elements with [routerLink].

c) ⚠️ provideRoutes() removed - PR bdb6ae9

The deprecated provideRoutes() function has been removed. Use provideRouter() or the ROUTES multi token instead:

// Before ❌
provideRoutes(myRoutes)

// After ✅
provideRouter(myRoutes)

// Or if you need the multi-token approach:
{ provide: ROUTES, useValue: myRoutes, multi: true }

d) unmatchedInputBehavior option for componentInputBinding - PR

When you enable withComponentInputBinding() in the router, route parameters and query params are automatically bound to component inputs. But what happens when a route parameter doesn’t match any input on the component? Previously, it was silently ignored.

The new unmatchedInputBehavior option lets you control this:

import { provideRouter, withComponentInputBinding } from '@angular/router';

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

This is useful for catching typos in route configurations or detecting when route params change names but components haven’t been updated. In development, setting this to 'warn' or 'error' helps catch mismatches early.

Rendering & Platform

a) ⚠️ Hammer.js integration removed - PR

The built-in Hammer.js integration has been completely removed. If you’re using gesture events like (swipe), (pinch), (rotate), etc., you’ll need to implement your own gesture handling or use a third-party library directly.

// Before ❌ — Angular handled Hammer.js integration
import { HammerModule } from ‘@angular/platform-browser’;

// After ✅ — Use Hammer.js directly or switch to Pointer Events
// Install hammerjs yourself and set it up manually,
// or migrate to native pointer events

For most apps, the Pointer Events API is the modern replacement.

b) Incremental Hydration Is Now the Default - PR

Incremental hydration is no longer opt-in — it’s the default behavior. Previously, you had to explicitly enable it. Now, when your application uses SSR with hydration, Angular will incrementally hydrate components as they become needed rather than hydrating the entire page at once.

What does this mean in practice? Your SSR pages will become interactive faster because Angular only hydrates the components that the user is actually interacting with. A component at the bottom of a long page won’t be hydrated until the user scrolls to it (or it’s triggered by some other interaction).

// Before: you had to explicitly opt in
// provideClientHydration(withIncrementalHydration())

// After ✅: incremental hydration is on by default
// Just use provideClientHydration() — incremental behavior is included
export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(routes),
    provideClientHydration(),  // incremental hydration is now default
  ],
};

You can still use @defer blocks to control hydration triggers:

@Component({
  template: `
    <header>
      <app-nav />
    </header>

    <main>
      <app-hero-section />

      @defer (on viewport) {
        <app-comments-section />  <!-- Only hydrates when scrolled into view -->
      }

      @defer (on interaction) {
        <app-feedback-form />  <!-- Only hydrates when user interacts -->
      }
    </main>
  `
})
export class PageComponent {}

This is a meaningful performance win for content-heavy pages. The initial Time to Interactive (TTI) drops because Angular isn’t spending time hydrating components the user hasn’t reached yet.

Developer Tooling

a) Angular DI Graph In-Page AI Tool - PR

Angular now ships a built-in AI tool that exposes the dependency injection graph at runtime. This is part of the broader push to make Angular applications introspectable by AI assistants and developer tools.

The DI graph tool lets AI-powered debugging assistants (think: Copilot, Gemini, or custom MCP tools) query the injector hierarchy, understand which services are provided where, and trace dependency chains — all from within the running application.

b) Register AI Runtime Debugging Tools - PR

Closely related to the DI graph tool above, this commit establishes the infrastructure for registering AI runtime debugging tools in Angular. It provides the foundation that allows Angular to expose runtime information (component trees, signal states, DI graphs) to external AI tools.

Think of it as the plumbing that makes the DI graph tool (and future AI tools) possible. The framework now has a standardized way to register and expose debugging capabilities that AI assistants can consume.

c) Enhanced Profiling with Documentation URLs - PR

Angular’s profiling output now includes links to relevant documentation. When you’re profiling your application and see a particular operation taking time, the profiler will point you directly to the docs that explain what that operation does and how to optimize it.

It’s a small but thoughtful improvement. Instead of seeing a cryptic profiling label and having to search the docs yourself, you get a direct link. This is especially helpful for developers who are newer to Angular’s internals.

d) provideWebMcpTools — MCP integration for Angular apps - PR

Angular is going all-in on AI tooling. provideWebMcpTools is a new provider function that registers WebMCP tools directly through Angular’s dependency injection system. MCP (Model Context Protocol) is the open standard that lets AI assistants — Claude, Copilot, Cursor, etc. — interact with your running application: inspecting component state, triggering actions, querying data.

Here’s what makes this interesting: the tools are tied to the lifecycle of the Injector they’re provided to. They register automatically when the environment initializes and unregister when the injector is destroyed. And the execute function runs in the injection context of that injector — meaning you can inject() any dependency inside it.

import { provideWebMcpTools } from '@angular/core';
import { ApplicationConfig } from '@angular/core';

export const appConfig: ApplicationConfig = {
  providers: [
    provideWebMcpTools([
      {
        name: 'getUserCart',
        description: 'Returns the current user cart items with quantities and prices',
        inputSchema: { type: 'object', properties: {} },
        execute: async () => {
          const cartService = inject(CartService);
          const items = cartService.items();

          return {
            content: [{
              type: 'text',
              text: JSON.stringify(items),
            }],
          };
        },
      },
    ]),
  ],
};

The execute function receives two arguments: the parsed args (typed from your inputSchema) and a WebMcpClient object containing an AbortSignal for cancellation support.

What’s particularly powerful is combining this with route-level providers and withExperimentalAutoCleanupInjectors. Tools register when the user navigates to a route and automatically unregister when navigating away:

import { provideRouter, withExperimentalAutoCleanupInjectors } from '@angular/router';
import { provideWebMcpTools } from '@angular/core';

export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(
      [
        {
          path: 'admin',
          component: AdminDashboardComponent,
          providers: [
            provideWebMcpTools([
              {
                name: 'getSystemMetrics',
                description: 'Returns current system health metrics (only available on admin page)',
                inputSchema: {
                  type: 'object',
                  properties: {
                    timeRange: { type: 'string', enum: ['1h', '24h', '7d'] },
                  },
                },
                execute: async (args) => {
                  const metrics = inject(MetricsService);
                  const data = await metrics.fetch(args.timeRange);

                  return { content: [{ type: 'text', text: JSON.stringify(data) }] };
                },
              },
            ]),
          ],
        },
      ],
      withExperimentalAutoCleanupInjectors(),
    ),
  ],
};

When the user navigates to /admin, the getSystemMetrics tool becomes available to AI assistants. Navigate away, and it’s gone. No manual cleanup needed.

Under the hood, provideWebMcpTools is a thin wrapper — it calls makeEnvironmentProviders with a provideEnvironmentInitializer that iterates over your tool descriptors and calls declareWebMcpTool for each one.

e) declareWebMcpTool — the low-level imperative API - PR

While provideWebMcpTools is the ergonomic, declarative approach, declareWebMcpTool is the lower-level primitive it’s built on. This function immediately registers a single WebMCP tool and ties its lifecycle to the current (or provided) Injector.

import { declareWebMcpTool } from '@angular/core';
import type { WebMcpToolDescriptor } from '@angular/core';

@Component({
  selector: 'app-chat',
  template: `<div class="chat-container">...</div>`,
  changeDetection: ChangeDetectionStrategy.OnPush,
})
export class ChatComponent {
  private _chatService = inject(ChatService);

  constructor() {
    // Registers the tool in the current injection context.
    // Automatically unregistered when this component's injector is destroyed.
    declareWebMcpTool({
      name: 'sendMessage',
      description: 'Sends a message in the active chat conversation',
      inputSchema: {
        type: 'object',
        properties: {
          message: { type: 'string' },
          channel: { type: 'string' },
        },
      },
      execute: async (args) => {
        await this._chatService.send(args.channel, args.message);
        return { content: [{ type: 'text', text: `Message sent to #${args.channel}` }] };
      },
    });
  }
}

The function signature:

declare function declareWebMcpTool<const InputSchema extends JsonSchemaForInference>(
  tool: WebMcpToolDescriptor<InputSchema>,
  injector?: Injector,
): void;

The optional injector parameter lets you register tools outside an injection context — useful for dynamic scenarios where you create tools programmatically.

Key types exported:

• WebMcpToolDescriptor<InputSchema> — the tool definition (name, description, inputSchema, execute)

• WebMcpToolExecute<InputSchema> — the execute function type: (args: InferArgsFromInputSchema<InputSchema>, client: WebMcpClient) => unknown

• WebMcpClient — contains signal: AbortSignal for cancellation

When to use which:

• provideWebMcpTools → declarative, multiple tools at once, works in providers arrays

• declareWebMcpTool → imperative, single tool, useful inside constructors or afterNextRender

Both are marked @experimental. The JSON Schema types are intentionally not exported from @angular/core — if you need them for complex schemas, add @mcp-b/webmcp-types as a direct dependency.

Language Tooling

a) Template inlay hints - PR

The Angular Language Service now supports inlay hints in templates. These are the subtle inline annotations your editor shows for parameter names, types, and other contextual information. If you use VS Code with the Angular extension, you’ll start seeing type hints directly in your templates.

b) Document Symbols for Angular templates - PR

The language service now provides Document Symbols for Angular templates. This means the Outline view in VS Code (and other editors) will show the structure of your template — components, directives, control flow blocks — making navigation in large templates much easier.

c) Idle timeout support in defer blocks - PR

The language service now understands the new idle timeout syntax in @defer blocks, providing proper autocompletion and diagnostics.

Legacy / Upgrade

a) ⚠️ getAngularLib/setAngularLib removed - PR

The deprecated getAngularLib and setAngularLib functions have been removed. Use getAngularJSGlobal and setAngularJSGlobal instead:

// Before ❌
import { getAngularLib, setAngularLib } from ‘@angular/upgrade/static’;

// After ✅
import { getAngularJSGlobal, setAngularJSGlobal } from ‘@angular/upgrade/static’;

🛠️ CLI & Build Tooling (angular/angular-cli)

@angular/cli

a) ⚡ Faster ng add with cached resolution - PR & PR

Two performance improvements to ng add: redundant package version resolution is now avoided, and the root manifest is cached with restricted package exports resolved upfront. If you’ve ever noticed ng add being slow on large monorepos, this should help.

b) MCP devserver custom port support - PR

The MCP (Model Context Protocol) devserver start tool now supports a custom port. This is relevant if you’re using Angular’s AI tooling integration.

c) Chunk Optimization Enabled by Default with Smart Heuristics - PR

The advanced chunk optimization pass — which uses Rollup (or optionally Rolldown) to re-bundle lazy chunks after esbuild — is now enabled by default. Previously, you had to explicitly opt in via the NG_BUILD_OPTIMIZE_CHUNKS environment variable. That’s no longer the case.

Here’s the thing: not every project benefits from this. A small app with one or two lazy routes won’t see meaningful gains, and the extra build step just adds overhead. So the Angular team introduced a heuristic: the optimization only kicks in when your build produces 3 or more lazy chunks. This threshold hits the sweet spot where chunk merging and deduplication actually pay off.

The heuristic counts .js files in the build output that aren’t part of the initial bundle. If that count meets the threshold, the optimization runs automatically. For most medium-to-large apps with multiple lazy-loaded routes, this means smaller total bundle sizes and fewer network requests — without you having to configure anything.

You can still control the behavior through the NG_BUILD_OPTIMIZE_CHUNKS environment variable:

# Force optimization on regardless of chunk count
NG_BUILD_OPTIMIZE_CHUNKS=true ng build

# Disable optimization entirely
NG_BUILD_OPTIMIZE_CHUNKS=false ng build

# Set a custom threshold (e.g., only optimize when 5+ lazy chunks exist)
NG_BUILD_OPTIMIZE_CHUNKS=5 ng build

What happens under the hood: after esbuild generates the initial chunks, Angular feeds them through Rollup (or Rolldown if you’ve opted into it via NG_BUILD_CHUNKS_ROLLDOWN). Rollup analyzes cross-chunk dependencies and merges small chunks that share code, reducing the total number of files the browser needs to fetch for lazy routes.

For a typical app with 10+ lazy routes, this can reduce the number of JS files by 30-50%, which translates directly to fewer HTTP requests and faster route transitions. The build time increase is minimal — usually under a second for the optimization pass itself.

d) Quiet Option for Suppressing Build Noise in Unit Tests - PR

A new quiet option has been added to @angular/build that suppresses build output noise during unit test runs. When running Vitest through the Angular builder, the build system now supports silencing the verbose compilation output that clutters test results.

This is a developer experience improvement. When you’re running tests, you want to see test results — not pages of build logs scrolling by. The quiet option lets the test runner focus the terminal output on what matters: which tests passed, which failed, and why.

e) Stabilized Jasmine-to-Vitest Migration Schematic - PR

The refactor-jasmine-vitest schematic has been marked as stable. This schematic automates the migration from Jasmine test syntax to Vitest, which is now Angular’s recommended testing framework.

If you’ve been holding off on migrating your test suite because the schematic was experimental — that barrier is gone. You can now run it with confidence:

ng generate @schematics/angular:refactor-jasmine-vitest

The schematic handles the mechanical parts of the migration: updating imports, converting Jasmine-specific APIs to their Vitest equivalents, and adjusting configuration files. It won’t rewrite your test logic, but it takes care of the boilerplate changes that make manual migration tedious.

This stabilization signals that the Angular team considers the Vitest migration path production-ready. If you’re still on Karma + Jasmine, this is a good time to start planning the switch.

@angular/build

a) Runtime Zone.js detection in Vitest - PR

The Vitest unit test runner now supports runtime Zone.js detection. If your project still uses Zone.js, the test runner will detect it automatically — no manual configuration needed.

b) ⚠️ process.env.PORT takes priority in dev server - PR

The ng serve dev server now gives highest priority to the PORT environment variable. This overrides both angular.json config and the --port CLI flag — including the default 4200.

# This now takes priority over everything
PORT=3000 ng serve
# Even if angular.json says port: 4200 and you pass --port 8080

This is a breaking change if you rely on --port or angular.json to override an environment variable. The priority order is now: PORT env var > --port flag > angular.json.

c) experimentalPlatform renamed to platform - PR

The experimentalPlatform option in the application builder has been renamed to platform. If you were using this option in your angular.json, update the key name.

d) ⚠️ istanbul-lib-instrument is now an optional peer dependency - PR

If you’re using Karma with code coverage, you’ll need to ensure istanbul-lib-instrument is installed as a direct dependency. The ng update schematic handles this automatically.

e) Subresource Integrity (SRI) validation for dynamically loaded modules - PR

This is a security improvement. When you enable subresourceIntegrity: true in your build configuration, Angular already generates integrity hashes for scripts in index.html. But lazy-loaded chunks — the ones fetched at runtime via dynamic import() — weren’t validated.

Now they are. The build system generates integrity metadata for all lazy chunks, and the runtime validates them before execution. If a CDN or proxy tampers with a lazy-loaded module, the browser will reject it.

{
  "architect": {
    "build": {
      "builder": "@angular/build:application",
      "options": {
        "subresourceIntegrity": true
      }
    }
  }
}

What happens under the hood: the build emits a manifest mapping chunk filenames to their SHA-384 hashes. When Angular’s router triggers a lazy import, the runtime fetches the chunk and verifies its integrity against the manifest before evaluating it.

This closes a gap that existed since Angular adopted code splitting. Previously, subresourceIntegrity only protected the initial bundle — the scripts directly referenced in index.html with integrity attributes. Lazy chunks were unprotected. Now the entire application is covered.

For apps served behind CDNs or third-party proxies, this is a meaningful security hardening. It ensures that even if an intermediary modifies a JavaScript chunk in transit, the application will refuse to execute it rather than running potentially malicious code.

@angular/ssr

a) ⚠️ SSR: No more CSR fallback for invalid hosts - PR

The Angular SSR server no longer falls back to Client-Side Rendering when a request fails host validation. Requests with unrecognized Host headers now return a 400 Bad Request. Make sure all valid hosts are configured in the allowedHosts option.

@schematics/angular

a) Strict templates default in generated workspaces - PR

New workspaces generated with ng new now rely on the strict template default. This aligns with the migration that adds strictTemplates to existing projects during ng update.

b) Karma-to-Vitest migration schematic - PR

A new migration schematic that helps you move from Karma to Vitest. Run it during ng update to automatically update your test configuration.

c) Migration to add istanbul-lib-instrument - PR

Removed packages

a) ⚠️ @angular-devkit/architect-cli removed - PR

The @angular-devkit/architect-cli package is no longer available. The architect CLI tool has been moved to the @angular-devkit/architect package.

b) ⚠️ Experimental Jest and Web Test Runner builders removed - PR

The experimental @angular-devkit/build-angular:jest and @angular-devkit/build-angular:web-test-runner builders have been removed. Vitest is now the recommended test runner going forward.

🎨 Components & CDK (angular/components)

📦 Migrations & Schematics (cross-cutting)

a) Add strictTemplates to tsconfig during ng update — angular/angular - PR

When you run ng update, Angular now automatically adds strictTemplates: true to your tsconfig.json if it’s not already there. This has been the recommended setting for a while, and now it’s enforced during migration.

b) Migration schematic for provideHttpClient with XHR — angular/angular - PR

Since FetchBackend is now the default, a migration schematic is provided to add withXhr() to your provideHttpClient() calls if your app relies on XHR-specific features (like upload progress).

c) Migration for ChangeDetectionStrategy.Eager — angular/angular

Automatically adds ChangeDetectionStrategy.Eager to components that need it after the default changed to OnPush.

d) Migration for CanMatchFn snapshot parameter — angular/angular - PR

The currentSnapshot parameter in CanMatchFn and the canMatch method of the CanMatch interface is now required. While the Router already passed this at runtime, existing class implementations must now include the third argument to satisfy the interface. A migration schematic handles this automatically.

// Before ❌ — third parameter was optional
canMatch(route: Route, segments: UrlSegment[]): boolean {
  return true;
}

// After ✅ — currentSnapshot is now required
canMatch(route: Route, segments: UrlSegment[], currentSnapshot: ActivatedRouteSnapshot): boolean {
  return true;
}

e) Karma-to-Vitest migration — angular/angular-cli

f) Migration to add istanbul-lib-instrument — angular/angular-cli

g) Auto-Disable nullishCoalescingNotNullable & optionalChainNotNullable on ng update - PR

When you run ng update to upgrade to this version, the migration will automatically add suppression rules for the nullishCoalescingNotNullable and optionalChainNotNullable diagnostics to your tsconfig.json.

This is the companion migration for the breaking compiler change described above. The idea is simple: don’t block your update with hundreds of new warnings. The migration suppresses them so you can update cleanly, then you can address the warnings incrementally.

After updating, you’ll find this in your tsconfig.json:

{
  "angularCompilerOptions": {
    "extendedDiagnostics": {
      "checks": {
        "nullishCoalescingNotNullable": "suppress",
        "optionalChainNotNullable": "suppress"
      }
    }
  }
}

Once you’ve cleaned up the unnecessary ?. and ?? operators in your templates, remove these suppressions to benefit from the stricter type checking going forward.

h) Auto-Add strictTemplates to tsconfig During ng update - PR

When you run ng update to upgrade to Angular 22, a new migration will automatically add strictTemplates: false to your tsconfig.json under angularCompilerOptions — but only if it’s not already set.

Why false? Because Angular 22 is making strictTemplates: true the default compiler behavior. Projects that haven’t explicitly opted into strict templates would suddenly get a wave of new type-checking errors in their templates. The migration preserves the previous implicit behavior by making it explicit, so your update doesn’t break anything.

The migration is smart about it:

• If strictTemplates is already set (to true or false), it leaves it alone

• If compilerOptions is empty or missing, it skips the file (not a real tsconfig)

• If angularCompilerOptions doesn’t exist, it creates the section with strictTemplates: false

// What the migration adds to your tsconfig.json
{
  "compilerOptions": {
    "target": "es2022"
    // ... your existing options
  },
  "angularCompilerOptions": {
    "strictTemplates": false  // ← added by migration
  }
}

After updating, you can (and should) work toward enabling strictTemplates: true at your own pace. Strict template type checking catches real bugs — wrong property names, type mismatches in bindings, missing inputs — that would otherwise only surface at runtime. But the migration ensures you’re not forced into it during the update itself.

i) Model + Output conflict migration - PR

When Angular introduced model() signals, it implicitly created a <name>Change output for two-way binding. But some codebases already had explicit output() declarations with that same name — creating a conflict where the component had duplicate outputs.

This migration automatically detects the pattern and converts it to input() + linkedSignal(), which preserves the reactive behavior without the naming collision.

// Before — broken duplicate outputs ❌
@Component({
  selector: 'app-slider',
  template: '',
})
export class SliderComponent {
  foo = model(0);              // implicitly creates fooChange output
  fooChange = output<number>(); // explicit output — CONFLICT!
}

// After migration ✅
@Component({
  selector: 'app-slider',
  template: '',
})
export class SliderComponent {
  fooInput = input(0, { alias: 'foo' });
  foo = linkedSignal(this.fooInput);
  fooChange = output<number>();
}

The migration handles several cases:

• Preserves access modifiers (public, protected, readonly)

• Handles generic types (model<string>('initial') → input<string>('initial', {alias: 'bar'}))

• Adds input and linkedSignal to the import statement automatically

• Only triggers when there’s an actual naming conflict — if your model() doesn’t have a conflicting explicit output, nothing changes

This runs automatically during ng update to Angular 22.

j) Migrate fakeAsync to Vitest fake timers - PR

The schematic now automatically converts fakeAsync/tick/flush patterns to Vitest’s native fake timer APIs. Angular’s fakeAsync was a Zone.js-powered utility — in a zoneless Vitest world, you use vi.useFakeTimers() and vi.advanceTimersByTime() instead.

// Before (Jasmine + Zone.js) ❌
it('should debounce input', fakeAsync(() => {
  component.onSearch('angular');
  tick(300);
  expect(component.results().length).toBeGreaterThan(0);
}));

// After (Vitest) ✅
it('should debounce input', () => {
  vi.useFakeTimers();
  component.onSearch('angular');
  vi.advanceTimersByTime(300);
  expect(component.results().length).toBeGreaterThan(0);
  vi.useRealTimers();
});

k) Migrate fakeAsync‘s flush behavior in beforeEach - PR

When fakeAsync with flush() is used inside beforeEach blocks, the schematic now correctly transforms it. This is a common pattern where setup code needs to wait for async initialization to complete before each test.

l) Set up fake timers in beforeEach instead of beforeAll - PR

The schematic ensures fake timers are set up in beforeEach (per-test isolation) rather than beforeAll (shared across tests). This prevents timer state from leaking between tests — a common source of flaky test suites.

m) Update TSConfig globals during migration - PR

When migrating from Karma to Vitest, the schematic now updates your tsconfig.spec.json to include Vitest’s global type definitions. This ensures TypeScript recognizes vi, describe, it, expect and other Vitest globals without manual configuration.

n) Conditionally install istanbul coverage provider - PR

During the Karma-to-Vitest migration, the schematic now checks if your project uses code coverage and conditionally installs @vitest/coverage-istanbul. This ensures your existing coverage pipeline (Codecov, SonarQube, etc.) continues working without manual intervention.

⚠️ Breaking Changes Summary

⚠️ Deprecations Summary

Thanks for reading so far 🙏

I’d like to have your feedback, so please leave a comment, clap or follow. 👏

Spread the Angular love! 💜

If you liked it, share it among your community, tech bros and whoever you want! 🚀👥

Don’t forget to follow me and stay updated: 📱

• 🔗 LinkedIn

• 📝 Medium

• 🎥 YouTube

• 🐦 Twitter

Thanks for being part of this Angular journey! 👋😁

If you’ve used ngxtension/inject-lazy, this will feel familiar. But the API is different, and the trade-offs matter.

The Problem

Bundle size. You have a ChartService that pulls in D3, a PdfService that imports pdfjs, or an AnalyticsService that loads a heavy SDK. These services aren’t needed on initial render — maybe they’re triggered by a button click, a route guard, or a conditional feature flag.

With providedIn: 'root', the service class and its dependencies end up in the main bundle regardless of whether the user ever triggers the code path that uses them.

Lazy routes solve this for route-level code splitting. But what about services used within a component that’s already loaded?

Before injectAsync: The Manual Approach

@Component({
  selector: 'app-report',
  template: `<button (click)="generate()">Generate PDF</button>`,
  changeDetection: ChangeDetectionStrategy.OnPush,
})
export class ReportComponent {
  private _injector = inject(EnvironmentInjector);

  async generate(): Promise<void> {
    const { PdfService } = await import('./pdf.service');
    const pdfService = this._injector.get(PdfService);
    pdfService.createReport();
  }
}

Read more

The short version

provideRouter(routes, withComponentInputBinding({ queryParams: false }))

That’s it. Query params no longer bind to your component inputs. Path params and route data? Still work fine.

So what was the problem?

Let me show you. Say you have this:

// Route: { path: 'user/:id', component: UserComponent, data: { role: 'admin' } }
// URL: /user/42?tab=settings

@Component({ ... })
export class UserComponent {
  id = input<string>();       // ← from :id
  tab = input<string>();      // ← from ?tab=
  role = input<string>();     // ← from route data
}

All three sources — path params, query params, route data — bind to your inputs automatically. Sounds great until you realize that query params are completely user-controlled. Anyone can type whatever they want in the URL bar.

Picture this:

Read more

Before you start diving into this new topic you can review the full guide of resource() that was introduced in Angular 19.

TL;DR

Angular added a debounced() function that takes a signal and a wait time, and returns a Resource:

signal → debounced(signal, 500) → Resource<T>

The resource’s value() holds the debounced value. Its status tells you whether the value is settled ('resolved'), still waiting ('loading'), or if the source threw ('error'). No RxJS, no setTimeout wrappers, no custom hooks. Just signals in, Resource out.

The Problem

You have a search input. The user types “Tokyo”. Without debouncing, you fire 5 HTTP requests: one per keystroke. That’s wasteful, potentially slow, and can cause race conditions if responses arrive out of order.

The RxJS way:

searchControl.valueChanges.pipe(
  debounceTime(500),
  distinctUntilChanged(),
  switchMap(query => this.http.get(`/api/search?q=${query}`))
).subscribe(results => { ... });

The manual way:

let timer: ReturnType<typeof setTimeout>;
function onInput(value: string) {
  clearTimeout(timer);
  timer = setTimeout(() => {
    // now do something with value
  }, 500);
}

Both work. Neither integrates with signals. You end up bridging between observables or callbacks and signals, losing reactivity along the way.

The real gap: there was no signal-native way to debounce a value and get a reactive, composable result back.

The Solution: debounced()

The API

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

const search = signal('');
const debouncedSearch = debounced(() => search(), 500);

debouncedSearch is a Resource<string>. It has everything you’d expect:

• debouncedSearch.value() — the debounced value (updates only after 500ms of silence)

• debouncedSearch.status() — 'resolved' when settled, 'loading' while waiting, 'error' if the source threw

• debouncedSearch.isLoading() — true while a value is pending

• debouncedSearch.error() — the error, if the source signal threw

Full Signature

Read more

Before you start diving into this new topic you can review the full guide of resource() that was introduced in Angular 19.

TL;DR

Angular added three things that let you take a resource, modify its behavior, and get back a real resource.

Resource  →  .snapshot  →  transform it  →  resourceFromSnapshots()  →  Resource

The killer use case? Keep showing old data while new data loads — no more blank screens when switching between items. And it’s a generic utility you write once and reuse everywhere.

PR: feat(core): resource composition via snapshots
Authors: Alex Rickabaugh & Jessica Janiuk
Status: Experimental · Angular 21.2+

Code Repository Example in this article can be found here.

The Problem (in Plain English)

Imagine you have a weather app. The user is looking at London’s weather. They click “Tokyo.” What happens?

Before this PR:

1. The resource enters “loading” state

2. value() immediately becomes undefined

3. The weather card disappears — blank screen, skeleton loader

4. Tokyo’s data arrives, card re-appears

That flash of empty content feels broken. Users hate it.

You might think: “I’ll just keep the old value around in a separate signal.” Sure, but then you lose the Resource interface. Your workaround doesn’t have .isLoading(), .hasValue(), .status(). It’s a one-off hack that doesn’t compose.

The real problem: there was no way to take a Resource, tweak its behavior, and get back something that’s still a Resource.

Read more

The Problem Nobody Talks About

Every time Angular introduces a new API, the community gets excited about greenfield projects. “Look how clean this is!” And it is clean. Signal forms are a genuine improvement over reactive forms — less boilerplate, better type safety, signals instead of observables.

But here’s the thing: most of us aren’t building new apps from scratch. We’re maintaining applications with dozens — sometimes hundreds — of reactive forms. Forms that work. Forms that are tested. Forms that have edge cases baked into them over years of production use.

The question isn’t “are signal forms better?” — they are. The question is: how do you get there without rewriting everything?

Angular 21.2 answers this with two interop tools:

1. SignalFormControl — A signal-based control that extends AbstractControl, so it plugs directly into existing FormGroup and FormArray structures

2. compatForm — A version of form() that accepts reactive FormControl instances as part of the data model

Both are exported from @angular/forms/signals/compat. Both are experimental. And both solve different migration scenarios.

Understanding the Two Migration Paths

Before diving into code, it’s worth understanding when to use each approach.

SignalFormControl is for when you want to migrate individual fields inside an existing reactive form. You replace one FormControl with a SignalFormControl, and the parent FormGroup doesn’t even notice — it just sees an AbstractControl.

compatForm is for when you want to migrate the form itself to signal forms, but some fields are still FormControl instances that you’re not ready to convert yet.

Think of it this way:

• I want to add signal validation to one field in my reactive form → SignalFormControlReactive form → signal field

• I want to use form() but keep some existing FormControls → compatFormSignal form → reactive fields

Most teams will start with SignalFormControl because it’s the least disruptive. You change one field, ship it, observe, then do the next one.

SignalFormControl: Your First Migration Step

What It Is

SignalFormControl extends AbstractControl — the same base class that FormControl, FormGroup, and FormArray extend. This means it’s a drop-in replacement anywhere Angular’s reactive forms infrastructure expects a control.

Internally, it’s backed by a WritableSignal<T> and a signal forms FieldTree. It translates between the two worlds: when the reactive form reads .value, it gets the signal’s current value. When signal forms validation runs, the results are exposed through the reactive .errors getter.

import { SignalFormControl } from '@angular/forms/signals/compat';

Read more

1. @angular/animations

2. @angular/build

a) Headless Option for Unit-Test Builder - PR

The unit-test builder now supports a headless option for browser-based tests. You can toggle between headless and headed mode without modifying your Vitest configuration.

ng test --headless=false  # Run with visible browser for debugging
ng test                   # Default: headless

b) Vitest Browser with Playwright OS Theme - PR

When running Vitest browser tests with Playwright, the browser now respects your operating system’s theme (light/dark mode). This means your tests run in an environment that matches your system preferences, which can be relevant for testing theme-dependent UI behavior.

3. @angular/common

a) Outlet Injector Option for ngTemplateOutlet - PR

To understand this feature, you first need to understand a quirk of how ngTemplateOutlet works with Angular’s dependency injection.

The problem: templates resolve services from where they’re defined, not where they’re rendered.

Imagine you define an <ng-template> at the root of your component. Inside that template, you try to inject() a service. Angular will look for that service starting from the definition site of the template (where the <ng-template> tag lives in the source code), not from where the template is actually stamped into the DOM via *ngTemplateOutlet.

Here’s a concrete example to make this tangible:

Read more

1. @angular/common

a) Custom Transformations for Cloudflare and Cloudinary Image Loaders - PR

Adds support for custom transformations to Cloudinary and Cloudflare image loaders via a transform parameter.

You can learn more about How to Configure an image loader for NgOptimizedImage.

b) Custom Transformations for ImageKit and Imgix Loaders - PR

Similar custom transformation support extends to ImageKit and Imgix, two other popular image CDN providers.

You can learn more about How to Configure an image loader for NgOptimizedImage.

Read more

Here’s what makes this interesting: the form doesn’t just validate that you typed something. It calls an API to verify the city exists in a weather database, manages the loading state while checking, caches results so you don’t hammer the server, and gives instant feedback. That’s where metadata becomes essential.

The Core Problem

Traditional validation answers simple questions: Is the field empty? Does it match this pattern? But modern forms need smarter behavior. When someone types “Barcelona, Spain,” you want to know:

• Does this city exist in your weather database?

• Are we currently checking with the server?

• Did we already validate this exact combination?

• Should we show a spinner?

Your form data is just { city: “Barcelona”, country: “Spain” }. Everything else—the validation state, the API response, the loading indicators—that’s metadata. It’s the difference between what the user entered and what you need to know about what they entered.

Starting With Basic Validation

Let’s look at the foundation. This is pure validation, no async behavior yet:

const cityNameSchema = schema<string>((path) => {
  required(path, { message: ‘City is required’ });
  minLength(path, 2, { message: ‘City must be at least 2 characters’ });
  maxLength(path, 50, { message: ‘City name is too long’ });
});

export const locationSchema = schema<WeatherLocation>((path) => {
  apply(path.city, cityNameSchema);
  apply(path.country, countryNameSchema);
});

This checks structure and format. But it doesn’t verify if Barcelona is real or if someone made it up. For that, you need to talk to an API.

Adding Real Validation

Here’s where it gets interesting. We’re going to validate cities against a weather API as the user types:

Read more

If you’ve been experimenting with the new Signal Forms in Angular 21, you might have noticed something missing. You set up your schemas, you wired up your signals, but when you looked at the DOM... it was clean.

Too clean.

In the old ReactiveForms world, Angular automatically slapped classes like .ng-invalid, .ng-dirty, and .ng-touched onto your inputs. CSS frameworks (like Bootstrap or Material) relied on these hooks to turn borders red or show error icons. With Signal Forms, that automatic behavior was gone—until now.

With the latest merge into core (Commit 7d5c7cf), Angular 21.1 introduces provideSignalFormsConfig. This acts as a bridge between your pure logic signal state and your UI styling.

Let’s look at how this changes the game for our Weather Chatbot, specifically how we can use it to drive a “Tailwind-native” form experience without cluttering our templates.

The “Lazy” Way: Back to Basics

If you just want the old behavior back because you have existing CSS that targets .ng-invalid, the Angular team provided a pre-baked constant.

In your app.config.ts:

import { ApplicationConfig } from ‘@angular/core’;
import { provideSignalFormsConfig } from ‘@angular/forms/signals’;
import { NG_STATUS_CLASSES } from ‘@angular/forms/signals/compat’;

export const appConfig: ApplicationConfig = {
  providers: [
    // 🪄 Magic: Automatically adds ng-valid, ng-invalid, ng-dirty, etc.
    provideSignalFormsConfig({
      classes: NG_STATUS_CLASSES
    })
  ]
};

But we are writing modern Angular. We can do better than legacy compatibility.

The “Pro” Way: Semantic Configuration

This new API allows us to map any CSS class to a predicate function that reads the field state. This is incredibly powerful.

Read more

1. @angular/animations

2. @angular/common

a) Zero-Configuration HTTP Services - PR

HTTP services are now automatically provided in the root injector, eliminating the need for explicit provideHttpClient().

import { bootstrapApplication } from '@angular/platform-browser';
import { provideHttpClient } from '@angular/common/http';

// Before
bootstrapApplication(AppComponent, {
  providers: [
    provideHttpClient() // ❌ Required for basic HTTP functionality
  ]
});

// After
bootstrapApplication(AppComponent, {
  providers: [
    // ✅ HTTP services automatically available
  ]
});

Advanced Configuration: For custom interceptors, client configuration, or specific features, continue using provideHttpClient():

bootstrapApplication(AppComponent, {
  providers: [
    provideHttpClient(
      withInterceptors([authInterceptor]),
      withFetch() // Custom features require explicit provider
    )
  ]
});

b) ⚠️ NgComponentOutlet NgModuleFactory Removal - PR

The ngModuleFactory input of NgComponentOutlet was a legacy feature that relied on the deprecated NgModuleFactory class, creating unnecessary complexity and maintenance overhead.

Now ngModuleFactory input from NgComponentOutlet is removed, using only the modern NgModule approach.

Read more

The Problem We’ve All Been Ignoring

Here’s something embarrassing: I had a search field in one of my apps that was hitting our ElasticSearch cluster on every single keystroke. A user typing “San Francisco” would trigger 13 API calls. Multiply that by a few hundred concurrent users, and our AWS bill was... let’s just say “uncomfortable.”

The old solution? RxJS operators like debounceTime() scattered throughout components, manual subscription management, and crossing your fingers that you didn’t create a memory leak. It worked, but it felt like duct tape on a leaky pipe.

Signal Forms’ new debounce() rule takes a completely different approach. Instead of managing debouncing at the component level, it’s built directly into the form’s schema definition. The form itself knows when to synchronize user input with your data model.

Read more

But here’s where we’re going to do something different from typical tutorials. Instead of building a generic weather API or todo list MCP server, we’re creating something immediately valuable for Angular developers: an MCP server with a powerful refactoring tool that enforces modern Angular and TypeScript best practices.

Read more

The Birth of a New Standard: How MCP Came to Be

Large Language Models (LLMs) like ChatGPT, Claude, and Gemini can write code, debug complex problems, and explain technical concepts with remarkable fluency. Yet despite their brilliance, they’ve been operating in isolation—powerful minds trapped in a room with no doors or windows.

Picture this: you have an AI assistant that can write flawless TypeScript, suggest perfect Angular component architectures, and identify bugs in milliseconds. But it can’t see your actual project files, can’t access your database, can’t read your API documentation, and has no idea what tools you’re using. It’s like hiring a world-class architect who has to design your house without ever seeing the plot of land, checking local building codes, or knowing what materials are available.

This has been the fundamental limitation of AI development tools—until now.

The Genesis: Anthropic’s Vision

In November 2024, Anthropic—the AI safety company founded by former OpenAI researchers and creators of Claude—unveiled something that would change the landscape of AI integration: the Model Context Protocol (MCP).

The team at Anthropic had been grappling with a persistent problem. As they worked on making Claude more useful for real-world tasks, they kept running into the same wall: every time they wanted to connect Claude to a new tool, service, or data source, they had to build a custom integration from scratch. Database access required one approach. File system operations needed another. API integrations each demanded unique implementations.

It was the API chaos problem we explored earlier, but at a massive scale.

The Open Standard Revolution

Rather than building yet another proprietary solution, Anthropic made a bold decision: they would create an open, universal protocol that any AI system could use to connect with any tool or service. On November 25, 2024, they released MCP as an open-source specification, complete with SDKs in Python and TypeScript.

The core idea was elegant: instead of building point-to-point integrations between every AI model and every service, create a standardized “language” that both sides could speak. Think of it as establishing USB-C for AI connectivity—one protocol to rule them all.

What made MCP truly revolutionary wasn’t just the technical specification. It was the philosophy behind it:

• Open and Free: Anyone could implement it, no licensing fees, no vendor lock-in

• Bidirectional: Both AI systems and services could initiate communication

• Secure by Design: Built-in authorization and sandboxing capabilities

• Simple Yet Powerful: Easy enough for individual developers to implement, robust enough for enterprise systems

The Unprecedented Adoption

Here’s where the story gets really interesting. In the tech world, standards battles typically drag on for years. Companies fight over competing specifications, each pushing their own solution. But something different happened with MCP.

By March 2025, just four months after its introduction, OpenAI—Anthropic’s biggest competitor—announced they were adopting MCP for GPT integrations. Let that sink in: a company competing directly with Anthropic chose to embrace their open standard rather than build their own.

April 2025 brought another bombshell: Google DeepMind integrated MCP support into their AI offerings. Microsoft followed in May 2025, incorporating MCP into Azure AI services and announcing plans to support it across their development tools ecosystem.

When fierce competitors this quickly agree on a standard, you’re witnessing something rare in tech history. It’s reminiscent of how HTTP became the universal protocol for the web, or how REST APIs became the de facto standard for web services.

From Concept to Ecosystem

Today, less than a year after its introduction, MCP has evolved from a novel idea into a thriving ecosystem. Development tools like Cursor, Windsurf, and Zed have built-in MCP support. Major SaaS companies are releasing official MCP servers. The community has created hundreds of integrations.

What started as Anthropic’s solution to their own integration challenges has become the foundation for how AI systems interact with the digital world.

And that’s exactly what we’re going to explore in this article: understanding the principles behind MCP and learning how to build our own MCP server using Angular, joining this revolution in AI integration.

The Fundamental Problem: AI That Can Only "Talk"

When you ask ChatGPT to "plan me a week-long holiday in Costa Rica," it can tell you exactly what to do, suggest amazing destinations, even help you create detailed itineraries—but it cannot actually open a browser, navigate to travel sites, check real-time availability, or complete bookings. LLMs are fundamentally text generators, not action-takers. This is essentially the limitation that Large Language Models (LLMs) like GPT face today.

Enter AI Agents: The Hands and Feet of AI

This is where AI agents come into play. Think of an AI agent as an intelligent assistant that combines the reasoning power of an LLM with the ability actually to do things. It's like giving that brilliant person in the room a set of tools, internet access, and the ability to interact with the outside world.

An AI agent follows a simple but powerful pattern:

1. Receive a request from the user

2. Think about it using an LLM ("What kind of holiday experience does the user want?")

3. Take actions by calling external services and APIs

4. Think again about the results ("Do these options match their preferences? Do I need more information?")

5. Repeat until the task is complete

For example, when you say "plan me an adventure holiday in Costa Rica," an AI agent might:

• Ask the LLM to extract details (budget, interests, group size, dates)

• Call tourism APIs to find available activities and accommodations

• Check weather services for seasonal considerations

• Ask the LLM to analyze options against your adventure preferences

• Present a complete itinerary with bookable options

The API Chaos Problem

Here's where things get complicated. Every travel service has its own API:

• Airbnb uses /v2/listings/search

• TripAdvisor uses /experiences/search

• National Parks Service uses /parks/activities

• Local tour operators each have unique endpoints

// The nightmare of integrating multiple travel APIs - each one is different!

class HolidayPlanningAgent {
  
  async findAccommodations(destination, checkin, checkout, guests) {
    let results = [];
    
    // Airbnb - uses Bearer token, POST request
    const airbnbResponse = await fetch(`https://api.airbnb.com/v2/listings/search`, {
      method: 'POST',
      headers: { 'Authorization': `Bearer ${this.airbnbToken}` },
      body: JSON.stringify({
        location: destination,        // calls it 'location'
        check_in: checkin,           // underscore format
        adults: guests
      })
    });
    // Returns: { listings: [{ price_per_night, coordinates: {lat, lng} }] }
    
    // Booking.com - uses Basic auth, GET request  
    const bookingResponse = await fetch(`https://distribution-xml.booking.com/2.4/json/hotelAvailability`, {
      method: 'GET',
      headers: { 'Authorization': `Basic ${this.bookingAuth}` },
      params: {
        city: destination,           // calls it 'city'
        checkin_date: checkin,      // different naming
        room1: `A,A,${guests}`      // completely different format
      }
    });
    // Returns: { result: [{ min_total_price, latitude, longitude }] }

    // Hotels.com - uses API key, different date format
    const hotelsResponse = await fetch(`https://api.ean.com/ean-services/rs/hotel/v3/list`, {
      headers: { 'Authorization': `EAN APIKey=${this.hotelsKey}` },
      params: {
        destinationString: destination,    // yet another name
        arrivalDate: checkin.replace(/-/g, '/'),  // wants MM/DD/YYYY format
        RoomGroup: `(A,${guests})`        // parentheses format
      }
    });
    // Returns: { HotelListResponse: { HotelList: { HotelSummary: [{ lowRate }] } } }
    
    return results; // Each API returns completely different data structures
  }

  async findActivities(destination, type) {
    // TripAdvisor
    await fetch(`https://api.tripadvisor.com/api/partner/2.0/experiences/search`, {
      params: { location: destination, category: this.mapToTripAdvisorCategory(type) }
    });
    // Returns: { data: [{ experience_id, title, price_from }] }

    // GetYourGuide  
    await fetch(`https://www.getyourguide.com/api/v1/activities`, {
      method: 'POST',
      body: JSON.stringify({
        data: { type: 'activity-search', attributes: { destination } }
      })
    });
    // Returns JSON API format: { data: [{ id, attributes: { title, price: { amount } } }] }

    // National Parks
    await fetch(`https://developer.nps.gov/api/v1/activities/parks`, {
      params: { q: destination }  // calls it 'q' instead of 'destination'
    });
    // Returns: { data: [{ parks: [{ fullName, entranceFees: [{ cost }] }] }] }
  }

  // Every API needs different category mappings
  mapToTripAdvisorCategory(type) {
    return { 'adventure': 'outdoor-activities', 'culture': 'cultural-tours' }[type];
  }
}

/*
The Problem: 
- 6 different authentication methods (Bearer, Basic, API Key)
- 6 different request formats (POST vs GET, different JSON structures)
- 6 different parameter names for the same concept (location vs city vs destinationString vs q)
- 6 different response formats to parse and normalize
- 6 different error handling approaches
- Constant maintenance as each API evolves independently

Result: You spend more time on API integration than actual holiday planning logic!
*/

Each returns data in different formats, requires different authentication, and has different parameter names. If you want your AI agent to work with hundreds of accommodation providers, activity companies, restaurants, and attractions, you'd need to write custom integration code for each one.

This is like having a universal remote control that needs a different button layout for every device—it's technically possible but practically unsustainable.

Model Context Protocol: The Universal Translator

Model Context Protocol (MCP) solves this problem by creating a standardized way for AI agents to communicate with external services. Instead of writing custom code for each travel API, you create an MCP server that acts as a translator between the standardized MCP language and the service's specific API.

Think of MCP as creating a universal interface. Instead of your AI agent needing to learn 1,000 different ways to say "find adventure activities," there's now one standard way that works with any MCP-compatible service.

The Three Pillars of MCP

Every MCP server exposes three types of capabilities:

1. Tools - The Actions

Tools are the things your AI agent can do. These are functions that perform actions or retrieve data:

• search_accommodations(location, checkin, checkout, guests)

• find_activities(destination, activity_type, difficulty_level)

• get_restaurant_recommendations(location, cuisine, budget)

• check_weather_forecast(destination, dates)

2. Resources - The Context

Resources are static information that helps the AI make better decisions:

• Destination guides and local customs

• Activity difficulty ratings and requirements

• Seasonal travel recommendations

• Visa and vaccination requirements

• Currency exchange rates and tipping guides

3. Prompts - The Wisdom

Prompts are pre-written instructions that help the AI use the tools correctly:

• "When planning adventure trips, always check weather patterns and seasonal accessibility"

• "For family holidays, prioritize activities suitable for all age groups mentioned"

• "When suggesting accommodations, consider proximity to planned activities"

The Architecture: Client Meets Server

MCP follows a simple client-server model:

MCP Client (your AI agent or IDE):

• Discovers what an MCP server can do

• Sends requests to perform actions

• Receives responses and data

MCP Server (the service provider):

• Exposes tools, resources, and prompts

• Handles the actual API calls to external services

• Returns standardized responses

The communication happens through JSON-RPC, a lightweight protocol that's like having a standardized conversation format:

Client: "Can you search for adventure activities?"
Server: "Yes, I can do that. Give me destination, activity type, and difficulty level."
Client: "Find zip-lining activities in Costa Rica for intermediate level"
Server: "Here are 8 zip-lining tours matching your criteria..."

The Communication Protocol: JSON-RPC 2.0

Before diving into the MCP specification itself, we need to understand how MCP clients and servers actually communicate with each other. MCP uses JSON-RPC 2.0 as its communication protocol—think of it as the "language" that clients and servers speak when exchanging information.

What is JSON-RPC?

JSON-RPC (JSON Remote Procedure Call) is a lightweight, stateless protocol that allows a client to call methods on a remote server and receive responses. It's essentially a standardized way to say "run this function with these parameters" across a network or between processes.

The "2.0" refers to the specification version, which defines exactly how requests and responses should be formatted. This standardization ensures that any JSON-RPC 2.0 client can communicate with any JSON-RPC 2.0 server, regardless of what programming language they're built with.

The Basic Structure

Every JSON-RPC request must include four elements:

// JSON-RPC 2.0 Request Structure
{
  "jsonrpc": "2.0",
  "method": "search_hotels",
  "params": {
    "destination": "Costa Rica",
    "checkin": "2024-12-15",
    "checkout": "2024-12-22",
    "guests": 2
  },
  "id": 1
}

// JSON-RPC 2.0 Response Structure (Success)
{
  "jsonrpc": "2.0",
  "result": {
    "hotels": [
      {
        "id": "hotel_123",
        "name": "Rainforest Lodge",
        "price_per_night": 150,
        "location": "Manuel Antonio",
        "rating": 4.5
      },
      {
        "id": "hotel_456", 
        "name": "Beach Resort",
        "price_per_night": 200,
        "location": "Guanacaste",
        "rating": 4.2
      }
    ]
  },
  "id": 1
}

// JSON-RPC 2.0 Response Structure (Error)
{
  "jsonrpc": "2.0",
  "error": {
    "code": -32602,
    "message": "Invalid params",
    "data": "Missing required parameter: destination"
  },
  "id": 1
}

Transport Mechanisms

JSON-RPC 2.0 is transport-agnostic, meaning the protocol doesn't dictate how messages are delivered. MCP supports two primary transport methods:

Standard I/O (stdio): Perfect for local development and testing. The MCP server runs as a subprocess, and messages are exchanged through standard input/output pipes. This is lightweight, secure, and ideal for IDEs like Cursor or VS Code extensions.

HTTP: Used when the MCP server is hosted remotely or needs to serve multiple clients simultaneously. Messages are sent as HTTP POST requests, making it easy to deploy MCP servers as web services.

MCP-Specific Conventions

While MCP uses standard JSON-RPC 2.0, it defines specific method names and parameter structures:

Discovery Methods:

• tools/list - Get available tools

• resources/list - Get available resources

• prompts/list - Get available prompts

Action Methods:

• tools/call - Execute a specific tool

• resources/read - Retrieve resource content

• prompts/get - Get a specific prompt

Notification Methods (no response expected):

• notifications/initialized - Client signals it's ready

• notifications/progress - Server reports progress updates

Error Handling

JSON-RPC 2.0 defines standard error codes that MCP extends:

• -32700 Parse error (invalid JSON)

• -32600 Invalid request (malformed JSON-RPC)

• -32601 Method not found

• -32602 Invalid params

• -32603 Internal error

• -32000 to -32099 Server-defined errors (MCP uses these for domain-specific issues)

This standardized approach means client applications can handle errors consistently across different MCP servers.

The beauty of this protocol choice is that it abstracts away all the complexity we saw in our API chaos examples. Instead of learning different authentication schemes, parameter formats, and response structures for each service, developers work with one consistent JSON-RPC interface while MCP servers handle the underlying API complexity behind the scenes.

The Ecosystem Effect

The real power of MCP emerges when it becomes widespread. Imagine a world where:

• Every major travel platform provides an MCP server

• Tourism boards offer MCP servers for their destinations

• AI development tools automatically discover and connect to travel MCP servers

• Building a holiday planning agent is as simple as configuring which destinations and services you want to include

• Your agent can seamlessly work with any new tourism service that supports MCP

We're moving toward a future where AI agents can plan and coordinate complex holiday experiences as easily as humans browse travel websites—and MCP is the standard that makes it possible.

What's Next?

Now that you understand the foundational concepts of MCP, you're ready to dive into the technical implementation. In the next article, we'll explore how to build your own MCP server, create custom tools, and integrate everything into a working AI agent system (basically into our Angular project).

The beauty of MCP is that once you understand these core concepts, the implementation becomes a matter of following the specification—and that's where the real fun begins.

Thanks for reading so far 🙏

I’d like to have your feedback, so please leave a comment, clap or follow. 👏

Spread the Angular love! 💜

If you liked it, share it among your community, tech bros and whoever you want! 🚀👥

Don’t forget to follow me and stay updated: 📱

• 🔗 LinkedIn

• 📝 Medium

• 🎥 YouTube

• 🐦 Twitter

Thanks for being part of this Angular journey! 👋😁

🆕 Last updated for Angular 22.0.0 — includes FormRoot directive, submission options, parse errors, transformedValue(), SignalFormControl bridge, debounce('blur'), reloadValidation(), getError(), ngNoCva, FVC template/reactive interop, inline debounce for async validators, and lazy field instantiation.

Introduction

Traditional Angular forms, while powerfu…

Read more

1. 🔥 @angular/core

a) Support TypeScript 5.9

b) Angular Components Now Use Real Tag Names in Tests - PR

Until now, there was a subtle but important difference between how your components behaved in tests versus production:

In Production: angular creates components using tag names inferred from their selectors:

@Component({selector: 'user-profile', template: '...'})
// Creates actual <user-profile> element

In Tests (Previously): TestBed always wrapped components in generic <div> elements:

const fixture = TestBed.createComponent(UserProfileComponent);
// Always created <div> regardless of selector

This mismatch could hide CSS styling issues, accessibility problems, or any logic that depended on the actual element tag name.

Angular now offers the inferTagName option to align test behavior with production:

// Option 1: Per-component basis
const fixture = TestBed.createComponent(UserProfileComponent, {
  inferTagName: true
});
// Now creates <user-profile> element in tests

// Option 2: Configure globally for all tests
TestBed.configureTestingModule({
  inferTagName: true,
  // ... other config
});

@Component({selector: 'my-button'}) 
// → Creates <my-button>

@Component({selector: 'custom-input[type="text"]'}) 
// → Creates <custom-input>

@Component({selector: '[data-widget]'}) 
// → Falls back to <div> (no tag name in selector)

@Component({template: '...'}) 
// → Creates <ng-component> (no selector)

c) Property-to-Attribute Mapping - PR

Previously, developers faced a choice between verbose syntax and potential SSR problems when working with ARIA attributes:

// Verbose but SSR-safe
<button [attr.aria-label]="buttonText">

// Clean but potential SSR issues  
<button [ariaLabel]="buttonText">

The problem: ARIA DOM properties don't always correctly reflect as HTML attributes during server-side rendering, potentially breaking accessibility for users with assistive technologies.

Angular now supports clean property binding syntax that automatically renders as proper HTML attributes:

// All of these now work identically and render correctly on SSR
<button [aria-label]="buttonText">     // New simplified syntax
<button [ariaLabel]="buttonText">      // Existing camelCase
<button [attr.aria-label]="buttonText"> // Explicit attribute binding

The enhancement includes intelligent mapping for all standard ARIA properties:

@Component({
  template: `
    <div [ariaLabel]="label"
         [ariaExpanded]="isExpanded" 
         [ariaDisabled]="isDisabled"
         [aria-hidden]="isHidden">
      <!-- All render as proper aria-* attributes -->
    </div>
  `
})

Automatic conversions include:

• ariaLabel → aria-label

• ariaExpanded → aria-expanded

• ariaHasPopup → aria-haspopup

• Plus 30+ other ARIA properties

The system intelligently prioritizes component inputs over attribute binding:

@Component({
  selector: 'custom-button'
})
class CustomButton {
  @Input() ariaLabel!: string; // This takes precedence
}

// Binds to component input, not HTML attribute
<custom-button [ariaLabel]="text">

This feature particularly shines in SSR scenarios where proper attribute rendering is crucial for accessibility:

// Server renders: <button aria-label="Save Document">
// Client hydrates seamlessly with identical markup
<button [aria-label]="saveLabel">

d) Promote zoneless to stable

As of Angular v20.2, Zoneless (provideZonelessChangeDetection) Angular is now stable and includes improvements in error handling and server-side rendering.

e) Control Flow Enhancement: as Aliases in @else if Blocks - PR

<!-- ✅ Enhanced: as works in @else if blocks -->
@if (user$ | async; as user) {
  <h1>Welcome, {{user.name}}</h1>
  <p>Role: {{user.role}}</p>
} @else if (userRole$ | async; as role) {
  <!-- 🎉 Now we can use 'as' here too! -->
  <p>Loading user data for {{role}}...</p>
  <p>Please wait while we fetch your {{role}} profile...</p>
} @else {
  <p>Please log in</p>
}

2. 🔥 @angular/common/http

a) Add referrer & integrity support for fetch requests in httpResource - PR

Currently, Angular's httpResource does not expose the referrer and integrity options from the underlying Fetch API.

Exposing these options would provide developers with finer control over the request's referrer and subresource integrity validation, which are important for ensuring security, privacy, and trust in critical resource fetching scenarios.

httpResource(() => ({
  url: '${CDN_DOMAIN}/assets/data.json',
  method: 'GET',
  referrer: 'no-referrer',
  integrity: 'sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GhEXAMPLEKEY='
}));

b) New redirected Property - PR

Angular's HttpClient now provides complete visibility into HTTP redirects with a new redirected property that aligns with the native Fetch API.

@Injectable({
  providedIn: 'root'
})
export class ApiService {
  constructor(private http: HttpClient) {}
  
  getUserProfile(userId: string) {
    return this.http.get(`/api/users/${userId}`, { 
      observe: 'response' 
    }).pipe(
      tap(response => {
        if (response.redirected) {
          console.log('User profile request was redirected');
          console.log('Original URL:', `/api/users/${userId}`);
          console.log('Final URL:', response.url);
          
          // Track redirect for analytics
          this.trackRedirect('user-profile', response.url);
        }
      }),
      map(response => response.body)
    );
  }
  
  private trackRedirect(endpoint: string, finalUrl: string | null) {
    // Send redirect data to analytics service
    analytics.track('http_redirect', {
      endpoint,
      finalUrl,
      timestamp: new Date().toISOString()
    });
  }
}

3. 🔥 @angular/language-service

a) Angular Language Service Now Detects Deprecated APIs in Templates - PR

export class LegacyComponent {
  /**
   * @deprecated Use newProp instead
   */
  @Input() oldProp: string;
}

<!-- Your IDE will now show a suggestion diagnostic here -->
<legacy-component [oldProp]="someValue"></legacy-component>
                   ~~~~~~~ 'oldProp' is deprecated. Use newProp instead

b) Auto-Import for Angular Attributes: No More Manual Directive Imports - PR

When you use directive attributes in your templates, the IDE will now automatically suggest importing the directive for you.

<!-- Type this: -->
<div appHighlight="yellow">
     ↑ 
💡 Quick Fix: Import HighlightDirective from '@app/highlight'

// Automatically added to your component:
import { HighlightDirective } from '@app/highlight';

@Component({
  imports: [HighlightDirective], // ← Added automatically!
  template: `<div appHighlight="yellow">Content</div>`
})
export class MyComponent { }

4. 🔥 @angular/service-worker

a) Take Control of Service Worker Updates: Angular's New updateViaCache Configuration Option - PR

The new updateViaCache option allows you to specify exactly when the browser should check its HTTP cache when updating service workers or any scripts imported via importScripts(). This translates to:

Improved Performance Control: choose between 'imports', 'all', or 'none' to optimize your update strategy based on your application's specific needs.

Better Development Experience: gain more predictable behavior during development cycles, especially when testing service worker updates.

Production Optimization: fine-tune caching strategies for production deployments where update timing is critical.

export const appConfig: ApplicationConfig = {
  providers: [
    provideServiceWorker('ngsw-worker.js', {
      enabled: !isDevMode(),
      updateViaCache: 'imports', // New cache control option
      registrationStrategy: 'registerWhenStable:30000',
    }),
  ],
};

b) New proactive storage monitoring system that prevents cache failures before they happen - PR

The system monitors storage usage and alerts when capacity reaches 95% of the available quota:

private async detectStorageFull() {
  try {
    const estimate = await navigator.storage.estimate();
    const { quota, usage } = estimate;
    
    // Handle cases where quota or usage might be undefined
    if (typeof quota !== 'number' || typeof usage !== 'number') {
      return;
    }
    
    // Consider storage "full" if usage is >= 95% of quota
    // This provides a safety buffer before actual storage exhaustion
    const usagePercentage = (usage / quota) * 100;
    const isStorageFull = usagePercentage >= 95;
    
    if (isStorageFull) {
      this.debugHandler.log(
        'Storage is full or nearly full',
        `DataGroup(${this.config.name}@${this.config.version}).detectStorageFull()`,
      );
    }
  } catch {
    // Error estimating storage, possibly by unsupported browser.
  }
}

For PWA Applications

// Example of how this helps PWAs maintain offline functionality
if (storageNearFull) {
  // Implement cleanup strategies
  // Prioritize critical resources
  // Notify user about storage constraints
}

For Content-Heavy Apps

// Applications with large caching needs benefit from early warnings
if (storageApproachingLimit) {
  // Implement cache eviction policies
  // Compress cached data
  // Switch to selective caching strategies
}

Developers now get clear indicators when storage issues occur:

Storage is full or nearly full -DataGroup(api@v1.2.3).detectStorageFull()

c) Real-Time Version Failure Notifications - PR

Previously, when a Service Worker version encountered critical failures, applications would experience degraded functionality without clear visibility into the root cause. The system introduces a new VersionFailedEvent that provides comprehensive failure information:

/**
 * An event emitted when a specific version of the app has encountered a critical failure
 * that prevents it from functioning correctly.
 */
export interface VersionFailedEvent {
  type: 'VERSION_FAILED';
  version: {hash: string; appData?: object};
  error: string;
}

Automatic Client Notification

When a version fails, the Service Worker automatically notifies all affected clients. Applications can listen for version failures using the existing SwUpdate service:

@Component({
  selector: 'app-root',
  template: `
    <div class="app">
      @if (versionError()) {
        <div class="error-banner">
          <h3>Application Update Issue</h3>
          <p>{{versionError()}}</p>
          <button (click)="handleVersionFailure()">
            Refresh Application
          </button>
        </div>
      }
      
      <router-outlet />
    </div>
  `,
  styles: [`
    .error-banner {
      background: #fee;
      border: 1px solid #fcc;
      border-radius: 4px;
      padding: 16px;
      margin: 8px;
      color: #c66;
    }
    
    .error-banner button {
      background: #c66;
      color: white;
      border: none;
      padding: 8px 16px;
      border-radius: 4px;
      cursor: pointer;
      margin-top: 8px;
    }
  `]
})
export class AppComponent implements OnInit {
  versionError = signal<string | null>(null);
  
  constructor(private swUpdate: SwUpdate) {}
  
  ngOnInit() {
    // Listen for all version events
    this.swUpdate.versionUpdates.subscribe(event => {
      switch (event.type) {
        case 'VERSION_FAILED':
          this.handleVersionFailure(event);
          break;
        case 'VERSION_READY':
          this.handleVersionReady(event);
          break;
        case 'VERSION_DETECTED':
          this.handleVersionDetected(event);
          break;
      }
    });
  }
  
  private handleVersionFailure(event: VersionFailedEvent) {
    console.error('Service Worker version failed:', event);
    
    // Set user-friendly error message
    this.versionError.set(
      `Application version ${event.version.hash.substring(0, 8)} has encountered an error. ` +
      `Please refresh to restore full functionality.`
    );
    
    // Optional: Report to error monitoring service
    this.reportVersionFailure(event);
  }
  
  private handleVersionReady(event: VersionReadyEvent) {
    // Clear any previous errors when new version is ready
    this.versionError.set(null);
    console.log('New version ready:', event.latestVersion.hash);
  }
  
  private handleVersionDetected(event: VersionDetectedEvent) {
    console.log('New version detected:', event.latestVersion.hash);
  }
  
  handleVersionFailure() {
    // Force page reload to get latest version
    window.location.reload();
  }
  
  private reportVersionFailure(event: VersionFailedEvent) {
    // Example: Send to monitoring service
    // errorService.report({
    //   type: 'service-worker-version-failure',
    //   version: event.version.hash,
    //   error: event.error,
    //   userAgent: navigator.userAgent,
    //   timestamp: new Date().toISOString()
    // });
  }
}

Testing the Feature

The new functionality includes comprehensive test coverage:

it('processes version failed events with cache corruption error', (done) => {
  update.versionUpdates.subscribe((event) => {
    expect(event.type).toEqual('VERSION_FAILED');
    expect((event as VersionFailedEvent).version).toEqual({
      hash: 'B',
      appData: {name: 'test-app'},
    });
    expect((event as VersionFailedEvent).error).toContain('Cache corruption detected');
    done();
  });
  
  mock.sendMessage({
    type: 'VERSION_FAILED',
    version: {
      hash: 'B',
      appData: {name: 'test-app'},
    },
    error: 'Cache corruption detected during resource fetch',
  });
});

d) Better Service Worker Debugging: Angular Now Catches Message Errors - PR

When Service Workers receive corrupted or badly formatted messages, they would previously fail silently. Instead of silent failures, you now get clear logs when messages fail:

[SW] Message error occurred - data could not be deserialized
[SW] Driver.onMessageError(origin: https://myapp.com)

e) Modern Service Workers: Angular Adds ES Module Support - PR

Angular Service Workers now support ES modules with a new type configuration option, bringing modern JavaScript features like import and export to your Service Worker scripts.

// Enable ES modules in Service Workers
export const appConfig: ApplicationConfig = {
  providers: [
    provideServiceWorker('ngsw-worker.js', {
      enabled: !isDevMode(),
      type: 'module', // Enable ES module features
      scope: '/app',
      updateViaCache: 'imports'
    }),
  ],
};

f) Service Worker Error Handling: unhandled promise rejections - PR

Unhandled promise rejections happen when a Promise fails but there's no .catch() block or error handling to deal with it:

// Before: Silent failure scenario
class DataSyncService {
  syncUserPreferences() {
    // This could fail silently if the API is down
    fetch('/api/sync-preferences', {
      method: 'POST',
      body: JSON.stringify(this.preferences)
    })
    .then(response => response.json())
    .then(result => {
      // Update local cache
      this.updateLocalCache(result);
    });
    // No .catch() - failures would be silent!
  }
}

// After: With the new logging, you'd see in DevTools:
// "Unhandled promise rejection occurred: NetworkError: Failed to fetch"

5. 🔥 @angular/compiler-cli

a) Smart Template Diagnostics: Catch Function Reference Mistakes Before Runtime - PR

How many times have you written something like this and wondered why it displays [Function] instead of the actual value?

@Component({
  template: `<p>Welcome {{ getUserName }}</p>` // Missing parentheses!
})
class WelcomeComponent {
  getUserName(): string {
    return 'Sarah';
  }
}

The Solution: NG8117 Diagnostic

Angular now automatically detects this pattern and shows a clear warning:

❌ Before: Silent runtime behavior displaying [Function]
✅ Now: Compile-time warning with diagnostic NG8117

6. 🔥 @angular/animations

Say goodbye to @angular/animations (60KB bundle impact) and hello to native CSS animations with animate.enter and animate.leave in Angular 20.2!

Read more here.

7. 🔥 @angular/forms

a) FormArray Gets Efficient Multi-Control Push Support - PR

Previously, adding multiple controls to a FormArray required individual push() calls, each triggering change detection and validation events:

// Old approach - inefficient for large datasets
const formArray = new FormArray([]);
const newControls = [
  new FormControl('value1'),
  new FormControl('value2'),
  new FormControl('value3'),
  // ... potentially hundreds more
];

// Each push triggers valueChanges, statusChanges, and validation
newControls.forEach(control => {
  formArray.push(control); // Triggers events every time!
});

The push() method now supports both individual and batch operations:

// Before: Only single controls
push(control: TControl, options?: { emitEvent?: boolean }): void

// After: Single controls OR arrays of controls  
push(control: TControl | Array<TControl>, options?: { emitEvent?: boolean }): void

8. 🔥 @angular/router

a) Router Goes Reactive: New currentNavigation Signal Replaces Deprecated Method - PR

// Old approach - complex and inefficient
export class App {
  private router = inject(Router);
  
  // Required complex Observable setup
  isNavigating = toSignal(this.router.events.pipe(
    map(() => !!this.router.getCurrentNavigation()) // Deprecated method
  ));
  
  // Manual state checking
  checkNavigationState() {
    const nav = this.router.getCurrentNavigation(); // Deprecated
    return nav ? 'Navigating...' : 'Idle';
  }
}

// New approach - simple and reactive
export class App {
  private router = inject(Router);
  
  // Clean, reactive navigation state
  isNavigating = computed(() => !!this.router.currentNavigation());
  
  // Derive any navigation state reactively
  navigationState = computed(() => {
    const nav = this.router.currentNavigation();
    return nav ? 'Navigating...' : 'Idle';
  });
}

9. 🔥 @angular/platform-browser

a) Warns About Hydration and Blocking Navigation Conflicts - PR

When building Angular applications with server-side rendering (SSR), developers sometimes unknowingly combine features that don't work well together:

// This configuration causes subtle runtime issues
bootstrapApplication(AppComponent, {
  providers: [
    provideClientHydration(), // Enable hydration
    provideRouter(routes, 
      withEnabledBlockingInitialNavigation() // Enable blocking navigation
    )
  ]
});

// Console output:
// ⚠️ Configuration error: found both hydration and enabledBlocking initial navigation 
//    in the same application, which is a contradiction.

b) Angular Introduces IsolatedShadowDom Encapsulation - PR

⚠️ Note: This feature was not included in 20.2, but it may be included in the next 21.0 release.

Ever tried building a reusable component only to have it break when used in different projects?:

// Your beautiful blue button component
@Component({
  template: '<button class="btn">Click me</button>',
  styles: ['.btn { background: blue; color: white; }'],
  encapsulation: ViewEncapsulation.ShadowDom
})

/* Their global styles */
.btn { background: red !important; }

Your blue button becomes red! 😱 Shadow DOM was supposed to prevent this, but Angular's implementation had a leak. The solution:

// Now with TRUE isolation
@Component({
  template: '<button class="btn">Click me</button>',
  styles: ['.btn { background: blue; color: white; }'],
  encapsulation: ViewEncapsulation.IsolatedShadowDom // 🎉
})

// Result: Your button stays blue EVERYWHERE! 💙

When to Choose Each Mode

Use ViewEncapsulation.ShadowDom when:

• You need backward compatibility with existing applications

• You want some global styles to be available in your component

• You're gradually migrating to Shadow DOM

Use ViewEncapsulation.IsolatedShadowDom when:

• Building reusable component libraries

• Creating embeddable widgets for third-party sites

• Need guaranteed style isolation

• Following web standards precisely

• Building micro-frontends that must be completely isolated

10. 🔥 @angular/cli

a) New Angular MCP features

Angular CLI just added powerful AI integration capabilities through MCP (Model Context Protocol) server functionality.

Read more here.

Thanks for reading so far 🙏

I’d like to have your feedback, so please leave a comment, clap or follow. 👏

Spread the Angular love! 💜

If you liked it, share it among your community, tech bros and whoever you want! 🚀👥

Don't forget to follow me and stay updated: 📱

• 🔗 LinkedIn

• 📝 Medium

• 🎥 YouTube

• 🐦 Twitter

Thanks for being part of this Angular journey! 👋😁

Angular CLI 20.2 quietly introduced something that could fundamentally change how we develop Angular applications: Model Context Protocol (MCP) server functionality. If you’re wondering what tools are available and how to use them, you’re in the right place.

If you want to learn more about the beginning of the MCP servers and how Angular integrated its own, you can do it here.

Prerequisites & Core Concept

Before diving into the tools, it is essential to understand the roles of the three main components and what you need to get started:

Essential Prerequisites

• Node.js & npm: The Angular CLI MCP server is a Node.js process, so ensure you have a recent version of Node.js (v18 or newer is typically recommended).

• Angular CLI: The server functionality is built into the latest versions of the Angular CLI (@angular/cli).

• A Compatible AI Client: You must be using an IDE or editor with an AI agent that supports the Model Context Protocol (MCP), such as VS Code (with GitHub Copilot/Agent mode) or Cursor.

Configure your MCP following the official Angular MCP guide.

Important: Two Ways to Configure

Throughout this guide, you’ll see two ways to enable tools and modes:

1. Command Line - For testing or one-time use:

ng mcp --read-only -E modernize

2. Configuration File - For persistent setup in your IDE:

{
   “servers”: {
     “angular-cli”: {
       “command”: “npx”,
       “args”: [”-y”, “@angular/cli”, “mcp”, “--read-only”, “-E”, “modernize”]
     }
   }
}

Most users will use the configuration file approach as it persists across IDE sessions.

Read more

Why @angular/animations Is Being Retired

After eight years of service, @angular/animations is showing its age. Created before modern CSS features like @keyframes and hardware-accelerated transforms were widely supported, the package solved important problems, but now creates new ones:

Size Impact: the package adds approximately 60KB to your bundle size
Performance Issues: animations run in JavaScript without hardware acceleration
Learning Curve: Angular-specific API that doesn't translate to other frameworks
Integration Friction: difficlt to use with popular third-party animation libraries like GSAP or Anime.js

Meanwhile, the web platform has evolved dramatically, offering native animation capabilities that are faster, smaller, and more widely applicable.

Meet Your New Animation System: animate.enter and animate.leave

Starting in Angular 20.2.0, two powerful new features provide everything you need for smooth, performant animations:

Basic Usage: CSS Class Application

The simplest approach applies CSS animation classes automatically:

@Component({
  template: `
    @if (showMessage()) {
      <div animate.enter="slide-in" animate.leave="fade-out">
        Welcome to the future of Angular animations!
      </div>
    }
    <button (click)="toggle()">Toggle Message</button>
  `,
  styles: [`
    .slide-in {
      animation: slideIn 0.3s ease-out;
    }
    
    .fade-out {
      animation: fadeOut 0.2s ease-in;
    }
    
    @keyframes slideIn {
      from { transform: translateY(-20px); opacity: 0; }
      to { transform: translateY(0); opacity: 1; }
    }
    
    @keyframes fadeOut {
      from { opacity: 1; }
      to { opacity: 0; }
    }
  `]
})
export class MessageComponent {
  showMessage = signal(false);
  
  toggle(): void {
    this.showMessage.update((v: boolean) => !v);
  }
}

Advanced Control with Animation Functions

For complex animations or third-party library integration, use function-based control:

@Component({
  template: `
    <div class="animation-playground">
      @if (showElement()) {
        <div class="animated-box"
             (animate.enter)="handleEnterAnimation($event)"
             (animate.leave)="handleLeaveAnimation($event)">
          <h3>Advanced Animation</h3>
          <p>Powered by GSAP integration</p>
        </div>
      }
      
      <button (click)="toggleElement()">
        {{showElement() ? 'Hide' : 'Show'}} Element
      </button>
    </div>
  `,
  styles: [`
    .animated-box {
      width: 300px;
      height: 200px;
      background: linear-gradient(45deg, #667eea 0%, #764ba2 100%);
      border-radius: 12px;
      display: flex;
      flex-direction: column;
      justify-content: center;
      align-items: center;
      color: white;
      margin: 20px 0;
    }
  `]
})
export class AdvancedAnimationComponent {
  showElement = signal(false);

  handleEnterAnimation(event: AnimationCallbackEvent): void {
    // Using GSAP for complex enter animation
    gsap.fromTo(event.target, 
      {
        scale: 0,
        rotation: -180,
        opacity: 0
      },
      {
        scale: 1,
        rotation: 0,
        opacity: 1,
        duration: 0.8,
        ease: "back.out(1.7)",
        onComplete: () => {
          // Animation complete callback is automatic for enter animations
          console.log('Enter animation completed!');
        }
      }
    );
  }

  handleLeaveAnimation(event: AnimationCallbackEvent): void {
    // Complex leave animation with staggered effects
    const timeline = gsap.timeline({
      onComplete: () => {
        // Must call this to complete the removal process
        event.animationComplete();
      }
    });

    timeline
      .to(event.target, {
        scale: 1.1,
        duration: 0.1,
        ease: "power2.out"
      })
      .to(event.target, {
        scale: 0,
        rotation: 180,
        opacity: 0,
        duration: 0.5,
        ease: "power2.in"
      });
  }

  toggleElement(): void {
    this.showElement.update((v: boolean) => !v);
  }
}

Host Element Animations

Apply animations directly to component host elements:

@Component({
  selector: 'notification-card',
  template: `
    <div class="notification-content">
      <h4>{{title()}}</h4>
      <p>{{message()}}</p>
      <button (click)="dismiss()">×</button>
    </div>
  `,
  host: {
    '[animate.enter]': 'enterAnimation',
    '[animate.leave]': 'leaveAnimation',
    'class': 'notification-card'
  },
  styles: [`
    :host {
      display: block;
      background: white;
      border-radius: 8px;
      box-shadow: 0 4px 12px rgba(0,0,0,0.15);
      padding: 16px;
      margin: 8px 0;
      max-width: 400px;
    }
    
    .slide-in-right {
      animation: slideInRight 0.3s ease-out;
    }
    
    .slide-out-right {
      animation: slideOutRight 0.3s ease-in;
    }
    
    @keyframes slideInRight {
      from { transform: translateX(100%); opacity: 0; }
      to { transform: translateX(0); opacity: 1; }
    }
    
    @keyframes slideOutRight {
      from { transform: translateX(0); opacity: 1; }
      to { transform: translateX(100%); opacity: 0; }
    }
  `]
})
export class NotificationCardComponent {
  title = input.required<string>();
  message = input.required<string>();
  type = input<'success' | 'warning' | 'error'>('success');
  autoClose = input<boolean>(true);
  
  dismissed = output<void>();

  enterAnimation = 'slide-in-right';
  leaveAnimation = 'slide-out-right';

  // Auto-close functionality using signals
  private autoCloseTimer = signal<ReturnType<typeof setTimeout> | null>(null);

  constructor() {
    // Set up auto-close when enabled
    effect(() => {
      if (this.autoClose()) {
        const timer = setTimeout(() => this.dismiss(), 5000);
        this.autoCloseTimer.set(timer);
      }
    });
  }

  dismiss() {
    const timer = this.autoCloseTimer();
    if (timer) {
      clearTimeout(timer);
      this.autoCloseTimer.set(null);
    }
    this.dismissed.emit();
  }
}

// Usage in parent component with signal inputs
@Component({
  template: `
    <div class="notifications">
      @for (notification of notifications(); track notification.id) {
        <notification-card 
          [title]="notification.title"
          [message]="notification.message"
          [type]="notification.type"
          [autoClose]="notification.autoClose"
          (dismissed)="removeNotification(notification.id)" />
      }
    </div>
    
    <div class="controls">
      <button (click)="addSuccessNotification()">Add Success</button>
      <button (click)="addWarningNotification()">Add Warning</button>
      <button (click)="addErrorNotification()">Add Error</button>
    </div>
  `,
  styles: [`
    .notifications {
      position: fixed;
      top: 20px;
      right: 20px;
      z-index: 1000;
    }
    
    .controls {
      margin: 20px;
    }
    
    .controls button {
      margin-right: 10px;
      padding: 8px 16px;
      border: none;
      border-radius: 4px;
      cursor: pointer;
    }
  `]
})
export class NotificationContainerComponent {
  notifications = signal<Array<{
    id: number;
    title: string;
    message: string;
    type: 'success' | 'warning' | 'error';
    autoClose: boolean;
  }>>([]);
  
  private nextId = signal(1);

  addSuccessNotification() {
    this.addNotification({
      title: 'Success!',
      message: 'Operation completed successfully!',
      type: 'success',
      autoClose: true
    });
  }

  addWarningNotification() {
    this.addNotification({
      title: 'Warning',
      message: 'Please review your settings.',
      type: 'warning',
      autoClose: false
    });
  }

  addErrorNotification() {
    this.addNotification({
      title: 'Error',
      message: 'Something went wrong. Please try again.',
      type: 'error',
      autoClose: false
    });
  }

  private addNotification(notificationData: Omit<any, 'id'>) {
    const newNotification = {
      id: this.nextId(),
      ...notificationData
    };
    
    this.nextId.update(id => id + 1);
    this.notifications.update(notifications => 
      [...notifications, newNotification]
    );
  }

  removeNotification(id: number) {
    this.notifications.update(notifications => 
      notifications.filter(n => n.id !== id)
    );
  }
}

Testing Support

Angular provides an ANIMATIONS_DISABLED token for test environments:

TestBed.configureTestingModule({
  providers: [
    { provide: ANIMATIONS_DISABLED, useValue: true }
  ]
});

When disabled, animations complete immediately while still triggering all lifecycle events.

Migration Strategy

For existing @angular/animations users, Angular provides a comprehensive migration guide. The most common patterns translate directly:

Before (Angular Animations):

@Component({
  animations: [
    trigger('slideIn', [
      transition(':enter', [
        style({ transform: 'translateX(-100%)' }),
        animate('300ms ease-in', style({ transform: 'translateX(0%)' }))
      ])
    ])
  ]
})

After (Native Animations):

@Component({
  template: `<div animate.enter="slide-in">`,
  styles: [`
    .slide-in {
      animation: slideIn 300ms ease-in;
    }
    @keyframes slideIn {
      from { transform: translateX(-100%); }
      to { transform: translateX(0%); }
    }
  `]
})

The Future is Bright

This change represents more than just a new API—it's Angular's commitment to embracing web standards while providing the developer experience you expect. By moving to native CSS animations, Angular applications become:

• Faster: hardware-accelerated animations

• Smaller: no large animation runtime

• More Portable: skills transfer across frameworks

• More Flexible: easy third-party library integration

The animations field in component decorators is officially deprecated as of Angular 20.2 and will be removed in version 23, giving developers a clear migration timeline.

Thanks for reading so far 🙏

I’d like to have your feedback, so please leave a comment, clap or follow. 👏

Spread the Angular love! 💜

If you liked it, share it among your community, tech bros and whoever you want! 🚀👥

Don't forget to follow me and stay updated: 📱

• 🔗 LinkedIn

• 📝 Medium

• 🎥 YouTube

• 🐦 Twitter

Thanks for being part of this Angular journey! 👋😁

Large Language Models (LLMs) like ChatGPT, Claude, and Gemini have fundamentally changed how we think about software interaction. These AI systems, trained on vast amounts of text data, can understand and generate human-like responses. But here's the thing: they're incredibly powerful yet frustratingly isolated. They can write brilliant code, explain complex concepts, and solve problems, but they can't do anything in your development environment.

Imagine having a brilliant coding assistant who can tell you exactly how to fix a bug but can't see your actual codebase, can't run your tests, and can't understand your project structure. That's been the reality for most AI coding tools until now.

Enter the Model Context Protocol

In November 2024, Anthropic (the company behind Claude) introduced something called the Model Context Protocol. Think of MCP as the missing bridge between AI models and the real world of development tools. It's an open standard that allows AI systems to securely connect to external data sources, tools, and services.

Here's what makes MCP revolutionary: instead of building custom integrations for every single tool, MCP provides a universal language that AI systems can use to communicate with any compatible service. It's like creating a USB-C standard for AI connectivity.

The protocol caught fire quickly. By March 2025, even OpenAI (Anthropic's biggest competitor) had adopted it. Google DeepMind followed suit in April. When fierce competitors agree on a standard this quickly, you know something big is happening.

Angular's Smart Move

Now, here's where Angular's implementation gets interesting. The Angular team didn't just add MCP support – they've positioned Angular as an AI-first development platform. When you run ng mcp, you're not just starting a server; you're making your entire Angular workspace available to AI systems in a structured, secure way.

The current implementation provides two key capabilities:

1. Angular Best Practices as AI Knowledge: The MCP server exposes Angular's official best practices and coding guidelines directly to AI systems. This means when an AI is helping you code, it has immediate access to the latest Angular conventions, TypeScript patterns, and framework-specific guidance.

2. Project Structure Awareness: The server can list and understand your Angular workspace structure, reading from your angular.json file. This gives AI systems spatial awareness of your project – they know what apps and libraries you have, how they're organized, and can provide contextually relevant suggestions.

Getting Started

Run ng mcp and you'll get instructions for configuring your AI host to connect to your Angular workspace:

ng mcp

// If it's the first time, it will print this:                                                                            

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

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

In my case, I’m using VS Code, and this is the configuration I need to add: .vscode/mcp.json. To check the configuration for other IDEs, follow the Angular guide.

Now, if you go to your Copilot in Agent mode (look at tools), you have enabled those features:

From now on, if you chat (Copilot, Amazon Q…), these features will be applied. Remember that you can do the same in other IDEs or desktop LLM clients.

Conclusion

Angular's MCP support might seem like a small feature update, but it represents something much bigger: the transformation of Angular from a framework you use to build applications into a platform for AI-assisted development.

Thanks for reading so far 🙏

I’d like to have your feedback, so please leave a comment, clap or follow. 👏

Spread the Angular love! 💜

If you liked it, share it among your community, tech bros and whoever you want! 🚀👥

Don't forget to follow me and stay updated: 📱

• 🔗 LinkedIn

• 📝 Medium

• 🎥 YouTube

• 🐦 Twitter

Thanks for being part of this Angular journey! 👋😁

Let's be honest - @angular/animations has been showing its age. Here's what's been bothering developers:

• Heavy bundle impact: 60kb of JavaScript just for animations

• No hardware acceleration: Animations run in JavaScript instead of leveraging the GPU

• Angular-only skills: The API doesn't translate to other frameworks or vanilla web development

• Third-party integration pain: Want to use GSAP or Anime.js? Good luck with that.

Enter the New Champions: animate.in and animate.out

The Angular team is introducing two new native framework features that will revolutionize how we animate elements entering and leaving the DOM.

The Sweet Syntax

<!-- CSS Classes (Simple and Clean) -->
<my-component animate.out="fade-out" />
<my-component [animate.in]="dynamicAnimationClasses" />

<!-- JavaScript Functions (For the Power Users) -->
<my-component (animate.out)="customExitAnimation($event)" />
<my-component (animate.in)="handleEntryAnimation($event)" />

Why This Matters

animate.out solves the biggest pain point in CSS animations - you can't easily animate an element out of the DOM because... well, once it's removed, it's gone! This feature delays element removal until your animation completes.

animate.in provides symmetry and consistency, automatically removing CSS classes when animations finish. While CSS now has @starting-styles for this, having both features creates a cohesive API.

Real-World Examples

CSS-Based Animations

<div class="card" 
     animate.in="slide-in-from-left"
     animate.out="fade-out-scale">
  <h3>I animate beautifully!</h3>
</div>

.slide-in-from-left {
  animation: slideIn 0.3s ease-out;
}

.fade-out-scale {
  animation: fadeOutScale 0.25s ease-in;
}

Third-Party Library Integration

// GSAP Animation
animateWithGSAP = (event: AnimationEvent) => {
  gsap.to(event.element, {
    rotation: 360,
    scale: 0,
    duration: 0.5,
    ease: "back.in",
    onComplete() {
      event.animationComplete();
    }
  });
}

<div (animate.out)="animateWithGSAP($event)">
  Powered by GSAP!
</div>

What's Different About This Approach?

🚀 Performance First

• Native CSS animations with hardware acceleration

• Tree-shakeable and optimized

• No 60kb animation library dependency

🎯 Platform-Aligned

• Works with modern CSS features like @starting-styles

• Skills transfer to other frameworks and vanilla web dev

• Embraces web standards

🔧 Developer Experience

• Simple syntax that follows Angular conventions

• Works with CSS classes or JavaScript functions

• Host binding support for reusable animation directives

🧪 Testing-Friendly

• Animations can be disabled in test environments

• Maintains element lifecycle for reliable testing

The Great Naming Debate

The community is split on naming conventions:

• Team animate.in/out: Short, clear, and follows the dot notation pattern

• Team animate.enter/leave: More descriptive and aligns with existing animation terminology

The Angular team seems to be leaning toward animate.in and animate.out to maintain consistency with other dot-notation bindings like class. and style..

What This Means for Your Apps

Migration Path

The Angular team is creating comprehensive migration guides from @angular/animations to pure CSS. The old system will coexist during the transition period, so no rush!

Bundle Size Impact

Removing the animations package dependency could save you 60kb of JavaScript - that's significant for performance, especially on mobile devices.

Future-Proofing

As web standards evolve (hello, scoped view transitions!), this approach positions Angular to adopt new capabilities without major API changes.

Key Takeaways

1. @angular/animations is being deprecated - but not immediately removed

2. animate.in and animate.out are coming - built into the framework core

3. CSS-first approach - embrace modern web platform capabilities

4. Third-party library friendly - use GSAP, Anime.js, or whatever you prefer

5. Performance wins - hardware acceleration and smaller bundles

Try It Out

The Angular team has provided a StackBlitz prototype where you can experiment with the new features (CSS classes only for now).

Check the complete RFC here.

The Bottom Line

This RFC represents Angular's commitment to evolving with web standards while maintaining the developer experience that makes the framework special. By embracing CSS-native animations and providing escape hatches for complex scenarios, Angular is positioning itself for the next generation of web applications.

If you are interested in a guide on old Angular animations, I have a complete tutorial about it on YouTube.

Thanks for reading so far 🙏

I’d like to have your feedback, so please leave a comment, clap or follow. 👏

Spread the Angular love! 💜

If you liked it, share it among your community, tech bros and whoever you want! 🚀👥

Don't forget to follow me and stay updated: 📱

• 🔗 LinkedIn

• 📝 Medium

• 🎥 YouTube

• 🐦 Twitter

Thanks for being part of this Angular journey! 👋😁