Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Guard with observable causing the entire app to misbehave [Minimal stackblitz included] #41553

Closed
vajahath opened this issue Apr 10, 2021 · 2 comments

Comments

@vajahath
Copy link

vajahath commented Apr 10, 2021

🐞 bug report

Affected Package

This can be by the @angular/router

Is this a regression?

No

Description

Let's say I have a guard like this:

const authState = new ReplaySubject<boolean>();
setTimeout(() => {
  authState.next(true);
}, 2000);

// guard
@Injectable({
  providedIn: "root",
})
export class AuthGuard implements CanActivate {
  constructor() { }

  canActivate(): Observable<boolean> {
    return authState
  }
}

And a routing like this:

const routes: Routes = [
  { path: "route-1", component: Route1Component, canActivate: [AuthGuard] },
  { path: "route-2", component: Route2Component, canActivate: [AuthGuard] },
  { path: "", pathMatch: "full", redirectTo: "route-1" }
];

Then, when I try to navigate from the "route-1" to "route-2" via a <a routerLink="../route-2">. The app navigation goes out of ngZone (or that is what I understand from the error message).

Moreover, when this happens, every routerLinks in "route-2" goes buggy. And the app layouts etc. jumps while clicking this buggy routerLink (may be because this happens out of zone).

And if you comment out the

// { path: "", pathMatch: "full", redirectTo: "route-1" }

this kind of works. Strange!

🔬 Minimal Reproduction

https://stackblitz.com/edit/angular-ivy-hkhiy3?devtoolsheight=33&file=src/app/route-1.component.ts

  • start form the root page /
  • open console
  • click "to-router-2"
  • you see the err message in console
  • and the routerLinks in route-2 goes buggy

🔥 Exception or Error


Navigation triggered outside Angular zone, did you forget to call 'ngZone.run()'?

🌍 Your Environment

Angular Version:


Angular CLI: 11.2.8
Node: 12.19.0
OS: win32 x64

Angular: 11.2.9
... animations, common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, router
Ivy Workspace: Yes

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1102.8
@angular-devkit/build-angular   0.1102.8
@angular-devkit/core            11.2.8
@angular-devkit/schematics      11.2.8
@angular/cdk                    11.2.8
@angular/cli                    11.2.8
@angular/fire                   6.1.4
@angular/material               11.2.8
@schematics/angular             11.2.8
@schematics/update              0.1102.8
ng-packagr                      11.2.4
rxjs                            6.6.7
typescript                      4.1.5


@JoostK
Copy link
Member

JoostK commented Apr 10, 2021

I'd consider this a duplicate of #37223. As the console warning suggests, the navigation is triggered outside of the Angular zone. The signal that completes the Observable that has been returned from the guard originates from a setTimeout that was scheduled from the top-level, such that the Angular Zone was not active at that point. This causes all subsequent route processing to also occur outside of the Angular zone, which affects how and when change detection runs. That is why the warning is reported.

And if you comment out the

// { path: "", pathMatch: "full", redirectTo: "route-1" }
this kind of works. Strange!

This is only because Stackblitz does hot module reloading such that the Subject in the different file is not refreshed; therefore it continues to have been completed. As such, the router guard completes synchronously while the NgZone is still active. A full reload shows that it is broken as before.

Using the rezone trick as presented in #37223 (comment) makes this work as you expected:

import { Injectable, NgZone } from "@angular/core";
import {
  CanActivate,
  CanActivateChild,
  CanLoad,
  Route,
  UrlSegment,
  ActivatedRouteSnapshot,
  RouterStateSnapshot,
  UrlTree
} from "@angular/router";
import { Observable, of, ReplaySubject } from "rxjs";
import { map, switchMap, take, tap } from "rxjs/operators";

let k = new ReplaySubject<boolean>();

@Injectable({
  providedIn: "root"
})
export class AuthGuard implements CanActivate {
  constructor(private zone: NgZone) {}

  canActivate(
    route: ActivatedRouteSnapshot,
    state: RouterStateSnapshot
  ):
    | Observable<boolean | UrlTree>
    | Promise<boolean | UrlTree>
    | boolean
    | UrlTree {
    console.log("In guard", state);
    return k.pipe(
      rezone(this.zone),
    );
  }
}

// simulating a later emitting observable
setTimeout(() => {
  k.next(true)
}, 500);

const rezone = (zone: NgZone) => <T>(source: Observable<T>) =>
  new Observable<T>(observer => source.subscribe({
    next: (v) => zone.run(() => observer.next(v)),
    error: (e) => zone.run(() => observer.error(e)),
    complete: () => zone.run(() => observer.complete()),
  }));

@JoostK JoostK closed this as completed Apr 10, 2021
@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators May 11, 2021
atscott added a commit to atscott/angular that referenced this issue Mar 30, 2024
…zone

When Angular receives a clear indication that change detection should
run again, this should not be ignored, regardless of what Zone it
happened in. This change updates the default change detection scheduling
approach of Zone-based applications to ensure a change detection will
run when these events happen outside the Angular zone (which includes,
for example, updating a signal that's read in a template, setting an
input of a `ComponentRef`, attaching a view marked for check, calling
`ChangeDetectorRef.markForCheck`, etc.).

This does not apply to applications using `NoopNgZone` or those which
have a custom `NgZone` implementation without ZoneJS.

The impact of this change will most often be seen in existing unit tests. Tests
execute outside the Angular Zone and this can mean that state in the
test is not fully recognized by Angular. Now that Angular will ensure
change detection _does_ run, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior. Often, this should be seen
as more correct and the test should be updated, but in cases where it is
too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

fixes angular#53844
fixes angular#53841
fixes angular#52610
fixes angular#53566
fixes angular#52940
fixes angular#51970
fixes angular#51768
fixes angular#50702
fixes angular#50259
fixes angular#50266
fixes angular#50160
fixes angular#49940
fixes angular#49398
fixes angular#48890
fixes angular#48608
fixes angular#45105
fixes angular#42241
fixes angular#41553
fixes angular#37223
fixes angular#37062
fixes angular#35579
fixes angular#31695
fixes angular#24728
fixes angular#23697
fixes angular#19814
fixes angular#13957
fixes angular#11565
fixes angular#15770
fixes angular#15946
fixes angular#18254
fixes angular#19731
fixes angular#20112
fixes angular#22472
fixes angular#23697
fixes angular#24727
fixes angular#47236

