You have finally taken the plunge. You removed zone.js from your polyfills, updated your angular.json, and added provideExperimentalZonelessChangeDetection() to your application config. The bundle size dropped significantly, and the startup time improved.
But now, specific parts of your application feel "stuck."
A loading spinner never disappears even after the data arrives. A notification triggered by setTimeout never renders. Third-party libraries that previously integrated seamlessly now fail to update the DOM.
This is the most common hurdle in migrating to Zoneless Angular. Here is exactly why the framework stopped watching your code, and the architectural patterns required to fix it.
The Root Cause: The End of Monkey-Patching
To understand why your view is stale, you must understand how Angular worked for the last decade.
Traditionally, Zone.js acted as a global interceptor. It "monkey-patched" standard browser APIs, including window.setTimeout, setInterval, Promise.then, and addEventListener. Every time you called setTimeout, you weren't calling the browser's native function directly; you were calling a Zone.js wrapper.
When that wrapper finished executing your callback, it signaled Angular to run a global Change Detection (CD) cycle. It assumed that any asynchronous event could potentially change the application state.
Zoneless Change Detection removes this safety net.
In a zoneless application, Angular no longer intercepts browser events. If you update a standard class property inside a setTimeout or a generic callback, Angular has no way of knowing that the data changed. The framework waits for an explicit notification that the View needs to refresh.
The Solution: Reactivity via Signals
The primary mechanism for driving updates in Zoneless Angular is Signals.
In the Zone.js era, we relied on mutation. We changed a value, and Zone.js triggered the check. In the Zoneless era, we rely on notification. When you update a Signal, it notifies its consumers (the template) that the value is dirty.
Angular's scheduler picks up this notification and updates the DOM. If your state is wrapped in a Signal, setTimeout and setInterval work perfectly fine because the act of updating the signal is the trigger, not the timer itself.
The "Broken" Code (Legacy Style)
Here is a typical component that fails in a Zoneless environment. It relies on implicit change detection triggering after the timer completes.
import { Component, OnInit } from '@angular/core';
@Component({
selector: 'app-status-tracker',
standalone: true,
template: `
<div class="status-box">
<!-- In Zoneless, this stays 'Initializing...' forever -->
<h3>Current Status: {{ status }}</h3>
</div>
`
})
export class StatusTrackerComponent implements OnInit {
status = 'Initializing...';
ngOnInit() {
// ❌ Fails in Zoneless:
// The callback runs, 'status' updates in memory,
// but Angular is never told to re-render the template.
setTimeout(() => {
this.status = 'Active';
console.log('Status updated to Active (View will not reflect this)');
}, 2000);
}
}
The Fix: Migrating to Signals
Refactoring mutable properties to Signals restores reactivity without requiring Zone.js.
import { Component, OnInit, signal } from '@angular/core';
@Component({
selector: 'app-status-tracker-fixed',
standalone: true,
template: `
<div class="status-box">
<!-- ✅ The template listens to the signal -->
<h3>Current Status: {{ status() }}</h3>
</div>
`
})
export class StatusTrackerFixedComponent implements OnInit {
// 1. Initialize as a writable signal
status = signal('Initializing...');
ngOnInit() {
setTimeout(() => {
// 2. Update the signal
// This explicitly notifies the scheduler that this view is dirty.
this.status.set('Active');
}, 2000);
}
}
Because the template reads {{ status() }}, Angular creates a reactive graph dependency. When .set() is called, Angular knows exactly which component needs to re-render, regardless of the context (timer, fetch, or websocket) that triggered it.
Edge Case: Handling Third-Party Libraries
While Signals are the gold standard, you cannot always rewrite the internal state management of a third-party library.
If you are using a library that maintains its own internal state and exposes an event callback (e.g., a chart library or a rich text editor) that doesn't use Signals, you need a manual escape hatch.
You must explicitly tell Angular to check the view using ChangeDetectorRef.
The Manual Fix
Use this approach sparingly. It mimics the behavior of the old markForCheck strategy but is strictly necessary for non-signal integrations.
import { Component, OnInit, ChangeDetectorRef, inject } from '@angular/core';
@Component({
selector: 'app-legacy-integration',
standalone: true,
template: `
<div>
<p>External Data: {{ legacyData }}</p>
</div>
`
})
export class LegacyIntegrationComponent implements OnInit {
legacyData = 'Waiting...';
// Inject the ChangeDetectorRef
private cdr = inject(ChangeDetectorRef);
ngOnInit() {
// Simulate a library that runs outside Angular's awareness
// e.g., externalLib.on('event', callback)
const externalSource = {
subscribe: (cb: (val: string) => void) => {
setTimeout(() => cb('Data Received'), 1500);
}
};
externalSource.subscribe((data) => {
this.legacyData = data;
// ❌ Without this, the view remains stale.
// ✅ Explicitly mark the component for check.
this.cdr.markForCheck();
});
}
}
In Zoneless mode, markForCheck() schedules a tick. It does not run synchronously; it coalesces updates to ensure performance efficiency.
RxJS and the AsyncPipe
A common misconception is that RxJS streams break in Zoneless Angular. This is incorrect.
If you use the AsyncPipe in your templates, you do not need to change anything.
<!-- This works automatically in Zoneless -->
<div *ngIf="userData$ | async as user">
{{ user.name }}
</div>
The AsyncPipe internally calls markForCheck() whenever a new value is emitted from the observable. It bridges the gap between the stream and the generic Change Detection mechanism automatically.
However, if you .subscribe() manually in your TypeScript code to update a plain class property, that functionality will break. You must either convert that property to a Signal or manually call cdr.markForCheck().
Summary of Migration Rules
To ensure high retention of the user interface responsiveness during your migration, follow these three rules:
- Prefer Signals: Convert mutable state to
signal(). This is the native language of Zoneless Angular. - Trust AsyncPipe: Keep using Observables in templates; the pipe handles the scheduling for you.
- Manual Fallback: Only use
ChangeDetectorRef.markForCheck()when integrating with imperative APIs or libraries you do not control.
Disabling Zone.js is a significant performance upgrade, removing the overhead of monkey-patching and reducing bundle size. By shifting from implicit detection to explicit signaling, you gain finer control over rendering and predictable application behavior.