Due to being only 1 letter away from `provideRouter`, it is quite
possible that developers may accidentally use `provideRoutes` rather
than `provideRouter` in the `boostrapApplication` function. This change
will warn developers when `provideRoutes` is used without the `Router`.
PR Close#47896
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
Currently, the scroll event is fired immediately after the
`NavigationEnd`. However, this is problematic because a change detection
has not been able to run, meaning that Angular will not yet have run the update
block of the component templates being rendered as part of the navigation.
This change delays the scroll event using a `setTimeout`, which will
allow Angular's change detection to run before the scroll restoration is
performed.
fixes#24547
PR Close#47563
The original description gave a false impression that only query params and fragment changes are ignored, while actually `routeParams` changes are ignored as well.
PR Close#47786
In v14, we've introduced core concepts to allow Components, Directives and Pipes to configure their dependencies
without the need to use NgModules and without the need to be declared in an NgModule. The concepts and initial
set of APIs were marked as "developer preview" to allow developers to use these APIs and share the feedback.
Since v14, we've been reviewing the entire API surface of the framework and either updating existing APIs to support standalone or creating new APIs that allowed to use Router, HttpClient and other abstractions without NgMod
ules.
Based on the mentioned work to review and stabilize APIs and also based on the positive feedback from the commun
ity, we are happy to announce that the Standalone APIs are promoted to stable!
This commit updates vast majority of standalone-related APIs to drop the `@developerPreview` label, which effect
ively documents then as stable.
Two APIs that retained the `@developerPreview` annotations are:
- withRequestsMadeViaParent (from `@angular/common/http`)
- renderApplication (from `@angular/platform-server`)
We plan to collect some additional feedback for the mentioned APIs and drop the `@developerPreview` annotation b
efore the next major release.
Co-Authored-By: Alex Rickabaugh <alx@alxandria.net>
Co-Authored-By: Andrew Scott <atscott@google.com>
Co-Authored-By: Dylan Hunn <dylhunn@gmail.com>
Co-Authored-By: Jessica Janiuk <jessicajaniuk@google.com>
Co-Authored-By: JoostK <joost.koehoorn@gmail.com>
Co-Authored-By: Kristiyan Kostadinov <crisbeto@abv.bg>
Co-Authored-By: Pawel Kozlowski <pkozlowski.opensource@gmail.com>
PR Close#47754
This change aligns with the supported Node.js versions of the Angular CLI.
See: https://github.com/angular/angular-cli/pull/24026
BREAKING CHANGE: Angular no longer supports Node.js versions `14.[15-19].x` and `16.[10-12].x`. Current supported versions of Node.js are `14.20.x`, `16.13.x` and `18.10.x`.
PR Close#47730
This commit adds the `provideLocationMocks()` function that returns mocks for the `Location` and `LocationStrategy` classes. This function can be used in tests to configure an environment where it's possible to fire simulated location events (helpful when testing Router configuration).
PR Close#47674
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
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
Some versions of rxjs cause the algorithm used in the Router to not recognize Route configs correctly.
This commit updates the algorithm to be compatible in the same way as other code locations internally.
Context:
https://github.com/angular/angular/commit/1160b8194f78141b40d1d4885ec182d033ff2659fixes#47089
Note: This does not have a test because I was unable to identify the
version of rxjs that would cause a failure here.
PR Close#47098
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
In Angular 14, we introduced the `loadComponent` API for a `Route` to
allow lazy loading of a routed component in addition to the existing
`loadChildren` which allows lazy loading of child routes. As a result,
the `preload` method of the `PreloadingStrategy` needs to sometimes be
called even when there is a `canLoad` guard on the `Route`. `CanLoad`
guards block loading of child routes but _do not_ block loading of the
component.
This change updates the conditional checks in the internal preloader to
skip calling the `PreloadingStrategy.preload` when there is only a
`loadChildren` callback with a `canLoad` guard an no `loadComponent`.
In this case, the callback passed to the `preload` method is already
effectively a no-op so it's not necessary to call it at all.
resolves#47003
PR Close#47007
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
This updates the internal use of INITIAL_NAVIGATION to do two things:
1. Explicitly provide `Enabled` as the default for the token factory
2. Use an enum instead of a string to reduce bundle size
PR Close#46925
This commit refactors the `NgModuleRef` implementation to drop functions required by the `EnvironmentInjector` interface. Previously the idea was that the `NgModuleRef` can act as an Injector to facilitate easier transition to standalone. However, from the mental model perspective, the `NgModuleRef` has the `injector` field, which is the correct injector reference and can be used is needed as an `EnvironmentInjector`.
PR Close#46896
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
Karma jasmine updated the `jasmine-core` dependency. Jasmine is now more
strict when:
* The done callback is invoked multiple times
* The done callback is used, while a promise is also returned
* The done callback is treated as error when e.g. a number is returned
as first argument. This was the case with `requestAnimationFrame`.
The Router transition observable pipe keeps an outer reference to a `t`
variable for use in the `catchError` operator. However, this variable is
not updated with intermediate state. This commit fixes that so the
`catchError` can access properties that get updated in intermediate
states. Specifically, `RouterStateSnapshot` in the `NavigationError` for
now but could be more in the future.
PR Close#46842
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
Before this commit, the `NavigationCancellationCode` would always be set
to `Redirect` when encountering a "navigationcancelingError". However,
this error can also be thrown when `CanLoad` guars reject. This commit
ensures these cancellation errors have a code as well so this mistake
cannot be made again.
PR Close#46752
The existing logic does something similar but in a more roundabout way.
It reads _the whole array_. If it encounters a pending value, it ignores
the remaining ones. If it hasn't encountered a pending value by the time
it hits false/UrlTree, it returns that result.
The new logic is the same, but reverses what we're looking for. Instead
of processing the whole array, we stop when we encounter an initial
value. When we encounter one that isn't `true`, that gets returned. If
we get to the end and everything was `true`, return `true`.
PR Close#46745
PR Close#46745
The existing logic does something similar but in a more roundabout way.
It reads _the whole array_. If it encounters a pending value, it ignores
the remaining ones. If it hasn't encountered a pending value by the time
it hits false/UrlTree, it returns that result.
The new logic is the same, but reverses what we're looking for. Instead
of processing the whole array, we stop when we encounter an initial
value. When we encounter one that isn't `true`, that gets returned. If
we get to the end and everything was `true`, return `true`.
PR Close#46745
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
Andrew Scott