Comparing Angular's markForCheck with detectChanges

Question

Comparing Angular's markForCheck with detectChanges

Starting with the knowledge that I have come across a similar query on StackOverflow, but it only addressed the difference.

My question is centered around determining when to use each method and understanding the potential drawbacks of both.

I am aware that using `detectChanges` triggers an immediate change detection cycle for both the element and its children, while `markForCheck` simply flags the current element and its ancestors as needing checking during the next cycle.

This inquiry stems from my uncertainty about always resorting to `markForCheck` in asynchronous calls.

Take, for example, an `InputComponent` which wraps a standard HTML input and has `ChangeDetectionStrategy.OnPush` activated.

In scenarios where I retrieve data asynchronously from the server to update a list of options within this `InputComponent`, two approaches are viable.

The first option (which I believe is preferable) involves using `detectChanges` as it ensures checks are limited to this particular component, whereas `markForCheck` would involve checking the entire branch of the tree.

Therefore, the question remains - what method should be utilized and is there ever a necessity to utilize `markForCheck`?

angular typescript performance angular-changedetection

Answer 1

Answer №1

My question is about choosing the right method for different situations and understanding the drawbacks of each.

It's important to note that you should avoid using detectChanges().

In most cases, using detectChanges() indicates issues with managing immutability, state management, and component mutation within a project.

If your code requires detectChanges(), it's a sign that the code could be improved and rewritten to eliminate this need.

On the other hand, there are scenarios where markForCheck() can be beneficial.

I'm raising this question because I'm unsure if markForCheck should always be used in asynchronous calls.

You'll often see references to this near instances where markForCheck() is called.

@Component({...})
export class ExampleComponent {
    //......
    public function work() {
        this.httpClient.get(...).subscribe(resp => 
            this.data = resp.data;
            this.changeDetectorRef.markForCheck();
        });
    }
}

In functional programming, referencing this is considered impure and can lead to mutable external states, which goes against best practices. By sticking to pure functions in async operations, you can avoid the need for markForCheck(). However, once you introduce a reference to this, the component's state is altered, necessitating a view update.

While this approach isn't inherently wrong, excessive use of this in RxJS subscriptions can make code maintenance challenging.

It's recommended to refactor your code to leverage reactive programming and utilize the async pipe in templates. The goal is to create stateless components where properties don't require constant updates – everything should flow through reactive streams.

@Component({
    template: `<ng-container *ngIf="data$ | async as data">
               <!-- stuff -->
               </ng-container>`,
    // .....
})
export class ExampleComponent {
    public data$: Observable<any>;

    public function work() {
        this.data$ = this.httpClient.get(...).pipe(shareReplay(1));
    }
}

If you design components to be stateless and rely on RxJS for data processing, you may not need to use markForCheck(). Even when handling DOM events, data can be piped into other observables to avoid direct usage of this.

While there may still be occasions where markForCheck() is necessary, consider revisiting your approach to find alternative solutions that don't rely on it.

Answer 2

My question is about choosing the right method for different situations and understanding the drawbacks of each.

It's important to note that you should avoid using detectChanges().

In most cases, using detectChanges() indicates issues with managing immutability, state management, and component mutation within a project.

If your code requires detectChanges(), it's a sign that the code could be improved and rewritten to eliminate this need.

On the other hand, there are scenarios where markForCheck() can be beneficial.

I'm raising this question because I'm unsure if markForCheck should always be used in asynchronous calls.

You'll often see references to this near instances where markForCheck() is called.

@Component({...})
export class ExampleComponent {
    //......
    public function work() {
        this.httpClient.get(...).subscribe(resp => 
            this.data = resp.data;
            this.changeDetectorRef.markForCheck();
        });
    }
}

In functional programming, referencing this is considered impure and can lead to mutable external states, which goes against best practices. By sticking to pure functions in async operations, you can avoid the need for markForCheck(). However, once you introduce a reference to this, the component's state is altered, necessitating a view update.

While this approach isn't inherently wrong, excessive use of this in RxJS subscriptions can make code maintenance challenging.

It's recommended to refactor your code to leverage reactive programming and utilize the async pipe in templates. The goal is to create stateless components where properties don't require constant updates – everything should flow through reactive streams.

@Component({
    template: `<ng-container *ngIf="data$ | async as data">
               <!-- stuff -->
               </ng-container>`,
    // .....
})
export class ExampleComponent {
    public data$: Observable<any>;

    public function work() {
        this.data$ = this.httpClient.get(...).pipe(shareReplay(1));
    }
}

If you design components to be stateless and rely on RxJS for data processing, you may not need to use markForCheck(). Even when handling DOM events, data can be piped into other observables to avoid direct usage of this.

While there may still be occasions where markForCheck() is necessary, consider revisiting your approach to find alternative solutions that don't rely on it.

Answer 3

Answer №2

Time has passed since the original query was posed, marking changes in the landscape.

Currently, many individuals find utilizing signals to be more beneficial.

Signals are straightforward, efficient, and now trigger change detection with Angular v18 updates even when modifications occur outside the Angular zone. With Angular v18's experimental zoneless change detection, everything functions smoothly.

Moreover, updating a signal's value only prompts checking for changes in components connected to that specific signal (assuming all components in your application use OnPush, as it still operates on the old change detection methodology).

Hence, signals serve as a superior alternative akin to a silver bullet compared to using markForCheck and detectChanges.

In upcoming developments, signal components will enhance performance further while requiring no code adjustments for those who have already implemented signals for state-holding properties destined for template rendering and periodic updates (omitting signals if the rendered value remains static).

Regarding the advice of "never use detectChanges," I partially concur. If you possess comprehensive knowledge of Angular's change detection mechanism and are confident in the necessity, feel free to utilize it without reservations.

However, for the majority of users and common scenarios, markForCheck proves to be the reliable go-to solution, ensuring smooth operations in 99.99999% of cases.

Answer 4