Angular 棄用清單

2022-07-22 10:26 更新

已棄用的 API 和特性

Angular 力圖兼顧創(chuàng)新與穩(wěn)定。但有時，API 和特性已經(jīng)過時，需要進(jìn)行刪除或替換，以便 Angular 可以及時跟上新的最佳實踐、依賴項變更或者 Web 平臺自身的變化。

為了使這些轉(zhuǎn)換盡可能容易，我們在刪除這些 API 和特性之前會棄用它們一段時間。這讓你有時間將應(yīng)用程序更新為最新的 API 和最佳實踐。

本指南包含了當(dāng)前已棄用的所有 Angular API 和特性的匯總表。

索引

為幫助你的項目面向未來，下表列出了所有已棄用的 API 和特性，并按它們將被移除的候選版本進(jìn)行組織。每個項目都鏈接到本指南后面描述棄用原因和替換選項的部分。

特性區(qū)

API 或特性

將移除于
@angular/common ?ReflectiveInjector? v11
@angular/common ?CurrencyPipe ?- ?DEFAULT_CURRENCY_CODE? v11
@angular/common/http ?XhrFactory? v15
@angular/common/http/testing

TestRequest 接受 ErrorEvent 參數(shù)以進(jìn)行錯誤模擬

 v16
@angular/core ?DefaultIterableDiffer? v11
@angular/core ?ReflectiveKey? v11
@angular/core ?RenderComponentType? v11
@angular/core

?ApplicationRef.bootstrap? 的基于工廠的簽名

 v15
@angular/core ?PlatformRef.bootstrapModuleFactory? v15
@angular/core ?getModuleFactory? v16
@angular/core ?ModuleWithComponentFactories? v16
@angular/core ?Compiler? v16
@angular/core ?CompilerFactory? v16
@angular/core ?NgModuleFactory? v16
@angular/platform-browser-dynamic ?JitCompilerFactory? v16
@angular/forms

和響應(yīng)式表單一起使用 ?ngModel?

 v11
@angular/upgrade ?@angular/upgrade? v11
@angular/upgrade ?getAngularLib? v11
@angular/upgrade ?setAngularLib? v11
@angular/upgrade

?downgradeModule ?基于工廠的簽名

 v15

模板語法

 ?<template>? v11

膩子腳本

 ?reflect-metadata? v11
@angular/compiler-cli

?@Input setter? 強制類型轉(zhuǎn)換

 v15
@angular/compiler-cli ?fullTemplateTypeCheck? v15
@angular/core ?defineInjectable? v11
@angular/core ?entryComponents? v11
@angular/core ?ANALYZE_FOR_ENTRY_COMPONENTS? v11
@angular/core

?ViewContainerRef.createComponent? 基于工廠的簽名

 v15
@angular/core/testing ?TestBed.get? v12
@angular/core/testing ?async? v12
@angular/core/testing

?aotSummaries ?中的 ?TestBed.initTestEnvironment? 參數(shù)

 v14
@angular/core/testing

?TestModuleMetadata ?類型的 ?aotSummaries ?字段

 v14
@angular/forms

?FormBuilder.group? 老式選項參數(shù)

 v14
@angular/platform-server ?renderModuleFactory? v15
@angular/service-worker ?SwUpdate#activated? v16
@angular/service-worker ?SwUpdate#available? v16

模板語法

?/deep/?, ?>>>? 和 ?::ng-deep?

未指定

模板語法

?bind-?, ?on-?, ?bindon-? 和 ?ref-?

 v15

要了解 Angular CDK 和 Angular Material 的棄用情況，參閱變更記錄。

已棄用的 API

本節(jié)包含所有當(dāng)前已棄用的 API 的完整列表，其中包含一些可幫助你規(guī)劃如何遷移到其替代品的詳細(xì)信息。

@angular/common

API

替代品

聲明棄用于

備注
?CurrencyPipe ?- ?DEFAULT_CURRENCY_CODE? {provide: DEFAULT_CURRENCY_CODE, useValue: 'USD'} v9

從 v11 開始，默認(rèn)代碼將從 LOCALE_ID 給出的語言環(huán)境數(shù)據(jù)中提取，而不是 USD 。

@angular/common/http

API

替代品

聲明棄用于

備注
?XhrFactory?

@angular/common 中的 XhrFactory

v12

