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
When a Content Security Policy is defined that uses trusted-types in an application that uses lazy chunk files, ng
serve will be broken as angular#bundler entry needs to be added to
Content Security Policy.
Fixes#44647
PR Close#45450
In the example, @ContentChild is used in app.component.ts but the component we want to project content into is example-zippy.component.ts.
PR Close#45828
change the alerts present in the docs to callouts so
that their header can be properly rendered
(since alters don't support have headers)
PR Close#46262
This commit updates the releasing/versioning doc on angular.io to cover the
new "Developer Preview" concept. This replaces the old section on the no-
longer-relevant "Angular Labs".
PR Close#46050
change the alert present in the lifecycicle-hook docs to a callout so
that its header can be properly rendered (since alters don't support have headers)
PR Close#46145
the symbol `…` displays correctly in code-example blocks and in
plain html text, it does however not work correctly for code espressed
using backticks, fix such occurrences by replacing `…` with `...`
PR Close#46123
tweak the current structural directives guide (currently mainly targeted
at the creation of custom structural directives) so that is more generic
and a point of reference for structural directives in general
this also includes the re-addition of the one-per-element section
removed in PR #40015resolves#44786
PR Close#44895
Add a new page in developers guide section with the general
overview of the standalone components, directives and pipes
Additional APIs (bootstrapApplication, router, DI) as also
covered.
PR Close#46058
DEPRECATED:
The `initialValueIsDefault` option has been deprecated and replaced with the otherwise-identical `nonNullable` option, for the sake of naming consistency.
Some CLI versions (such as `@next`) are not parsed (and thus not
formatted) correctly in code snippets. Fix this by explicitly adding an
appropriate CSS class to the `<aio-angular-dist-tag>` elements to let
PrettyPrint know how to style this token.
PR Close#46020
Document updated with the assistance of the SME.
Add missing prerequisites and what's next sections
Make suggested changes to Event binding doc.
PR Close#45897
New binding overview doc. Content derived from existing docs.
Make changes suggested in PR for binding overview doc.
Deleted bottom paragraph from Binding overview per comments made by
atscott and alxhub.
PR Close#45897
New Transforming data with pipes document.
Content taken from the original Pipes document.
Content edited with the assistance of the SME.
PR Close#45897
New overview file using the Understanding… format.
The original Pipes document was considered too long and
was broken down into several separate topics.
Content edited with the assistance of the SME.
PR Close#45897
Class and style binding was pulled out of Attribute, class, and style
binding doc and put in its own doc.
Content edited with the assistance of the SME.
Prerequisites and What's next sections were added.
PR Close#45897
