Rather than the navigation transitions managing Router state, this
commit updates the Router to manage its own state based on ongoing
transition events. In the future, this can be abstracted even further to
have a totally separate class that manages the Router state. This would
allow the potential for swapping state manager implementations rather
than having to implement all types of state management in a single place.
One finding during tests was that unexpected errors thrown by the state management code moved
to the Router here will no longer be caught by the transition pipe's `catchError`.
This only includes calls to the following public Api methods:
* `go`, `replaceState`, `historyGo`, `isCurrentPathEqualTo` on `Location`
* `UrlSerializer.serialize`
* `UrlHandlingStrategy.merge`.
None of these methods should throw if the router is expected to function.
These might throw when tests include incomplete mocks, which is not
supported, or in cases where the actual browser methods like
`replaceState` would throw. This will already result in unexpected/unsupported
behavior. The failure case here is now arguably better - the navigation
itself still completes but the state update (either updating Router
internal state or updating the browser URL) fails separately and is
unhandled.
PR Close#48427
Setting the page ID is currently broken for the first page because the
helper method's second parameter is optional, which allowed the initally
`undefined` page ID to be used again when the router performs its
initial navigation.
fixes#50983
PR Close#51441
Angular 16.1 introduced the input transform feature, requiring the partial compilation output to be extended
with a reference to the input transform function. This has resulted in a subtle breaking change, where older
versions of the Angular linker can no longer consume libraries that have started to use this feature.
We do try to support using a 16.1 library from an Angular 16.0 application, but if a library actually
adopts a new feature then this is no longer possible. In such cases, it is desirable to report a message
telling the user that their version of the Angular compiler is too old, as determined by the `"minVersion"`
property that is present in each partial declaration. This version would still indicate that the declaration
required at least Angular 14.0 to be compiled, but this is not accurate once input transforms are being
used. Consequently, this error would not be reported, causing a less informative error once the input transform
was being observed.
Fixes#51411
PR Close#51413
The example for clearing secondary outlets currently only works because
the named outlet appears at the root of the application's route config.
If developers follow this example with an outlet that is not at the
root level, they will not be able to close the outlet.
This commit updates the example to provide a more robust way
of clearing the outlet from the activated outlet component
as well as providing a warning about how the commands are applied.
Lastly, there is a small bit of guidance provided for developers who
might want to explore the ability to close an outlet from any location
in the app, without needing to be aware of the activated route.
An example of this can be found here:
https://stackblitz.com/edit/close-outlet-from-anywhereresolves#51373resolves#13523
PR Close#51376
This adds a section to cover the case of CDNs that have optimizations that will break both Angular and Hydration by stripping comment nodes.
PR Close#51355
Empty path routes are effectively 'passthrough' routes that do not
appear in the URL. When these exist in the route tree, we do not want to
apply named outlet commands to that tree location. Instead, we skip past
this location in the tree, effectively squashing/removing this
passthrough route from the tree.
fixes#50356
PR Close#51292
The documentation incorrectly stated that the app.module.ts file is generated
when the --standalone flag is used. This is not the case, and the documentation
should accurately reflect the behavior.
Closes#51306
PR Close#51307
A minor error is present within the documentation. Specifically, in the documentation for the CanActivateFn function, a reference is made to the CanActivateChildFn function. However, it appears that the CanActivateChildFn function is not utilized or referenced elsewhere in the documentation of CanActivateFn.
PR Close#51283
Andrew Kushnir