XhrFactory 已從 @angular/common/http 移到了 @angular/common 。

@angular/core

API

替代品

聲明棄用于

備注
?DefaultIterableDiffer? n/a v4

不再是公共 API。
?ReflectiveInjector? Injector.create() v5

參見下文的 ?ReflectiveInjector?
?ReflectiveKey?

無

 v5

無
?defineInjectable? ??defineInjectable v8

僅在生成的代碼中使用。任何源代碼都不應(yīng)依賴此 API。
?entryComponents?

無

 v9

參見下文的 ?entryComponents?
?ANALYZE_FOR_ENTRY_COMPONENTS?

無

 v9

參見下文的 ?ANALYZE_FOR_ENTRY_COMPONENTS?
?async? ?waitForAsync? v11

來自 @angular/core/testing 的?async?函數(shù)已重命名為 waitForAsync 以避免與原生 JavaScript async 語法混淆。現(xiàn)有特性已棄用，將在未來版本中刪除。
?getModuleFactory? ?getNgModuleById? v13

Ivy 允許直接使用 NgModule 類，而無需檢索相應(yīng)的工廠。
ViewChildren.emitDistinctChangesOnly / ContentChildren.emitDistinctChangesOnly

無（是問題 #40091的一部分）

這是作為問題 #40091的錯誤修復(fù)的一部分引入的臨時標(biāo)志，將被刪除。

?ApplicationRef.bootstrap?的基于工廠的簽名

?ApplicationRef.bootstrap?的基于類型的簽名

 v13

有了 ivy，不需要解析 Component factory，直接提供 Component Type 即可。
?PlatformRef.bootstrapModuleFactory ? ?PlatformRef.bootstrapModule? v13

有了 ivy，就不需要解析 NgModule factory，直接提供 NgModule Type 即可。
?ModuleWithComponentFactories ?

無

 v13

Ivy JIT 模式不需要訪問這個符號。
?Compiler?

無

 v13

Ivy JIT 模式不需要訪問這個符號。
?CompilerFactory?

無

 v13

Ivy JIT 模式不需要訪問這個符號。
?NgModuleFactory?

使用基于非工廠的框架 API，如PlatformRef.bootstrapModule?和?createNgModuleRef?

 v13

Ivy JIT 模式不需要訪問這個符號。

?ViewContainerRef.createComponent? 基于工廠的簽名

?ViewContainerRef.createComponent? 基于類型的簽名

 v13

Angular 不再需要組件工廠來動態(tài)創(chuàng)建組件。使用 createComponent 方法的不同簽名，允許直接傳遞 Component 類。

@angular/core/testing

API

替代品

聲明棄用于

備注
?TestBed.get? ?TestBed.inject? v9

行為沒變，但類型安全。
?async? ?waitForAsync? v10

行為相同，只是改名以免混淆。

?aotSummaries ?中的 ?TestBed.initTestEnvironment? 參數(shù)

無需更換

 v13

Ivy 中不使用摘要文件。

?TestModuleMetadata ?類型的 ?aotSummaries ?字段

無需更換

 v13

Ivy 中未使用摘要文件。

@angular/platform-browser-dynamic

API

替代品

聲明棄用于

備注
?JitCompilerFactory?

無

 v13

不再需要此符號。

@angular/platform-server

API

替代品

聲明棄用于

備注
?renderModuleFactory? ?renderModule? v13

不再需要此符號。

@angular/forms

API

替代品

聲明棄用于

備注

?ngModel ?與響應(yīng)式表單一起使用

 ?FormControlDirective? v6

無

?FormBuilder.group? 老式選項參數(shù)

?AbstractControlOptions ?參數(shù)值

 v11

無

@angular/service-worker

API

替代品

聲明棄用于

備注
?SwUpdate#activated?

?SwUpdate#activateUpdate()? 的返回值

 v13

SwUpdate#activateUpdate() 的返回值指示更新是否成功激活。
?SwUpdate#available? ?SwUpdate#versionUpdates? v13

SwUpdate#available 的行為可以通過過濾?SwUpdate#versionUpdates?上的 VersionReadyEvent 事件來重建

@angular/upgrade

API

替代品

聲明棄用于

備注

所有入口點

?@angular/upgrade/static? v5

參閱從 AngularJS 升級。

@angular/upgrade/static

API

替代品

