Forem: Andy Tu Hoang

How Angular Change Detection Works Without ZoneJs?

Andy Tu Hoang — Mon, 18 May 2026 03:14:19 +0000

Angular Change Detection is the process that keeps the UI in sync with component state. When a value changes in TypeScript, Angular must update the template. For example:

<h1>{{ title }}</h1>

If title changes, Angular needs to update the text in the DOM. This is important because users should always see the latest state of the application.

How Change Detection Worked Before with Zone.js

In older Angular applications, Zone.js helped Angular know when it should run Change Detection. Zone.js patches common async browser APIs, such as:

click events
HTTP requests
setTimeout
setInterval
promises

After one of these async tasks finishes, Zone.js can notify Angular. Then Angular runs Change Detection.

setTimeout(() => {
  this.message = 'Loaded';
}, 1000);

With Zone.js, Angular can update this template automatically:

<p>{{ message }}</p>

This was convenient, but it also had problems. Zone.js can add runtime overhead. It can also make updates feel implicit. Sometimes Change Detection runs because of an async task, but the reason is not clear from your component code. That is one reason Angular is moving to a more explicit model.

Why Angular Is Moving Away from Zone.js

Angular is moving toward zoneless Change Detection. The goal is to make UI updates more predictable. In a zoneless app, Angular does not depend on Zone.js to watch all async browser tasks. Instead, Angular listens to Angular-level notifications.

This gives some benefits:

better performance
fewer unnecessary checks
clearer update triggers
more control for developers
better support for Signals

The main idea is simple: Angular should run Change Detection when Angular knows that UI state changed.

Introduction to Zoneless in Angular

Zoneless is the default in Angular v21+ so you do not need to do anything to enable it. You should verify that provideZoneChangeDetection is not used anywhere to override the default configuration.

If you are using Angular v20, enable zoneless change detection by adding provideZonelessChangeDetection() at bootstrap:

import { provideZonelessChangeDetection } from '@angular/core';
import { bootstrapApplication } from '@angular/platform-browser';
import { AppComponent } from './app/app.component';

bootstrapApplication(AppComponent, {
  providers: [
    provideZonelessChangeDetection()
  ]
});

From Angular core, provideZonelessChangeDetection() provides the zoneless scheduler and replaces NgZone with NoopNgZone:

{provide: ChangeDetectionScheduler, useExisting: ChangeDetectionSchedulerImpl},
{provide: NgZone, useClass: NoopNgZone},
{provide: ZONELESS_ENABLED, useValue: true},

So Angular no longer needs Zone.js to decide when to schedule a render update. Instead, Angular uses ChangeDetectionSchedulerImpl.

Change Detection Triggers in Zoneless Mode

In zoneless mode, Angular still runs Change Detection. The difference is that Angular does not wait for Zone.js to say, "An async task finished." Angular has its own triggers.

The common triggers are:

a signal used in a template changes
a component input is set
a template or host listener runs
ChangeDetectorRef.markForCheck() is called

Deep Dive into the Angular Core Flow

Now let us follow the main path in Angular core.

Signal Path

When a signal is read in a template, Angular tracks it with a reactive template consumer. When that signal changes, Angular marks the ancestors for traversal.

export function markAncestorsForTraversal(lView: LView) {
  // Notify scheduler that Angular needs to traverse the view tree again.
  lView[ENVIRONMENT].changeDetectionScheduler?.notify(NotificationSource.MarkAncestorsForTraversal);

  // Mark parent views for traversal.
  ...
}

This function tells Angular that some part of the view tree must be visited again.

Other Triggers Call markViewDirty

For inputs, listeners, and markForCheck(), Angular usually goes through markViewDirty(). For example, when an input is set:

setInput(name: string, value: unknown): void {
  ...
  markViewDirty(childComponentLView, NotificationSource.SetInput);
}

For a template listener:

function wrapListenerIn_markDirtyAndPreventDefault(event: any) {
  ...
  markViewDirty(startView, NotificationSource.Listener);
  ...
}

For ChangeDetectorRef.markForCheck():

markForCheck(): void {
  markViewDirty(this._cdRefInjectingView || this._lView, NotificationSource.MarkForCheck);
}

All of these paths call markViewDirty().

export function markViewDirty(lView: LView, source: NotificationSource): LView | null {
  // Decide which dirty flags should be used for the current state.
  const dirtyBitsToUse = isRefreshingViews()
    ? LViewFlags.Dirty
    : LViewFlags.RefreshView | LViewFlags.Dirty;

  // Notify the zoneless scheduler about this change.
  lView[ENVIRONMENT].changeDetectionScheduler?.notify(source);

  while (lView) {
    // Mark current view and ancestor views as dirty.
    lView[FLAGS] |= dirtyBitsToUse;

    // Walk up to the root view.
    const parent = getLViewParent(lView);

    if (isRootView(lView) && !parent) {
      return lView;
    }

    lView = parent!;
  }

  return null;
}

This function marks the view tree and sends the notification to the zoneless scheduler.

The Scheduler Receives the Notification

The scheduler receives the source in notify(). Before scheduling a tick, Angular maps the source to dirty flags and checks whether a tick should be scheduled.

notify(source: NotificationSource): void {
  // Check whether zoneless is enabled and whether this source should notify the scheduler.
  ...

  // Convert the notification source into ApplicationRef dirty flags.
  ...

  // Stop here if a tick is already scheduled, already running, or the app is destroyed.
  ...

  const scheduleCallback = this.useMicrotaskScheduler
    ? scheduleCallbackWithMicrotask
    : scheduleCallbackWithRafRace;

  this.pendingRenderTaskId = this.taskService.add();

  if (this.scheduleInRootZone) {
    this.cancelScheduledCallback = Zone.root.run(() => scheduleCallback(() => this.tick()));
  } else {
    this.cancelScheduledCallback = this.ngZone.runOutsideAngular(() =>
      scheduleCallback(() => this.tick()),
    );
  }
}

This is the difference from Zone.js. Zone.js says, "An async task happened." Zoneless says, "This Angular view or reactive value changed." Then Angular schedules this.tick().

The Scheduler Calls tick()

After the scheduler callback runs, Angular calls tick().

private tick(): void {
  if (this.runningTick || this.appRef.destroyed) {
    return;
  }

  if (this.appRef.dirtyFlags === ApplicationRefDirtyFlags.None) {
    this.cleanup();
    return;
  }

  const task = this.taskService.add();

  try {
    this.ngZone.run(
      () => {
        this.runningTick = true;

        // Start application-level Change Detection.
        this.appRef._tick();
      },
      undefined,
      this.schedulerTickApplyArgs,
    );
  } catch (e: unknown) {
    this.applicationErrorHandler(e);
  } finally {
    this.taskService.remove(task);
    this.cleanup();
  }
}

At this point, Angular starts the real Change Detection work for the application.

ApplicationRef Runs Synchronization

ApplicationRef._tick() calls the internal synchronization flow.

private tickImpl = (): void => {
  ...

  try {
    this._runningTick = true;
    this.synchronize();
    ...
  } finally {
    ...
  }
};

Then synchronizeOnce() checks the dirty views.

private synchronizeOnce(): void {
  ...

  if (this.dirtyFlags & ApplicationRefDirtyFlags.ViewTreeAny) {
    ...

    for (let {_lView} of this.allViews) {
      if (!useGlobalCheck && !requiresRefreshOrTraversal(_lView)) {
        continue;
      }

      const mode =
        useGlobalCheck && !this.zonelessEnabled
          ? ChangeDetectionMode.Global
          // In zoneless mode, Angular uses targeted checking.
          : ChangeDetectionMode.Targeted;

      detectChangesInternal(_lView, mode);
    }
  }

  ...
}

