Currently, when deactivating a route, the detach method of the RouteReuseStrategy is always called
even when we are dealing with a componentless route. If when using a custom strategy we attempt to
detach a componentless route, an exception is thrown causing the navigation to break.
This change prevents this from happening, by not triggering the detach of the route reuse strategy.
Fixes#44239
PR Close#44240
Currently, it's impossible to cache (detach/attach) parent route without caching child routes.
This produces a bug, when navigating from a/b to c, then to a/d, where a route is cached.
On the last navigation, we incorrectly restore a/b route instead of a/d.
This change introduces new behavior: if the route should be detached/attached,
we do so, but we check also child routes recursively.
Fixes#17333
PR Close#43791
Experimentation with the Router URL management exposed a situation where
the `currentNavigation` was being cleared in the `finalize` after the
`currentNavigation` was already set to the next one.
This change ensures that the `currentNavigation` is only cleared if the
id of the finalized transition matches the one on the
`currentNavigation` object.
PR Close#43852
* beforePreactivation hook is unused
* The only place that uses afterPreactivation does not use the arguments
Not to say we won't want to provide hooks similar to this in the future,
but the current state is over-engineered for what it's being used for.
PR Close#43804
Previously, when a router-outlet is conditionally shown with an ngIf, and a sub-route was re-attached
via a custom RouteReuseStrategy, router-outlet would try to mount a destroyed component into the view
if the router-outlet is destroyed and re-initialized.
This commit fixes it by unsetting context.attachRef when router-outlet is destroyed, so when the
router-outlet is being initialized again, it no longer sees an attachRef that it needs to mount to the
view.
Fixes#43696
PR Close#43697
Many of the tests in the router code use the deprecated loadChildren as a string. This
has been deprecated for years and can easily be changed to just a function that
returns the module.
PR Close#43578
Previously the events of `RouterOutlet` (activate/deactivate) were not fired
when an outlet got attached/detached with `RouteReuseStrategy`. The changes configure
`RouterOutlet` to emit events when an outlet gets attached/detached.
Fixes#25521, #20501
PR Close#43333
This bit of code is problematic for several reasons:
1. AngularJS-specific handling should not exist in core router code if it can be avoided.
It's not something that should complicated the code long-term
2. It causes URL flickering (the `replace: /` really does happen and can be observed)
3. The original intent was likely for the URL to not actually change;
since the Router only initially supported 'deferred' navigations, this would _usually_ be the case.
4. It actually causes observers of URL changes more problems in handling changes
because the router is already about to process another navigation request.
Notice that when using `'computed'` restoration logic, we do not reset the URL
because it would cause another location change event and conflict with the new navigation.
5. It only resets the browser URL but does nothing to sync the rest of the internal state of the router.
6. It makes guards which call `router.navigate()` behave _slightly_ differently
than guard which return `UrlTree`. Guards which return `UrlTree` do not reset the
URL, but instead just trigger a new navigation.
7. It resets the entire URL rather than just the portion that the
`UrlHandlingStrategy` is configured to handle. Theoretically, the
Router could be configured to only handle a part of the URL so failed
navigations should not reset parts it is not configured to touch.
Note that this is actually a problem in other places in the router as
well where `resetState` is not called before
`resetUrlToCurrentUrlTree`.
As a nice benefit, when `urlUpdateStrategy` is set to `'eager'`, this
makes #17004 possible.
BREAKING CHANGE:
The router will no longer replace the browser URL when a new navigation
cancels an ongoing navigation. This often causes URL flicker and was
only in place to support some AngularJS hybrid applications. Hybrid
applications which rely on the `navigationId` being present on initial
navigations that were handled by the Angular router should instead
subscribe to `NavigationCancel` events and perform the
`location.replaceState` themselves to add `navigationId` to the Router
state.
In addition, tests which assert `urlChanges` on the `SpyLocation` may
need to be adjusted to account for the `replaceState` which is no longer
triggered.
PR Close#43496
The getTransition helper function ensures that urlAfterRedirects is assigned for when
the router does not process the previous or current URL. In this case, we would set
the browserUrlTree to be the urlAfterRedirects, which was initialized to be the browserUrlTree.
This is a no-op, so there's no need for the getTransition function at all.
PR Close#43436
PR #43102 broke some use-cases. These tests document expected behavior
and would have prevented #43446 and #43447. Recent changes have already
addressed these issues, but it would still be a good idea to cover these
use-cases in tests as well.
PR Close#43449
The previous code would set the browser URL to be only the part that's
extracted by the `UrlHandlingStrategy`. However, there may be parts of
the URL which are _should not_ be handled by the Angular Router. This
change updates the code to set the browser URL in the same way that's
done with `'deferred'`: Merging the extracted URL after redirects with
the whole raw URL of the navigation, which includes parts not handled by
the `UrlHandlingStrategy`.
PR Close#43421
There are situations where the Router does not currently clean up failed navigations
correctly. While this is problematic on its own, we can mitigate some of
the damage by processing any URL when we get a navigation request when
the internal router state is out of sync.
Each of the added tests would fail without this change.
fixes#34795
PR Close#43424
* Do not emit url pop on Location.go
* Emit a `popstate` event before each `hashchange` to have the same
behavior of the browser.
* Track the url change in the internal history when calling `simulateHashChange`
The changes to the router tests reflect the goals of the test.
Generally when `Location.go` is used to trigger navigations, it is only
relevant for `HashLocationStrategy` and verifying that the Router picks
up changes from manual URL changes. To do this, we convert those calls
to `simulateHashChange` instead.
Manual URL bar changes to the path when not using the `HashLocationStrategy`
would otherwise trigger a full page refresh so they aren't relevant to
these test scenarios which assert correct behavior during the lifetime
of the router.
[Reference for no `popstate` on `pushState`/`replaceState`](https://developer.mozilla.org/en-US/docs/Web/API/Window/popstate_event)
> Note that just calling history.pushState() or history.replaceState() won't
trigger a popstate event. The popstate event will be triggered by doing a browser
action such as a click on the back or forward button (or calling history.back()
or history.forward() in JavaScript).
[Reference for `popstate` before `hashChange`](https://developer.mozilla.org/en-US/docs/Web/API/Window/popstate_event#when_popstate_is_sent)
> When the transition occurs, either due to the user triggering the browser's
> "Back" button or otherwise, the popstate event is near the end of the process to transition to the new location
...
> 12. If the value of state changed, the popstate event is sent to the document.
> 13. Any persisted user state is restored, if the browser chooses to do so.
> 14. If the original and new entry's shared the same document, but had different fragments in their URLs, send the hashchange event to the window.
BREAKING CHANGE:
The behavior of the `SpyLocation` used by the `RouterTestingModule` has changed
to match the behavior of browsers. It no longer emits a 'popstate' event
when `Location.go` is called. In addition, `simulateHashChange` now
triggers _both_ a `hashchange` and a `popstate` event.
Tests which use `location.go` and expect the changes to be picked up by
the `Router` should likely change to `simulateHashChange` instead.
Each test is different in what it attempts to assert so there is no
single change that works for all tests. Each test using the `SpyLocation` to
simulate browser URL changes should be evaluated on a case-by-case basis.
fixes#27059
PR Close#41730
This commit adds a new output to `routerLinkActive` directive.
Whenever, the associated link becomes active or inactive, an
event will be fired on this out with the correct status
PR Close#37284
PR Close#43280
The management of `browserUrlTree` currently has several problems with
correctly tracking the actual state of the browser.
This change makes the Router eagerly update the `browserUrlTree` when
handling navigations triggered by browser events (i.e., not 'imperative'). This
is because with those types of navigations, the browser URL bar is
_already_ updated. If we do not update the internal tracking of the
`browserUrlTree`, we will be out of sync with the real URL if the
navigation is rejected.
It would be best if we could remove `browserUrlTree` completely, but doing that
would require a lot more investigation and is blocked by #27059 because
the SpyLocation used in tests does not emulate real browser behavior.
fixes#43101
PR Close#43102
For now it's not possible to provide custom route reuse strategy via DI
for `RouterTestingModule`, only imperative instantiation. These changes
makes it possible to provide custom route reuse strategy via DI.
PR Close#42434
When `canceledNavigationResolution='computed'`, the `Router` needs to
handle the cases where errors are thrown. Previously, the logic was not
updated and would simply do a `replaceState` rather than determining
where in the history we should move to restore the page/url from before
the failed navigation.
PR Close#42933
When another navigation is triggered during an in-process navigation and
the `canceledNavigationResolution` is `'computed'`, we should not
attempt to restore the browser history using `history.go`. Doing that
would trigger a third navigation through the router which would conflict
with the new navigation that we were trying to process. Instead, we
treat this as a redirect and skip the history restoration attempt. This
acts similarly to returning `UrlTree` from a guard.
Fixes issue described in https://github.com/angular/angular/pull/38884#issuecomment-863767152
PR Close#42751
This is something I ran into while working on a fix for the `TestBed` module teardown behavior for #18831. In the `RouterInitializer.appInitializer` we have a callback to the `LOCATION_INITIALIZED` which has to do some DI lookups. The problem is that if the module is destroyed before the location promise resolves, the `Injector.get` calls will fail. This is unlikely to happen in a real app, but it'll show up in unit tests once the test module teardown behavior is fixed.
PR Close#42560
We can’t determine whether the user actually meant the `back` or
the `forward` using the popstate event (triggered by a browser
back/forward)
so we instead need to store information on the state and compute the
distance the user is traveling withing the browser history.
So by using the `History#go` method,
we can bring the user back to the page where he is supposed to be after
performing the action.
implementation for #13586
PR Close#38884
We have some internal proxies for all of the Jasmine functions, as well as some other helpers. This code hasn't been touched in more than 5 years, it can lead to confusion and it isn't really necessary since the same can be achieved using Jasmine.
These changes remove most of the code and clean up our existing unit tests.
PR Close#42177
When recognizing routes, the router merges nodes which map to the same
empty path config. This is because auxiliary outlets under empty path
parents need to match the parent config. This would result in two
outlet matches for that parent which need to be combined into a single
node: The regular 'primary' match and the match for the auxiliary outlet.
In addition, the children of the merged nodes should also be merged to
account for multiple levels of empty path parents.
Fixes#41481
PR Close#41584
Add new method `historyGo`, that will let
the user navigate to a specific page from session history identified by its
relative position to the current page.
We add some tests to `location_spec.ts` to validate the behavior of the
`historyGo` and `forward` methods.
Add more tests for `location_spec` to test `location.historyGo(0)`, `location.historyGo()`,
`location.historyGo(100)` and `location.historyGo(-100)`. We also add new tests for
`Integration` spec to validate the navigation when we using
`location#historyGo`.
Update the `historyGo` function docs
Note that this was made an optional function in the abstract classes to
avoid a breaking change. Because our location classes use `implements PlatformLocation`
rather than `extends PlatformLocation`, simply adding a default
implementation was not sufficient to make this a non-breaking change.
While we could fix the classes internal to Angular, this would still have been
a breaking change for any external developers who may have followed our
implementations as an example.
PR Close#38890
ActivatedRoute.fragment was typed as Observable<string> but could emit
both null and undefined due to incorrect non-null assertion. These
non-null assertions have been removed and fragment has been retyped to
string | null.
BREAKING CHANGE:
Strict null checks will report on fragment potentially being null.
Migration path: add null check.
Fixes#23894, fixes#34197.
PR Close#37336
No longer emits to `Router.events` after the router has been destroyed. Also
returns a resolved promise to the navigation methods.
Fixes#40502.
PR Close#40638
When loading a module that doesn't provide `RouterModule.forChild()` preloader will get stuck
in an infinite loop and throw `ERROR Error: Maximum call stack size exceeded.`
The issue is that child module's `Injector` will look to its parent `Injector` when it doesn't
find any `ROUTES` so it will return routes for it's parent module instead. This will load the
child again that returns its parent's routes and so on.
Closes#29164
PR Close#36605
Do not warn that navigation was triggered outside Angular zone if the
Router was created outside Angular zone in the first place.
Closes#25837
PR Close#25839
During route activation, a componentless route will not have a context created
for it, but the logic continues to recurse so that children are still
activated. This can be seen here:
https://github.com/angular/angular/blob/362f45c4bf1bb49a90b014d2053f4c4474d132c0/packages/router/src/operators/activate_routes.ts#L151-L158
The current deactivation logic does not currently account for componentless routes.
This commit adjusts the deactivation logic so that if a context cannot
be retrieved for a given route (because it is componentless), we
continue to recurse and deactivate the children using the same
`parentContexts` in the same way that activation does.
Fixes#20694
PR Close#40196
There are two parts to this commit:
1. Revert the changes from #38379. This change had an incomplete view of
how things worked and also diverged the implementations of
`applyRedirects` and `recognize` even more.
2. Apply the fixes from the `recognize` algorithm to ensure that named
outlets with empty path parents can be matched. This change also passes
all the tests that were added in #38379 with the added benefit of being
a more complete fix that stays in-line with the `recognize` algorithm.
This was made possible by using the same approach for `split` by
always creating segments for empty path matches (previously, this was
only done in `applyRedirects` if there was a `redirectTo` value). At the
end of the expansions, we need to squash all empty segments so that
serializing the final `UrlTree` returns the same result as before.
Fixes#39952Fixes#10726Closes#30410
PR Close#40029
Allow configuration of `relativeTo` in the `routerLink` directive. This
is related to the clearing of auxiliary routes, where you need to use
`relativeTo: route.parent` in order to clear it from the activated
auxiliary component itself. This is because `relativeTo: route` will
consume the segment that we're trying to clear, so there is really no
way to do this with routerLink at the moment.
Related issue: #13523
Related (internal link): https://yaqs.corp.google.com/eng/q/5999443644645376
PR Close#39720
Remove preserveQueryParams as it was deprecated for removal in v4, use
queryParamsHandling="preserve" instead.
BREAKING CHANGE: preserveQueryParams has been removed, use
queryParamsHandling="preserve" instead
PR Close#38762
Previously, RouterTestingModule only assigned two of the options within ExtraOptions to the Router.
Now, it assigns the same options as RouterModule does (with the exception of enableTracing) via a
new shared function assignExtraOptionsToRouter.
Fixes#23347
PR Close#39096
In certain circumstances (errors during component constructor) the router outlet may not be activated before
redirecting to a new route. If the new route requires running guards and resolvers the current logic will throw
when accessing outlet.component due to an isActivated check within the property getter. This update brings the
logic inline with deactivateRouterAndItsChildren, namely checking outlet.isActivated before trying to access
outlet.component.
Fixes#39030
PR Close#39049
This change contains the test from #38780 and also removes `defer` from
the `apply_redirects` logic because the change that introduced
`concatMap` instead of `map`...`concatAll` makes `defer` unnecessary.
PR Close#38781
This commit introduces a new subscription in the `routerLinkActive` directive which triggers an update
when any of its associated routerLinks have changes. `RouterLinkActive` not only needs to know when
links are added or removed, but it also needs to know about if a link it already knows about
changes in some way.
Quick note that `from...mergeAll` is used instead of just a simple
`merge` (or `scheduled...mergeAll`) to avoid introducing new rxjs
operators in order to keep bundle size down.
Fixes#18469
PR Close#38511
When navigations coming from Angular router we may have a payload stored in state property. When this
exists, set extras's state to the payload.
PR Close#28176
The current method of handling duplicate navigations caused by 'hashchange' and 'popstate' events for the same url change does not correctly handle cancelled navigations. Because `scheduleNavigation` is called in a `setTimeout` in the location change subscription, the duplicate navigations are not flushed at the same time. This means that if the initial navigation hits a guard that schedules a new navigation, the navigation for the duplicate event will not compare to the correct transition (because we inserted another navigation between the duplicates). See https://github.com/angular/angular/issues/16710#issuecomment-646919529Fixes#16710
PR Close#37674
CanLoad guards are processed in asynchronous manner with the following rules:
* If all guards return `true`, operator returns `true`;
* `false` and `UrlTree` values wait for higher priority guards to resolve;
* Highest priority `false` or `UrlTree` value will be returned.
`prioritizedGuardValue` uses `combineLatest` which in order subscribes to each Observable immediately (not waiting when previous one completes that `concatAll` do). So it makes some advantages in order to run them concurrently. Respectively, a time to resolve all guards will be reduced.
PR Close#37523
This PR changes the logic for determining when to skip route processing from
using the URL of the last attempted navigation to the actual resulting URL after
that transition.
Because guards may prevent navigation and reset the browser URL, the raw
URL of the previous transition may not match the actual URL of the
browser at the end of the navigation process. For that reason, we need to use
`urlAfterRedirects` instead.
Other notes:
These checks in scheduleNavigation were added in https://github.com/angular/angular/commit/eb2ceff4ba19a09a5f400f81e371ec176878cd37
The test still passes and, more surprisingly, passes if the checks are removed
completely. There have likely been changes to the navigation handling that
handle the test in a different way. That said, it still appears to be important
to keep the checks there in some capacity because it does affect how many
navigation events occur. This addresses an issue that came up in #16710: https://github.com/angular/angular/issues/16710#issuecomment-634869739
This also partially addresses #13586 in fixing history for imperative
navigations that are cancelled by guards.
PR Close#37716
Value of "undefined" passed as segment in routerLink is stringified to string "undefined".
This change introduces the same behavior for value of "null".
PR Close#32616
For URLs that use auxiliary route outlets in the second or following path segments,
when removing the auxiliary route segment, parenthesis remain for the primary outlet segment.
This causes the following error when trying to reload an URL: "Cannot match any route".
The commit adds a check for this scenario, serializing the URL as "a/b" instead of "a/(b)".
PR Close#24656
PR Close#37163
Kristiyan Kostadinov