None of the public properties of the `Router` are meant to be writeable.
They should all be configured using other methods, all of which have been
documented.
DEPRECATED: router writable properties
The following strategies are meant to be configured by registering the
application strategy in DI via the `providers` in the root `NgModule` or
`bootstrapApplication`:
* `routeReuseStrategy`
* `titleStrategy`
* `urlHandlingStrategy`
The following options are meant to be configured using the options
available in `RouterModule.forRoot` or `provideRouter`.
* `onSameUrlNavigation`
* `paramsInheritanceStrategy`
* `urlUpdateStrategy`
* `canceledNavigationResolution`
The following options are available in `RouterModule.forRoot` but not
available in `provideRouter`:
* `malformedUriErrorHandler` - This was found to not be used anywhere
internally.
* `errorHandler` - Developers can instead subscribe to `Router.events`
and filter for `NavigationError`.
PR Close#48006
The router has several default strategy implementations that are either
assigned via `new XStrategy()` property assignements or via the factory
function for the `Router` itself. These can be simplified by providing
the default implementation in the strategy `Injectable`. Custom
implementations can still override the defaults by specifying them in
the `providers` list.
Notably, this change also makes the `UrlHandlingStrategy` and
`RouteReuseStrategy` defaults injectable via DI rather than having to
indirectly grab them by going through the `Router` instance and
accessing the properties.
PR Close#48022
The public API for enabling this option has already been removed. This change
updates the internal Router code to not include any logic to support it.
PR Close#47933
This function is too similar in name to the new `provideRouter` and can
lead to misconfiguring the router. The function itself is just a small
wrapper around `{provide: ROUTES, multi: true, useValue: routes}`. It is
rarely necessary to provide routes in this way. The harm `provideRoutes`
will cause due to being only 1 letter away from `provideRouter` vastly
outweighs the benefit of a slightly shorter provider.
PR Close#47896
This commit switches `provideRouter()` to return the new
`EnvironmentProviders` wrapper type, preventing it from being accidentally
(or intentionally) included in `@Component.providers`.
PR Close#47669
This commit introduces a new type `EnvironmentProviders` which can be used
in contexts where Angular accepted `Provider`s destined for
`EnvironmentInjector`s. This includes contexts such as `@NgModule.providers`
and `Route.providers`.
The new type is useful for preventing such providers from accidentally
ending up in `@Component.providers`. It can be used as the return type of
provider functions (such as `provideRouter`) to enforce this safety.
Because `Provider` allows `any[]` nested arrays, the compile-time safety
provided by `EnvironmentProviders` is easily circumvented. However, the
runtime shape of `EnvironmentProviders` is not compatible with component
injectors and will result in a runtime error if it leaks through (NG0207).
A new function `makeEnvironmentProviders` is used to construct this new type
from an array of providers.
The existing `importProvidersFrom` operation previously returned a very
similar type `ImportedNgModuleProviders` which had the same goal. This
machinery is switched over to use the new `EnvironmentProviders` interface
instead (in fact, `ImportedNgModuleProviders` is now just an alias to
`EnvironmentProviders`).
PR Close#47669
This commit updates the `RouterLink` to extend the selector to also include `<a>` and `<area>` elements, which were previously matched by the `RouterLinkWithHref` directive. The code of the directives was merged together (since there was a lot of duplication) and this commit finalizes the merge. The `RouterLinkWithHref` becomes an alias of the `RouterLink` directive.
Now there is no need to import and use the `RouterLinkWithHref` class, the `RouterLink` directive will match any element that has the `routerLink` attribute.
DEPRECATED:
The `RouterLinkWithHref` directive is deprecated, use the `RouterLink` directive instead. The `RouterLink` contains the code from the `RouterLinkWithHref` to handle elements with `href` attributes.
PR Close#47630
The `relativeLinkResolution` is no longer supported. The only behavior
now is the correct behavior.
BREAKING CHANGE: `relativeLinkResolution` is no longer configurable in
the Router. This option was used as a means to opt out of a bug fix.
PR Close#47623
This commit updates the `RouterLinkWithHref` class to further align with the `RouterLink` class by removing own constructor from the `RouterLinkWithHref` class.
PR Close#47619
When using `loadChildren` or `loadComponent`, a common pattern is to pass
a function that returns a `Promise` from a dynamic import:
```typescript
{
path: 'lazy',
loadComponent: () => import('./lazy-file').then(m => m.LazyCmp),
}
```
The `.then` part of the expression selects the particular exported
component symbol from the dynamically imported ES module.
ES modules can have a "default export", created with the `export default`
modifier:
```typescript
@Component({...})
export default class LazyCmp { ... }
```
This default export is made available to dynamic imports under the well-
known key of `'default'`, per the ES module spec:
https://tc39.es/ecma262/#table-export-forms-mapping-to-exportentry-records
This commit adds a feature to the router to automatically dereference such
default exports. With this logic, when `export default` is used, a `.then`
operation to select the particular exported symbol is no longer required:
```typescript
{
path: 'lazy',
loadComponent: () => import('./lazy-file'),
}
```
The above `loadComponent` operation will automatically use the `default`
export of the `lazy-file` ES module.
This functionality works for `loadChildren` as well.
PR Close#47586
This commit breaks out the code in @angular/router needed to support the
deprecated `loadChildren` signature into a separate file, which reduces the
opportunity for conflicts when patching that behavior in g3.
PR Close#47586
This commit updates the 'name' of `RouterOutlet` to be an `Input` rather
than an attribute. Note that this change does not affect `[attr.name]=`
because those already would not have worked. The static name was only
read in the constructor and if it wasn't available, it would use
'PRIMARY' instead.
fixes#12522
BREAKING CHANGE: Previously, the `RouterOutlet` would immediately
instantiate the component being activated during navigation. Now the
component is not instantiated until the change detection runs. This
could affect tests which do not trigger change detection after a router
navigation. In rarer cases, this can affect production code that relies
on the exact timing of component availability.
PR Close#46569
This commit updates the `RouterLink` directive to use a renderer to apply an `href` attribute value. Previously, the `RouterLinkWithHref` used a host binding for this and that prevented further merge of the `RouterLink` and `RouterLinkWithHref` directives.
PR Close#47605
Currently, the `RouterLink` and `RouterLinkWithHref` classes share a lot of common code (with some special logic around handling `<a>`-related scenarios). This commit unifies the logic of the mentioned directives by moving the necessary handling to the `RouterLink` directive and making it a parent one for the `RouterLinkWithHref` class (i.e. class RouterLinkWithHref extends RouterLink).
This is the first step in upcoming unification to merge both directives and just keep `RouterLink` one (it'd be done in followup PRs).
PR Close#47500
ActivatedRouteSnapshot data gets mutated in the resolve phase of the Router. The title is assigned as part of this.
As a result, the title must be a getter in order to pick up the value that was note available during the class creation.
fixes#47459
BREAKING CHANGE: The title property is now required on ActivatedRouteSnapshot
PR Close#47481
This is the compile-time implementation of the `hostDirectives` feature plus a little bit of runtime code to illustrate how the newly-generated code will plug into the runtime. It works by creating a call to the new `ɵɵHostDirectivesFeature` feature whenever a directive has a `hostDirectives` field. Afterwards `ɵɵHostDirectivesFeature` will patch a new function onto the directive definition that will be invoked during directive matching.
For example, if we take the following definition:
```ts
@Directive({
hostDirectives: [HostA, {directive: HostB, inputs: ['input: alias']}]
})
class MyDir {}
```
Will compile to:
```js
MyDir.ɵdir = ɵɵdefineComponent({
features: [ɵɵHostDirectivesFeature([HostA, {
directive: HostB,
inputs: {
input: "alias"
}
}])]
});
```
The template type checking is implemented during directive matching by adding the host directives applied on the host to the array of matched directives whenever the host is matched in a template.
Relates to #8785.
PR Close#46868
The `UrlTree` is a fundamental concept in the router's API design.
Generally speaking, a `UrlTree` would be constructed via things like
`Router.createUrlTree` or `UrlSerializer#parse`. The second example here
is the core reason to make the constructor public, regardless of how
develpers generally create a `UrlTree` in an application.
Applications can provide their own `UrlSerializer` and may want to implement their
own `parse` method. This means they would also need to create a
`UrlTree` but would not be able to do so effectively because the
constructor is marked `@internal`.
In addition, the `UrlTree` constructor only has 3 parameters, all of
which are already public. There's nothing "special" about it other than
the potential desire to push developers to use other methods for
constructing a `UrlTree` (i.e. `Router.createUrlTree`).
Also see http://b/234604699#comment9 for additional context.
PR Close#47186
This commit creates and exposes the APIs required to use the Angular Router without importing `RouterModule`.
The newly added APIs are tree-shakable and you can add features using special functions rather than using `ExtraOptions` to control the providers via an internal switch in Router code.
```
const appRoutes: Routes = [];
bootstrapApplication(AppComponent,
{
providers: [
provideRouter(appRoutes,
withDebugTracing(), // enables debug tracing feature
withInMemoryScrolling() // enables scrolling feature
]
}
);
```
This "features" pattern allows for router behavior to evolve in a backwards compatible and tree-shakable way in the future. This approach also makes features more discoverable.
The newly added APIs can be used in any application today (doesn't require an application to be bootstrapped using standalone-based APIs).
Note: APIs added in this commit are released in the "Developer Preview" mode, read more about this mode in Angular docs: https://angular.io/guide/releases#developer-preview
PR Close#47010
Add wider typings to setter of preserveFragment, skipLocationChange and replaceUrl inputs of routerLink directives and coerce them to boolean
PR Close#47101
The current Router APIs require guards/resolvers to be present in the DI tree. This is because we want to treat all guards/resolvers equally and some may require dependencies. This requirement results in quite a lot of boilerplate for guards. Here are two examples:
```
const MY_GUARD = new InjectionToken<any>('my_guard');
…
providers: {provide: MY_GUARD, useValue: () => window.someGlobalState}
…
const route = {path: 'somePath', canActivate: [MY_GUARD]}
```
```
@Injectable({providedIn: 'root'})
export class MyGuardWithDependency {
constructor(private myDep: MyDependency) {}
canActivate() {
return myDep.canActivate();
}
}
…
const route = {path: 'somePath', canActivate: [MyGuardWithDependency]}
```
Notice that even when we want to write a simple guard that has no dependencies as in the first example, we still have to write either an InjectionToken or an Injectable class.
With this commit router guards and resolvers can be plain old functions.
For example:
```
const route = {path: 'somePath', component: EditCmp, canDeactivate: [(component: EditCmp) => !component.hasUnsavedChanges]}
```
Additionally, these functions can still use Angular DI with `inject` from `@angular/core`.
```
const route = {path: 'somePath', canActivate: [() => inject(MyDependency).canActivate()]}
```
PR Close#46684
This commit adds the `defaultUrlMatcher` from the Router to the public
API. `UrlMatcher` and `UrlMatchResult` are already in the public api so
the signature of the function as well as the return value are already
exposed. Any change to those or the implementation of `defaultUrlMatcher`
would already be breaking so there's no additional risk in exposing the
default matcher.
This function can be useful for developers who want to create a custom
matcher which builds on the default matcher of the Router. Currently,
the only way to do this would be to copy-paste the implementation.
fixes#35928
PR Close#46913
The implementation of the `DefaultTitleStrategy` was modeled after the
existing strategy patterns in the Router. These patterns were developed
before the `providedIn` syntax for injectables. We can simplify the
model a lot by providing the default in the factory of the abstract
class.
Note that the other strategy patterns aren't touched in this PR due to
how long they've existed. Because they have been there for such a long
time, it's possible there will need to be some adjustments to code
if/when they are refactored to do the same.
PR Close#46876
This commit makes the router directives standalone and refactors some of
the Router injectables to be `providedIn: 'root'` along with factory
functions for initialization.
PR Close#46758
This commit adds the target `RouterStateSnapshot` to the
`NavigationError` so error handlers/subscribers can more easily
determine which navigation failed, including the matched `Route` configs
for the navigation. This information was previously not available
(neither in `NavigationError` nor the `Router#getCurrentNavigation()`).
fixes#27626
PR Close#46731
This commit adds a stable cancelation code to the `NavigationCancel`
event. This code is acceptable for use in production whereas parsing the
`reason` string is not. This allows developers to determine more
specifically _why_ a navigation was canceled and perform different
actions in different scenarios.
PR Close#46675
Extracting preloading to a provider moves us towards
thinking about a world where `ExtraOptions` doesn't exist to control
behaviors that are opt-in/opt-out. Instead, these behaviors could be
controlled by the presence (or lackthereof) of the providers which has
the functionality. This is relevant to a world in which we no longer
have the `RouterModule` but instead have something like `provideRouter`
where the features are tree-shakeable.
This change _does not_ make the `RouterPreloader` tree-shakeable inside
`RouterModule.forRoot` because the compiler cannot statically determine
whether it's needed. However, in the `provideRouter` world without
`forRoot`, preloading could be exposed through the provider function
instead, making the `RouterPreloader` and `PreloadingStrategy`
implementations tree-shakeable for those that don't use it (which is the
default - no preloading).
PR Close#46215
Currently it's not possible to return plain `UrlTree` from `CanMatchFn`,
only wrapped `UrlTree` into Observable or Promise is allowed.
These changes allow to return `UrlTree` from `CanMatchFn`.
PR Close#46455
The `CanMatchFn` is already exposed in the type signature for `canMatch` on the
`Route`. This function type should already be exposed as public API but was
missed in the initial implementation because the older guards use the `any` type
instead.
PR Close#46394
Currently we have two main types of guards:
`CanLoad`: decides if we can load a module (used with lazy loading)
`CanActivate` and friends. It decides if we can activate/deactivate a route.
So we always decide where we want to navigate first ("recognize") and create a new router state snapshot. And only then we run guards to check if the navigation should be allowed.
This doesn't handle one very important use case where we want to decide where to navigate based on some data (e.g., who the user is).
I suggest to add a new guard that allows us to do that.
```
[
{path: 'home', component: AdminHomePage, canUse: [IsAdmin]},
{path: 'home', component: SimpleHomePage}
]
```
Here, navigating to '/home' will render `AdminHomePage` if the user is an admin and will render 'SimpleHomePage' otherwise. Note that the url will remain '/home'.
With the introduction of standalone components and new features in the Router such as `loadComponent`,
there's a case for deprecating `CanLoad` and replacing it with the `CanMatch` guard. There are a few reasons for this:
* One of the intentions of having separate providers on a Route is that lazy
loading should not be an architectural feature of an application. It's an
optimization you do for code size. That is, there should not be an architectural
feature in the router to specifically control whether to lazy load something or
not based on conditions such as authentication. This is a slight nuanced
difference between the proposed canUse guard: this guard would control whether
you can use the route at all and as a side-effect, whether we download the code.
`CanLoad` only specified whether the code should be downloaded so canUse is more powerful and more appropriate.
* The naming of `CanLoad` will be potentially misunderstood for the `loadComponent` feature.
Because it applies to `loadChildren`, it feels reasonable to think that it will
also apply to `loadComponent`. This isn’t the case: since we don't need
to load the component until right before activation, we defer the
loading until all guards/resolvers have run.
When considering the removal of `CanLoad` and replacing it with `CanMatch`, this
does inform another decision that needed to be made: whether it makes sense for
`CanMatch` guards to return a UrlTree or if they should be restricted to just boolean.
The original thought was that no, these new guards should not allow returning UrlTree
because that significantly expands the intent of the feature from simply
“can I use the route” to “can I use this route, and if not, should I redirect?”
I now believe it should allowed to return `UrlTree` for several reasons:
* For feature parity with `CanLoad`
* Because whether we allow it as a return value or not, developers will still be
able to trigger a redirect from the guards using the `Router.navigate` function.
* Inevitably, there will be developers who disagree with the philosophical decision
to disallow `UrlTree` and we don’t necessarily have a compelling reason to refuse this as a feature.
Relates to #16211 - `CanMatch` instead of `CanActivate` would prevent
blank screen. Additional work is required to close this issue. This can
be accomplished by making the initial navigation result trackable (including
the redirects).
Resolves#14515
Replaces #16416Resolves#34231Resolves#17145Resolves#12088
PR Close#46021
This exposes a new function from the router public API that allows
developers to create a `UrlTree` from _any_ `ActivatedRouteSnapshot`.
The current Router APIs only support creating a `UrlTree` from an
`ActivatedRoute` which is both active _and_ materially appears in the
`UrlTree` (it cannot be an empty path named outlet). This is because the
implementation of the current way of creating a `UrlTree` attempts to
look up the `UrlSegment` of the `ActivatedRoute` in the currently active
`UrlTree` of the router. When this doesn't work, the `UrlTree` creation
fails.
Note that this API does not replace the current one. That would actually be a
breaking change but should be done at some point in the future (v15). That is,
`router.navigate` should call this new function. At that point, we can
remove `_lastPathIndex`, `_urlSegment`, and `_correctedPathIndex` from
the `ActivatedRoute`, along with all of the logic associated with
determining what those should be. In addition, this would unblock a fix
for #26081 because the `applyRedirects` and `recognize` operations
could be combined into one. Overall, this would simplify logic in the router
and reduce code size. It also exposes core routing capabilities as a helper function
which were previously private API, which is a necessary step towards #42953.
As a stress test for this new function, it _was_ swapped in as the
default for `UrlTree` creation in #45859 and tested internally. The
results indicate that this function behaves correctly.
resolves#42191 (Tested directly)
resolves#38276 (The test with a guard covers this case)
resolves#22763 (Tested directly)
PR Close#45877
All router events now have a `type` property with a string name identifying the specific type of the event.
The `type` property can be used to perform TypeScript type narrowing using an `if` statement, `switch`
statement, or similar. This removes the need to perform `instanceof` checks but still allows them if
preferred. An `instanceof` check requires the use of the event class value which may not be available
or preferred in certain situations.
The Router's `enableTracing` option is also now guarded with the `ngDevMode` flag which combined with
the use of a new `stringifyEvent` function allows the tree-shaking of the string generation code for
each router event class. However, the original `toString` class methods are still present to prevent
a potential breaking change. As a result, full benefits of the tree-shaking potential will not be realized
until they are removed.
PR Close#44189
`importProvidersFrom` provides a bridge from the world of NgModule-based DI
configuration to the new, "standalone" world of direct providers and
environment injectors. Early user feedback suggested some confusion around
where this function was supposed to be used, particularly around importing
NgModule-based providers into standalone component `providers` arrays, which
is not the intended use. This confusion is exacerbated by the fact that due
to the unified `Provider` type, this kind of misconfiguration was happily
accepted by the type system.
This commit changes the return type of `importProvidersFrom` to wrap the
returned providers in an opaque type that prevents them from being used in
component provider contexts. This, together with stronger documentation
around the purpose and functionality of `importProvidersFrom`, should
address some of the above confusion.
PR Close#45838
Similarly to the symmetry being strengthened between children and loadChildren,
a new loadComponent property will be introduced as the asynchronous version of component.
This will allow for direct single-component lazy loading:
```
{path: 'lazy/a', loadComponent:
() => import('./lazy/a.component').then(m => m.ACmp)},
{path: 'lazy/b', loadComponent:
() => import('./lazy/b.component').then(m => m.BCmp)},
```
This option requires that the component being loaded is standalone and
is implemented as a runtime check.
Other notes:
* Components are not loaded until all guards and resolvers complete.
* Loading the component is included in the function passed to the router
preloading strategy
* `RouteConfigLoadStart` and `RouteConfigLoadEnd` events emit at the
start and end of the component loading
* `CanLoad` guards _do not_ apply to `loadComponent`. `canActivate`
should be used instead, just like you would do if it were simply
`component` instead.
PR Close#45705
This commit expands the `LoadChildrenCallback` to accept returning `Routes`
in addition to the existing `NgModule` type. In addition, it adds a
check to ensure these loaded routes all use standalone components.
The components must be standalone because if they were not,
we would not have the required `NgModule` which the component is declared in.
Existing API:
```
{path: 'lazy/route', loadChildren: import('./lazy').then(m => m.LazyModule)}
@NgModule({
imports: [
ExtraCmpModule,
RouterModule.forChild([
{path: 'extra/route', component: ExtraCmp},
]),
],
})
export class LazyModule {}
```
The new API for lazy loading route configs with standalone components
(no NgModule) is to expand `loadChildren` to allow returning simply a `Routes` array.
```
// parent.ts
{
path: 'parent',
loadChildren: () => import('./children').then(m => m.ROUTES),
}
// children.ts
export const ROUTES: Route[] = [
{path: 'child', component: ChildCmp},
];
```
Note that this includes minimal documentation updates. We need to
include a holistic update to the documentation for standalone components
in the future that includes this feature.
PR Close#45700
add the ariaCurrentWhenActive input to the RouterLinkActive directive so that
users can easily set the aria-current property to their active router
links
resolves#35051
PR Close#45167
DEPRECATED:
The `resolver` argument of the `RouterOutletContract.activateWith` function and the `resolver` field of the `OutletContext` class are deprecated. Passing component factory resolvers are no longer needed. The `ComponentFactoryResolver`-related symbols were deprecated in `@angular/core` package since v13.
PR Close#45597
The current API for `activateWith` uses the deprecated
`ComponentFactoryResolver`. The replacement for this is to use
`EnvironmentInjector`. That is, instead of
```
const factory = componentFactoryResolver.resolveComponentFactory(component);
location.createComponent(factory, location.length, injector);
```
the replacement would be
```
location.createComponent(
component, {index: location.length, injector, environmentInjector});
```
PR Close#45597
Currently, the only way to specify new providers for a `Route` and the
children is to create a new `NgModule` with those providers and use the
`loadChildren` feature. This is pretty confusing and a wholly indirect
way of accomplishing this task. With this commit, developers will be
able to specify a list of providers directly on the `Route` itself.
These providers will apply the that route and its children.
This feature was inspired by the upcoming standalone components feature.
This ties in there because, as mentioned before, the prior art for lazy
loading configs was to load an `NgModule`. This loaded module contained
new route configs _and_ could specify new providers. Separating those
two concepts, there should be a way to load _just_ some new routes, but
there should also be a way to specify new providers as well (something
you could do in the `NgModule` world and now will be able to do in the
world without any `NgModule` through this feature).
PR Close#45673
This commit adds a type field to .d.ts metadata for directives, components,
and pipes which carries a boolean literal indicating whether the given type
is standalone or not. For backwards compatibility, this flag defaults to
`false`.
Tests are added to validate that standalone types coming from .d.ts files
can be correctly imported into new standalone components.
PR Close#45672
BREAKING CHANGE:
The type of `component` on `ActivatedRoute` and `ActivatedRouteSnapshot`
includes `string`. In reality, this is not the case. The component
cannot be anything other than a component class.
PR Close#45625
This wasn't exactly possible before because the `RouterConfigLoader` was
not an Injectable so there wasn't a straightforward way to share
information between `ApplyRedirects` and the preloader. They each had
their own implementation so they needed to store the values on the
`Route` so they both had access to them. I imagine this was the case
because trying to inject `Router` (to get access to the events) into the
preloader would have caused a circular dependency.
This refactor co-locates the loading details with the loader itself
rather than leaking implementation into the public route config and
mutating the object in an awkward way. This also promotes
`RouterConfigLoader` to a proper `Injectable` so data can be shared
throughout the system.
PR Close#45656
Andrew Scott