Fixed an issue where back/forward (`popstate`) navigation attempted to match the displayed `browserUrl` instead of the internal route, which could result in `NG04002: Cannot match any routes`.
Fixes#67549
(cherry picked from commit 6eff439546)
Enables specifying a custom browser URL for router links via a new input,
allowing navigation to use an explicit browser URL in navigation options.
Closes#66805
The `precommitHandler` of the Navigation API unlocks some of the truly
powerful features for Routers like Angular's which defer the URL
updates. Without the `precommitHandler`, we cannot initiate a navigation
until we are ready to commit the URL because it causes the URL to update
immediately.
With `precommitHandler` support, we are able to create a `NavigateEvent`
_immediately_ on navigation, which allows the browser to show that a
navigation is happening with a loading indicator. Site visitors will
also have the ability to cancel the navigation with the "stop" button.
When we are ready to commit the URL, the precommitHandler supports a
"redirect" function that we can use to first redirect the navigation to
a new location immediately before committing it.
The commit operation is not synchronous because the API waits for all
precommitHandlers to resolve. This commit adds a small bit of handling
to account for this so that the Router's transition does not advance
to the next stage until the URL has been committed.
This publishes the work that was done to integrate with the Navigation
API as an experimental router feature. Browser support is limited and in
active development. There are also known bugs in the browser implementations
and only Chromium browsers supported deferred URL updates with the
`precommitHandler`. Relates to #53321, which I would likely not mark as
completed until this is at least in dev preview, which likely won't
happen until it is widely available and potentially delayed until
`precommitHandler` is widely available as well.
The final form of this api might not even be a "router feature" in the end, but instead be
something similar to what other frameworks have to provide different
platform integrations (e.g. `provideNavigationRouter`). That would
support omitting the history-based integration from the bundle when only
the navigation integration is used. Alternatively, the current
`provideRouter` could require one of `withHistory` or `withPlatformNavigation`.
The `precommitHandler` of the Navigation API unlocks some of the truly
powerful features for Routers like Angular's which defer the URL
updates. Without the `precommitHandler`, we cannot initiate a navigation
until we are ready to commit the URL because it causes the URL to update
immediately.
With `precommitHandler` support, we are able to create a `NavigateEvent`
_immediately_ on navigation, which allows the browser to show that a
navigation is happening with a loading indicator. Site visitors will
also have the ability to cancel the navigation with the "stop" button.
When we are ready to commit the URL, the precommitHandler supports a
"redirect" function that we can use to first redirect the navigation to
a new location immediately before committing it.
The commit operation is not synchronous because the API waits for all
precommitHandlers to resolve. This commit adds a small bit of handling
to account for this so that the Router's transition does not advance
to the next stage until the URL has been committed.
Unnecessarily aborting traversal navigations will break focus and scroll
restoration. We need to keep them open rather than replacing them with
an identical router-initiated navigation.
This further builds out the Router integration with the platform
Navigation API. Key features in this state include:
* History restoration via direct platform APIs rather than markers left on
`history.state`. This means more guaranteed correctness and less
internal code to compute traversal restorations.
* Ability to observe navigations triggered outside the Router APIs.
Practically speaking, this means some navigations can be performed
through the platform rather than requiring `Router.navigate`. Note
that because the `NavigateEvent` is never intercepted at this point of
the implementation, regular anchor tags cannot be used because they
will still trigger a popstate navigation.
This implementation does _not_ intercept the `NavigateEvent` but future
iterations should. By omitting the interception, we are missing out on
features such as:
* Platform-supported scroll and focus reset
* Holding the navigate event open for the duration of the router
navigation, allowing for a visual loading indicator in the browser
* Support for intercepting navigations from regular anchor tags (e.g.
not `RouterLink`s) and converting those to SPA navigations.
PR Close#64905
This adds a (private) provider for integrating with the browser Navigation API.
This provider ensures that interactions with the `Location` service
use the underlying platform navigation rather than the history and
location APIs.
This cleans up the navigation transitions a bit by removing some
unnecessary operators. Combining operators makes debugging easier by
making it possible to step through the code.
PR Close#64480
This fixes a bug introduced in #63485 where `firstValueFrom` was used. This
doesn't work in all situations here because some observables don't
emit before completing. These errors should result in the route matching
logic moving on to the next route.
Note: This is marked as a refactor rather than fix because the commit above is not in
any release yet.
PR Close#63546
This commit also include an `ng update` migration to ensure `lastSuccessfulNavigation` is invoked.
BREAKING CHANGE: `lastSuccessfulNavigation` is now a signal and needs to be invoked
PR Close#63057
This new signal property is convenient to derive a `isNavigating` state.
`isNavigating = computed(() => !!this.router.currentNavigation())`
DEPRECATED: The Router.getCurrentNavigation method is deprecated. Use the Router.currentNavigation signal instead.
fixes#62958
PR Close#63011
This new signal property is convenient to derive a `isNavigating` state.
`isNavigating = computed(() => !!this.router.currentNavigation())`
DEPRECATED: The Router.getCurrentNavigation method is deprecated. Use the Router.currentNavigation signal instead.
fixes#62958
PR Close#62971
This updates async router tests to use the jasmine autoTick feature. Observed test timings
for the chromium tests went down from ~7.5s to ~3.5-4s. For node, these decreased from ~5.5s to ~3s.
In addition to the speed improvement, this feature:
* Removes the need to be careful about timeout ordering when there are several timeouts in tests.
* Removes the need to ensure test timeouts are kept sufficiently small
* Reduces overall flakiness
PR Close#62776
Preloaded components were not being activated in certain scenarios when preloading was enabled. This change ensures that components are correctly activated after being preloaded.
PR Close#62502
This updates the timeouts in a couple flakey router tests. Ideally we can use the jasmine
auto ticking as soon as tests are migrated to web test runner and we are on the latest
version of jasmine
PR Close#62141
These helpers are often imported by various tests throughout the
repository, but the helpers aren't exported/exposed from the public
entry-point; even though they confusingly reside in there.
This commit fixes this, and moves the helpers into
`packages/private/testing`. This is a preparation for the `ts_project`
migration where we don't want to leverage deep imports between packages.
PR Close#61472
There is nothing in the Router that requires ZoneJS and we do not need
`fakeAsync` as a mock clock. We can instead use any mock clock implementation
to speed up test execution.
This removes ZoneJS completely from the bundle of the Router tests.
ZoneJS causes the stacks to be unreadable when combined with the massive
rxjs stack in the router transition.
PR Close#61078
This commit adds the ability to directly abort a navigation through the
`Router.getCurrentNavigation()?.abort()` method. While there are no
feature requests for this, it is a feature that will be necessary for
integration with the navigation API. The API enables better tracking of
an ongoing navigation for SPAs and a site visitor can cancel a
navigation by clicking the stop button in the browser. While this could
technically be done on the transition with an internal jsdoc comment to
hide it from application developers, there's no need.
With this feature, I believe it would be possible to create somewhat of a shim
to integrate with the navigation API even before the router has full support
using the router events to control a deferred navigation that never
commits the URL and always aborts itself on navigation end.
PR Close#60380