BREAKING CHANGE:

Angular will ensure change detection runs, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior.

This change will be more likely to impact existing unit tests.
This should usually be seen as more correct and the test should be updated,
but in cases where it is too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

Similarly, applications which may want to update state outside the zone
and _not_ trigger change detection can add
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the providers in `bootstrapApplication` or add
`schedulingMode: NgZoneSchedulingMode.NgZoneOnly` to the
`BootstrapOptions` of `bootstrapModule`.
atscott added a commit to atscott/angular that referenced this issue Mar 30, 2024
…zone

When Angular receives a clear indication that change detection should
run again, this should not be ignored, regardless of what Zone it
happened in. This change updates the default change detection scheduling
approach of Zone-based applications to ensure a change detection will
run when these events happen outside the Angular zone (which includes,
for example, updating a signal that's read in a template, setting an
input of a `ComponentRef`, attaching a view marked for check, calling
`ChangeDetectorRef.markForCheck`, etc.).

This does not apply to applications using `NoopNgZone` or those which
have a custom `NgZone` implementation without ZoneJS.

The impact of this change will most often be seen in existing unit tests. Tests
execute outside the Angular Zone and this can mean that state in the
test is not fully recognized by Angular. Now that Angular will ensure
change detection _does_ run, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior. Often, this should be seen
as more correct and the test should be updated, but in cases where it is
too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

fixes angular#53844
fixes angular#53841
fixes angular#52610
fixes angular#53566
fixes angular#52940
fixes angular#51970
fixes angular#51768
fixes angular#50702
fixes angular#50259
fixes angular#50266
fixes angular#50160
fixes angular#49940
fixes angular#49398
fixes angular#48890
fixes angular#48608
fixes angular#45105
fixes angular#42241
fixes angular#41553
fixes angular#37223
fixes angular#37062
fixes angular#35579
fixes angular#31695
fixes angular#24728
fixes angular#23697
fixes angular#19814
fixes angular#13957
fixes angular#11565
fixes angular#15770
fixes angular#15946
fixes angular#18254
fixes angular#19731
fixes angular#20112
fixes angular#22472
fixes angular#23697
fixes angular#24727
fixes angular#47236

BREAKING CHANGE:

Angular will ensure change detection runs, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior.

This change will be more likely to impact existing unit tests.
This should usually be seen as more correct and the test should be updated,
but in cases where it is too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

Similarly, applications which may want to update state outside the zone
and _not_ trigger change detection can add
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the providers in `bootstrapApplication` or add
`schedulingMode: NgZoneSchedulingMode.NgZoneOnly` to the
`BootstrapOptions` of `bootstrapModule`.
atscott added a commit to atscott/angular that referenced this issue Apr 8, 2024
…zone

When Angular receives a clear indication that change detection should
run again, this should not be ignored, regardless of what Zone it
happened in. This change updates the default change detection scheduling
approach of Zone-based applications to ensure a change detection will
run when these events happen outside the Angular zone (which includes,
for example, updating a signal that's read in a template, setting an
input of a `ComponentRef`, attaching a view marked for check, calling
`ChangeDetectorRef.markForCheck`, etc.).

This does not apply to applications using `NoopNgZone` or those which
have a custom `NgZone` implementation without ZoneJS.

The impact of this change will most often be seen in existing unit tests. Tests
execute outside the Angular Zone and this can mean that state in the
test is not fully recognized by Angular. Now that Angular will ensure
change detection _does_ run, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior. Often, this should be seen
as more correct and the test should be updated, but in cases where it is
too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

fixes angular#53844
fixes angular#53841
fixes angular#52610
fixes angular#53566
fixes angular#52940
fixes angular#51970
fixes angular#51768
fixes angular#50702
fixes angular#50259
fixes angular#50266
fixes angular#50160
fixes angular#49940
fixes angular#49398
fixes angular#48890
fixes angular#48608
fixes angular#45105
fixes angular#42241
fixes angular#41553
fixes angular#37223
fixes angular#37062
fixes angular#35579
fixes angular#31695
fixes angular#24728
fixes angular#23697
fixes angular#19814
fixes angular#13957
fixes angular#11565
fixes angular#15770
fixes angular#15946
fixes angular#18254
fixes angular#19731
fixes angular#20112
fixes angular#22472
fixes angular#23697
fixes angular#24727
fixes angular#47236

BREAKING CHANGE:

Angular will ensure change detection runs, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior.

This change will be more likely to impact existing unit tests.
This should usually be seen as more correct and the test should be updated,
but in cases where it is too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

Similarly, applications which may want to update state outside the zone
and _not_ trigger change detection can add
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the providers in `bootstrapApplication` or add
`schedulingMode: NgZoneSchedulingMode.NgZoneOnly` to the
`BootstrapOptions` of `bootstrapModule`.
atscott added a commit to atscott/angular that referenced this issue Apr 8, 2024
…zone

When Angular receives a clear indication that change detection should
run again, this should not be ignored, regardless of what Zone it
happened in. This change updates the default change detection scheduling
approach of Zone-based applications to ensure a change detection will
run when these events happen outside the Angular zone (which includes,
for example, updating a signal that's read in a template, setting an
input of a `ComponentRef`, attaching a view marked for check, calling
`ChangeDetectorRef.markForCheck`, etc.).

This does not apply to applications using `NoopNgZone` or those which
have a custom `NgZone` implementation without ZoneJS.

The impact of this change will most often be seen in existing unit tests. Tests
execute outside the Angular Zone and this can mean that state in the
test is not fully recognized by Angular. Now that Angular will ensure
change detection _does_ run, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior. Often, this should be seen
as more correct and the test should be updated, but in cases where it is
too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

