DEV Community: Max

Deep dive into the infamous ExpressionChangedAfterItHasBeenCheckedError in Angular

Max — Tue, 31 Jan 2023 09:17:00 +0000

Overview

One of the most frequent Angular related topics on StackOverflow is about the infamous ExpressionChangedAfterItHasBeenCheckedError error. Usually these questions come up because developers do not really understand why the check that produces this error is required. Many even view it as a flaw in the framework design. However, for Angular it’s simply a way to enforce unidirectional data flow and ensure that application state and UI are in sync after a single pass of change detection cycle.

Unidirectional data flow entails that once Angular has processed bindings for the current component, you can no longer update the properties of that component that make up bindings expressions. Angular implements checkNoChanges method that runs after a regular change detection cycle and re-evaluates binding expressions. If during this check Angular detects that an expression produces different value compared to the value it produced during the preceding detectChanges run, it will throw ExpressionChangedAfterItHasBeenCheckedError.

A binding defines the property name to update and the expression that produces a value for the property. Bindings are encoded as rendering engine (Ivy) instructions which Angular’s compiler puts into the component’s
template function. When Angular checks a component view during change detection, it runs over all bindings by executing corresponding instructions. For each binding, it evaluates expressions and compares the results to the previous value produced by the expression. That’s where the name dirty checking comes from.

If those values differ, Angular updates the property defined by the binding. That’s what happens in the regular change detection cycle triggered by the detectChanges method. However, when running in special checkNoChangesMode that is triggered by checkNoChanges method, when the difference is detected, instead of updating the binding the Expression Changed error is thrown.

The function that checks for the difference and throws the error is bindingUpdated. Here’s a bit simplified implementation of this function:

export function bindingUpdated(lView, bindingIndex, value) {
  const oldValue = lView[bindingIndex];

  // no update is needed
  if (Object.is(oldValue, value)) {
    return false;
  } else {
    // if we're in development mode and the values are not equal,
    // throw the error and return without updating the binding
    if (ngDevMode && isInCheckNoChangesMode()) {
      const oldValueToCompare = oldValue !== NO_CHANGE ? oldValue : undefined;
      if (!devModeEqual(oldValueToCompare, value)) {
        const details = getExpressionChangedErrorDetails(...);
        throwErrorIfNoChangesMode(oldValue === NO_CHANGE, details.oldValue, ...);
      }
      return false;
    }
    lView[bindingIndex] = value;
    return true;
  }
}

We can do a quick usage search to identify all Ivy instructions that use bindingUpdated and hence can throw the error:

Interestingly, there’s also a unit-test that validates the logic that produces the error. Here’s how it checks if the property instruction that updates the [id] property correctly throws the error:

class MyApp {
      unstableStringExpression: string = 'initial';

      ngAfterViewChecked() {
        this.unstableStringExpression = 'changed';
      }
}

it('should include field name in case of property binding', () => {
  const message = `Previous value for 'id': 'initial'. Current value: 'changed'`;
  expect(() => initWithTemplate('<div [id]="unstableStringExpression"></div>'))
      .toThrowError(new RegExp(message));
});