聲明棄用于

備注
?getAngularLib? ?getAngularJSGlobal? v5

參閱從 AngularJS 升級。
?setAngularLib? ?setAngularJSGlobal? v5

參閱從 AngularJS 升級。

?downgradeModule ?基于工廠的簽名

?downgradeModule ?基于 NgModule 的簽名

 v13

downgradeModule 支持更符合人體工程學(xué)的基于 NgModule 的 API（相對于基于 NgModule 工廠的 API）。

已棄用的特性

本部分列出了所有當(dāng)前已棄用的特性，其中包括模板語法、配置選項以及上述已棄用 API部分中未列出的任何其他棄用特性。它還包括已棄用的 API 使用場景或 API 組合，以作為上述信息的補充。

Bazel 構(gòu)建器和原理圖

Angular Labs 中引入了 Bazel 構(gòu)建器和原理圖，讓用戶無需管理 Bazel 版本和 BUILD 文件即可試用 Bazel。此特性已被棄用。

Web 跟蹤框架集成

Angular 以前支持與Web 跟蹤框架 (WTF)集成，以對 Angular 應(yīng)用程序進(jìn)行性能測試。此集成未經(jīng)維護(hù)，現(xiàn)已失效。因此，該集成在 Angular 版本 8 中被棄用，并且由于沒有任何現(xiàn)有使用的證據(jù)，因此在版本 9 中被刪除。

/deep/ 、 >>> 和 ::ng-deep 組件樣式選擇器

這類 shadow-dom-piercing 后代組合器已棄用，并且正在從主要瀏覽器和工具中刪除支持。因此，在 v4 中，我們棄用了 Angular 對 ?/deep/? 、 ?>>>? 和 ?::ng-deep? 三個的支持。在正式移除之前， ?::ng-deep? 是首選，因為它與工具具有更廣泛的兼容性。

bind- 、 on- 、 bindon- 和 ref- 前綴

模板前綴 ?bind-? 、 ?on-? 、 ?bindon-? 和 ?ref-? 在 v13 中已被棄用。模板應(yīng)該使用更廣為人知的語法進(jìn)行綁定和引用：

  • ?[input]="value"? 代替 ?bind-input="value" ?
  • ?[@trigger]="value"? 代替 ?bind-animate-trigger="value" ?
  • ?(click)="onClick()"? 代替 ?on-click="onClick()" ?
  • ?[(ngModel)]="value"? 代替 ?bindon-ngModel="value" ?
  • ?#templateRef? 代替 ?ref-templateRef?

<template> 標(biāo)簽

?<template>? 標(biāo)簽在 v4 中已被棄用，以避免與 DOM 的同名元素發(fā)生沖突（例如在使用 Web 組件時）。使用 ?<ng-template>? 代替。

和響應(yīng)式表單一起使用 ngModel

在 Angular v6 中已不推薦把 ?ngModel ?輸入屬性、?ngModelChange ?事件與響應(yīng)式表單指令一起使用，并將在 Angular 的未來版本中刪除。

現(xiàn)在已經(jīng)棄用：

<input [formControl]="control" [(ngModel)]="value">
this.value = 'some value';

出于多種原因，此支持已被棄用。首先，開發(fā)人員發(fā)現(xiàn)這種模式令人困惑。似乎正在使用實際的 ?ngModel ?指令，但實際上它是響應(yīng)式表單指令上名為 ?ngModel ?的輸入/輸出屬性，它模擬了該指令的一些行為，但又不完全一樣。它允許獲取和設(shè)置值并攔截值事件，但 ?ngModel ?的一些其他特性，例如使用 ?ngModelOptions ?延遲更新或?qū)С鲋噶?，不起作用?/p>

另外，該模式混用了模板驅(qū)動和響應(yīng)式這兩種表單策略，這會妨礙我們獲取任何一種策略的全部優(yōu)點。 在模板中設(shè)置值的方式，也違反了響應(yīng)式表單所遵循的“模板無關(guān)”原則；反之，在類中添加 ?FormControl?/?FormGroup ?層也破壞了“在模板中定義表單”的約定。

要在移除支持之前更新你的代碼。你需要決定是堅持使用響應(yīng)式表單指令（并使用響應(yīng)式表單模式來獲取/設(shè)置值）還是切換到模板驅(qū)動表單指令。

