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

Setting/updating a signal must be done in NgZone(?) #53566

Closed
csisy-bt4w opened this issue Dec 14, 2023 · 2 comments
Closed

Setting/updating a signal must be done in NgZone(?) #53566

csisy-bt4w opened this issue Dec 14, 2023 · 2 comments

Comments

@csisy-bt4w
Copy link

Describe the problem that you experienced

We've just started using signals and OnPush change detection and found out that setting/updating a signal must be done in NgZone, otherwise the component will not be updated (until something else forces a change detection).

The documentation writes about signals and OnPush components, but it does not mention anything about the zone.

Enter the URL of the topic with the problem

https://angular.io/guide/signals#reading-signals-in-onpush-components

Describe what you were looking for in the documentation

Clarification, or more in-depth description about the connection between the zone and signals.

Describe the actions that led you to experience the problem

We are using a ResizeObserver to detect if an element is resized. The following Stackblitz example is simplified, but the root problem is the same: https://stackblitz.com/edit/stackblitz-starters-fbyzdi?file=src%2Fmain.ts

All you have to do is to resize the viewport and check if the is small? value turns to true (the value is logged into the console as well).

Currently, the OutsideZoneComponent is used and as you can see, the component is not updated. More importantly, the component will not be updated even if the OnPush strategy is not used.

If you uncomment the <app-inside-zone/> tag in the App's template, everything works as expected.

Describe what you want to experience that would fix the problem

No response

Add a screenshot if that helps illustrate the problem

No response

If this problem caused an exception or error, please paste it here

No response

If the problem is browser-specific, please specify the device, OS, browser, and version

No response

Provide any additional information here in as much as detail as you can

No response

@JeanMeche
Copy link
Member

JeanMeche commented Dec 14, 2023

Hi, this is a dupe of essentially #31695.
ResizeObserver isn't patched by zone.js so the callback is run outside the angular zone.

@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 Jan 14, 2024
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