INCRM
Angular
General
Commonly used apps
Extras
Additional pages and features
Documentation
Resources for developers
Your trial is expiring soon!
You have 3 days left in your trial. Upgrade to pro to continue using all features.
Check out BuilderKit; the next generation of toolkit for building beautiful Angular applications. Use promo code FUSE on checkout for 20% off your purchase!
AI Chat
Today
Yesterday
Previous 7 days
Zoneless change detection migration
We are about to flip our Angular app to zoneless. What breaks first in practice?
In practice the first casualties are the places where you mutate state outside of a signal and quietly rely on Zone.js to notice. The three most common ones are: values updated from a setTimeout or a raw addEventListener callback, third-party widgets that write to component fields directly, and anything driven by a plain class property that a template reads.
The fix is almost always mechanical rather than architectural. Move the property to a signal and the template re-renders on write, no matter which context produced it.
typescript
export class Ticker {
readonly elapsed = signal(0);
constructor() {
const id = setInterval(() => this.elapsed.update((v) => v + 1), 1000);
inject(DestroyRef).onDestroy(() => clearInterval(id));
}
}Once that pass is done, turn on the zoneless provider in a single feature route first rather than the whole app. It keeps the blast radius small and the failures easy to attribute.
Our test suite uses fakeAsync heavily. Does that survive the switch?
Mostly, yes. fakeAsync still patches timers and microtasks, so tests that tick through a debounce keep working. What changes is the implicit re-render: after advancing time you now need an explicit fixture.detectChanges() where the zone used to do it for you.
A practical migration order is to start with the specs that already call detectChanges explicitly, since those need no edits at all, then work through the ones that assert on the DOM
Generating...
AI can make mistakes. Check important info.