fixes angular#55238
fixes angular#53844
fixes angular#53841
fixes angular#52610
fixes angular#53566
fixes angular#52940
fixes angular#51970
fixes angular#51768
fixes angular#50702
fixes angular#50259
fixes angular#50266
fixes angular#50160
fixes angular#49940
fixes angular#49398
fixes angular#48890
fixes angular#48608
fixes angular#45105
fixes angular#42241
fixes angular#41553
fixes angular#37223
fixes angular#37062
fixes angular#35579
fixes angular#31695
fixes angular#24728
fixes angular#23697
fixes angular#19814
fixes angular#13957
fixes angular#11565
fixes angular#15770
fixes angular#15946
fixes angular#18254
fixes angular#19731
fixes angular#20112
fixes angular#22472
fixes angular#23697
fixes angular#24727
fixes angular#47236

BREAKING CHANGE:

Angular will ensure change detection runs, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior.

This change will be more likely to impact existing unit tests.
This should usually be seen as more correct and the test should be updated,
but in cases where it is too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

Similarly, applications which may want to update state outside the zone
and _not_ trigger change detection can add
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the providers in `bootstrapApplication` or add
`schedulingMode: NgZoneSchedulingMode.NgZoneOnly` to the
`BootstrapOptions` of `bootstrapModule`.
atscott added a commit to atscott/angular that referenced this issue Apr 12, 2024
…zone

When Angular receives a clear indication that change detection should
run again, this should not be ignored, regardless of what Zone it
happened in. This change updates the default change detection scheduling
approach of Zone-based applications to ensure a change detection will
run when these events happen outside the Angular zone (which includes,
for example, updating a signal that's read in a template, setting an
input of a `ComponentRef`, attaching a view marked for check, calling
`ChangeDetectorRef.markForCheck`, etc.).

This does not apply to applications using `NoopNgZone` or those which
have a custom `NgZone` implementation without ZoneJS.

The impact of this change will most often be seen in existing unit tests. Tests
execute outside the Angular Zone and this can mean that state in the
test is not fully recognized by Angular. Now that Angular will ensure
change detection _does_ run, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior. Often, this should be seen
as more correct and the test should be updated, but in cases where it is
too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

fixes angular#55238
fixes angular#53844
fixes angular#53841
fixes angular#52610
fixes angular#53566
fixes angular#52940
fixes angular#51970
fixes angular#51768
fixes angular#50702
fixes angular#50259
fixes angular#50266
fixes angular#50160
fixes angular#49940
fixes angular#49398
fixes angular#48890
fixes angular#48608
fixes angular#45105
fixes angular#42241
fixes angular#41553
fixes angular#37223
fixes angular#37062
fixes angular#35579
fixes angular#31695
fixes angular#24728
fixes angular#23697
fixes angular#19814
fixes angular#13957
fixes angular#11565
fixes angular#15770
fixes angular#15946
fixes angular#18254
fixes angular#19731
fixes angular#20112
fixes angular#22472
fixes angular#23697
fixes angular#24727
fixes angular#47236

BREAKING CHANGE:

Angular will ensure change detection runs, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior.

This change will be more likely to impact existing unit tests.
This should usually be seen as more correct and the test should be updated,
but in cases where it is too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

Similarly, applications which may want to update state outside the zone
and _not_ trigger change detection can add
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the providers in `bootstrapApplication` or add
`schedulingMode: NgZoneSchedulingMode.NgZoneOnly` to the
`BootstrapOptions` of `bootstrapModule`.
atscott added a commit to atscott/angular that referenced this issue Apr 12, 2024
…zone

When Angular receives a clear indication that change detection should
run again, this should not be ignored, regardless of what Zone it
happened in. This change updates the default change detection scheduling
approach of Zone-based applications to ensure a change detection will
run when these events happen outside the Angular zone (which includes,
for example, updating a signal that's read in a template, setting an
input of a `ComponentRef`, attaching a view marked for check, calling
`ChangeDetectorRef.markForCheck`, etc.).

This does not apply to applications using `NoopNgZone` or those which
have a custom `NgZone` implementation without ZoneJS.

The impact of this change will most often be seen in existing unit tests. Tests
execute outside the Angular Zone and this can mean that state in the
test is not fully recognized by Angular. Now that Angular will ensure
change detection _does_ run, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior. Often, this should be seen
as more correct and the test should be updated, but in cases where it is
too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

fixes angular#55238
fixes angular#53844
fixes angular#53841
fixes angular#52610
fixes angular#53566
fixes angular#52940
fixes angular#51970
fixes angular#51768
fixes angular#50702
fixes angular#50259
fixes angular#50266
fixes angular#50160
fixes angular#49940
fixes angular#49398
fixes angular#48890
fixes angular#48608
fixes angular#45105
fixes angular#42241
fixes angular#41553
fixes angular#37223
fixes angular#37062
fixes angular#35579
fixes angular#31695
fixes angular#24728
fixes angular#23697
fixes angular#19814
fixes angular#13957
fixes angular#11565
fixes angular#15770
fixes angular#15946
fixes angular#18254
fixes angular#19731
fixes angular#20112
fixes angular#22472
fixes angular#23697
fixes angular#24727
fixes angular#47236

BREAKING CHANGE:

Angular will ensure change detection runs, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior.

This change will be more likely to impact existing unit tests.
This should usually be seen as more correct and the test should be updated,
but in cases where it is too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

Similarly, applications which may want to update state outside the zone
and _not_ trigger change detection can add
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the providers in `bootstrapApplication` or add
`schedulingMode: NgZoneSchedulingMode.NgZoneOnly` to the
`BootstrapOptions` of `bootstrapModule`.
atscott added a commit to atscott/angular that referenced this issue Apr 12, 2024
…zone

When Angular receives a clear indication that change detection should
run again, this should not be ignored, regardless of what Zone it
happened in. This change updates the default change detection scheduling
approach of Zone-based applications to ensure a change detection will
run when these events happen outside the Angular zone (which includes,
for example, updating a signal that's read in a template, setting an
input of a `ComponentRef`, attaching a view marked for check, calling
`ChangeDetectorRef.markForCheck`, etc.).

