This commit updates the minimum supported Node version across packages from 16.13.0 -> 16.14.0 to ensure compatibility with dependencies.
PR Close#49771
`RouterTestingModule` is not needed as of v16. Instead, TestBed
automatically provides `MockPlatformLocation` in order to help test
navigations in the application. The location mocks in the
RouterTestingModule aren't necessary anymore.
There doesn't appear to be any real documentation around
`RouterTestingModule` other than the API docs.
PR Close#49427
The previous fix for squashing empty children didn't quite work when the
existing route had segments. The result would be that the segments from
the existing route were dropped from the final URL.
PR Close#49691
The navigation transition clears the current navigation in the finalize
operator of the current navigation Observer. This commit both completes
the `bootstrapDone` observable and updates the transition to only take 1
emit from the completed navigation. Either of these changes on their own
would fix the issue. The latter is a preventative measure in case a
mistake like the former is made again.
fixes#49567
PR Close#49572
The easiest way to access route data is now to use direct bindings to
component inputs rather than going through `ActivatedRoute`.
The tour of heroes guide still uses `ActivatedRoute` for now. I was
hesitant to remove all of the content in one swoop and the tour of
heroes is quite a bit more involved.
PR Close#49633
Adds ability for `RouterOutlet` to bind `Router` information to the routed
component's inputs. This commit also exposes some helpers for
implementers of custom outlets to do their own input binding if desired.
Resolves#18967
PR Close#49633
When navigating in the Router, the current approach does the redirects
and the creation of the `RouterStateSnapshot` in two separate steps
(applyRedirects and recognize). These two steps duplicate the route
matching logic, resulting in user code on routes being executing twice
(custom `UrlMatcher` and `canMatch` guards). This also duplicates the
complex matching logic in two places, which increases the bundle size
and maintenance burden.
This commit combines the `applyRedirects` and `recognize` steps into a
single matching algorithm.
fixes#26081
PR Close#49163
This commit updates the logic in the Router that keep track of the initial navigation from being a synchronous to a microtask (Promise.resolve) to allow redirects during the initial navigation.
PR Close#49619
This commit implements a simple tracker of the pending tasks during initial rendering. The class allows adding and removing tasks from the set. The class also exposes a promise that gets resolved once the last task is removed.
This tracker is needed to keep track of ongoing processes like Router navigation (and potentially HTTP requests) and acts as a signaling mechanism to SSR and hydration that the application is in the "stable" state and a serialization can be performed.
This class would also act as a future replacement for the `ApplicationRef.isStable` for zoneless applications.
PR Close#49576
When navigating in the Router, the current approach does the redirects
and the creation of the `RouterStateSnapshot` in two separate steps
(applyRedirects and recognize). These two steps duplicate the route
matching logic, resulting in user code on routes being executing twice
(custom `UrlMatcher` and `canMatch` guards). This also duplicates the
complex matching logic in two places, which increases the bundle size
and maintenance burden.
This commit combines the `applyRedirects` and `recognize` steps into a
single matching algorithm.
fixes#26081
PR Close#49163
The preloading strategy did not handle a `loadComponent` on a route with
a static `children`. It only preloaded children if they were also
`loadChildren` or both were not lazy loaded.
fixes#49558
PR Close#49571
This commit updates parts of the FW to be ES2022 complaint.
These changes are needed to fix the following problems problems with using properties before they are initialized.
Example
```ts
class Foo {
bar = this.buz;
constructor(private buz: unknown){}
}
```
PR Close#49559
This commit updates parts of the FW to be ES2022 complaint.
These changes are needed to fix the following problems problems with using properties before they are initialized.
Example
```ts
class Foo {
bar = this.buz;
constructor(private buz: unknown){}
}
```
PR Close#49332
BREAKING CHANGE:
`ComponentFactoryResolver` has been removed from Router APIs.
Component factories are not required to create an instance of a component
dynamically. Passing a factory resolver via resolver argument is no longer needed
and code can instead use `ViewContainerRef.createComponent` without the
factory resolver.
PR Close#49239
The private util `isObservable` was actually just testing the same thing as`isSubscribable()`. As the implementation is closer to the function's name, let's only keep ``isSubscribable`.
PR Close#49295
The `Router` already has the `getCurrentNavigation()` helper function to
expose information about the ongoing navigation.
`lastSuccessfulNavigation` is actually already exposed in the
`Navigation` object. This commit only _slightly_ extends the current API
surface by providing access to the `lastSuccessfulNavigation` object
outside of an ongoing navigation.
fixes#45685
PR Close#49235
This zone code was added with the incorrect assumption that it would
avoid scheduling a new change detection by creating the timeout outside
of the Angular zone. However, it has recently been (re)discovered that
calling `zone.run` when you are outside the angular zone results in a
synchronous change detection. With that, this bit of code doesn't
actually accomplish what it set out to do so it can be removed.
minimal repro: https://stackblitz.com/edit/angular-hbzbqs?file=src%2Fmain.ts
PR Close#49238
BREAKING CHANGE: Node.js v14 support has been removed
Node.js v14 is planned to be End-of-Life on 2023-04-30. Angular will stop supporting Node.js v14 in Angular v16. Angular v16 will continue to officially support Node.js versions v16 and v18.
PR Close#49255
This change makes the `createUrlTreeFromSnapshot` added in #45877 the
default and only behavior in the Router. This now addreses #42191, #38276, #22763,
and #48472 without needing to create custom handling to
call `createUrlTreeFromSnapshot` (since it's now called by `Router.createUrlTree`).
BREAKING CHANGE: Tests which mock `ActivatedRoute` instances may need to be adjusted
because Router.createUrlTree now does the right thing in more
scenarios. This means that tests with invalid/incomplete ActivatedRoute mocks
may behave differently than before. Additionally, tests may now navigate
to a real URL where before they would navigate to the root. Ensure that
tests provide expected routes to match.
There is rarely production impact, but it has been found that relative
navigations when using an `ActivatedRoute` that does not appear in the
current router state were effectively ignored in the past. By creating
the correct URLs, this sometimes resulted in different navigation
behavior in the application. Most often, this happens when attempting to
create a navigation that only updates query params using an empty
command array, for example `router.navigate([], {relativeTo: route,
queryParams: newQueryParams})`. In this case, the `relativeTo` property
should be removed.
PR Close#48508
This commit introduces helper functions to easily convert `Injectable`s with
functions compatible with `Route` guards to the corresponding guard functions.
These functions will serve to aid in migrating off of the now deprecated
class-based guards, but also provide an easy avenue to still defining
guards as `Injectable` classes if that is desired.
PR Close#48709
Add a more specific error message when defining a lazy-loaded route using
`loadComponent` and passing it a NgModule instead of a standalone component,
when the user should actually be using `loadChildren`.
PR Close#49164
41e2a68e30 added a `type` property on all router events, and added all type of events to the `Event` union type, but forgot to remove `RouterEvent`.
This removes the benefit of the `type` field, because it is not possible to write:
```
this.router.events.pipe(filter((event: Event): event is NavigationEnd => event.type === EventType.NavigationEnd)).subscribe(/*...*/);
```
as `RouterEvent` does not have a `type` field (hence TS complains).
This commit fixes the issue by removing `RouterEvent` from the union type.
BREAKING CHANGE: The `RouterEvent` type is no longer present in the `Event` union type representing all router event types. If you have code using something like `filter((e: Event): e is RouterEvent => e instanceof RouterEvent)`, you'll need to update it to `filter((e: Event|RouterEvent): e is RouterEvent => e instanceof RouterEvent)`.
PR Close#46061
Very cosmetic, but it might be necessary :
I updated the ```canAccess``` method second signature name and type in the provided sample. As it stands, it triggers `TS(2345): Argument of type 'Route' is not assignable to parameter of type 'string'`.
PR Close#49140
The Router scroller only listens for NavigationEnd events. However, the
default behavior of the Router is to ignore navigations to the same URL.
This breaks the anchor scrolling when clicking on an anchor whose
fragment is already in the URL.
fixes#29099
BREAKING CHANGE: The `Scroll` event's `routerEvent` property may also be
a `NavigationSkipped` event. Previously, it was only a `NavigationEnd`
event.
PR Close#48025
This warning was put in place to surface an error when developers use an ActivatedRoute
with an invalid structure in tests. However, there isn't a clear path to fixing it and
the tests continue to pass (ideally - that's what the recovery code is there for).
Rather than surfacing an error that developers would be confused by and likely ignore,
it would be better to not warn at all unless there is a clearer action to take to
resolve the issue.
resolves#49116
PR Close#49117
v16 will have a breaking change to the way `UrlTree`s are constructed.
This change is actually a bug fix that makes `UrlTree` creation correct
in more scenarios (see #48508). However, this can affect applications that are
relying on the current incorrect behavior. This commit adds a dev mode
warning when the target of a navigation will change once #48508 is
submitted.
PR Close#48688
This commit updates the docs of the functional guards and resolvers to improve the migration
experience when moving away from class-based equivalents.
PR Close#48873
In order to test components and services which depend on router navigations, such as `ActivatedRoute` instances, tests currently need to provide a fair bit of boilerplate _or_ they can set up a stub for `ActivatedRoute` and list it in the `providers` to override it in `TestBed`. This approach of stubbing the `ActivatedRoute` creates a situation that can easily cause the test to break. The stub often only mocks out the dependencies that the component/service _currently_ needs. This dependencies might change over time and break the test in an unexpected way. In addition, it is difficult to get the structure of `ActivatedRoute` exactly correct.
This change will allow unit tests to quickly set up routes, trigger real navigations in the Router, and get instances of component's to test along with real instances of `ActivatedRoute`. This all comes without needing to know that the component depends on `ActivatedRoute` at all. This becomes more important when considering that a component may be refactored in the future to use `@Input` rather than access data on the `ActivatedRoute` instance (see #18967). Tests which mock out `ActivatedRoute` would all break, but those which use `navigateForTest` would continue to work without needing any updates.
resolves#15779resolves#48608
PR Close#48552
There may be use-cases in the future where `afterNextNavigation` is used
in other locations. For example, a test helper function which navigates
should likely wait for all redirects to complete rather than simply
waiting for the promise returned from `navigate` to resolve.
PR Close#48552
The details of this commit are pretty thoroughly described in the tests
and code comments. In short, it is sometimes ambiguous where to apply commands in
a `SegmentGroup` tree that is created from an `ActivatedRoute` when
dealing with empty paths. This adjusts the strategy to tolerate more
ambiguity while still allowing developers to be explicit.
This is a fix-forward for b/265215141
PR Close#48734
Class and `InjectionToken`-based guards and resolvers are not as configurable,
are less re-usable, require more boilerplate, cannot be defined inline with the route,
and require more in-depth knowledge of Angular features (`Injectable`/providers).
In short, they're less powerful and more cumbersome.
In addition, continued support increases the API surface which in turn increases
bundle size, code complexity, the learning curve and API surface to teach,
maintenance cost, and cognitive load (needing to grok several different types
of information in a single place).
Lastly, supporting only the `CanXFn` types for guards and `ResolveFn` type
for resolvers in the `Route` interface will enable better code
completion and integration with TypeScript. For example, when writing an
inline functional resolver today, the function is typed as `any` and
does not provide completions for the `ResolveFn` parameters. By
restricting the type to only `ResolveFn`, in the example below
TypeScript would be able to correctly identify the `route` parameter as
`ActivatedRouteSnapshot` and when authoring the inline route, the
language service would be able to autocomplete the function parameters.
```
const userRoute: Route = {
path: 'user/:id',
resolve: {
"user": (route) => inject(UserService).getUser(route.params['id']);
}
};
```
Importantly, this deprecation only affects the support for class and
`InjectionToken` guards at the `Route` definition. `Injectable` classes
and `InjectionToken` providers are _not_ being deprecated in the general
sense. Functional guards are robust enough to even support the existing
class-based guards through a transform:
```
function mapToCanMatch(providers: Array<Type<{canMatch: CanMatchFn}>>): CanMatchFn[] {
return providers.map(provider => (...params) => inject(provider).canMatch(...params));
}
const route = {
path: 'admin',
canMatch: mapToCanMatch([AdminGuard]),
};
```
With regards to tests, because of the ability to map `Injectable`
classes to guard functions as outlined above, nothing _needs_ to change
if projects prefer testing guards the way they do today. Functional
guards can also be written in a way that's either testable with
`runInContext` or by passing mock implementations of dependencies.
For example:
```
export function myGuardWithMockableDeps(
dep1 = inject(MyService),
dep2 = inject(MyService2),
dep3 = inject(MyService3),
) { }
const route = {
path: 'admin',
canActivate: [() => myGuardWithMockableDeps()]
}
// test file
const guardResultWithMockDeps = myGuardWithMockableDeps(mockService1, mockService2, mockService3);
const guardResultWithRealDeps = TestBed.inject(EnvironmentInjector).runInContext(myGuardWithMockableDeps);
```
DEPRECATED: Class and `InjectionToken` guards and resolvers are
deprecated. Instead, write guards as plain JavaScript functions and
inject dependencies with `inject` from `@angular/core`.
PR Close#47924
Working towards removing the backwards dependency on router from the
navigation transition handler, this change moves `rootComponentType` and
`afterPreactivation` to the transition handler since that is the only
location those properties are used.
PR Close#48475
Andrew Kushnir