欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

一文詳解typeScript的extends關(guān)鍵字

 更新時間:2023年03月28日 14:50:56   作者:鯊叔  
這篇文章主要為大家介紹了typeScript的extends關(guān)鍵字使用示例詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪

前言

聲明: 以下文章所包含的結(jié)論都是基于 typeScript@4.9.4 版本所取得的。

extends 是 typeScript 中的關(guān)鍵字。在 typeScript 的類型編程世界里面,它所扮演的角色實在是太重要了,所以,我們不得不需要重視它,深入學(xué)習(xí)它。在我看來,掌握它就是進(jìn)入高級 typeScript 類型編程世界的敲門磚。但是,現(xiàn)實是,它在不同的上下文中,具體不同的,相差很大的語義。如果沒有深入地對此進(jìn)行梳理,它會給開發(fā)者帶來很大的困惑。梳理并深入學(xué)習(xí)它,最后掌握它,這就是我編寫這篇文章的初衷。

extends 的幾個語義

讓我們開門見山地說吧,在 typeScript 在不同的上下文中,extends 有以下幾個語義。不同語義即有不同的用途:

  • 用于表達(dá)類型組合;
  • 用于表達(dá)面向?qū)ο笾小割悺沟睦^承
  • 用于表達(dá)泛型的類型約束;
  • 在條件類型(conditional type)中,充當(dāng)類型表達(dá)式,用于求值。

extends 與 類型組合/類繼承

extends 可以跟 interface 結(jié)合起來使用,用于表達(dá)類型組合。

示例 1-1

interface ChildComponentProps {
    onChange: (val: string)=> void
}
interface ParentComponentProps extends ChildComponentProps {
    value: string
}

在 react 組件化開發(fā)模式中,存在一種自底向上的構(gòu)建模式 - 我們往往會先把所有最底層的子組件的 props 構(gòu)建好,最后才定義 container component(負(fù)責(zé)提升公共 state,聚合和分發(fā) props) 的 props。此時,inferface 的 extends 正好能表達(dá)這種語義需求 - 類型的組合(將所有子組件的 props 聚合到一塊)。

當(dāng)然,interfaceextends 從句是可以跟著多個組合對象,多個組合對象之間用逗號,隔開。比如 ParentComponentProps組合多個子組件的 props

示例 1-2

interface ChildComponentProps {
    onChange: (val: string)=> void
}
interface ChildComponentProps2 {
    onReset: (value: string)=> void
}
interface ParentComponentProps extends ChildComponentProps, ChildComponentProps2 {
    value: string
}

注意,上面指出的是「多個組合對象」,這里也包括了Class。對,就是普通面向概念中的「類」。也就是說,下面的代碼也是合法的:

示例 1-3

interface ChildComponentProps {
    onChange: (val: string)=> void
}
interface ChildComponentProps2 {
    onReset: (value: string)=> void
}
class SomeClass {
    private name!: string // 變量聲明時,變量名跟著一個感嘆號`!`,這是「賦值斷言」的語法
    updateName(name:string){
        this.name = name || ''
    }
}
interface ParentComponentProps extends
ChildComponentProps,
ChildComponentProps2,
SomeClass {
    value: string
}

之所以這也是合法的,一切源于一個特性:在 typeScript 中,一個 class 變量既是「值」也是「類型」。在interface extends class的上下文中,顯然是取 class 是「類型」的語義。一個 interface extends 另外一個 class,可以理解為 interface 拋棄這個 class 的所有實現(xiàn)代碼,只是跟這個 class 的「類型 shape」 進(jìn)行組合。還是上面的示例代碼中,從類型 shape 的角度,SomeClass 就等同于下面的 interface:

示例 1-4

interface SomeClass {
   name: string
   updateName: (name:string)=> void
}

好了,以上就是 extends 關(guān)鍵字的「類型組合」的語義。事情開始發(fā)生了轉(zhuǎn)折。

如果某個 interface A 繼承了某個 class B,那么這個 interface A 還是能夠被其他 interface 去繼承(或者說組合)。但是,如果某個 class 想要 implements 這個 interface A,那么這個 class 只能是 class B 本身或者 class B 的子類。

示例 1-5

class Control {
   private state: any;
  constructor(intialValue: number){
    if(intialValue > 10){
      this.state = false
    }else {
      this.state = true
    }
  }
  checkState(){
    return this.state;
  }
}
interface SelectableControl extends Control {
  select(): void;
}
// 下面的代碼會報錯:Class 'DropDownControl' incorrectly implements interface
// 'SelectableControl'.
// Types have separate declarations of a private property 'state'.(2420)
class DropDownControl  implements SelectableControl {
  private state = false;
  checkState(){
    // do something
  }
  select(){
    // do something
  }
}