之后（選擇 1 - 使用響應(yīng)式表單）：

<input [formControl]="control">
this.control.setValue('some value');

之后（選擇 2 - 使用模板驅(qū)動表單）：

<input [(ngModel)]="value">
this.value = 'some value';

默認(rèn)情況下，當(dāng)你使用此模式時，你將在開發(fā)模式下看到一次棄用警告。你可以通過在導(dǎo)入時配置 ?ReactiveFormsModule ?來選擇消除此警告：

imports: [
  ReactiveFormsModule.withConfig({warnOnNgModelWithFormControl: 'never'})
],

或者，你可以選擇為該模式的每個實例顯示一個單獨的警告，配置值為 ?"always"? 。這可能有助于在更新代碼時跟蹤代碼中使用模式的位置。

ReflectiveInjector

在 v5 中，Angular 用 ?StaticInjector ?代替了 ?ReflectiveInjector?。該注入器不再需要 Reflect 的膩子腳本，對大部分開發(fā)人員來說都顯著減小了應(yīng)用的體積。

之前：

ReflectiveInjector.resolveAndCreate(providers);

之后：

Injector.create({providers});

loadChildren 字符串語法

當(dāng) Angular 第一次引入惰性路由時，還沒有瀏覽器能支持動態(tài)加載額外的 JavaScript。因此 Angular 創(chuàng)建了自己的方案，所用的語法是 ?loadChildren: './lazy/lazy.module#LazyModule'? 并且還構(gòu)建了一些工具來支持它?，F(xiàn)在，很多瀏覽器都已支持 ECMAScript 的動態(tài)導(dǎo)入，Angular 也正朝著這個新語法前進(jìn)。

在版本 8 中，不推薦使用 ?loadChildren ?路由規(guī)范的字符串語法，而是改用基于 ?import()? 的新語法。

之前：

const routes: Routes = [{
    path: 'lazy',
    // The following string syntax for loadChildren is deprecated
    loadChildren: './lazy/lazy.module#LazyModule',
  }];

之后：

const routes: Routes = [{
    path: 'lazy',
    // The new import() syntax
    loadChildren: () => import('./lazy/lazy.module').then(m => m.LazyModule)
  }];

版本 8 更新：當(dāng)你更新到版本 8 時， ?ng update? 命令會自動執(zhí)行轉(zhuǎn)換。在版本 7 之前， ?import()? 語法僅適用于 JIT 模式（使用視圖引擎）。

聲明語法：遵循路由聲明語法 ?loadChildren: () => import('...').then(m => m.ModuleName)? 很重要，這樣 ?ngc ?才能發(fā)現(xiàn)惰性加載的模塊和關(guān)聯(lián)的 ?NgModule ?。你可以在此處找到允許的語法結(jié)構(gòu)的完整列表。這些限制將隨著 Ivy 的發(fā)布而放寬，因為它將不再使用 ?NgFactories ?。

JIT 模式下對反射元數(shù)據(jù) polyfill 的依賴

Angular 應(yīng)用程序，特別是依賴于 JIT 編譯器的應(yīng)用程序，過去常常需要 reflect-metadata API 的膩子腳本。

在 Angular 8.0 版（見#14473 ）中移除了對這個膩子腳本的需求，這將使得大多數(shù) Angular 應(yīng)用程序不再需要此膩子腳本。因為此膩子腳本可能被第三方庫依賴，因此不能從所有 Angular 項目中刪除它，我們從 8.0 版本開始棄用對這個膩子腳本的要求。這樣可以給庫作者和應(yīng)用程序開發(fā)人員足夠的時間來評估他們是否需要此膩子腳本，并執(zhí)行任何必要的重構(gòu)以消除對它的依賴。

在典型的 Angular 項目中，這個膩子腳本不用于生產(chǎn)版本，因此刪除它不會影響生產(chǎn)環(huán)境的應(yīng)用程序。刪除它是為了從整體上上簡化構(gòu)建設(shè)置并減少外部依賴項的數(shù)量。

@ViewChild() / @ContentChild() 默認(rèn)使用靜態(tài)解析

在版本 9 中，?@ViewChild? 和 ?@ContentChild? 這兩個查詢的默認(rèn)設(shè)置會改變，以修復(fù)查詢中的 BUG 和意外行為。

