Deep Analysis and Practical Applications of markForCheck() vs detectChanges() in Angular Change Detection

In Angular application development, change detection is a core mechanism that ensures synchronization between data models and views. By default, Angular uses Zone.js to automatically monitor asynchronous events (e.g., DOM events, timers, HTTP requests) to trigger change detection. However, in complex scenarios, developers may need to manually intervene in the change detection process, where the markForCheck() and detectChanges() methods provided by ChangeDetectorRef become essential tools. Although both are used to handle view updates, their working principles, triggering timing, and applicable scenarios differ fundamentally, and misuse can lead to performance issues or view desynchronization. Based on Angular official documentation and community practices, this article provides a comprehensive analysis of these two methods through comparative analysis, code examples, and scenario simulations.

detectChanges(): Immediate Change Detection Execution

The detectChanges() method immediately executes change detection on the current component and its subtree, forcing view updates to reflect recent changes in the data model. This method is suitable for scenarios not covered by Angular's automatic change detection cycle, typically triggered in the following cases:

First, when the change detector is explicitly detached, view updates cease. For example, after calling cd.detach(), the component no longer responds to automatic detection, and detectChanges() must be called manually to update the view. Sample code:

// Assume ChangeDetectorRef instance is cd
cd.detach(); // Detach change detector
// ... Update data model
model.text = "new text";
cd.detectChanges(); // Manually trigger detection to update view

Second, when data updates occur outside the Angular Zone, Angular cannot automatically detect changes. This is common when integrating third-party libraries or non-Angular code, for example:

// Third-party function updates model
thirdPartyFunction() {
    this.model.value = "external update";
}

// Call in Angular component
myMethod() {
    this.thirdPartyFunction(); // This operation is outside Zone
    this.cd.detectChanges(); // Notify Angular to detect changes
}

Alternatives include using NgZone.run() to wrap code within the Angular Zone or indirectly triggering detection via setTimeout (patched by Zone.js), but detectChanges() offers more direct control.

Additionally, updating the model after the change detection cycle may cause the "Expression has changed after it was checked" error. While best practice is to refactor code to complete updates within the cycle, a temporary solution is to call detectChanges() to re-detect. For example:

ngAfterViewInit() {
    // Assume this update occurs after detection cycle
    this.data = "new value";
    this.cd.detectChanges(); // Avoid error, but use cautiously
}

Note that overusing detectChanges() may violate Angular's unidirectional data flow principle and increase performance overhead.

markForCheck(): Mark Ancestor Components for Checking

Unlike detectChanges(), markForCheck() does not immediately execute change detection but marks all ancestor components using the OnPush strategy from the current component to the root as "to be checked." When the next change detection cycle runs (e.g., triggered by an event), these components will be re-evaluated. This method is primarily used with ChangeDetectionStrategy.OnPush.

Under the OnPush strategy, components only trigger detection when their input properties change reference or internal events occur. If object properties are updated via mutation without changing the reference, detection does not execute. For example:

// Component uses OnPush strategy
@Component({
    selector: 'app-example',
    templateUrl: './example.component.html',
    changeDetection: ChangeDetectionStrategy.OnPush
})
export class ExampleComponent {
    @Input() data: any;
    constructor(private cd: ChangeDetectorRef) {}

    updateData() {
        this.data.property = "mutated value"; // Mutation, reference unchanged
        this.cd.markForCheck(); // Mark ancestors for update in next detection
    }
}

In contrast, replacing the entire object (reference change) automatically triggers detection:

this.data = { property: "new object" }; // Reference change, no manual call needed

Moreover, when updates occur in asynchronous operations like setTimeout, even with OnPush, markForCheck() may be necessary to ensure detection. Source code analysis shows that this method traverses the component tree, setting the view state to ChecksEnabled without directly scheduling detection.

Core Differences and Selection Guidelines

Mechanically, detectChanges() actively triggers local detection, while markForCheck() passively marks ancestors, relying on subsequent cycles. Performance-wise, the former may immediately update the entire subtree with higher overhead; the latter defers to the next detection, being more efficient. Usage scenarios are summarized as follows:

• Choose detectChanges(): When changes occur outside the Angular Zone, the detector is detached, or immediate view updates are needed after the cycle. Examples include integrating non-Angular code or handling dynamic data flows.
• Choose markForCheck(): When components use the OnPush strategy with data mutations, or performance optimization is needed to avoid unnecessary detection. Common in state management for large-scale applications.

Practical advice: Prioritize Angular's automatic detection mechanism and intervene manually only when necessary. Combining AsyncPipe and immutable data patterns can reduce manual calls. For instance, monitoring changes in ngDoCheck and using markForCheck() can enhance responsiveness in OnPush components.

In summary, markForCheck() and detectChanges() are advanced tools in Angular change detection. Understanding their differences helps build efficient and maintainable applications. Through scenario-based applications and code examples, developers can flexibly address complex update requirements, balancing performance and functionality.