This does not apply to applications using `NoopNgZone` or those which
have a custom `NgZone` implementation without ZoneJS.

The impact of this change will most often be seen in existing unit tests. Tests
execute outside the Angular Zone and this can mean that state in the
test is not fully recognized by Angular. Now that Angular will ensure
change detection _does_ run, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior. Often, this should be seen
as more correct and the test should be updated, but in cases where it is
too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

fixes angular#55238
fixes angular#53844
fixes angular#53841
fixes angular#52610
fixes angular#53566
fixes angular#52940
fixes angular#51970
fixes angular#51768
fixes angular#50702
fixes angular#50259
fixes angular#50266
fixes angular#50160
fixes angular#49940
fixes angular#49398
fixes angular#48890
fixes angular#48608
fixes angular#45105
fixes angular#42241
fixes angular#41553
fixes angular#37223
fixes angular#37062
fixes angular#35579
fixes angular#31695
fixes angular#24728
fixes angular#23697
fixes angular#19814
fixes angular#13957
fixes angular#11565
fixes angular#15770
fixes angular#15946
fixes angular#18254
fixes angular#19731
fixes angular#20112
fixes angular#22472
fixes angular#23697
fixes angular#24727
fixes angular#47236

BREAKING CHANGE:

Angular will ensure change detection runs, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior.

This change will be more likely to impact existing unit tests.
This should usually be seen as more correct and the test should be updated,
but in cases where it is too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

Similarly, applications which may want to update state outside the zone
and _not_ trigger change detection can add
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the providers in `bootstrapApplication` or add
`schedulingMode: NgZoneSchedulingMode.NgZoneOnly` to the
`BootstrapOptions` of `bootstrapModule`.
atscott added a commit to atscott/angular that referenced this issue Apr 16, 2024
…zone

When Angular receives a clear indication that change detection should
run again, this should not be ignored, regardless of what Zone it
happened in. This change updates the default change detection scheduling
approach of Zone-based applications to ensure a change detection will
run when these events happen outside the Angular zone (which includes,
for example, updating a signal that's read in a template, setting an
input of a `ComponentRef`, attaching a view marked for check, calling
`ChangeDetectorRef.markForCheck`, etc.).

This does not apply to applications using `NoopNgZone` or those which
have a custom `NgZone` implementation without ZoneJS.

The impact of this change will most often be seen in existing unit tests. Tests
execute outside the Angular Zone and this can mean that state in the
test is not fully recognized by Angular. Now that Angular will ensure
change detection _does_ run, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior. Often, this should be seen
as more correct and the test should be updated, but in cases where it is
too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

fixes angular#55238
fixes angular#53844
fixes angular#53841
fixes angular#52610
fixes angular#53566
fixes angular#52940
fixes angular#51970
fixes angular#51768
fixes angular#50702
fixes angular#50259
fixes angular#50266
fixes angular#50160
fixes angular#49940
fixes angular#49398
fixes angular#48890
fixes angular#48608
fixes angular#45105
fixes angular#42241
fixes angular#41553
fixes angular#37223
fixes angular#37062
fixes angular#35579
fixes angular#31695
fixes angular#24728
fixes angular#23697
fixes angular#19814
fixes angular#13957
fixes angular#11565
fixes angular#15770
fixes angular#15946
fixes angular#18254
fixes angular#19731
fixes angular#20112
fixes angular#22472
fixes angular#23697
fixes angular#24727
fixes angular#47236

BREAKING CHANGE:

Angular will ensure change detection runs, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior.

This change will be more likely to impact existing unit tests.
This should usually be seen as more correct and the test should be updated,
but in cases where it is too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

Similarly, applications which may want to update state outside the zone
and _not_ trigger change detection can add
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the providers in `bootstrapApplication` or add
`schedulingMode: NgZoneSchedulingMode.NgZoneOnly` to the
`BootstrapOptions` of `bootstrapModule`.
atscott added a commit to atscott/angular that referenced this issue Apr 16, 2024
…zone

When Angular receives a clear indication that change detection should
run again, this should not be ignored, regardless of what Zone it
happened in. This change updates the default change detection scheduling
approach of Zone-based applications to ensure a change detection will
run when these events happen outside the Angular zone (which includes,
for example, updating a signal that's read in a template, setting an
input of a `ComponentRef`, attaching a view marked for check, calling
`ChangeDetectorRef.markForCheck`, etc.).

This does not apply to applications using `NoopNgZone` or those which
have a custom `NgZone` implementation without ZoneJS.

The impact of this change will most often be seen in existing unit tests. Tests
execute outside the Angular Zone and this can mean that state in the
test is not fully recognized by Angular. Now that Angular will ensure
change detection _does_ run, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior. Often, this should be seen
as more correct and the test should be updated, but in cases where it is
too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

fixes angular#55238
fixes angular#53844
fixes angular#53841
fixes angular#52610
fixes angular#53566
fixes angular#52940
fixes angular#51970
fixes angular#51768
fixes angular#50702
fixes angular#50259
fixes angular#50266
fixes angular#50160
fixes angular#49940
fixes angular#49398
fixes angular#48890
fixes angular#48608
fixes angular#45105
fixes angular#42241
fixes angular#41553
fixes angular#37223
fixes angular#37062
fixes angular#35579
fixes angular#31695
fixes angular#24728
fixes angular#23697
fixes angular#19814
fixes angular#13957
fixes angular#11565
fixes angular#15770
fixes angular#15946
fixes angular#18254
fixes angular#19731
fixes angular#20112
fixes angular#22472
fixes angular#23697
fixes angular#24727
fixes angular#47236

BREAKING CHANGE:

Angular will ensure change detection runs, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior.

This change will be more likely to impact existing unit tests.
This should usually be seen as more correct and the test should be updated,
but in cases where it is too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

