[[413386]]

本文是關(guān)于 TypeScript 中的 type assertions 的，它與其他語言中的類型強(qiáng)制轉(zhuǎn)換有相似之處，并通過 as 運(yùn)算符執(zhí)行。

類型斷言

類型斷言使我們可以覆蓋 TypeScript 為存儲(chǔ)位置計(jì)算的靜態(tài)類型，這對于解決類型系統(tǒng)的限制很有用。

類型斷言與其他語言中的類型強(qiáng)制轉(zhuǎn)換有相似之處，但是它們不會(huì)引發(fā)異常，并且在運(yùn)行時(shí)也不做任何事情(它們確實(shí)會(huì)靜態(tài)執(zhí)行一些少量的檢查)。

const data: object = ['a', 'b', 'c']; // (A) 
 
// @ts-ignore: Property 'length' does not exist on type 'object'. 
data.length; // (B) 
 
assert.equal( 
  (data as Array<string>).length, 3); // (C) 

• 在 A 行中，我們把 Array 的類型擴(kuò)展為 object。
• 在 B 行中，我們看到此類型不允許訪問任何屬性。
• 在 C 行中，我們用類型斷言(運(yùn)算符 as)告訴 TypeScript data 是一個(gè)Array?，F(xiàn)在就可以訪問屬性 .length 了。

類型斷言是不得已的方法，應(yīng)盡可能的避免。他們(暫時(shí))刪除了靜態(tài)類型系統(tǒng)為我們提供的安全網(wǎng)。

注意，在 A 行中，我們還覆蓋了 TypeScript 的靜態(tài)類型，不過是通過類型注釋完成的。這種覆蓋方式比類型聲明要安全得多，因?yàn)槟憧梢宰龅氖虑樯俚枚唷ypeScript 的類型必須能夠分配給注釋的類型。

(1) 類型斷言的替代語法

TypeScript 對于類型斷言有另一種“尖括號”語法：

<Array<string>>data 

該語法已經(jīng)過時(shí)，并且與 React JSX 代碼(在 .tsx 文件中)不兼容。

(2) 示例：聲明一個(gè)接口

為了訪問任意對象 obj 的屬性 .name，我們暫時(shí)將 obj 的靜態(tài)類型更改為 Named(A行和B行)。

interface Named { 
  name: string; 
} 
function getName(obj: object): string { 
  if (typeof (obj as Named).name === 'string') { // (A) 
    return (obj as Named).name; // (B) 
  } 
  return '(Unnamed)'; 
} 

(3) 示例：聲明索引簽名

在以下代碼中，我們在行 A 用了類型斷言 as Dict ，以便可以訪問其推斷類型為 object 的值的屬性。也就是說，用靜態(tài)類型 Dict 覆蓋了推斷的靜態(tài)類型 object。

type Dict = {[k:string]: any}; 
 
function getPropertyValue(dict: unknown, key: string): any { 
  if (typeof dict === 'object' && dict !== null && key in dict) { 
    // %inferred-type: object 
    dict; 
 
    // @ ts-ignore：元素隱式具有“any”類型，因?yàn)?nbsp;
    // 類型'string'的表達(dá)式不能用于索引類型'{}'。 
    // 在類型“ {}”上沒有找到參數(shù)類型為'string'的索引簽名。 
    dict[key]; 
     
    return (dict as Dict)[key]; // (A) 
  } else { 
    throw new Error(); 
  } 
} 

與類型斷言相關(guān)的構(gòu)造

(1) 非空斷言運(yùn)算符(后綴 !)

如果值的類型是包含 undefined 或 null 類型的聯(lián)合，則 non-nullish聲明運(yùn)算符(或 non-null 聲明運(yùn)算符)將從聯(lián)合中刪除這些類型。我們告訴 TypeScript：“這個(gè)值不能是 undefined 或 null。”因此，我們可以執(zhí)行這兩個(gè)值的類型所阻止的操作，例如：

const theName = 'Jane' as (null | string); 
 
// @ts-ignore: Object is possibly 'null'. 
theName.length; 
 
assert.equal( 
  theName!.length, 4); // OK 

(2) 示例 – Maps: .has() 之后的 .get()

使用 Map 方法 .has() 之后，我們知道 Map 具有給定的鍵。遺憾的是，.get() 的結(jié)果不能反映這一點(diǎn)，這就是為什么我們必須使用 nullish 斷言運(yùn)算符的原因：

function getLength(strMap: Map<string, string>, key: string): number { 
  if (strMap.has(key)) { 
    // We are sure x is not undefined: 
    const value = strMap.get(key)!; // (A) 
    return value.length; 
  } 
  return -1; 
} 

由于 strMap 的值永遠(yuǎn)不會(huì)是 undefined，因此我們可以通過檢查 .get() 的結(jié)果是否為 undefined 來檢測丟失的 Map 條目(A 行)：

function getLength(strMap: Map<string, string>, key: string): number { 
  // %inferred-type: string | undefined 
  const value = strMap.get(key); 
  if (value === undefined) { // (A) 
    return -1; 
  } 
 
  // %inferred-type: string 
  value; 
 
  return value.length; 
} 

(3) 定值斷言

如果打開 strict 屬性初始化，有時(shí)需要告訴 TypeScript 我們確實(shí)初始化某些屬性——即使它認(rèn)為我們不需要這樣做。

這是一個(gè)例子，盡管 TypeScript 不應(yīng)這樣做，但它仍會(huì)報(bào)錯(cuò)：

class Point1 { 
  // @ts-ignore: Property 'x' has no initializer and is not definitely 
  // assigned in the constructor. 
  x: number; 
 
  // @ts-ignore: Property 'y' has no initializer and is not definitely 
  // assigned in the constructor. 
  y: number; 
 
  constructor() { 
    this.initProperties(); 
  } 
  initProperties() { 
    this.x = 0; 
    this.y = 0; 
  } 
} 

如果我們在 A 行和 B 行中使用“定值分配斷言”(感嘆號)，則錯(cuò)誤會(huì)消失：

class Point2 { 
  x!: number; // (A) 
  y!: number; // (B) 
  constructor() { 
    this.initProperties(); 
  } 
  initProperties() { 
    this.x = 0; 
    this.y = 0; 
  } 
}