The localize package intentionally duplicates some logic from the
compiler to avoid adding a dependency. This is now an error in the
packaging rule to prevent common pitfalls/code duplication. Here it's
an explicit decision though so we mark it as such and ask for the check
to be ignored for the particular import.
PR Close#51500
PR Close#51558
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
The easiest way to access route data is now to use direct bindings to
component inputs rather than going through `ActivatedRoute`.
The tour of heroes guide still uses `ActivatedRoute` for now. I was
hesitant to remove all of the content in one swoop and the tour of
heroes is quite a bit more involved.
PR Close#49633
As mentioned in #46021, `canMatch` guards can replace `canLoad`. There
are slight differences between the two but the purpose of preventing
user access to feature modules is still achievable. There are several
reasons keeping `CanLoad` around is detrimental to the API surface:
* 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 directly specifically control whether to lazy load something or
not based on conditions such as authentication. This slightly
different from the `canMatch` guard: the guard controls 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 `canMatch` 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.
* Unnecessary API surface bloat where two features (CanMatch and CanLoad) do
essentially the same thing. This affects code size for supporting two
nearly identical features as well as the learning and teaching journey
for them both.
* `CanLoad` guards have the downside of _only_ being run once to prevent
loading child routes. Once that passes and children are loaded, the
guard never runs again. As a result, developers need to always provide
_both_ canLoad and a canActivate in case the answer to the guard flips
back to `false`. This is not the case for `canMatch`, which will run
on every navigation.
DEPRECATED: CanLoad guards in the Router are deprecated. Use CanMatch
instead.
PR Close#48180
* Update extractedUrl documentation to point to the correct extract method
* Remove authService.redirectUrl from tour of heroes (it's not used anywhere)
PR Close#48009
These changes include
- Remove the usage of `enableProdMode`
- Remove `test.ts`, `polyfills.ts`, `karma.conf.js` and environment files which are no longer generated by default
PR Close#47904
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
Fixes issue #45769
Removes the malevolent comic book character, "Narco," from the list of heroes. This change removes the reference from the code, text and screenshots used in the documentation and makes other minor edits as necessary.
PR Close#46008
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
.substr() is deprecated so we replace it with functions which work similarily but aren't deprecated
Signed-off-by: Tobias Speicher <rootcommander@gmail.com>
PR Close#45397
The router used to wait for the resolvers to complete and take the last
value. The changes here take only the first
emitted value of every resolver and proceed the navigation. This matches
how other guards work in the `Router` code.
Resolves https://github.com/angular/angular/issues/44643
BREAKING CHANGE: Previously, resolvers were waiting to be completed
before proceeding with the navigation and the Router would take the last
value emitted from the resolver.
The router now takes only the first emitted value by the resolvers
and then proceeds with navigation. This is now consistent with `Observables`
returned by other guards: only the first value is used.
PR Close#44573
developers should not access the router-outlet directive in their
template before defining a template variable for it, such
implementation is present in a couple of aio guides, fix such guides
so that they show the more correct way of accessing the outlet's data
resolves#36173
PR Close#45140
add types to all the buttons in the angular.io examples to encourage
the best practice of always including a type per button (regardless
to whether it is in a form or now)
PR Close#44557
the aio examples have various eslint issues regarding template rules, those
are currently turned off and TODO comments have been added to them in the
examples eslintrc, fix such issues and remove the respective TODO comments
this also includes examples refactoring to use buttons for better accessibility,
this change tries to make the smallest amound of changes to the examples' behaviors
and designs/UI
PR Close#44557
This commit provides a service, `PageTitleStrategy` for setting
the document page title after a successful router navigation.
Users can provide custom strategies by extending `TitleStrategy` and
adding a provider which overrides it.
The strategy takes advantage of the pre-existing `data` and `resolve` concepts
in the Router implementation:
We can copy the `Route.title` into `data`/`resolve` in a
non-breaking way by using a `symbol` as the key. This ensures that we
do not have any collisions with pre-existing property names. By using
`data` and `resolve`, we do not have to add anything more to
the router navigation pipeline to support this feature.
resolves#7630
PR Close#43307
change variable name 'next' to 'route' in route guards examples on developer guides "Routing and Navigation Tutorial: Adding routing to Tour of Heroes" to make it consistent with api docs and subsequent examples.
Fixes#44291
PR Close#44444
This commit enable the `noImplicitOverride` and
`noPropertyAccessFromIndexSignature` TypeScript compiler options for
docs examples to better align with the default configuration of new
Angular CLI apps. It also makes the necessary changes to the docs
examples source code.
PR Close#43880
https://developer.mozilla.org/en-US/docs/Web/CSS/font-family
"You should always include at least one generic family name in a font-family list,
since there's no guarantee that any given font is available. This lets the browser
select an acceptable fallback font when necessary."
PR Close#40254
This commit disables the Selenium Promise Manager when running e2e tests
for docs examples in order to more closely align them with new apps
created with CLI v11. This change requires that any async operations in
tests are handled explicitly (e.g. using `async/await` or
`Promise#then()`).
PR Close#39818
This commit updates the docs examples to be compatible with the
`prefer-const` tslint rule.
This is in preparation of updating the docs examples `tslint.json` to
match the one generated for new Angular CLI apps in a future commit.
PR Close#38143
This commit updates the docs examples to be compatible with the
`no-string-literal`, `object-literal-key-quotes` and
`object-literal-shorthand` tslint rules.
This is in preparation of updating the docs examples `tslint.json` to
match the one generated for new Angular CLI apps in a future commit.
PR Close#38143
This commit updates the docs examples to be compatible with the
`semicolon` tslint rule.
This is in preparation of updating the docs examples `tslint.json` to
match the one generated for new Angular CLI apps in a future commit.
PR Close#38143
This commit updates the docs examples to be compatible with the `align`,
`space-before-function-paren` and `typedef-whitespace` tslint rules.
This is in preparation of updating the docs examples `tslint.json` to
match the one generated for new Angular CLI apps in a future commit.
PR Close#38143
This commit updates the docs examples to be compatible with the
`import-spacing` tslint rule.
This is in preparation of updating the docs examples `tslint.json` to
match the one generated for new Angular CLI apps in a future commit.
PR Close#38143
The wildcard example leads to display a 404 page with the PageNotFoundComponent. But before, there is a wildcard to redirect to the FirstComponent and because of the routes order the FirstComponent will be displayed; which it is not the target of the wildcard route example code. Also, fixing some wildcard docregions
PR Close#37127
The current implementation for redirecting users inside guards was in place
before the feature was added to allow `CanActivate` and `CanActivateChild` guards
to return `UrlTree` for redirecting users.
Returning `UrlTree` should be the default method, as it provides a more desirable
redirecting experience. When using `router.navigate` followed by `return false`,
the `Router` calls `resetUrlToCurrentUrlTree` (in the `finalize` operator) before
processing the navigation to the new route. This can result in an undesirable
history if the navigation was the first navigation in the application - that is,
the route will briefly be reset to just `/` (see #36187).
Fixes#36187
PR Close#37100
This rewrite changes headings to focus on user tasks rather than features,
verifies that content is up-to-date and complete, removes colloquial phrases,
adds prerequisites, and expands on a task-based section in the beginning
(a quick reference).
PR Close#35566
Previously, only e2e tests were run for docs examples on CI. As a
result, unit tests (which are included in the zipped archives we provide
for users to download and play with the examples locally) were often
outdated and broken.
This commit configures specific docs examples that have meaningful unit
tests to run them on CI (via the `run-example-e2e.js` script). Where
necessary, the unit tests are fixed to ensure they pass and reflect the
changes in the corresponding component/service.
This commit also removes some auto-generated unit tests that are not
meaningful (e.g. make trivial assertions, such that a component instance
is truthy) and are often broken anyway (e.g. because the corresponding
component has been changed in ways that make the tests fail).
PR Close#36143
Previously, the example in the `router` guide was not
preserving the query params after logging in.
This commit fixes this by using `navigate` instead of
using `navigateByUrl`, which ignores any properties in
the `NavigationExtras` that would change the provided URL.
Fixes 34917
PR Close#35176
The StackBlitz API (which we use to generate StackBlitz projects on the
fly, when a user clicks on a live example link in the docs) allows
specifying the file to open in the editor by passing a query param. If
no file is specified, StackBlitz opens a default one. In the past, it
used to be `main.ts` and nowadays it seems to be `app.component.ts`.
StackBlitz builder, the tool that we use to generate the StackBlitz
projects, allows specifying the primary file by setting the `file`
property in the corresponding `stackblitz.json`.
Previously, if the `file` property was not set, StackBlitz builder would
not specify a file, thus falling back on StackBlitz's default behavior.
This was not great, because the default behavior may change unexpectedly
is the future to something that is less useful for our users.
This commit change StackBlitz builder to always specify a primary file.
If no file is specified in `stackblitz.json`, the builder will look
for the first file that exists in the example from a list of predefined
files.
Partially addresses #22357.
PR Close#34553