Similarly, applications which may want to update state outside the zone
and _not_ trigger change detection can add
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the providers in `bootstrapApplication` or add
`schedulingMode: NgZoneSchedulingMode.NgZoneOnly` to the
`BootstrapOptions` of `bootstrapModule`.
atscott added a commit to atscott/angular that referenced this issue Apr 16, 2024
…zone

When Angular receives a clear indication that change detection should
run again, this should not be ignored, regardless of what Zone it
happened in. This change updates the default change detection scheduling
approach of Zone-based applications to ensure a change detection will
run when these events happen outside the Angular zone (which includes,
for example, updating a signal that's read in a template, setting an
input of a `ComponentRef`, attaching a view marked for check, calling
`ChangeDetectorRef.markForCheck`, etc.).

This does not apply to applications using `NoopNgZone` or those which
have a custom `NgZone` implementation without ZoneJS.

The impact of this change will most often be seen in existing unit tests. Tests
execute outside the Angular Zone and this can mean that state in the
test is not fully recognized by Angular. Now that Angular will ensure
change detection _does_ run, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior. Often, this should be seen
as more correct and the test should be updated, but in cases where it is
too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

fixes angular#55238
fixes angular#53844
fixes angular#53841
fixes angular#52610
fixes angular#53566
fixes angular#52940
fixes angular#51970
fixes angular#51768
fixes angular#50702
fixes angular#50259
fixes angular#50266
fixes angular#50160
fixes angular#49940
fixes angular#49398
fixes angular#48890
fixes angular#48608
fixes angular#45105
fixes angular#42241
fixes angular#41553
fixes angular#37223
fixes angular#37062
fixes angular#35579
fixes angular#31695
fixes angular#24728
fixes angular#23697
fixes angular#19814
fixes angular#13957
fixes angular#11565
fixes angular#15770
fixes angular#15946
fixes angular#18254
fixes angular#19731
fixes angular#20112
fixes angular#22472
fixes angular#23697
fixes angular#24727
fixes angular#47236

BREAKING CHANGE:

Angular will ensure change detection runs, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior.

This change will be more likely to impact existing unit tests.
This should usually be seen as more correct and the test should be updated,
but in cases where it is too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

Similarly, applications which may want to update state outside the zone
and _not_ trigger change detection can add
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the providers in `bootstrapApplication` or add
`schedulingMode: NgZoneSchedulingMode.NgZoneOnly` to the
`BootstrapOptions` of `bootstrapModule`.
atscott added a commit to atscott/angular that referenced this issue Apr 16, 2024
…zone

When Angular receives a clear indication that change detection should
run again, this should not be ignored, regardless of what Zone it
happened in. This change updates the default change detection scheduling
approach of Zone-based applications to ensure a change detection will
run when these events happen outside the Angular zone (which includes,
for example, updating a signal that's read in a template, setting an
input of a `ComponentRef`, attaching a view marked for check, calling
`ChangeDetectorRef.markForCheck`, etc.).

This does not apply to applications using `NoopNgZone` or those which
have a custom `NgZone` implementation without ZoneJS.

The impact of this change will most often be seen in existing unit tests. Tests
execute outside the Angular Zone and this can mean that state in the
test is not fully recognized by Angular. Now that Angular will ensure
change detection _does_ run, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior. Often, this should be seen
as more correct and the test should be updated, but in cases where it is
too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

fixes angular#55238
fixes angular#53844
fixes angular#53841
fixes angular#52610
fixes angular#53566
fixes angular#52940
fixes angular#51970
fixes angular#51768
fixes angular#50702
fixes angular#50259
fixes angular#50266
fixes angular#50160
fixes angular#49940
fixes angular#49398
fixes angular#48890
fixes angular#48608
fixes angular#45105
fixes angular#42241
fixes angular#41553
fixes angular#37223
fixes angular#37062
fixes angular#35579
fixes angular#31695
fixes angular#24728
fixes angular#23697
fixes angular#19814
fixes angular#13957
fixes angular#11565
fixes angular#15770
fixes angular#15946
fixes angular#18254
fixes angular#19731
fixes angular#20112
fixes angular#22472
fixes angular#23697
fixes angular#24727
fixes angular#47236

BREAKING CHANGE:

Angular will ensure change detection runs, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior.

This change will be more likely to impact existing unit tests.
This should usually be seen as more correct and the test should be updated,
but in cases where it is too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

Similarly, applications which may want to update state outside the zone
and _not_ trigger change detection can add
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the providers in `bootstrapApplication` or add
`schedulingMode: NgZoneSchedulingMode.NgZoneOnly` to the
`BootstrapOptions` of `bootstrapModule`.
atscott added a commit to atscott/angular that referenced this issue Apr 16, 2024
…zone

When Angular receives a clear indication that change detection should
run again, this should not be ignored, regardless of what Zone it
happened in. This change updates the default change detection scheduling
approach of Zone-based applications to ensure a change detection will
run when these events happen outside the Angular zone (which includes,
for example, updating a signal that's read in a template, setting an
input of a `ComponentRef`, attaching a view marked for check, calling
`ChangeDetectorRef.markForCheck`, etc.).

This does not apply to applications using `NoopNgZone` or those which
have a custom `NgZone` implementation without ZoneJS.

The impact of this change will most often be seen in existing unit tests. Tests
execute outside the Angular Zone and this can mean that state in the
test is not fully recognized by Angular. Now that Angular will ensure
change detection _does_ run, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior. Often, this should be seen
as more correct and the test should be updated, but in cases where it is
too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

fixes angular#55238
fixes angular#53844
fixes angular#53841
fixes angular#52610
fixes angular#53566
fixes angular#52940
fixes angular#51970
fixes angular#51768
fixes angular#50702
fixes angular#50259
fixes angular#50266
fixes angular#50160
fixes angular#49940
fixes angular#49398
fixes angular#48890
fixes angular#48608
fixes angular#45105
fixes angular#42241
fixes angular#41553
fixes angular#37223
fixes angular#37062
fixes angular#35579
fixes angular#31695
fixes angular#24728
fixes angular#23697
fixes angular#19814
fixes angular#13957
fixes angular#11565
fixes angular#15770
fixes angular#15946
fixes angular#18254
fixes angular#19731
fixes angular#20112
fixes angular#22472
fixes angular#23697
fixes angular#24727
fixes angular#47236

