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
Add zoneless scheduler to Angular by default #55102
Conversation
9d802f7
to
df587a8
Compare
df587a8
to
8dcdde6
Compare
packages/core/src/change_detection/scheduling/ng_zone_scheduling.ts
Outdated
Show resolved
Hide resolved
33ae041
to
712d8ca
Compare
a868484
to
f69f43e
Compare
f323b80
to
3223ff9
Compare
f434f68
to
b0cb960
Compare
…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`.
b0cb960
to
3f48dab
Compare
caretaker note: presubmit is using this patch, which will need to be submitted once this PR is merged. |
This PR was merged into the repository by commit de7447d. |
…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
At the first sight I was very confused with the description of this PR - I understood that this PR would be a huuuuge breaking change denying the sense of Fortunately, I'm calmed down now... 😌 after I came across @JeanMeche's great article https://riegler.fr/blog/2024-04-17-zoneless-with-zoneless-hybrid where he explains why I my understanding of this PR was wrong. |
fix(core): Angular should not ignore changes that happen outside the 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, callingChangeDetectorRef.markForCheck
, etc.).This does not apply to applications using
NoopNgZone
or those whichhave 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 addschedulingMode: NgZoneSchedulingMode.NgZoneOnly
to theBootstrapOptions
ofbootstrapModule
.