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
Comments
Hi, this is a dupe of essentially #31695. |
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
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.
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.tsAll 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 theApp
'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
The text was updated successfully, but these errors were encountered: