Angular2 Change Detection: In-depth Analysis of ngOnChanges Not Firing for Nested Objects

Problem Background

In Angular2 development, developers often encounter situations where the ngOnChanges lifecycle hook does not fire as expected, particularly with nested objects or arrays. This article addresses a typical scenario: when the rawLapsData array in a parent component is modified, the child component's ngOnChanges fails to trigger, preventing the redrawing of map markers. We will thoroughly analyze the root cause and present effective solutions.

Change Detection Mechanism Analysis

Angular's change detection system relies on reference checking (using the === operator) to determine if input properties have changed. For arrays and objects, it only checks if the reference has changed, without deeply comparing their contents. Thus, if array elements are directly modified (e.g., added, removed, or updated) while the array reference remains the same, ngOnChanges will not fire.

In the problem scenario, rawLapsData points to an array; even if its contents are altered by the deletePoints function, the reference does not change, so ngOnChanges does not respond. In contrast, the laps component displays array contents directly through template bindings, and Angular's default dirty checking detects these binding changes to update the DOM, explaining why laps responds to changes while the map component does not.

Solution One: Custom Detection with ngDoCheck

When standard change detection is insufficient, implement the ngDoCheck lifecycle hook to perform custom logic for detecting array content changes. The following example demonstrates how to compare current and previous array states:

import { Component, Input, DoCheck, KeyValueDiffers } from 'angular2/core';

@Component({
  selector: 'map',
  templateUrl: './map.html'
})
export class MapCmp implements DoCheck {
  @Input() lapsData: any[];
  private previousData: any[];
  private differ: any;

  constructor(private differs: KeyValueDiffers) {
    this.differ = differs.find([]).create();
  }

  ngDoCheck() {
    const changes = this.differ.diff(this.lapsData);
    if (changes) {
      console.log('Array changes detected');
      this.drawMarkers();
      this.previousData = [...this.lapsData]; // Update previous state
    }
  }

  private drawMarkers() {
    // Logic to redraw map markers
  }
}

This method uses the KeyValueDiffers service to detect array changes, ensuring that redrawing is triggered when content is modified. The advantage is that it does not require changing data references, but note the performance impact as ngDoCheck is called in every change detection cycle.

Solution Two: Reassigning Arrays to Trigger Changes

Another approach is to modify the code in the parent component by assigning a new array to rawLapsData after changing its contents. Since the reference changes, ngOnChanges will fire normally. Example code:

// In the parent component
this.rawLapsData = deletePoints(this.rawLapsData, this.selectedTps);
// Modify to:
this.rawLapsData = [...deletePoints(this.rawLapsData, this.selectedTps)]; // Use spread operator to create a new array

Or use the Array.prototype.slice() method:

this.rawLapsData = deletePoints(this.rawLapsData, this.selectedTps).slice();

This method is straightforward and leverages Angular's built-in mechanisms, but it requires returning a new array after data operations, which may increase memory usage.

Root Cause and Best Practices

The core issue lies in Angular's shallow comparison mechanism for input properties. For primitive types (e.g., strings, numbers), value changes trigger ngOnChanges; for objects and arrays, only reference changes do. In shared data scenarios, components access the same array via reference, so content changes are visible to all components, but ngOnChanges only responds to reference changes.

Best practices include: using immutable data patterns where possible to avoid direct modifications of objects or arrays; prioritizing ngDoCheck for complex detection needs; and evaluating the overhead of custom detection logic in performance-sensitive scenarios. Additionally, ensure that component template bindings align with input property change detection strategies to prevent inconsistent update behaviors.

Conclusion

Through this analysis, we have understood why ngOnChanges does not fire in Angular2 and mastered two practical solutions. In real-world development, choose the appropriate method based on application requirements: use ngDoCheck for fine-grained control or trigger reference changes via reassignment. These strategies help build responsive and efficient Angular applications, enhancing user experience.