要想解決這個問題,class DropDownControl必須要繼承 Control class 或者Control class 的子類:

示例 1-6

class Control {
   private state: any;
  constructor(intialValue: number){
    if(intialValue > 10){
      this.state = false
    }else {
      this.state = true
    }
  }
  checkState(){
    return this.state;
  }
}
interface SelectableControl extends Control {
  select(): void;
}
// 下面的代碼就不會報錯,且能得到預(yù)期的運行結(jié)果
class DropDownControl  extends Control  implements SelectableControl {
  // private state = false;
  //checkState(){
    // do something
  //}
  select(){
    // do something
  }
}
const dropDown = new DropDownControl(1);
dropDown.checkState(); // Ok
dropDown.select(); // Ok

上面這個示例代碼扯出了 extends 關(guān)鍵字的另外一個語義 - 「繼承」。當(dāng)extends用于 typeScript 的類之間,它的準(zhǔn)確語義也就是 ES6 中面向?qū)ο笾小竐xtends」關(guān)鍵字的語義。AClass extends BClass 不再應(yīng)該解讀為「類型的組合」而是面向?qū)ο缶幊讨械摹窤Class 繼承 BClass」和「AClass 是父類 BClass 的子類」。與此同時,值得指出的是,此時的 extends 關(guān)鍵字是活在了「值的世界」, 遵循著 ES6 中 extends關(guān)鍵字一樣的語義。比較顯著的一點就是,ts 中的 extends 也是不能在同一時間去繼承多個父類的。比如,下面的代碼就會報錯:

示例 1-7

class A {}
class B {}
// 報錯: Classes can only extend a single class.(1174)
class C extends A,B {
}

關(guān)于具有「繼承」語義的 extends 更多行為特性的闡述已經(jīng)屬于面向?qū)ο缶幊谭妒降姆懂犃耍@里就不深入討論了,有興趣的同學(xué)可以自行去了解。

至此,我們算是了解 extends 關(guān)鍵字跟 interfaceclass 結(jié)合起來所表達(dá)的兩種不同的語義:

  • 類型的組合
  • 面向?qū)ο蟾拍钪小割惖睦^承」

接下來,我們看看用于表達(dá)泛型類型約束的 extends

extends 與類型約束

更準(zhǔn)確地說,這一節(jié)是要討論 extends 跟泛型形參結(jié)合時候的「類型約束」語義。在更進(jìn)一步討論之前,我們不妨先復(fù)習(xí)一下,泛型形參聲明的語法以及我們可以在哪些地方可以聲明泛型形參。

具體的泛型形參聲明語法是:

  • 標(biāo)識符后面用尖括號<>包住一個或者多個泛型形參
  • 多個泛型形參用,號隔開
  • 泛型新參的名字可以隨意命名(我們見得最多就是使用單個英文字母T,U之類的)。

在 typeScript 中,我們可以在以下地方去聲明一個泛型形參。

在普通的函數(shù)聲明中:

function dispatch<A>(action: A): A {
    // Do something
}

在函數(shù)表達(dá)式形態(tài)的類型注解中:

const dispatch: <A>(action: A)=> A =  (action)=> {
  return action
}
// 或者
interface Store {
 dispatch: <A>(action: A)=> A
}

interface 的聲明中:

interface Store<S> {
 dispatch: <A>(action: A)=> A
 reducer: <A>(state: S,action: A)=> S
}

class 的聲明中:

class GenericAdd<AddableType> {
  zeroValue!: AddableType;
  add!: (x: AddableType, y: AddableType) => AddableType;
}
let myGenericNumber = new GenericNumber<number>();
myGenericNumber.zeroValue = 0;
myGenericNumber.add = function (x, y) {
    return x + y;
};

在自定義類型聲明中:

 type Dispatch<A>=(action:A)=> A
  • 在類型推導(dǎo)中: typeScript // 此處,F(xiàn) 和 Rest 就是泛型形參 type GetFirstLetter<S> = S extends `${infer F extends `${number}`}${infer Rest}` ? F : S;  以上就是簡單梳理后的可以產(chǎn)生泛型形參的地方,可能還有疏漏,但是這里就不深入發(fā)掘了。

下面重點來了 - 凡是有泛型形參的地方,我們都可以通過 extends 來表達(dá)類型約束。這里的類型約束展開說就是,泛型形參在實例化時傳進(jìn)來的類型實參必須要滿足我們所聲明的類型約束。到這里,問題就來了,我們該怎樣來理解這里的「滿足」呢?在深究此問題之前,我們來看看類型約束的語法:

`泛型形參` extends `某個類型`

為了引出上面所說「滿足」的理解難題,我們不妨先看看下面的示例的代碼:

示例 2-1

// case 1
type UselessType<T extends number> = T;
type Test1 = UselessType<any> // 這里會報錯嗎?
type Test1_1 = UselessType<number|string> // 這里會報錯嗎?
// case 2
type UselessType2<T extends {a:1, b:2}> = T;
type Test2 = UselessType2<{a:1, b:2, c:3}> // 這里會報錯嗎?
type Test2_1 = UselessType2<{a:1}> // 這里會報錯嗎?
type Test2_2 = UselessType2<{[key:string]: any}> // 這里會報錯嗎?
type Test2_3 = {a:1, b:2} extends  {[key:string]: any} ? true : false
// case 3
class BaseClass {
    name!: string
}
class SubClass extends  BaseClass{
    sayHello!: (name: string)=> void
}
class SubClass2 extends  SubClass{
    logName!: ()=> void
}
type UselessType3<T extends SubClass> = T;
type Test3 = UselessType3<{name: '鯊叔'}> // 這里會報錯嗎?
type Test3_1 = UselessType3<SubClass> // 這里會報錯嗎?
type Test3_2 = UselessType3<BaseClass> // 這里會報錯嗎?

不知道讀者朋友們在沒有把上述代碼拷貝到 typeScript 的 playground 里面去驗證之前你是否能全部猜中。如果能,證明你對 extends 在類型約束的語義上下文中的行為表現(xiàn)已經(jīng)掌握的很清楚了。如果不能,請允許我為你娓娓道來。

相信有部分讀者了解過 typeScript 的類型系統(tǒng)的設(shè)計策略。由于 js 是一門動態(tài)弱類型的腳本語言,再加上需要考慮 typeScript 與 js 的互操性和兼容性。所以, typeScript 類型系統(tǒng)被設(shè)計為一個「structural typing」系統(tǒng)(結(jié)構(gòu)化類型系統(tǒng))。所謂的結(jié)構(gòu)化類型系統(tǒng)的一個顯著的特點就是 - 具有某個類型 A 的值是否能夠賦值給另外一個類型 B 的值的依據(jù)是,類型 A 的類型結(jié)構(gòu)是否跟類型 B 的類型結(jié)構(gòu)是否兼容。 而類型之間是否兼容看重的類型的結(jié)構(gòu)而不是類型的名字。再說白一點,就是 B 類型有的屬性和方法,你 A 類型也必須有。到這里,就很容易引出一個廣為大眾接受的,用于理解類型「可賦值性」行為的心智模型,即:

  • 用集合的角度去看類型。故而這里有「父集」和 「子集」的概念,「父集」包含 「子集」;
  • 在 typeScript 的類型系統(tǒng)中, 子集類型是可以賦值給父集類型。
  • 在泛型形參實例化時,如果 extends 前面的類型是它后面的類型的子集,那么我們就說當(dāng)前的實例化是「滿足」我們所聲明的類型約束的。

以下是 示例 2-1 的運行結(jié)果:

實際上,上面的那個心智模型是無法匹配到以上示例在 typeScript@4.9.4 上的運行結(jié)果。以上面這個心智模型(子集類型能賦值給父集類型,反之則不然)來看示例的運行結(jié)果,我們會有下面的直覺認(rèn)知偏差:

  • case 1 中,anynumber 的父集,為什么它能賦值給 number 類型的值?
  • case 1 中,number | string 應(yīng)該是 number 的父集,所以,它不能賦值給 number 類型的值。
  • case 1 中,number & string 應(yīng)該是 number 的父集,按理說,這里應(yīng)該報錯,但是為什么卻沒有?
  • case 2 中,{a:1}{a:1,b:2} 的子集,按理說,它能賦值給 {a:1,b:2}類型的值啊,為什么會報錯?
  • case 3 中,感覺{name: '鯊叔'}SubClass 的子集,按理說,它能賦值給 SubClass類型的值啊,為什么會報錯?
  • case 3 中,感覺BaseClassSubClass 的子集,按理說,它能賦值給 SubClass類型的值啊,為什么會報錯?

經(jīng)過反復(fù)驗證和查閱資料,正確的認(rèn)知如下:

  • case 1 中,any 是任何類型的子集,也是任何類型的父集。這里 typeScript 往寬松方向去處理,即取 number 的子集之意;
  • number | string 之所以不能賦值給 number ,并不是因為 number | stringnumber 的父集,而是因為聯(lián)合類型遇到 extends關(guān)鍵字所產(chǎn)生的「分配律」的結(jié)果。即是因為 number|string extends number的結(jié)果等于 (number extend number) | (string extends number)的結(jié)果。顯然,(number string extends number的值是 false 的,所以,整個類型約束就不滿足;
  • 對象類型的類型不能采用 子集類型 extends 父集類型 = true的心智模型來理解。而是得采用 父集類型 extends 子集類型 = true。與此同時,當(dāng)子集類型中有明確字面量 key-value 對的時候,父集類型中也必須需要有。否則的話,就是不可賦值給子集類型。
  • number & string 應(yīng)該被視為對象類型的類型,遵循上面一條的規(guī)則。

基于上面的正確認(rèn)知,我們不妨把我們的心智模型修正一下:

  • 應(yīng)該使用「父類型」和「子類型」的概念去理解滿足類型約束背后所遵循的規(guī)則;
  • 在類型約束 AType extends BType 中,如果 ATypeBType的子類型,那么我們就會說 AType 是滿足我們所聲明的類型約束的;
  • 根據(jù)下面的 「ts 類型層級關(guān)系圖」來判斷兩種類型的父-子類型關(guān)系:

注:

1)A -> B表示「A 是 B 的父類型,B 是 A 的子類型」;

2)strictNullChecks 編譯標(biāo)志位打開后,undefined,voidnull就不會成為 typeScript 類型系統(tǒng)的一層,因為它們是不能賦值給其他類型的。

關(guān)于上面這張圖,有幾點可以單獨拿出來強(qiáng)調(diào)一下:

  • any 無處不在。它既是任何類型的子類型,也是任何類型的父類型,甚至可能是任意類型自己。所以,它可以賦值給任何類型;
  • {} 充當(dāng) typeScript 類型的時候,它是有特殊含義的 - 它對應(yīng)是(Object.prototype.__proto__)=null在 js 原型鏈上的地位,它被視為所有的對象類型的基類。
  • array 的字面量形式的子類型就是tuple,function 的字面量形式的子類型就是函數(shù)表達(dá)式類型。tuple函數(shù)表達(dá)式類型都被囊括到 字面量類型中去。

現(xiàn)在我們用這個新的心智模型去理解一下 示例 2-1 報錯的地方:

  • type Test1_1 = UselessType<number|string> 之所以報錯,是因為在類型約束中,如果 extends前面的類型是聯(lián)合類型,那么要想滿足類型約束,則聯(lián)合類型的每一個成員都必須滿足類型約束才行。這就是所謂的「聯(lián)合類型的分配律」。顯然,string extends number 是不成立的,所以整個聯(lián)合類型就不滿足類型約束;
  • 對于對象類型的類型 - 即強(qiáng)調(diào)由屬性和方法所組成的集合類型,我們需要先用面向?qū)ο蟮母拍顏泶_定兩個類型中,誰是子類,誰是父類。這里的判斷方法是 - 如果 A 類型相比 B 類型多出了一些屬性/方法的話(這也同時意味著 B 類型擁有的屬性或者方法,A 類型也必須要有),那么 A 類型就是父類,B 類型就是子類。然后,我們再轉(zhuǎn)換到子類型和父類型的概念上來 - 父類就是「父類型」,子類就是「子類型」。
    • type Test2_1 = UselessType2<{a:1}> 之所以報錯,是因為{a:1}{a:1, b:2}的父類型,所以是不能賦值給{a:1, b:2};
    • {[key:string]: any}并不能成為 {a:1, b:2} 的子類型,因為,父類型有的屬性/方法,子類型必須顯式地?fù)碛小?code>{[key:string]: any}沒有顯式地?fù)碛?,所以,它不?{a:1, b:2}的子類型,而是它的父類型。
    • type Test3 = UselessType3<{name: '鯊叔'}>type Test3_2 = UselessType3<BaseClass> 報錯的原因也是因為因為缺少了相應(yīng)的屬性/方法,所以,它們都不是SubClass的子類型。

到這里,我們算是剖析完畢。下面總結(jié)一下。

  • 當(dāng) extends 緊跟在泛型形參后面時,它是在表達(dá)「類型約束」的語義;
  • AType extends BType 中,只有 ATypeBType 的子類型,ts 通過類型約束的檢驗;
  • 面對兩個 typeScript 類型,到底誰是誰的子類型,我們可以根據(jù)上面給出的 「ts 類型層級關(guān)系圖」來判斷。而對于一些充滿迷惑的邊緣用例,死記硬背即可。

extends 與條件類型

眾所周知,ts 中的條件類型就是 js 世界里面的「三元表達(dá)式」。只不過,相比值世界里面的三元表達(dá)式最終被計算出一個「值」,ts 的三元表達(dá)式最終計算出的是「類型」。下面,我們先來復(fù)習(xí)一下它的語法:

AType extends BType ?  CType :  DType

在這里,extends 關(guān)鍵字出現(xiàn)在三元表達(dá)的第一個子句中。按照我們對 js 三元表達(dá)式的理解,我們對 typeScript 的三元表達(dá)式的理解應(yīng)該是相似的:如果 AType extends BType 為邏輯真值,那么整個表達(dá)式就返回 CType,否則的話就返回DType。作為過來人,只能說,大部分情況是這樣的,在幾個邊緣 case 里面,ts 的表現(xiàn)讓你大跌眼鏡,后面會介紹。

跟 js 的三元表達(dá)式支持嵌套一樣,ts 的三元表達(dá)式也支持嵌套,即下面也是合法的語法:

AType extends BType ?  (CType extends DType ? EType : FType) : (GType extends HType ? IType : JType)

到這里,我們已經(jīng)看到了 typeScript 的類型編程世界的大門了。因為,三元表達(dá)式本質(zhì)就是條件-分支語句,而后者就是邏輯編輯世界的最基本的要素了。而在我們進(jìn)入 typeScript 的類型編程世界之前,我們首要搞清楚的是,AType extends BType何時是邏輯上的真值。

幸運的是,我們可以復(fù)用「extends 與類型約束」上面所產(chǎn)出的心智模型。簡而言之,如果 ATypeBType 的子類型,那么代碼執(zhí)行就是進(jìn)入第一個條件分支語句,否則就會進(jìn)入第二個條件分支語句。

上面這句話再加上「ts 類型層級關(guān)系圖」,我們幾乎可以理解AType extends BType 99% 的語義。還剩下 1% 就是那些違背正常人直覺的特性表現(xiàn)。下面我們重點說說這 1% 的特性表現(xiàn)。

extends 與 {}

我們開門見山地問吧:“請說出下面代碼的運行結(jié)果。”

type Test = 1 extends {} ? true : false // 請問 `Test` 類型的值是什么?

如果你認(rèn)真地去領(lǐng)會上面給出的「ts 類型層級關(guān)系圖」,我相信你已經(jīng)知道答案了。如果你是基于「鴨子辯型」的直觀理解去判斷,那么我相信你的答案是false。但是我的遺憾地告訴你,在 typeScript@4.9.4中,答案是true。這明顯是違背人類直覺的。于是乎,你會有這么一個疑問:“字面量類型 1{}類型似乎牛馬不相及,既不形似,也不神似,它怎么可能是是「字面量空對象」的子類型呢?”

好吧,就像我們在上一節(jié)提過的,{}在 typeScript 中,不應(yīng)該被理解為字面量空對象。它是一個特殊存在。它是一切有值類型的基類。ts 對它這么定位,似乎也合理。因為呼應(yīng)了一個事實 - 在 js 中,一切都是對象 (字面量 1 在 js 引擎內(nèi)部也是會被包成一個對象 - Number()的實例)。

現(xiàn)在,你不妨拿別的各種類型去測試一下它跟 {} 的關(guān)系,看看結(jié)果是不是跟我說的一樣。最后,有一個注意點值的強(qiáng)調(diào)一下。假如我們忽略無處不在,似乎是百變星君的 any,{} 的父類型只有一個 - unknown。不信,我們可以試一試:

type Test = unknown extends {} ? true : false // `Test` 類型的值是 `false`

Test2 類型的值是 false,從而證明了unknown{}的父類型。

extends 與 any

也許你會覺得,extendsany 有什么好講得嘛。你上面不是說了「any」既是所有類型的子類型,又是所有類型的父類型。所以,以下示例代碼得到的類型一定是true:

type Test = any extends number ? true : false

額......在 typeScript@4.9.4 中, 結(jié)果似乎不是這樣的 - 上面示例代碼的運行結(jié)果是boolean。這到底是怎么回事呢?這是因為,在 typeScript 的條件類型中,當(dāng)any 出現(xiàn)在 extends 前面的時候,它是被視為一個聯(lián)合里類型。這個聯(lián)合類型有兩個成員,一個是extends 后面的類型,一個非extends 后面的類型。還是用上面的示例舉例子:

type Test = any extends number ? true : false
// 其實等同于
type Test = (number | non-number) extends number ? true : false
// 根據(jù)聯(lián)合類型的分配率,展開得到
type Test = (number extends number ? true : false) | (non-number extends number ? true : false)
          = true | false
          = boolean
// 不相信我?我們再來試一個例子:
type Test2 = any extends number ? 1 : 2
// 其實等同于
type Test2 = (number | non-number) extends number ? 1 : 2
// 根據(jù)聯(lián)合類型的分配率,展開得到
type Test = (number extends number ? 1 : 2) | (non-number extends number ? 1 : 2)
          = 1 | 2

也許你會問,如果把 any 放在后面呢?比如:

type Test = number extends any ? true : false

這種情況我們可以依據(jù) 「任意類型都是any的子類型」得到最終的結(jié)果是true。

關(guān)于 extends 與 any 的運算結(jié)果,總結(jié)一下,總共有兩種情況:

  • any extends SomeType(非 any 類型) ? AType : BType 的結(jié)果是聯(lián)合類型 AType | BType
  • SomeType(可以包含 any 類型) extends any ? AType : BType 的結(jié)果是 AType

extends 與 never

在 typeScript 的三元表達(dá)式中,當(dāng) never 遇見 extends,結(jié)果就變得很有意思了??梢該Q個角度說,是很奇怪。假設(shè),我現(xiàn)在要你實現(xiàn)一個 typeScript utility 去判斷某個類型(不考慮any)是否是never的時候,你可能會不假思索地在想:因為 never 是處在 typeScript 類型層級的最底層,也就是說,除了它自己,沒有任何類型是它的子類型。所以答案肯定是這樣:

type IsNever<T> = T extends never ? true : false

然后,你信心滿滿地給泛型形參傳遞個never去測試,你發(fā)現(xiàn)結(jié)果是never,而不是true或者false:

type  Test = IsNever<never> // Test 的值為 `never`, 而不是我們期待的  `true`

再然后,你不甘心,你寫下了下面的代碼去進(jìn)行再次測試:

type  Test = never extends never ? true : false // Test 的值為 `true`, 符合我們的預(yù)期

你會發(fā)現(xiàn),這次的結(jié)果卻是符合我們的預(yù)期的。此時,你腦海里面肯定有千萬匹草泥馬奔騰而過。是的,ts 類型系統(tǒng)中,某些行為就是那么的匪夷所思。

對于這種違背直覺的特性表現(xiàn),當(dāng)前的解釋是:當(dāng) never 充當(dāng)實參去實例化泛型形參的時候,它被看作沒有任何成員的聯(lián)合類型。當(dāng) tsc 對沒有成員的聯(lián)合類型執(zhí)行分配律時,tsc 認(rèn)為這么做沒有任何意義,所以就不執(zhí)行這段代碼,直接返回 never。

那正確的實現(xiàn)方式是什么啊?是這個:

type IsNever<T> = [T] extends [never] ? true : false

原理是什么???答曰:「通過放入 tuple 中,消除了聯(lián)合類型碰上 extends 時所產(chǎn)生的分配律」。

extends 與 聯(lián)合類型

上面也提到了,在 typeScript 三元表達(dá)中,當(dāng) extends 前面的類型是聯(lián)合類型的時候,ts 就會產(chǎn)生類似于「乘法分配律」行為表現(xiàn)。具體可以用下面的示例來表述:

type Test = (AType | BType) extends SomeType ? 'yes' : 'no'
          =  (AType extends SomeType ? 'yes' : 'no') | (BType extends SomeType ? 'yes' : 'no')

我們再來看看「乘法分配律」:(a+b)*c = a*c + b*c。對比一下,我們就是知道,三元表達(dá)式中的 |就是乘法分配律中的 +, 三元表達(dá)式中的 extends 就是乘法分配律中的 *。下面是表達(dá)這種類比的偽代碼:

type Test = (AType + BType) * (SomeType ? 'yes' : 'no')
          =  AType * (SomeType ? 'yes' : 'no') + BType * (SomeType ? 'yes' : 'no')

另外,還有一個很重要的特性是,當(dāng)聯(lián)合類型的泛型形參的出現(xiàn)在三元表達(dá)式中的真值或者假值分支語句中,它指代的是正在遍歷的聯(lián)合類型的成員元素。在編程世界里面,利用聯(lián)合類型的這個特性,我們可以遍歷聯(lián)合類型的所有成員類型。比如,ts 內(nèi)置的 utility Exclude<T,U> 就是利用這種特性所實現(xiàn)的:

type  MyExclude<T,U>= T extends U ? never :  T; // 第二個條件分支語句中, T 指代的是正在遍歷的成員元素
type Test = MyExclude<'a'|'b'|'c', 'a'> // 'b'|'c'

在上面的實現(xiàn)中,在你將類型實參代入到三元表達(dá)式中,對于第二個條件分支的T 記得要理解為'a'|'b'|'c'的各個成員元素,而不是理解為完整的聯(lián)合類型。

有時候,聯(lián)合類型的這種分配律不是我們想要的。那么,我們該怎么消除這種特性呢?其實上面在講「extends 與 never 」的時候也提到了。那就是,用方括號[]包住 extends 前后的兩個類型參數(shù)。此時,兩個條件分支里面的聯(lián)合類型參數(shù)在實例化時候的值將會跟 extends 子句里面的是一樣的。

// 具有分配律的寫法
type ToArray<Type> = Type extends any ? Type[] : never; //
type StrArrOrNumArr = ToArray<string | number>; // 結(jié)果是:`string[] | number[]`
// 消除分配律的寫法
type ToArrayNonDist<Type> = [Type] extends [any] ? Type[] : never;
type StrArrOrNumArr2 = ToArray<string | number>; // 結(jié)果是:`(string | number)[]`

也許你會覺得 string[] | number[](string | number)[]是一樣的,我只能說:“客官,要不您再仔細(xì)瞧瞧?”。

extends 判斷類型嚴(yán)格相等

在 typeScript 的類型編程世界里面,很多時候我們需要判斷兩個類型是否是一模一樣的,即這里所說的「嚴(yán)格相等」。如果讓你去實現(xiàn)這個 utility 的話,你會怎么做呢?我相信,不少人會跟我一樣,不假思索地寫下了下面的答案:

type  IsEquals<T,U>= T extends U ? U extends T ? true : false :  false

這個答案似乎是邏輯正確的。因為,如果只有自己才可能既是自己的子類型也是自己的父類型。然后,我們用很多測試用例去測,似乎結(jié)果也都符合我們的預(yù)期。直到我們碰到下面的邊緣用例:

type  Test1= IsEquals<never,never> // 期待結(jié)果:true,實際結(jié)果: never
type  Test2= IsEquals<1,any> // 期待結(jié)果:false,實際結(jié)果: boolean
type  Test3= IsEquals<{readonly a: 1},{a:1}> // 期待結(jié)果:false,實際結(jié)果: true

沒辦法, typeScript 的類型系統(tǒng)有太多的違背常識的設(shè)計與實現(xiàn)了。如果還是沿用上面的思路,即使你把上面的特定用例修復(fù)好了,但是說不定還有其他的邊緣用例躲在某個陰暗的角度等著你。所以,對于「如何判斷兩個 typeScript 類型是嚴(yán)格相等」的這個問題上,目前社區(qū)里面從 typeScript 實現(xiàn)源碼角度上給出了一個終極答案:

type IsEquals<X, Y> =
      (<T>() => (T extends  X ? 1 : 2)) extends
      (<T>() => (T extends  Y ? 1 : 2))
      ? true
      : false;

目前我還沒理解這個終極答案為什么是行之有效的,但是從測試結(jié)果來看,它確實是 work 的,并且被大家所公認(rèn)。所以,目前為止,對于這個實現(xiàn)只能是死記硬背了。

extends 與類型推導(dǎo)

type Test<A> = A extends SomeShape ? 第一個條件分支 : 第二支條件分支

當(dāng) typeScript 的三元表達(dá)式遇見類型推導(dǎo)infer SomeType, 在語法上是有硬性要求的:

  • infer 只能出現(xiàn)在 extends 子句中,并且只能出現(xiàn)在 extends 關(guān)鍵字后面
  • 緊跟在 infer 后面所聲明的類型形參只能在三元表達(dá)式的第一個條件分支(即,真值分支語句)中使用

除了語法上有硬性要求,我們也要正確理解 extends 遇見類型推導(dǎo)的語義。在這個上下文中,infer SomeType 更像是具有某種結(jié)構(gòu)的類型的占位符。SomeShape 中可以通過 infer 來聲明多個類型形參,它們與一些已知的類型值共同組成了一個代表具有如此形態(tài)的SomeShape 。而 A extends SomeShape 是我們開發(fā)者在表達(dá):「tsc,請按照顧我所聲明的這種結(jié)構(gòu)去幫我推導(dǎo)得出各個泛型形參在運行時的值,以便供我進(jìn)一步消費這些值」,而 tsc 會說:「好的,我盡我所能」。

「tsc 會盡我所能地去推導(dǎo)出具體的類型值」這句話的背后蘊(yùn)含著不少的 typeScript 未在文檔上交代的行為表現(xiàn)。比如,當(dāng)類型形參與類型值共同出現(xiàn)在「數(shù)組」,「字符串」等可遍歷的類型中,tsc 會產(chǎn)生類似于「子串/子數(shù)組匹配」的行為表現(xiàn) - 也就是說,tsc 會以非貪婪匹配模式遍歷整個數(shù)組/字符串進(jìn)行子串/數(shù)組匹配,直到匹配到最小的子串/子數(shù)組為止。這個結(jié)果,就是我們類型推導(dǎo)的泛型形參在運行時的值。

舉個例子,下面的代碼是實現(xiàn)一個ReplaceOnce 類型 utility 代碼:

type ReplaceOnce<
  S extends string,
  From extends string,
  To extends string
> = From extends ""
  ? S
  : S extends `${infer Left}${From}${infer Right}`
  ? `${Left}${To}${Right}`
  : S
  “”
type Test = Replace<"foobarbar", "bar", ""> // 結(jié)果是:“foobar”

tsc 在執(zhí)行上面的這行代碼「S extends ${infer Left}${From}${infer Right}」的時候,背后做了一個從左到右的「子串匹配」行為,直到匹配到所傳遞進(jìn)來的子串From為止。這個時候,也是 resolve 出形參LeftRight具體值的時候。

以上示例很好的表達(dá)出我想要表達(dá)的「當(dāng)extends 跟類型推導(dǎo)結(jié)合到一塊所產(chǎn)生的一些微妙且未見諸于官方文檔的行為表現(xiàn)」。在 typeScript 高級類型編程中,善于利用這一點能夠幫助我們?nèi)ソ鉀Q很多「子串/子數(shù)組匹配」相關(guān)的問題。

總結(jié)

在 typeScript 在不同的上下文中,extends 有以下幾個語義:

  • 用于表達(dá)類型組合;
  • 用于表達(dá)面向?qū)ο笾小割悺沟睦^承
  • 用于表達(dá)泛型的類型約束;
  • 在條件類型(conditional type)中,充當(dāng)類型表達(dá)式,用于求值。

最值得注意的是,extends在條件類型中與其他幾個特殊類型結(jié)合所產(chǎn)生的特殊語義。幾個特殊類型是:

  • {}
  • any
  • never
  • 聯(lián)合類型

參考資料

以上就是一文詳解typeScript的extends關(guān)鍵字的詳細(xì)內(nèi)容,更多關(guān)于typeScript extends關(guān)鍵字的資料請關(guān)注腳本之家其它相關(guān)文章!

相關(guān)文章

  • 微信小程序 后臺https域名綁定和免費的https證書申請詳解

    微信小程序 后臺https域名綁定和免費的https證書申請詳解

    這篇文章主要介紹了微信小程序 后臺https域名綁定和免費的https證書申請詳解的相關(guān)資料,需要的朋友可以參考下
    2016-11-11
  • 微信小程序 教程之條件渲染

    微信小程序 教程之條件渲染

    這篇文章主要介紹了微信小程序 條件渲染的相關(guān)資料,并附簡單實例代碼,需要的朋友可以參考下
    2016-10-10
  • 微信小程序  modal詳解及實例代碼

    微信小程序 modal詳解及實例代碼

    這篇文章主要介紹了微信小程序 modal詳解及實例代碼的相關(guān)資料,需要的朋友可以參考下
    2016-11-11
  • element彈窗表格的字體模糊bug解決

    element彈窗表格的字體模糊bug解決

    這篇文章主要為大家介紹了element彈窗表格的字體模糊bug解決,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪
    2023-02-02
  • 網(wǎng)頁里控制圖片大小的相關(guān)代碼

    網(wǎng)頁里控制圖片大小的相關(guān)代碼

    網(wǎng)頁里控制圖片大小的相關(guān)代碼...
    2006-06-06
  • 淺談 JavaScript 沙箱Sandbox

    淺談 JavaScript 沙箱Sandbox

    在計算機(jī)安全中,沙箱(Sandbox)是一種用于隔離正在運行程序的安全機(jī)制,通常用于執(zhí)行未經(jīng)測試或不受信任的程序或代碼,它會 為待執(zhí)行的程序創(chuàng)建一個獨立的執(zhí)行環(huán)境,內(nèi)部程序的執(zhí)行不會影響到外部程序的運行,下文我們來介紹一個“瀏覽器世界”的沙箱
    2021-10-10
  • Js視頻播放器插件Video.js使用方法詳解

    Js視頻播放器插件Video.js使用方法詳解

    Video.js 是一個通用的在網(wǎng)頁上嵌入視頻播放器的JS庫,Video.js自動檢測瀏覽器對HTML5的支持情況,如果不支持HTML5則自動使用Flash 播放器,推薦大家好好看看
    2020-02-02
  • 在博客園博文中添加自定義右鍵菜單的方法詳解

    在博客園博文中添加自定義右鍵菜單的方法詳解

    本文是DOM鼠標(biāo)事件的一個實際應(yīng)用。查看博客園的博客文章時,有的文章非常長,卻沒有回到頂部按鈕;而且文章的點贊和評論都在文章最底部,使用時并不方便。所以使用自定義右鍵菜單來實現(xiàn)回到頂部、點贊、評論這三個主要功能,需要的朋友可以參考下
    2020-02-02
  • 網(wǎng)頁常用特效代碼整理

    網(wǎng)頁常用特效代碼整理

    網(wǎng)頁常用特效代碼整理...
    2006-06-06
  • Astro Islands靜態(tài)頁面交互式UI組件

    Astro Islands靜態(tài)頁面交互式UI組件

    這篇文章主要為大家介紹了Astro Islands靜態(tài)頁面交互式UI組件使用示例詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪
    2023-08-08

最新評論