BREAKING CHANGE:

Angular will ensure change detection runs, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior.

This change will be more likely to impact existing unit tests.
This should usually be seen as more correct and the test should be updated,
but in cases where it is too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

Similarly, applications which may want to update state outside the zone
and _not_ trigger change detection can add
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the providers in `bootstrapApplication` or add
`schedulingMode: NgZoneSchedulingMode.NgZoneOnly` to the
`BootstrapOptions` of `bootstrapModule`.
atscott added a commit to atscott/angular that referenced this issue Apr 16, 2024
…zone

When Angular receives a clear indication that change detection should
run again, this should not be ignored, regardless of what Zone it
happened in. This change updates the default change detection scheduling
approach of Zone-based applications to ensure a change detection will
run when these events happen outside the Angular zone (which includes,
for example, updating a signal that's read in a template, setting an
input of a `ComponentRef`, attaching a view marked for check, calling
`ChangeDetectorRef.markForCheck`, etc.).

This does not apply to applications using `NoopNgZone` or those which
have a custom `NgZone` implementation without ZoneJS.

The impact of this change will most often be seen in existing unit tests. Tests
execute outside the Angular Zone and this can mean that state in the
test is not fully recognized by Angular. Now that Angular will ensure
change detection _does_ run, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior. Often, this should be seen
as more correct and the test should be updated, but in cases where it is
too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

fixes angular#55238
fixes angular#53844
fixes angular#53841
fixes angular#52610
fixes angular#53566
fixes angular#52940
fixes angular#51970
fixes angular#51768
fixes angular#50702
fixes angular#50259
fixes angular#50266
fixes angular#50160
fixes angular#49940
fixes angular#49398
fixes angular#48890
fixes angular#48608
fixes angular#45105
fixes angular#42241
fixes angular#41553
fixes angular#37223
fixes angular#37062
fixes angular#35579
fixes angular#31695
fixes angular#24728
fixes angular#23697
fixes angular#19814
fixes angular#13957
fixes angular#11565
fixes angular#15770
fixes angular#15946
fixes angular#18254
fixes angular#19731
fixes angular#20112
fixes angular#22472
fixes angular#23697
fixes angular#24727
fixes angular#47236

BREAKING CHANGE:

Angular will ensure change detection runs, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior.

This change will be more likely to impact existing unit tests.
This should usually be seen as more correct and the test should be updated,
but in cases where it is too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

Similarly, applications which may want to update state outside the zone
and _not_ trigger change detection can add
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the providers in `bootstrapApplication` or add
`schedulingMode: NgZoneSchedulingMode.NgZoneOnly` to the
`BootstrapOptions` of `bootstrapModule`.
atscott added a commit to atscott/angular that referenced this issue Apr 16, 2024
…zone

When Angular receives a clear indication that change detection should
run again, this should not be ignored, regardless of what Zone it
happened in. This change updates the default change detection scheduling
approach of Zone-based applications to ensure a change detection will
run when these events happen outside the Angular zone (which includes,
for example, updating a signal that's read in a template, setting an
input of a `ComponentRef`, attaching a view marked for check, calling
`ChangeDetectorRef.markForCheck`, etc.).

This does not apply to applications using `NoopNgZone` or those which
have a custom `NgZone` implementation without ZoneJS.

The impact of this change will most often be seen in existing unit tests. Tests
execute outside the Angular Zone and this can mean that state in the
test is not fully recognized by Angular. Now that Angular will ensure
change detection _does_ run, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior. Often, this should be seen
as more correct and the test should be updated, but in cases where it is
too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

fixes angular#55238
fixes angular#53844
fixes angular#53841
fixes angular#52610
fixes angular#53566
fixes angular#52940
fixes angular#51970
fixes angular#51768
fixes angular#50702
fixes angular#50259
fixes angular#50266
fixes angular#50160
fixes angular#49940
fixes angular#49398
fixes angular#48890
fixes angular#48608
fixes angular#45105
fixes angular#42241
fixes angular#41553
fixes angular#37223
fixes angular#37062
fixes angular#35579
fixes angular#31695
fixes angular#24728
fixes angular#23697
fixes angular#19814
fixes angular#13957
fixes angular#11565
fixes angular#15770
fixes angular#15946
fixes angular#18254
fixes angular#19731
fixes angular#20112
fixes angular#22472
fixes angular#23697
fixes angular#24727
fixes angular#47236

BREAKING CHANGE:

Angular will ensure change detection runs, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior.

This change will be more likely to impact existing unit tests.
This should usually be seen as more correct and the test should be updated,
but in cases where it is too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

Similarly, applications which may want to update state outside the zone
and _not_ trigger change detection can add
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the providers in `bootstrapApplication` or add
`schedulingMode: NgZoneSchedulingMode.NgZoneOnly` to the
`BootstrapOptions` of `bootstrapModule`.
atscott added a commit to atscott/angular that referenced this issue Apr 16, 2024
…zone

When Angular receives a clear indication that change detection should
run again, this should not be ignored, regardless of what Zone it
happened in. This change updates the default change detection scheduling
approach of Zone-based applications to ensure a change detection will
run when these events happen outside the Angular zone (which includes,
for example, updating a signal that's read in a template, setting an
input of a `ComponentRef`, attaching a view marked for check, calling
`ChangeDetectorRef.markForCheck`, etc.).

This does not apply to applications using `NoopNgZone` or those which
have a custom `NgZone` implementation without ZoneJS.

The impact of this change will most often be seen in existing unit tests. Tests
execute outside the Angular Zone and this can mean that state in the
test is not fully recognized by Angular. Now that Angular will ensure
change detection _does_ run, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior. Often, this should be seen
as more correct and the test should be updated, but in cases where it is
too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