In zoneless mode, Angular tries to check only the views that were marked or affected by reactive changes.

Angular Refreshes the View

Finally, Angular enters render3 Change Detection.

export function detectChangesInternal(lView: LView, mode = ChangeDetectionMode.Global) {
  ...

  try {
    detectChangesInViewWhileDirty(lView, mode);
  } finally {
    ...
  }
}

Inside that flow, Angular decides whether the view should refresh.

function detectChangesInView(lView: LView, mode: ChangeDetectionMode) {
  ...

  shouldRefreshView ||= !!(flags & LViewFlags.RefreshView);
  shouldRefreshView ||= !!(consumer?.dirty && consumerPollProducersForChange(consumer));

  ...

  if (shouldRefreshView) {
    refreshView(tView, lView, tView.template, lView[CONTEXT]);
  }
}

This is where the DOM update finally happens. The short flow is:

signal / input / listener / markForCheck
-> notify scheduler
-> schedule tick
-> ApplicationRef._tick()
-> targeted Change Detection
-> refreshView()
-> DOM updated

Compatibility with Legacy Projects

Apps that already use ChangeDetectionStrategy.OnPush often need fewer changes. The reason is simple: OnPush apps usually already use explicit notification mechanisms when they update values from async events. For example, they may use markForCheck(), AsyncPipe, or signals.

@Component({
  selector: 'app-user',
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `<p>{{ userName }}</p>`
})
export class UserComponent {
  userName = 'Loading...';

  constructor(private cdr: ChangeDetectorRef, private userService: UserService) {}

  ngOnInit() {
    this.userService.getUser().subscribe(user => {
      this.userName = user.name;

      // OnPush code often already has this line.
      // It also makes the component compatible with zoneless Change Detection.
      this.cdr.markForCheck();
    });
  }
}

If the app uses AsyncPipe, Angular also calls markForCheck() for you when the observable emits.

@Component({
  selector: 'app-user',
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `<p>{{ userName$ | async }}</p>`
})
export class UserComponent {
  userName$ = this.userService.getUserName();

  constructor(private userService: UserService) {}
}

Apps that do not use OnPush may need more changes. In a Zone.js app, this code can work because Zone.js schedules Change Detection after the HTTP callback. In a zoneless app, this update does not notify Angular by itself.

@Component({
  selector: 'app-user',
  template: `<p>{{ userName }}</p>`
})
export class UserComponent {
  userName = 'Loading...';

  constructor(private userService: UserService) {}

  ngOnInit() {
    this.userService.getUser().subscribe(user => {
      // In zoneless mode, this field update alone may not be enough.
      this.userName = user.name;
    });
  }
}

To make it compatible, use one of Angular's notification mechanisms.

ngOnInit() {
  this.userService.getUser().subscribe(user => {
    this.userName = user.name;
    this.cdr.markForCheck();
  });
}

Or move the state to a signal.

userName = signal('Loading...');

ngOnInit() {
  this.userService.getUser().subscribe(user => {
    this.userName.set(user.name);
  });
}

So OnPush is not strictly required for zoneless. But it is a recommended step because it makes missing notifications easier to find before removing Zone.js. Components using the default strategy can still work, as long as they notify Angular when Change Detection needs to run.

Conclusion

Zoneless Change Detection means Angular does not depend on Zone.js to schedule UI updates. Instead, Angular uses clear notifications from signals, inputs, listeners, and markForCheck().

In this article, we had a quick look about Zoneless Change Detection and how Angular updates the DOM without Zone.js.

Hope you found this article helpful.

For more in-depth content about Angular and web development, feel free to visit my blog at TuHoangDev.

If you have any questions, don’t hesitate to reach out via Facebook Messenger.

Angular: Fix 404 error after reloading Github Pages with Custom Angular CLI Builder

Andy Tu Hoang — Mon, 03 Apr 2023 04:54:41 +0000

