Some users are woried about `$any()` as function calls are to be avoided in templates. This sentence clarifies the situation.
fixes#48781
PR Close#48785
PNG converted to base64 don't work on stackblitz.
As stackblitz does't support binary files for dynamicaly created projects, we now use only svgs.
Fixes: #48773
PR Close#48774
- Update Chrome supported version description to match other browsers.
- Updates browserslist configuration in build section to match supported browsers
PR Close#48782
docs: Document extracted from the original Introduction document, which is to be retired. Linting suggested corrections made. Restructuring or rewording sentences to be shorter and clearer.
docs: revised understanding doc and pullapprove.yml
PR Close#47906
In Angular CLI 15.1 new sub commands to generate configuration and environments files were added. This commit updates several docs to mention these commands.
Closes#48364
PR Close#48757
Class and `InjectionToken`-based guards and resolvers are not as configurable,
are less re-usable, require more boilerplate, cannot be defined inline with the route,
and require more in-depth knowledge of Angular features (`Injectable`/providers).
In short, they're less powerful and more cumbersome.
In addition, continued support increases the API surface which in turn increases
bundle size, code complexity, the learning curve and API surface to teach,
maintenance cost, and cognitive load (needing to grok several different types
of information in a single place).
Lastly, supporting only the `CanXFn` types for guards and `ResolveFn` type
for resolvers in the `Route` interface will enable better code
completion and integration with TypeScript. For example, when writing an
inline functional resolver today, the function is typed as `any` and
does not provide completions for the `ResolveFn` parameters. By
restricting the type to only `ResolveFn`, in the example below
TypeScript would be able to correctly identify the `route` parameter as
`ActivatedRouteSnapshot` and when authoring the inline route, the
language service would be able to autocomplete the function parameters.
```
const userRoute: Route = {
path: 'user/:id',
resolve: {
"user": (route) => inject(UserService).getUser(route.params['id']);
}
};
```
Importantly, this deprecation only affects the support for class and
`InjectionToken` guards at the `Route` definition. `Injectable` classes
and `InjectionToken` providers are _not_ being deprecated in the general
sense. Functional guards are robust enough to even support the existing
class-based guards through a transform:
```
function mapToCanMatch(providers: Array<Type<{canMatch: CanMatchFn}>>): CanMatchFn[] {
return providers.map(provider => (...params) => inject(provider).canMatch(...params));
}
const route = {
path: 'admin',
canMatch: mapToCanMatch([AdminGuard]),
};
```
With regards to tests, because of the ability to map `Injectable`
classes to guard functions as outlined above, nothing _needs_ to change
if projects prefer testing guards the way they do today. Functional
guards can also be written in a way that's either testable with
`runInContext` or by passing mock implementations of dependencies.
For example:
```
export function myGuardWithMockableDeps(
dep1 = inject(MyService),
dep2 = inject(MyService2),
dep3 = inject(MyService3),
) { }
const route = {
path: 'admin',
canActivate: [() => myGuardWithMockableDeps()]
}
// test file
const guardResultWithMockDeps = myGuardWithMockableDeps(mockService1, mockService2, mockService3);
const guardResultWithRealDeps = TestBed.inject(EnvironmentInjector).runInContext(myGuardWithMockableDeps);
```
DEPRECATED: Class and `InjectionToken` guards and resolvers are
deprecated. Instead, write guards as plain JavaScript functions and
inject dependencies with `inject` from `@angular/core`.
PR Close#47924
This commits adds an action to update the Angular CLI help contents that are used by AIO to generate CLI guides.
This also changes the setup to include the files are source files instead of having to clone the repository each time. This also simplifies the PR review process of the PR opened by the action.
PR Close#48577
Following #24008, the schematics don't produce ngOnInit and the constructor. Let's reflect that in the Tour of Heroes tutorial.
Fixes#48575
PR Close#48576
`errorHandler` and `malformedUriErrorHandler` were already deprecated in
the Router class public API. This change updates the deprecation to
extend to `RouterModule.forRoot` configuration options.
PR Close#48551
`withNavigationErrorHandler` is a close replacement for the
`RouterModule.forRoot.errorHandler` / `Router.errorHandler`.
It provides a quick, short way for users to define a function to handle
`NavigationError` events.
PR Close#48551
- update `errors.ts` to annotate the error NG0403, so that the runtime can add a link to that guide when an error is thrown
- update `application_ref_spec.ts` to include the new link of the error
- update `errors.md` as a result of running `yarn bazel test packages/core/test`
Fixes#47985
PR Close#48483
This is basically a pre-step for combining devmode and prodmode into a
single compilation. We are already achieving this now, and can claim
with confidence that we reduced possible actions by half. This is
especially important now that prodmode is used more often, but rules
potentially still using the devmode ESM sources. We can avoid double
compilations (which existed before the whole ESM migration too!).
We will measure this more when we have more concrete documentation
of the changes & a better planning document.
Changes:
* ts_library will no longer generate devmode `d.ts`. Definitions are
generated as part of prodmode. That way only prodmode can be exposed
via providers.
* applied the same to `ng_module`.
* updates migrations to bundle because *everything* using `ts_library`
is now ESM. This is actually also useful in the future if
schematics rely on e.g. the compiler.
* updates schematics for localize to also bundle. similar reason as
above.
PR Close#48521
Since the Bazel setup in this repo will now always use ESM,
the tooling scripts/binaries in AIO need to be switched to ESM
too. Most of the scripts are already ESM, but a few had to be converted.
Note that the Dgeni generation does not use ESM because it's unaffected
and the Dgeni CLI is used. In the future we could also update the Dgeni
setup to ESM but there is no need currently.
PR Close#48521
Matthieu Riegler