fixes angular#55238
fixes angular#53844
fixes angular#53841
fixes angular#52610
fixes angular#53566
fixes angular#52940
fixes angular#51970
fixes angular#51768
fixes angular#50702
fixes angular#50259
fixes angular#50266
fixes angular#50160
fixes angular#49940
fixes angular#49398
fixes angular#48890
fixes angular#48608
fixes angular#45105
fixes angular#42241
fixes angular#41553
fixes angular#37223
fixes angular#37062
fixes angular#35579
fixes angular#31695
fixes angular#24728
fixes angular#23697
fixes angular#19814
fixes angular#13957
fixes angular#11565
fixes angular#15770
fixes angular#15946
fixes angular#18254
fixes angular#19731
fixes angular#20112
fixes angular#22472
fixes angular#23697
fixes angular#24727
fixes angular#47236

BREAKING CHANGE:

Angular will ensure change detection runs, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior.

This change will be more likely to impact existing unit tests.
This should usually be seen as more correct and the test should be updated,
but in cases where it is too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

Similarly, applications which may want to update state outside the zone
and _not_ trigger change detection can add
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the providers in `bootstrapApplication` or add
`schedulingMode: NgZoneSchedulingMode.NgZoneOnly` to the
`BootstrapOptions` of `bootstrapModule`.
atscott added a commit to atscott/angular that referenced this issue Apr 16, 2024
…zone

When Angular receives a clear indication that change detection should
run again, this should not be ignored, regardless of what Zone it
happened in. This change updates the default change detection scheduling
approach of Zone-based applications to ensure a change detection will
run when these events happen outside the Angular zone (which includes,
for example, updating a signal that's read in a template, setting an
input of a `ComponentRef`, attaching a view marked for check, calling
`ChangeDetectorRef.markForCheck`, etc.).

This does not apply to applications using `NoopNgZone` or those which
have a custom `NgZone` implementation without ZoneJS.

The impact of this change will most often be seen in existing unit tests. Tests
execute outside the Angular Zone and this can mean that state in the
test is not fully recognized by Angular. Now that Angular will ensure
change detection _does_ run, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior. Often, this should be seen
as more correct and the test should be updated, but in cases where it is
too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

fixes angular#55238
fixes angular#53844
fixes angular#53841
fixes angular#52610
fixes angular#53566
fixes angular#52940
fixes angular#51970
fixes angular#51768
fixes angular#50702
fixes angular#50259
fixes angular#50266
fixes angular#50160
fixes angular#49940
fixes angular#49398
fixes angular#48890
fixes angular#48608
fixes angular#45105
fixes angular#42241
fixes angular#41553
fixes angular#37223
fixes angular#37062
fixes angular#35579
fixes angular#31695
fixes angular#24728
fixes angular#23697
fixes angular#19814
fixes angular#13957
fixes angular#11565
fixes angular#15770
fixes angular#15946
fixes angular#18254
fixes angular#19731
fixes angular#20112
fixes angular#22472
fixes angular#23697
fixes angular#24727
fixes angular#47236

BREAKING CHANGE:

Angular will ensure change detection runs, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior.

This change will be more likely to impact existing unit tests.
This should usually be seen as more correct and the test should be updated,
but in cases where it is too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

Similarly, applications which may want to update state outside the zone
and _not_ trigger change detection can add
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the providers in `bootstrapApplication` or add
`schedulingMode: NgZoneSchedulingMode.NgZoneOnly` to the
`BootstrapOptions` of `bootstrapModule`.
atscott added a commit to atscott/angular that referenced this issue Apr 16, 2024
…zone

When Angular receives a clear indication that change detection should
run again, this should not be ignored, regardless of what Zone it
happened in. This change updates the default change detection scheduling
approach of Zone-based applications to ensure a change detection will
run when these events happen outside the Angular zone (which includes,
for example, updating a signal that's read in a template, setting an
input of a `ComponentRef`, attaching a view marked for check, calling
`ChangeDetectorRef.markForCheck`, etc.).

This does not apply to applications using `NoopNgZone` or those which
have a custom `NgZone` implementation without ZoneJS.

The impact of this change will most often be seen in existing unit tests. Tests
execute outside the Angular Zone and this can mean that state in the
test is not fully recognized by Angular. Now that Angular will ensure
change detection _does_ run, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior. Often, this should be seen
as more correct and the test should be updated, but in cases where it is
too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

fixes angular#55238
fixes angular#53844
fixes angular#53841
fixes angular#52610
fixes angular#53566
fixes angular#52940
fixes angular#51970
fixes angular#51768
fixes angular#50702
fixes angular#50259
fixes angular#50266
fixes angular#50160
fixes angular#49940
fixes angular#49398
fixes angular#48890
fixes angular#48608
fixes angular#45105
fixes angular#42241
fixes angular#41553
fixes angular#37223
fixes angular#37062
fixes angular#35579
fixes angular#31695
fixes angular#24728
fixes angular#23697
fixes angular#19814
fixes angular#13957
fixes angular#11565
fixes angular#15770
fixes angular#15946
fixes angular#18254
fixes angular#19731
fixes angular#20112
fixes angular#22472
fixes angular#23697
fixes angular#24727
fixes angular#47236

BREAKING CHANGE:

Angular will ensure change detection runs, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior.

This change will be more likely to impact existing unit tests.
This should usually be seen as more correct and the test should be updated,
but in cases where it is too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

Similarly, applications which may want to update state outside the zone
and _not_ trigger change detection can add
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the providers in `bootstrapApplication` or add
`schedulingMode: NgZoneSchedulingMode.NgZoneOnly` to the
`BootstrapOptions` of `bootstrapModule`.
atscott added a commit to atscott/angular that referenced this issue Apr 16, 2024
…zone

When Angular receives a clear indication that change detection should
run again, this should not be ignored, regardless of what Zone it
happened in. This change updates the default change detection scheduling
approach of Zone-based applications to ensure a change detection will
run when these events happen outside the Angular zone (which includes,
for example, updating a signal that's read in a template, setting an
input of a `ComponentRef`, attaching a view marked for check, calling
`ChangeDetectorRef.markForCheck`, etc.).