為了應(yīng)對這個變化，我們從版本 8 開始就要開始遷移所有應(yīng)用和庫，顯式指定 ?@ViewChild? 和 ?@ContentChild? 查詢的解析策略。

具體來說，這次遷移會添加一個顯式的 “static” 標(biāo)志，用來指出應(yīng)該何時對該查詢的結(jié)果進(jìn)行賦值。等升級到版本 9 的時候，這個標(biāo)志可以確保這些代碼的工作方式都是一樣的。

之前：

// query results sometimes available in `ngOnInit`, sometimes in `ngAfterViewInit` (based on template)
@ViewChild('foo') foo: ElementRef;

之后：

// query results available in ngOnInit
@ViewChild('foo', {static: true}) foo: ElementRef;

OR

// query results available in ngAfterViewInit
@ViewChild('foo', {static: false}) foo: ElementRef;

從版本 9 開始，?static ?標(biāo)志將默認(rèn)為 ?false?。那時候，可以安全地刪除所有 ?{static: false}? 標(biāo)志，而且我們還會提供一個能幫你更新代碼的原理圖（schematic）。

注意：這個標(biāo)志只適用于 ?@ViewChild? 和 ?@ContentChild? 這兩個查詢，這是因為 ?@ViewChildren? 和 ?@ContentChildren? 查詢都沒有靜態(tài)和動態(tài)的概念（它們總是“動態(tài)”解析）。

@ContentChild() / @Input() 一起使用

以下模式已棄用：

@Input() @ContentChild(TemplateRef) tpldeprecated !: TemplateRef<any>;

不要再使用此模式，而應(yīng)該將這兩個裝飾器分離到它們各自的屬性中并添加回退邏輯，如下例所示：

@Input() tpl !: TemplateRef<any>;
@ContentChild(TemplateRef) inlineTemplate !: TemplateRef<any>;

無法賦值給模板變量

在以下示例中，雙向綁定意味著應(yīng)在 ?valueChange ?事件觸發(fā)時寫入 ?optionName ?。

<option *ngFor="let optionName of options" [(value)]="optionName"></option>

然而，在實踐中，Angular 忽略了對模板變量的雙向綁定。從版本 8 開始，不推薦對模板變量賦值。在未來的版本中，我們將拋出錯誤以指出不支持寫入。

<option *ngFor="let optionName of options" [value]="optionName"></option>

在 platform-server 中綁定到 innerText

在服務(wù)器端渲染中使用的 Domino 不支持 ?innerText?，因此在平臺服務(wù)器中的 “domino 適配器”中，如果嘗試綁定到 ?innerText?，則有一些特殊代碼可以退回到 ?textContent?。

這兩個屬性有細(xì)微的差別，因此在幕后切換到 ?textContent ?可能會讓用戶感到驚訝。出于這個原因，我們棄用了這種行為。展望未來，用戶應(yīng)該在使用 Domino 時顯式綁定到 ?textContent ?。

wtfStartTimeRange 和所有 wtf* API

所有 ?wtf*? API 均已棄用，并將在未來版本中刪除。

不再需要 entryComponents 和 ANALYZE_FOR_ENTRY_COMPONENTS

以前， ?NgModule ?定義中的 ?entryComponents ?數(shù)組用于告訴編譯器將動態(tài)創(chuàng)建和插入哪些組件。使用 Ivy 后，這不再是必需的，并且可以從現(xiàn)有模塊聲明中刪除 ?entryComponents ?數(shù)組。這同樣適用于 ?ANALYZE_FOR_ENTRY_COMPONENTS ?注入令牌。

注意：如果構(gòu)建將由 View Engine 應(yīng)用程序使用的庫，你可能仍需要保留它們。

不帶泛型的 ModuleWithProviders 類型

一些 Angular 庫，例如 ?@angular/router? 和 ?@ngrx/store? ，實現(xiàn)的 API 返回名為 ModuleWithProviders 的類型（通常使用名為 ?ModuleWithProviders ??forRoot()? 的方法）。這種類型代表一個 ?NgModule ?以及其他提供者。 Angular 版本 9 已棄用沒有明確泛型類型的 ?NgModule ??ModuleWithProviders ?類型。在 Angular 的未來版本中，泛型將不再是可選的。

如果你使用的是 CLI，則 ?ng update? 應(yīng)該會自動遷移代碼。如果沒有使用 CLI，則可以將任何缺失的泛型類型手動添加到應(yīng)用程序中。例如：

之前

@NgModule({
/* ... */
})
export class MyModule {
  static forRoot(config: SomeConfig): ModuleWithProviders {
    return {
      ngModule: SomeModule,
      providers: [
        {provide: SomeConfig, useValue: config}
      ]
    };
  }
}

之后：

@NgModule({
/* ... */
})
export class MyModule {
  static forRoot(config: SomeConfig): ModuleWithProviders<SomeModule> {
    return {
      ngModule: SomeModule,
      providers: [
        {provide: SomeConfig, useValue: config}
      ]
    };
  }
}

輸入 setter 強制類型轉(zhuǎn)換

由于在 Angular 中引入了 ?strictTemplates ?標(biāo)志，編譯器已經(jīng)能夠根據(jù)相應(yīng)指令的聲明輸入類型對輸入綁定進(jìn)行類型檢查。當(dāng) “getter/setter 對”用于輸入時，可能需要讓 setter 接受比 getter 返回的類型更寬泛的類型集，例如當(dāng) setter 首次轉(zhuǎn)換輸入值時。然而，在 TypeScript 4.3 之前，需要 getter/setter 對具有相同的類型，因此無法準(zhǔn)確地聲明此模式。

為了減輕這種限制，可以在對輸入綁定進(jìn)行類型檢查時用到的指令中聲明輸入 setter 強制類型轉(zhuǎn)換字段。但是，從 TypeScript 4.3 開始，此限制已被移除； setter 現(xiàn)在可以接受比 getter 返回的類型更寬泛的類型。這意味著不再需要輸入強制類型轉(zhuǎn)換字段，因為它們的效果可以通過拓寬 setter 的類型來實現(xiàn)。

例如，以下指令：

@Component({
})
export class SubmitButtonComponent {
  static ngAcceptInputType_disabled: boolean|'';

  private disabledValue = false;

  @Input()
  get disabled(): boolean {
    return this.disabledValue;
  }
  set disabled(value: boolean) {
    this.disabledValue = (value === '') || value;
  }
}

可以重構(gòu)如下：

@Component({
})
export class SubmitButtonComponent {
  private disabledValue = false;

  @Input()
  get disabled(): boolean {
    return this.disabledValue;
  }

  set disabled(value: boolean|'') {
    this.disabledValue = (value === '') || value;
  }
}

fullTemplateTypeCheck

使用 AOT 編譯器編譯你的應(yīng)用程序時，你的模板會根據(jù)特定的嚴(yán)格級別進(jìn)行類型檢查。在 Angular 9 之前，?fullTemplateTypeCheck ?編譯器選項只支持兩個嚴(yán)格級別的模板類型檢查。在版本 9 中引入了 ?strictTemplates ?系列編譯器選項，作為一種更細(xì)粒度的方法來配置模板的類型檢查的嚴(yán)格程度。

?fullTemplateTypeCheck ?標(biāo)志已被棄用，取代它的是新的 ?strictTemplates ?選項及其相關(guān)的編譯器選項。當(dāng)前已配置為 ?fullTemplateTypeCheck: true? 的項目可以遷移到以下編譯器選項集以實現(xiàn)相同級別的類型檢查：

{
  "angularCompilerOptions": {
    ...
    "strictTemplates": true,
    "strictInputTypes": false,
    "strictNullInputTypes": false,
    "strictAttributeTypes": false,
    "strictOutputEventTypes": false,
    "strictDomEventTypes": false,
    "strictDomLocalRefTypes": false,
    "strictSafeNavigationTypes": false,
    "strictContextGenerics": false,
    ...
  }
}

由于 ViewEngine 棄用而導(dǎo)致的 JIT API 更改

在 ViewEngine 中， JIT 編譯需要在應(yīng)用程序中注入特殊的提供者（如 ?Compiler?、?CompilerFactory ?等）并調(diào)用相應(yīng)的方法。使用 Ivy，如果 Component、NgModule 等尚未進(jìn)行 AOT 編譯 ，則 JIT 編譯會隱式進(jìn)行。這些特殊的提供者在 Ivy 中仍然可用，以便與 ViewEngine 向后兼容，從而使向 Ivy 的過渡更加順暢。由于 ViewEngine 已被棄用并將很快被刪除，因此這些符號現(xiàn)在也已被棄用。

重要說明：此棄用不會影響 Ivy 中的 JIT 模式（JIT 在 Ivy 中仍然可用，但是我們正在探索將來棄用它的可能性。請參閱 RFC：Angular JIT 編譯模式的用例探索）。

TestRequest 接受 ErrorEvent 參數(shù)

Angular 提供了一些用于測試 ?HttpClient ?的實用工具。 ?@angular/common/http/testing? 中的 ?TestRequest ?類會模擬 HTTP 請求對象以與 ?HttpTestingController? 一起使用。

?TestRequest ?提供了一個 API 來模擬帶有錯誤的 HTTP 響應(yīng)。在早期版本的 Angular 中，此 API 接受 ?ErrorEvent ?類型的對象，這與瀏覽器本機返回的錯誤事件類型不匹配。如果你要將 ?ErrorEvent ?與 ?TestRequest ?一起使用，就應(yīng)該切換到 ?ProgressEvent ?。

這是使用 ?ProgressEvent ?的示例：

const mockError = new ProgressEvent('error');
const mockRequest = httpTestingController.expectOne(..);

mockRequest.error(mockError);

棄用的 CLI API 和選項

本節(jié)包含所有當(dāng)前已棄用的 CLI 標(biāo)志的完整列表。

@angular/cli

API/選項

可能移除于

備注
--prod v14

改用 --configuration production 。
ng update --all v14

已無效果。

@angular-devkit/build-angular

API/選項

可能移除于

備注
deployUrl v15

使用 baseHref 選項、 APP_BASE_HREF DI 令牌或兩者的組合。
showCircularDependencies v14

在項目代碼中檢測循環(huán)依賴的推薦方法是使用 lint 規(guī)則或其他外部工具。

Protractor 構(gòu)建器

 v14

作為 Protractor 棄用的一部分而棄用。

@angular-devkit/build-optimizer

整個 NPM 包已棄用。它一直是實驗性的（從未達(dá)到 ?1.0.0? ）并且一直是 Angular CLI 的內(nèi)部包。所有相關(guān)特性都已移至 ?@angular-devkit/build-angular? 。

刪除的 API

從 11.0.0*開始，已經(jīng)移除了以下 API：

包

 API

替代品
@angular/router preserveQueryParams ?queryParamsHandling?

[style] 和 [style.prop] 綁定的樣式清理

Angular 會清理 ?[style]? 和 ?[style.prop]? 綁定，以防止惡意代碼通過 CSS ?url()? 條目中的 ?javascript:? 表達(dá)式進(jìn)行插入。但是，大多數(shù)現(xiàn)代瀏覽器都已不再支持這些表達(dá)式的使用，所以這種清理只對 IE 6 和 7 才有意義。鑒于 Angular 不支持 IE 6 或 7，并且這種清理有性能代價，因此我們將不再清理 Angular 版本 10 中的樣式綁定。

@angular/router 中的 loadChildren 字符串語法

不能再用 ?loadChildren ?字符串語法來配置惰性路由。字符串語法已替換為動態(tài)導(dǎo)入語句。 ?DeprecatedLoadChildren ?類型已從 ?@angular/router? 中刪除。

支持類 ?NgModuleFactoryLoader ?、 ?SystemJsNgModuleLoader ?和 ?SystemJsNgModuleLoaderConfig ?類已從 ?@angular/core? 中刪除，并且 ?SpyNgModuleFactoryLoader ?已從 ?@angular/router? 中刪除。

WrappedValue

?WrappedValue ?是為了供變更檢測用的，它允許將相同的對象實例視為不同的。在 ?Observable ?產(chǎn)生相同值實例的情況下，它通常與 ?async ?管道一起使用。

鑒于此用例相對較少且特殊處理會影響應(yīng)用程序性能， ?WrappedValue ?API 已在 Angular 13 中刪除。

如果你依賴同一個對象實例應(yīng)該引起更改檢測的行為，你有兩個選擇：

  • 克隆結(jié)果值，使其具有新的標(biāo)識。
  • 顯式調(diào)用?ChangeDetectorRef.detectChanges()?已強制更新。


以上內(nèi)容是否對您有幫助：
在線筆記
App下載
App下載

掃描二維碼

下載編程獅App

公眾號
微信公眾號

編程獅公眾號