Back to the first time I deployed my Angular project to Github Pages, I just run ng run build and deployed the build artifacts to Github. Everything seem working ok. But then I got the issue that whenever I refresh my application, it return 404 Page. Obviously, I had to searching in the Google how to fix this issue. Fortunately, I found the way to fix this issue from angular.io. I just need to build the application and then add a 404 page, copy index.html into 404.html. Everything works perfectly. But now, when I want update my page, I have to build and copy again and again. I wondered if I can automatically generate 404.html file after run ng run build. And I found a solution that is using Custom Angular CLI Builders.

What is Angular CLI builders?

When working with Angular, we usually use some CLI commands like ng serve, ng build, ng run. These commands use an internal tool called Architect to run CLI builders, which apply another tool to accomplish the wanted task. From Angular version 8, Angular developers can use CLI Builder API to customize the Angular CLI by adding or modifying commands. For example, you could supply a builder to perform an entirely new task, or to change which third-party tool is used by an existing command.

Create our custom CLI builders

Update angular.json file

We have to update the angular.json file to add a target for this builder to the "architect" section of our new project.

{
  // …
  "projects": {
    // …
    "builder-test": {
      // …
      "architect": {
        // …
        "build": {
          "builder": "@angular-devkit/build-angular:browser",
          "options": {
            // … more options…
            "outputPath": "dist/builder-test",
            "index": "src/index.html",
            "main": "src/main.ts",
            "polyfills": "src/polyfills.ts",
            "tsConfig": "src/tsconfig.app.json"
          },
          "configurations": {
            "production": {
              // … more options…
              "optimization": true,
              "aot": true,
              "buildOptimizer": true
            }
          }
        },
        // other target. E.g: lint, server...
        "build-generate-404-page": {
          "builder": "./builders:build-generate-404-page"
        }
      }
    }
  }
  // …
}

To run our builder, use following CLI command:

ng run [project name]:build-generate-404-page

Of course, if you run this command right now, you will get the error because we have not implemented any logic for our custom builder. Back to angular.json, you can see in build-generate-404-page object, we added builder property. This property will instruct Angular which method to invoke when this target is called. Value of builder is a string with 2 sections that separated by the colon:

The first section is the path to folder which contain our custom builder. It can be a relative path if you create custom builder project in same workspace our project (like we will do in the example). Or it can be a name of npm library if you publish our builder as a library, it will look like: @builder-example.
The second path is the command that we want our builder executed. In the example, it is build-generate-404-page.

Create Builder Project

Our builder project structure will look like:

└── builders
    ├─ src
    │   └─ build-generate-404-page
    |      ├─ index.ts
    |      └─ schema.json
    ├─ builders.json
    ├─ package.json
    └─ tsconfig.json

package.json

{
  "name": "@andyt/custom-builder",
  "version": "1.0.0",
  "description": "Angular CLI custom builder",
  "builders": "builders.json",
  "scripts": {
    "build": "rimraf dist && tsc",
    "postbuild": "copyfiles --up 1 ./src/**/*.json ./dist",
    "build:watch": "tsc-watch --onSuccess 'npm run postbuild'"
  },
  "author": "Andy Tu Hoang",
  "license": "ISC",
  "devDependencies": {
    "@angular-devkit/architect": "^0.1402.8",
    "@angular-devkit/core": "^14.2.8",
    "@types/node": "^18.11.12",
    "copyfiles": "^2.4.1",
    "rimraf": "^3.0.2",
    "tsc-watch": "^6.0.0",
    "typescript": "~4.6.2"
  }
}

Like other Node.js projects, package.json describes dependencies of this project. Beside, in Angular CLI Builder project, we have to define builders property in package.json. When Angular run CLI Builder, it goes to package.json firstly and find builders property, this property points to builder definition file, in the example, it is builder.json (but you can name it anything). Then Angular goes to builder.json and base on it to find the script that need to be executed.

In our package.json, we also describes some scripts:

build - build typescript script to javascript script
postbuild - this script execute immediately after build. We use it to copy schema.json file to dist folder
build:watch - use watch mode to debug builder script

builders.json

{
  "builders": {
    "build-generate-404-page": {
      "description": "It builds application and then auto generate 404.html",
      "implementation": "./dist/build-generate-404-page",
      "schema": "./dist/build-generate-404-page/schema.json"
    }
  }
}

This file describes all available builders that exist in our builder projects. Each key under the builders property is the name of the builder, in this case, it is build-generate-404-page. Every builder will have some following property:

description – This field contains a message that describes what this builder does and it appears when you run e.g ng build --help command.
implementation – This field points to the NodeJS script that will be executed when Angular CLI call to corresponding builder.
schema – This field points to the JSON file that describes a list of options that can be provided for the builder function in the builder script. You can also describe type as well as default value and many other thing of the option. Note: If your builder script doesn't have any options like the example, you still have to define this property and create corresponding schema.json file.

tsconfig.json

{
  "compilerOptions": {
    "baseUrl": "./",
    "target": "ESNext",
    "outDir": "./dist",
    "rootDir": "./src",
    "module": "CommonJS"
  },
  "include": ["src/**/*"],
  "exclude": ["node_modules"]
}

The presence of a tsconfig.json file in a directory indicates that the directory is the root of a TypeScript project. The tsconfig.json file specifies the root files and the compiler options required to compile the project.

schema.json

{
  "$schema": "http://json-schema.org/schema",
  "type": "object",
  "properties": {}
}

In our builder, we don't use any options, so properties is empty. But let explore how @angular-devkit describes schema.json.

You can see assets property is described and type of it is an array. And this is exactly the property that you define in your angular.json file in the options property of the corresponding build architect target.

build-generate-404-page/index.ts

Now, we create a builder that copies index.html to 404.html after build project. To create a builder, use the createBuilder() CLI Builder function, and return a Promise object.

import { createBuilder } from '@angular-devkit/architect';
import { readFileSync, writeFileSync } from 'fs';

export default createBuilder(async (options, ctx) => {
  //put logic hear
});

First, we have to invoke target build in angular.json file to build our Angular application.

export default createBuilder(async (options, ctx) => {
  try {
    const build = await ctx.scheduleTarget({
      target: 'build',
      project: ctx.target!.project,
      configuration: ctx.target!.configuration!,
    });

  } catch (error) {
    return {
      success: false,
    };
  }
});

Then, we get the outputPath and use Node.js API readFileSync and writeFileSync to copy content from index.html to 404.html

export default createBuilder(async (options, ctx) => {
  ctx.logger.info('Builder has been started...');
  try {
    const build = await ctx.scheduleTarget({
      target: 'build',
      project: ctx.target!.project,
      configuration: ctx.target!.configuration!,
    });
    const result = await build.result;
    const success = result.success;
    const outputPath = result.outputPath as string;
    if (success) {
      const pathOfIndexPage = `${outputPath}/index.html`;
      const contentOfIndexPage = readFileSync(pathOfIndexPage, 'utf-8');
      const pathOfNotFoundPage = `${outputPath}/404.html`;
      writeFileSync(pathOfNotFoundPage, contentOfIndexPage);
      ctx.logger.info('Builder has been completed!!!');
      return { success };
    } else {
      return {
        success: false,
      };
    }
  } catch (error) {
    return {
      success: false,
    };
  }
});

Our builder logic is done. we run npm run build to compile it to Node.js script. And then go to our Angular application, run ng run [project name]:build-generate-404-page and push all to Github Repository. Your application will be run ok on Github Page without 404 redirect issue.

Summary

We already explored how to create a custom Angular CLI Builder to fix 404 redirect issue on Github Page. CLI Builder API is an intensive tool which you can do a lot of thing with this. If you want to learn more about CLI Builder, you can visit Angular.io.