Test specs use ngAfterViewChecked lifecycle hook to update the property as this hook is triggered after the bindings have been processed. In the it('should include field...) spec we saw above, the setup starts with the value "initial" for the unstableStringExpression component property. Then inside the ngAfterViewChecked hook, the value is set to "changed". The checkNoChanges verification cycle will throw the ExpressionChangedAfterItHasBeenCheckedError error because it detects the difference.

All this means that the root cause for the error is always the same - different value that comes to a binding during the regular detectChanges cycle and the validation detectNoChanges run. Accordingly, the primary fix is also always the same - ensuring the expression yields the same value during the regular detectChanges cycle and the verification checkNoChanges run.

This test suit basically defines all possible cases when bindings will throw the error:

initWithTemplate('<div [id]="unstableStringExpression"></div>')
initWithTemplate('<div id="Expressions: {{ a }}')
initWithTemplate('<div [attr.id]="unstableStringExpression"></div>')
initWithTemplate('<div [style.color]="unstableColorExpression"></div>')
initWithTemplate('<div [class.someClass]="unstableBooleanExpression"></div>')
initWithTemplate('<div i18n>Expression: {{ unstableStringExpression }}</div>')
initWithTemplate('<div i18n-title title="Expression: {{ unstableStringExpression }}"></div>')
initWithHostBindings({'[id]': 'unstableStringExpression'})
initWithHostBindings({'[style.color]': 'unstableColorExpression'})
initWithHostBindings({'[class.someClass]': 'unstableBooleanExpression'})

The particular fix for the error depends on the leading cause
which is something that leads to the binding getting different values. To find the leading cause we need to know what binding gets different values and where the difference in values comes from. Usually finding this leading cause isn't straightforward and requires the use of lots of interesting debugging techniques to pinpoint the culprit and we’ll explore in-depth how to do that in the next section finding the primary cause.

Let’s now take a look at a very simple illustration of this verification mechanism works.

The error mechanism in details

To see how the error is detected and thrown we’ll implement a component that renders a random number obtained through Math.random():

@Component({
  selector: 'p-cmp',
  template: `
    <h3>
      <button (click)="noop()">Generate number</button>
    </h3>
    <div [textContent]="number"></div>
  `
})
export class P {
  noop() {}
  get number() {
    return Math.random();
  }
}

The number expression used in the [textContent] binding gets different values during a regular and verification change detection cycles. Because of that fact, when we run the above application we can expect the error:

The leading cause here is that Math.random() produces different results each time it's called. So the value that textContent binding gets during the detectChanges will never match the value it receives for the checkNoChanges run.

The error we got gives us the following information:

ERROR Error: NG0100: ExpressionChangedAfterItHasBeenCheckedError: Expression has changed after it was checked.
Previous value for 'textContent': '0.9449286101652989'. Current value: '0.1686897170657191'.
Find more at https://angular.io/errors/NG0100

Just as we assumed, it tells us that the values produced by the expression number for the textContent binding were different during a regular change detection cycle and the verification run. This textContent binding is processed by the property instruction and we can see it in the callstack. The error itself comes from the bindingUpdated function we discussed above:

We can even see it using Chrome dev tools:

That’s actually might be quite surprising to you because usually that error comes up in a lot more sophisticated scenarios. But can you think of a very trivial fix for this case? 🤓

This particular case actually matches this spec from above mentioned unit-test suite:

initWithTemplate('<div [id]="unstableStringExpression"></div>')

Of course, real world examples are much more intricate and complex. They usually involve a component hierarchy and an interaction mechanism between ancestors and their descendent components. This interaction is often indirect and happens through shared services, event emitters or observables. It takes good understand and lots of practice to quickly discover the leading cause.

To illustrate the error mechanism that involves a hierarchy, let’s look at the very basic setup with a parent and a child component.

Updating ancestors

We’re defining a simple hierarchy of two components. A parent component declares the text property that is used in an interpolation binding. A child component injects the parent component through DI into the constructor and updates its text property in the ngAfterViewChecked hook. Just like Angular’s test suite, we use this hook because it’s triggered after the bindings have been processed.

Here’s the code snippet for the setup:

@Component({
  selector: 'q-cmp',
  template: `
    <h3>Q1 text: {{text}}</h3>
    <q1-cmp></q1-cmp>
  `
})
export class Q {
  text = 'initial';
}

@Component({
  selector: 'q1-cmp',
  template: ``
})
export class Q1 {
  constructor(private q: Q) {}

  ngAfterViewChecked() {
    this.q.text = 'updated';
  }
}

And as expected we get the error:

This time our demo setup corresponds to this spec from the unit tests suite:

initWithTemplate('<div id="Expressions: {{ a }}')

The relevant instruction is interpolation and we can see it in the callstack:

Interestingly, sometimes we could even get the error if we update the property in the ngOnInit hook:

@Component({
  selector: 'q-cmp',
  template: `
    <q2-cmp></q2-cmp>
    <h3>Q2 text: {{text}}</h3>
  `
})
export class Q {
  text = 'initial';
}

@Component({
  selector: 'q2-cmp',
  template: ``
})
export class Q2 {
  constructor(private q: Q) {}

  ngOnInit() {
    this.q.text = 'updated';
  }
}

Here’s the error again:

What might be very surprising, but actually makes sense, is that the error won’t happen if swap elements in a template of the Q component from this:

<h3>Q2 text: {{text}}</h3>
<q2-cmp></q2-cmp>

to this:

<q2-cmp></q2-cmp>
<h3>Q2 text: {{text}}</h3>

Basically we’re placing <q2-cmp> before the interpolation update. Run the example, no error pops up.

The magic is in a template function that’s generated by the compiler. Here’s the order of instructions in the tempate function for the original order:

Compare it to the swapped elements setup:

You can see that when <q2-cmp> precedes the interpolation update Q2 text: {{text}}, the hook ngOnInit is executed from the template function Q_Template and that happens before Angular updates the DOM. That’s why there’s no error. However, if <q2-cmp> follows the interpolation update, the ngOnInit hook is executed through executeInitAndCheckHooks after the text property has been processed by the template function and hence the binding throws the error.

From zone.js to zoneless Angular and back — how it all works

Max — Wed, 25 Jan 2023 16:09:16 +0000

This article is an excerpt from my Angular Deep Dive course

Autorun with zones

Change detection (rendering) in Angular is usually triggered completely automatically as a result of async events in a browser. This is made possible by utilizing zones implemented by zone.js library. In general, zones provide a mechanism to intercept the scheduling and calling of asynchronous operations. Interceptor logic can execute additional code before or after the task and notify interesting parties about the event. These rules are defined individually for each zone when it’s being created.

Zones are composed in a hierarchical parent-child relationship. At the start the browser runs in a special root zone, which is configured to behave exactly like the platform, making any existing code which is not zone-aware behave as expected. Only one zone can be active at any given time, and this zone can be retrieved through Zone.current property:

If you’re interested to learn how to work with zone.js directly, check out this article.

Contrary to popular belief, zones are not part of the change detection mechanism in Angular. In fact, Angular can work without zones using change detection services. To enable automatic change detection, Angular implements NgZone service that forks a child zone and subscribes to notifications from this zone.

This zone is referred to as Angular zone and all application specific code is expected to run inside this zone. That’s because NgZone only gets notifications about events that occur inside this Angular zone and doesn’t get any notifications about events in other zones:

If you explore NgZone, you’ll see that the reference to the forked Angular zone is stored in the _inner property:

export class NgZone {
  constructor(...) {
    forkInnerZoneWithAngularBehavior(self);
  }
}

function forkInnerZoneWithAngularBehavior(zone: NgZonePrivate) {
  zone._inner = zone._inner.fork({ ... });
}

This is the zone that is used to run a callback when you execute NgZone.run():

export class NgZone {
    run(fn, applyThis, applyArgs) {
        return this._inner.run(fn, applyThis, applyArgs);
    }
}

The current zone at the moment of forking the Angular zone is kept in the _outer property and is used to run a callback when you execute NgZone.runOutsideAngular():

export class NgZone {
    runOutsideAngular(fn) {
      return (this as any as NgZonePrivate)._outer.run(fn);
    }
}

Most often this outer zone is the top-most “root” zone.

When Angular finished its bootstrapping, that’s the hierarchy of zones you get:

"root"
   "angular"

Which you can easily see for yourself by simply logging the corresponding properties:

export class AppComponent {
  constructor(zone: NgZone) {
    console.log((zone as any)._inner.name); // angular
    console.log((zone as any)._outer.name); // root
  }
}

However, in the development mode, there’s also AsyncStackTaggingZone that sits in between root and angular zone like this:

"root"
   "AsyncStackTaggingZone"
               "angular"

In this case, NgZone instance keeps a reference to the AsyncStackTaggingZone in its _inner property. AsyncStackTaggingZone provides linked stack traces to show where the async operation is scheduled. For more details, refer to the article Better Angular Debugging with DevTools.

The last bit that we need to know is that Angular instantiates NgZone during the bootstrapping phase:

export class PlatformRef {
        bootstrapModuleFactory<M>(moduleFactory, options?) {
        const ngZone = getNgZone(options?.ngZone, getNgZoneOptions(options));
        const providers: StaticProvider[] = [{provide: NgZone, useValue: ngZone}];
        // all initialization logic runs inside Angular zone
        return ngZone.run(() => {...});
        }
}

Angular uses the onMicrotaskEmpty event inside ApplicationRef to automatically trigger change detection for the entire application:

@Injectable({providedIn: 'root'})
export class ApplicationRef {
  constructor(
      private _zone: NgZone,
      private _injector: EnvironmentInjector,
      private _exceptionHandler: ErrorHandler,
  ) {
    this._onMicrotaskEmptySubscription = this._zone.onMicrotaskEmpty.subscribe({
      next: () => {
        this._zone.run(() => {
          this.tick();
        });
      }
    });
  }
}

Let’s now see how Angular can work without zones.

Zoneless application

To run an Angular application without zone.js we need to pass noop value into bootstrapModule function for ngZone parameter like this:

platformBrowserDynamic()
    .bootstrapModule(AppModule, {
        ngZone: 'noop'
    });

If we now run this simple application:

@Component({
  selector: 'app-root',
  template: `{{time}}`
})
export class AppComponent {
  time = Date.now();
}

we’ll see that change detection is fully operational and renders time value in the DOM.

However, if update the name property inside the callback for setTimeout:

@Component({
  selector: 'app-root',
  template: `{{time}}`
})
export class AppComponent {
  time = Date.now();

  constructor() {
    setTimeout(() => { this.time = Date.now() }, 1000);
  }
}

We’ll see that the change is not updated. This is expected behavior since there’s no Angular zone to notify Angular about the timeout event occurrence. What’s interesting that we can still inject NgZone into the constructor:

import { ɵNoopNgZone } from '@angular/core';

export class AppComponent {
  constructor(zone: NgZone) {
    console.log(zone instanceof ɵNoopNgZone); // true
  }
}

But it’s an empty implementation of NgZone which does nothing. We could use a change detector service to manually run change detection:

@Component({
  selector: 'app-root',
  template: `{{time}}`
})
export class AppComponent {
  time = Date.now();

  constructor(cdRef: ChangeDetectorRef) {
    setTimeout(() => { this.time = Date.now() }, 1000);
    cdRef.detectChanges();
  }
}

We’ll go over this service in detail in
manual control chapter.

Running code inside Angular zone

You may find yourself in the situation where you have a function that somehow runs outside of Angular's zone and you don’t get the beneif to automatic change detection. It’s a common scenario with a third party library doing its stuff unaware of Angular context.

Here is an example of such question involving Google API Client Library (gapi). The common culprit is using techniques like JSONP that don’t use common AJAX APIs like
XMLHttpRequest or Fetch API which are patched and tracked by Zones. Instead, it creates a script tag with a source URL and defines a global callback to be triggered when the requested script with data is fetched from the server. This can’t be patched or detected by Zones and hence the frameworks remains oblivious to requests performed using this technique.

The common solution to such problems is to simply run a callback inside Angular zone like this. For example, for gapi we should do it like this:

// Load the JavaScript client library.
gapi.load('client', ()=> {
    // Run initialization code INSIDE Angular zone
    NgZone.run(()=>{
        // Initialize the JavaScript client library
        gapi.client.init({...}).then(function() { ... });
    });
});

Another example is a component that emits notifications from a callback that runs outside the Angular zone:

@Component({
  selector: 'n-cmp',
  template: '{{title}} <div><n1-cmp></n1-cmp></div>'
})
export class N {
  title = 'N component';
  emitter = new Subject();

  constructor(zone: NgZone) {
    zone.runOutsideAngular(() => {
      setTimeout(() => {
        this.emitter.next(3);
      }, 1000);
    });
  }
}

If we simply subscribe to the changes in the child N1 component like this:

@Component({
  selector: 'n1-cmp',
  template: '{{title}}, emitted value: {{value}}'
})
export class N1 {
  title = 'Child of N';
  value = 'nothing yet';

  constructor(parent: N, zone: NgZone) {
    parent.emitter.subscribe((v: any) => {
      this.value = v;
    });
  }
}

we won’t see any updates on the screen, even though the this.value is updated to 3 after the parent emits it.
To fix this, just like in the gapi example, we could run the callback in Angular zone:

@Component({...})
export class N1 {
  title = 'Child of N';
  value = 'nothing yet';

  constructor(parent: N, zone: NgZone) {
    parent.emitter.subscribe((v: any) => {
      zone.run(() => {
        this.value = v;
      });
    });
  }
}

this fixes it.

Component and change detection trees in Angular applications

Max — Mon, 23 Jan 2023 19:14:45 +0000

This article is an excerpt from my Angular Deep Dive course

Components tree

With component based approach in web applications, composition is achieved by including child components in templates. For this reason, we can think of an Angular application as a tree of components. However, under the hood, for components Angular uses a low-level abstraction called View. It’s a smallest grouping of elements which are created and destroyed together. All operations like property checks and DOM updates are performed on views, hence it’s more technically correct to state that angular is a tree of views, while a component can be described as a higher level concept of a view.

View related data structures

The structure of a View is defined by the LView interface. LView stores all of the information needed to process the instructions as they are invoked from the template. Each component and an embedded view has its corresponding LView. We can refer to views created for components as component views to distinguish from the embedded views created through ViewContainerRef using template references, i.e.ng-template elements.

The hierarchy of views is tracked using designated properties on LView:

export const PARENT = 3;
export const NEXT = 4;
export const CHILD_HEAD = 13;
export const CHILD_TAIL = 14;

export interface LView {
  [CHILD_HEAD]: LView|LContainer|null;
  [CHILD_TAIL]: LView|LContainer|null;
  [PARENT]: LView|LContainer|null;
  [NEXT]: LView|LContainer|null;
}

To traverse the tree of views Angular uses these traversal utils.

Angular also implements TView data structure that holds static data for an LView. This TView is shared between all LViews of a given type. This means that each instance of a particular component has its own instance of LView, but they all reference the same instance of TView.

The last bit we need to know is that Angular has a few different view types defined like this:

export const enum TViewType {
  Root = 0,
  Component = 1,
  Embedded = 2,
}

Component and Embedded view types should be self explanatory. The Root view is a special type of views that Angular uses to bootstrap top-level components into. It is used in conjunction with LView which takes an existing DOM node not owned by Angular and wraps it in LView so that other components can be loaded into it.

There is a direct relationship between a view and a component — one view is associated with one component and vice verse. A view holds a reference to the associated component class instance in the CONTEXT property. All operations like property checks and DOM updates are performed on views.

For a template that includes A component twice the data structures will look like this:

Change detection tree

In most applications you have one main tree of component views that starts with the component you reference in the index.html. There are other root views that are created through portals, mostly for modal dialogs, tooltips etc. These are the UI elements that need to be rendered outside of the hierarchy of the main tree mostly for styling purposes, for example, so that they are not effected by overflow:hidden.

Angular keeps top level elements of such trees in a _views property of the ApplicationRef. Those trees are referred to as change detection trees, because they are traversed when Angular runs change detection globally. The tick method that runs change detection iterates over each tree in _views and runs the check for each view by calling detectChanges method:

@Injectable({ providedIn: 'root' })
export class ApplicationRef {
  tick(): void {
    try {
      this._runningTick = true;
      for (let view of this._views) {
        view.detectChanges();
      }
      if (typeof ngDevMode === 'undefined' || ngDevMode) {
        for (let view of this._views) {
          view.checkNoChanges();
        }
      }
    } catch (e) { ... } finally { ... }
  }
}

You can also see that tick runs checkNoChanges method on the same set of views.

Attaching dynamic views to ApplicationRef

Angular allows to render a component into a standalone DOM element outside of Angular’s change detection tree. But since those views also need to be checked, ApplicationRef implements methods attachView() and detachView() to add/remove standalone views to change detection trees. This effectively adds those views to the _views array that’s traversed during change detection.

Let’s see this example. We have M component that we want to instantiate dynamically and then render into the DOM that’s outside main Angular tree. Here’s how we do it:

@Component({
  selector: 'l-cmp',
  template: 'L'
})
export class L {
  constructor(moduleRef: NgModuleRef<any>, appRef: ApplicationRef) {
    const resolver = moduleRef.componentFactoryResolver;
    const factory = resolver.resolveComponentFactory(M);

    let newNode = document.createElement('div');
    newNode.id = 'placeholder';
    document.body.prepend(newNode);

    const ref = factory.create(moduleRef.injector, [], newNode);
    appRef.attachView(ref.hostView);
  }
}

@Component({
  selector: 'm-cmp',
  template: '{{title}}'
})
export class M {
  title = 'I am the component that was created dynamically';
}

This is what we’ll see if we check the DOM structure in the application:

If we now take a look at _views property, this is what we’ll see:

We can use console to find out what those RootViewRef instances represent:

const TVIEW = 1;
const CONTEXT = 8;
const CHILD_HEAD = 13;

const view_1 = appRef._views[0];
const view_2 = appRef._views[1];

view_1._lView[TVIEW].type // 0 - HostView
view_1._lView[CONTEXT].constructor.name // M

view_1._lView[CHILD_HEAD][TVIEW].type // 0 - HostView
view_1._lView[CHILD_HEAD][CONTEXT].constructor.name // M

view_2._lView[CONTEXT].constructor.name // AppComponent (RootView)
view_2._lView[TVIEW].type // 0 - HostView

view_2._lView[CHILD_HEAD][CONTEXT].constructor.name // AppComponent (ComponentView)
view_2._lView[CHILD_HEAD][TVIEW].type // 1 - ComponentView

view_2._lView[CHILD_HEAD][CHILD_HEAD][CONTEXT].constructor.name // L

The chart will show these relationships clearer:

Bootstrapping multiple root components

It's possible to bootstrap multiple root components like this:

@NgModule({
  declarations: [ AppComponent, AppRootAnother ],
  imports: [  BrowserModule ],
  bootstrap: [ AppComponent, AppRootAnother ]
})
export class AppModule {}

which will create two root views and corresponding html tags:

The only thing to remember is that index.html should include tags for both selectors:

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>LearnAngular</title>
</head>
<body>
  <app-root></app-root>
  <app-root-another></app-root-another>
</body>
</html>

With this setup Angular will create two independent change detection trees. They will be registered under ApplicationRef._views and when ApplicationRef.tick() function will be called Angular will run change detection for both trees. This is in effect similar to using attachView. However, they will still be part of a single ApplicationRef, so they will share the injector defined for the AppModule.