yarn @angular/platform-browser-dynamic 18.0.0-next.0
v18.0.0-next.0

latest releases: 18.1.0-next.0, 18.0.1, 17.3.10...
2 months ago

18.0.0-next.0 (2024-03-14)

compiler-cli

Commit Description
fix - 9b424d7224 preserve original reference to non-deferrable dependency (#54759)

core

Commit Description
fix - d888da4606 ApplicationRef.tick should respect OnPush for host bindings (#53718)
fix - 64f870c12b ApplicationRef.tick should respect OnPush for host bindings (#53718) (#53718)
fix - 8cad4e8cbe ComponentFixture autoDetect respects OnPush flag of host view (#54824)
fix - ba8e465974 Change Detection will continue to refresh views while marked for check (#54734)
fix - 24bc0ed4f2 ComponentFixture autodetect should detect changes within ApplicationRef.tick (#54733)
fix - 10c5cdb49c ensure change detection runs in a reasonable timeframe with zone coalescing (#54578)
fix - ad045efd4b Ensure views marked for check are refreshed during change detection (#54735)
fix - 700c0520bb Update ApplicationRef.tick loop to only throw in dev mode (#54848)

router

Commit Description
feat - 8735af08b9 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 ComponentFixture autoDetect 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.

Don't miss a new platform-browser-dynamic release

NewReleases is sending notifications on new releases.