You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
preserve original reference to non-deferrable dependency (#54759)
core
Commit
Description
ApplicationRef.tick should respect OnPush for host bindings (#53718)
ApplicationRef.tick should respect OnPush for host bindings (#53718) (#53718)
ComponentFixtureautoDetect respects OnPush flag of host view (#54824)
Change Detection will continue to refresh views while marked for check (#54734)
ComponentFixture autodetect should detect changes within ApplicationRef.tick (#54733)
ensure change detection runs in a reasonable timeframe with zone coalescing (#54578)
Ensure views marked for check are refreshed during change detection (#54735)
Update ApplicationRef.tick loop to only throw in dev mode (#54848)
router
Commit
Description
Add ability to return UrlTree with NavigationBehaviorOptions from guards (#45023)
Breaking Changes
core
OnPush views at the root of the application need to
be marked dirty for their host bindings to refresh. Previously, the host
bindings were refreshed for all root views without respecting the OnPush change detection strategy.
OnPush views at the root of the application need to
be marked dirty for their host bindings to refresh. Previously, the host
bindings were refreshed for all root views without respecting the OnPush change detection strategy.
The ComponentFixtureautoDetect feature will no
longer refresh the component's host view when the component is OnPush
and not marked dirty. This exposes existing issues in components which
claim to be OnPush but do not correctly call markForCheck when they
need to be refreshed. If this change causes test failures, the easiest
fix is to change the component to ChangeDetectionStrategy.Default.
When Angular runs change detection, it will continue to
refresh any views attached to ApplicationRef that are still marked for
check after one round completes. In rare cases, this can result in infinite
loops when certain patterns continue to mark views for check using ChangeDetectorRef.detectChanges. This will be surfaced as a runtime
error with the NG0103 code.
The ComponentFixture.autoDetect feature now executes
change detection for the fixture within ApplicationRef.tick. This more
closely matches the behavior of how a component would refresh in
production. The order of component refresh in tests may be slightly
affected as a result, especially when dealing with additional components
attached to the application, such as dialogs. Tests sensitive to this
type of change (such as screenshot tests) may need to be updated.
Concretely, this change means that the component will refresh before
additional views attached to ApplicationRef (i.e. dialog components).
Prior to this change, the fixture component would refresh after other
views attached to the application.
The exact timing of change detection execution when
using event or run coalescing with NgZone is now the first of either setTimeout or requestAnimationFrame. Code which relies on this
timing (usually by accident) will need to be adjusted. If a callback
needs to execute after change detection, we recommend afterNextRender
instead of something like setTimeout.
Newly created and views marked for check and reattached
during change detection are now guaranteed to be refreshed in that same
change detection cycle. Previously, if they were attached at a location
in the view tree that was already checked, they would either throw ExpressionChangedAfterItHasBeenCheckedError or not be refreshed until
some future round of change detection. In rare circumstances, this
correction can cause issues. We identified one instance that relied on
the previous behavior by reading a value on initialization which was
queued to be updated in a microtask instead of being available in the
current change detection round. The component only read this value during
initialization and did not read it again after the microtask updated it.
router
Guards can now return RedirectCommand for redirects
in addition to UrlTree. Code which expects only boolean or UrlTree
values in Route types will need to be adjusted.