The proposed ES dynamic import() is now supported by the Angular CLI and the
larger toolchain. This renders the `loadChildren: string` API largely
redundant, as import() is far more natural, is less error-prone, and is
standards compliant. This commit deprecates the `string` form of
`loadChildren` in favor of dynamic import().
DEPRECATION:
When defining lazy-loaded route, Angular previously offered two options for
configuring the module to be loaded, both via the `loadChildren` parameter
of the route. Most Angular developers are familiar withthe `string` form of
this API. For example, the following route definition configures Angular to
load a `LazyModule` NgModule from `lazy-route/lazy.module.ts`:
```
[{
path: 'lazy',
loadChildren: 'lazy-route/lazy.module#LazyModule',
}]
```
This "magic string" configuration was previously necessary as there was
no dynamic module loading standard on the web. This has changed with the
pending standardization of dynamic `import()` expressions, which are now
supported in the Angular CLI and in web tooling in general. `import()`
offers a more natural and robust solution to dynamic module loading. The
above example can be rewritten to use dynamic `import()`:
```
[{
path: 'lazy',
loadChildren: () => import('./lazy-route/lazy.module').then(mod => mod.LazyModule),
}]
```
This form of lazy loading offers significant advantages in terms of:
* type checking via TypeScript
* simplicity of generated code
* future potential to run natively in supporting browsers
(see: [caniuse: dynamic import()](https://caniuse.com/#feat=es6-module-dynamic-import))
As a result, Angular is deprecating the `loadChildren: string` syntax in
favor of ES dynamic `import()`. An automatic migration will run during
`ng upgrade` to convert your existing Angular code to the new syntax.
PR Close#30073
Prior to this change, if a navigation was ongoing and a new one came in, the router could get into a state where `router.currentNavigation` was `null` even though a navigation was executing. This change moves where we set the `currentNavigation` value so it's inside a `switchMap`. This solves the problem because the `finally` on the `switchMap` had been setting `currentNavigation` to `null` but the new `currentNavigation` value would have already been set. Essentially this was a timing problem and is resolved with this change.
Fixes#29389#29590
PR Close#29636
clarify scrollPositionRestoration enabled to fully describe the functionality it provides. refactor app module example to compile and remove dependency on unnecessary framework. Remove component example due to bug on reload.
PR Close#29260
The router loadChildren property already supports a promise that returns a NgModuleFactory, but the typings cause the compilation to fail.
PR Close#29392
This PR also changes the name of `EmptyOutletComponent` to `ɵEmptyOutletComponent`. This is because `ngcc` requires the node to retain the original name while dts bundler will rename the node is it's only exported using the aliases.
Example typings files:
```ts
declare class EmptyOutletComponent {
}
export {EmptyOutletComponent as ɵEmptyOutletComponent}
```
will be emitted as
```ts
export declare class ɵEmptyOutletComponent {
}
```
PR Close#28833
* Use exclusively `TeamComponent` class for examples, as currently there are at least 3 different component classes being used, one of which is actually as a type argument for a `Resolve<T>` implementation.
PR Close#29093
When a UrlTree of root url was returned by a guard as a redirection, the
navigation was not processed. The issue came from the error handler which
incorrectly marked the router as already navigated.
Fixes#27845
PR Close#28271
The value here is unimportant on initialization since it's not looked at until the second navigation. However, sometimes in testing the `Location` service is mocked out, or the Router constructor manually called. Assuming `Location` exists in the constructor leads to test failures in `google3` therefore we initialize to a value that will not cause errors.
PR Close#28376
With #27680, a bug was fixed where multiple redirects using `eager` URL update could cause navigation to fail. However, that fix introduced a problem where with `skipLocationChange` enabled, the URL tree rendered was not properly stored for reference. This specifically caused an issue with named router outlets and subsequent navigations not being recognized.
This PR stores the correct `UrlTree` for reference with later navigations. It fixes the regression introdued with #27680.
Fixes#28200
PR Close#28300
* Interface that a class can implement to be a guard deciding if a children can be loaded.
'...if a children...' changed to '...if children...'
* Interface that a class can implement to be a guard deciding if children can be loaded.
PR Close#27894
Navigating to a route such as `/users`, you may get redirected to `/login`. Previously, if you go then route to `/users` again the URL will end up showing `/users` after the second redirect. This only happened in `UrlUpdateStrategy="eager"`. This is now fixed so after the second redirect, the URL shows the correct page.
Fixes#27116
PR Close#27523
This option means guards and resolvers will ignore changes when a provided predicate function returns `false`. This supports use cases where an application needs to ignore some param updates but not others. For example, changing a sort param in the URL might need to be ignored, whereas changing the a `project` param might require re-run of guards and resolvers.
Related to #26861#18253#27464
PR Close#27682
Navigating to a route such as `/users`, you may get redirected to `/login`. Previously, if you go then route to `/users` again the URL will end up showing `/users` after the second redirect. This only happened in `UrlUpdateStrategy="eager"`. This is now fixed so after the second redirect, the URL shows the correct page.
Fixes#27116
PR Close#27523
This option means guards and resolvers will ignore changes to matrix parameters. Guards and resolvers will be rerun when the path changes, when path parameters change, or when query parameters change.
The primary use case for such a mode is when updating the UI and getting the URL to be in sync with local changes. For example, if displaying a sortable table, changing the sort direction is often handled by the table itself. But you would want to update the URL to be in sync with what's being displayed to the user. As long as the table sort direction is stored as a matrix parameter, you can use this option to update the URL without causing the overhead of re-running guards and resolvers.
Related to #26861#18253
PR Close#27464
This option means guards and resolvers will ignore changes to optional
parameters such as query and matrix params. When the path or any path
params change, guards and resolvers will be run
Related to discussion in #18253
FW-560 #resolve
PR Close#26861
* Removed `andObservable` helper function in favor of inline implementation
* Flow `boolean | UrlTree` through guards check
* Add tests to verify behavior of `checkGuards` function flowing `UrlTree` properly
PR Close#26521
Alex Rickabaugh
Trevor Karjanis
Brandon
Filipe Silva
Frederik Prijck
Judy Bogart
Jason Aden
ijz953
Alan Agius
José Toledo Navarro
Maxim Mazurok
Sarun Intaralawan
Pawel Kozlowski
stoneLeaf
kevinphelps
William Neely
Karanveer Plaha
Matias Niemelä
cexbrayat
Miško Hevery
Igor Minar
miginmrs
Andrew Lobban
Pete Bacon Darwin