This does not apply to applications using `NoopNgZone` or those which
have a custom `NgZone` implementation without ZoneJS.

The impact of this change will most often be seen in existing unit tests. Tests
execute outside the Angular Zone and this can mean that state in the
test is not fully recognized by Angular. Now that Angular will ensure
change detection _does_ run, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior. Often, this should be seen
as more correct and the test should be updated, but in cases where it is
too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

fixes angular#55238
fixes angular#53844
fixes angular#53841
fixes angular#52610
fixes angular#53566
fixes angular#52940
fixes angular#51970
fixes angular#51768
fixes angular#50702
fixes angular#50259
fixes angular#50266
fixes angular#50160
fixes angular#49940
fixes angular#49398
fixes angular#48890
fixes angular#48608
fixes angular#45105
fixes angular#42241
fixes angular#41553
fixes angular#37223
fixes angular#37062
fixes angular#35579
fixes angular#31695
fixes angular#24728
fixes angular#23697
fixes angular#19814
fixes angular#13957
fixes angular#11565
fixes angular#15770
fixes angular#15946
fixes angular#18254
fixes angular#19731
fixes angular#20112
fixes angular#22472
fixes angular#23697
fixes angular#24727
fixes angular#47236

BREAKING CHANGE:

Angular will ensure change detection runs, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior.

This change will be more likely to impact existing unit tests.
This should usually be seen as more correct and the test should be updated,
but in cases where it is too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

Similarly, applications which may want to update state outside the zone
and _not_ trigger change detection can add
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the providers in `bootstrapApplication` or add
`schedulingMode: NgZoneSchedulingMode.NgZoneOnly` to the
`BootstrapOptions` of `bootstrapModule`.
alxhub pushed a commit that referenced this issue Apr 17, 2024
…zone (#55102)

When Angular receives a clear indication that change detection should
run again, this should not be ignored, regardless of what Zone it
happened in. This change updates the default change detection scheduling
approach of Zone-based applications to ensure a change detection will
run when these events happen outside the Angular zone (which includes,
for example, updating a signal that's read in a template, setting an
input of a `ComponentRef`, attaching a view marked for check, calling
`ChangeDetectorRef.markForCheck`, etc.).

This does not apply to applications using `NoopNgZone` or those which
have a custom `NgZone` implementation without ZoneJS.

The impact of this change will most often be seen in existing unit tests. Tests
execute outside the Angular Zone and this can mean that state in the
test is not fully recognized by Angular. Now that Angular will ensure
change detection _does_ run, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior. Often, this should be seen
as more correct and the test should be updated, but in cases where it is
too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

fixes #55238
fixes #53844
fixes #53841
fixes #52610
fixes #53566
fixes #52940
fixes #51970
fixes #51768
fixes #50702
fixes #50259
fixes #50266
fixes #50160
fixes #49940
fixes #49398
fixes #48890
fixes #48608
fixes #45105
fixes #42241
fixes #41553
fixes #37223
fixes #37062
fixes #35579
fixes #31695
fixes #24728
fixes #23697
fixes #19814
fixes #13957
fixes #11565
fixes #15770
fixes #15946
fixes #18254
fixes #19731
fixes #20112
fixes #22472
fixes #23697
fixes #24727
fixes #47236

BREAKING CHANGE:

Angular will ensure change detection runs, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior.

This change will be more likely to impact existing unit tests.
This should usually be seen as more correct and the test should be updated,
but in cases where it is too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

Similarly, applications which may want to update state outside the zone
and _not_ trigger change detection can add
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the providers in `bootstrapApplication` or add
`schedulingMode: NgZoneSchedulingMode.NgZoneOnly` to the
`BootstrapOptions` of `bootstrapModule`.

PR Close #55102
iteriani pushed a commit to iteriani/angular that referenced this issue Apr 18, 2024
…zone (angular#55102)

When Angular receives a clear indication that change detection should
run again, this should not be ignored, regardless of what Zone it
happened in. This change updates the default change detection scheduling
approach of Zone-based applications to ensure a change detection will
run when these events happen outside the Angular zone (which includes,
for example, updating a signal that's read in a template, setting an
input of a `ComponentRef`, attaching a view marked for check, calling
`ChangeDetectorRef.markForCheck`, etc.).

This does not apply to applications using `NoopNgZone` or those which
have a custom `NgZone` implementation without ZoneJS.

The impact of this change will most often be seen in existing unit tests. Tests
execute outside the Angular Zone and this can mean that state in the
test is not fully recognized by Angular. Now that Angular will ensure
change detection _does_ run, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior. Often, this should be seen
as more correct and the test should be updated, but in cases where it is
too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

fixes angular#55238
fixes angular#53844
fixes angular#53841
fixes angular#52610
fixes angular#53566
fixes angular#52940
fixes angular#51970
fixes angular#51768
fixes angular#50702
fixes angular#50259
fixes angular#50266
fixes angular#50160
fixes angular#49940
fixes angular#49398
fixes angular#48890
fixes angular#48608
fixes angular#45105
fixes angular#42241
fixes angular#41553
fixes angular#37223
fixes angular#37062
fixes angular#35579
fixes angular#31695
fixes angular#24728
fixes angular#23697
fixes angular#19814
fixes angular#13957
fixes angular#11565
fixes angular#15770
fixes angular#15946
fixes angular#18254
fixes angular#19731
fixes angular#20112
fixes angular#22472
fixes angular#23697
fixes angular#24727
fixes angular#47236

BREAKING CHANGE:

Angular will ensure change detection runs, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior.

This change will be more likely to impact existing unit tests.
This should usually be seen as more correct and the test should be updated,
but in cases where it is too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

Similarly, applications which may want to update state outside the zone
and _not_ trigger change detection can add
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the providers in `bootstrapApplication` or add
`schedulingMode: NgZoneSchedulingMode.NgZoneOnly` to the
`BootstrapOptions` of `bootstrapModule`.

PR Close angular#55102
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants