diff --git a/aio/content/guide/deprecations.md b/aio/content/guide/deprecations.md index b7537e0878..09106111f4 100644 --- a/aio/content/guide/deprecations.md +++ b/aio/content/guide/deprecations.md @@ -50,7 +50,7 @@ v8 - v11 | `@angular/upgrade` | [`@angular/upgrade`](#upgrade) | v9 | | `@angular/upgrade` | [`getAngularLib`](#upgrade-static) | v9 | | `@angular/upgrade` | [`setAngularLib`](#upgrade-static) | v9 | -| template syntax | [`/deep/`, `>>>`, and `::ng-deep`](#deep-component-style-selector) | v9 | +| template syntax | [`/deep/`, `>>>`, and `::ng-deep`](#deep-component-style-selector) | unspecified | | template syntax | [`](#template-tag) | v9 | | service worker | [`versionedFiles` setting](#sw-versionedfiles)| v9 | | polyfills | [reflect-metadata](#reflect-metadata) | v9 | @@ -234,7 +234,7 @@ Reminder: If you use these `Deprecated*` pipes, you should migrate to the curren When Angular first introduced lazy routes, there wasn't browser support for dynamically loading additional JavaScript. Angular created our own scheme using the syntax `loadChildren: './lazy/lazy.module#LazyModule'` and built tooling to support it. Now that ECMAScript dynamic import is supported in many browsers, Angular is moving toward this new syntax. -In v8, the string syntax for the [`loadChildren`](api/router/LoadChildren) route specification was deprecated, in favor of new syntax that uses `import()` syntax. +In version 8, the string syntax for the [`loadChildren`](api/router/LoadChildren) route specification was deprecated, in favor of new syntax that uses `import()` syntax. Before: @@ -260,7 +260,7 @@ const routes: Routes = [{
-**v8 update**: When you update to version 8, the [`ng update`](cli/update) command performs the transformation automatically. Prior to version 7, the `import()` syntax only works in JIT mode (with view engine). +**Version 8 update**: When you update to version 8, the [`ng update`](cli/update) command performs the transformation automatically. Prior to version 7, the `import()` syntax only works in JIT mode (with view engine).
@@ -286,10 +286,88 @@ Angular applications, and specifically applications that relied on the JIT compi The need for this polyfill was removed in Angular version 8.0 ([see #14473](https://github.com/angular/angular-cli/pull/14473)), rendering the presence of the poylfill in most Angular applications unnecessary. Because the polyfill can be depended on by 3rd-party libraries, instead of removing it from all Angular projects, we are deprecating the requirement for this polyfill as of version 8.0. This should give library authors and application developers sufficient time to evaluate if they need the polyfill, and perform any refactoring necessary to remove the dependency on it. -In typical Angular project, the polyfill is not used in production builds, so deprecating it (rather than removing it) doesn't have impact on the production applications. The goal behind this removal is overall simplification of the build setup and decrease in the number of external dependencies. +In a typical Angular project, the polyfill is not used in production builds, so removing it should not impact production applications. The goal behind this removal is overall simplification of the build setup and decrease in the number of external dependencies. We expect to remove the polyfill from most if not all CLI projects via an `ng upgrade` migration from version 8 to 9. +{@a static-query-resolution} +### `@ViewChild()` / `@ContentChild()` static resolution as the default + +The API docs have always recommended searching for `ViewChild()` query results in +the `ngAfterViewInit()` hook at the earliest and searching for +`ContentChild()` query results in the `ngAfterContentInit()` hook at the earliest. + +However, in practice, `@ViewChild()` and `@ContentChild()` queries are sometimes +resolved earlier in the lifecycle (that is, before change detection runs) if the +results are not influenced by bindings (for example, some results are +embedded in an `*ngIf` or `*ngFor`). + +This default resolution behavior is deprecated. In a future version of Angular, all queries will be resolved only before their guaranteed hooks by default. + +If you do need to access the `ViewChild()` or `ContentChild()` value +before change detection runs (for example, in `ngOnInit()`), you can +use a static flag as in the following example: + +``` +@ViewChild('foo', {static: true}) foo !: ElementRef; +``` + +{@a contentchild-input-together} +### `@ContentChild()` / `@Input()` used together + +The following pattern is deprecated: + +```ts +@Input() @ContentChild(TemplateRef) tpl !: TemplateRef; +``` + +Rather than using this pattern, separate the two decorators into their own +properties and add fallback logic as in the following example: + +```ts +@Input() tpl !: TemplateRef; +@ContentChild(TemplateRef) inlineTemplate !: TemplateRef; +``` +{@a cant-assign-template-vars} +### Cannot assign to template variables + +In the following example, the two-way binding means that `optionName` +should be written when the `valueChange` event fires. + +```html +