理解TypeScript中“类型”的概念到底有多难?

如果你不喜欢广告,请收藏我的网站,下次在网站中搜索
用真金白银赞赏有价值的内容,请通过文末二维码打赏

TypeScript是JavaScript的超集。这是最大的一个误解!TS并不能在没有任何的条件下,包含JS,你必须升级TS编译器来支持新的JS特性,所以,TS并不是JS的超集,而是以JS为编译目标的另一门语言。TypeScript的核心概念就是“类型”,对于很多初接触TS的同学,类型就是冒号后面的内容,然而,事实真的是这样吗?本文将从一个另类的角度,聊一聊TS里面的泛型、&、子类型、类型推导、类型空间等话题,从而为你展现一个可能从来没想过的TS类型概念。

类型声明文件.d.ts

一切先从.d.ts文件开始说起吧。在我们已经写好的js库中,可以通过.d.ts向外提供本库的类型声明,以方便类似vscode之类的编辑器可以智能提示和补全,以及在ts项目中正确推导本库的api用法。在.d.ts文件中,我们通过declare来对需要暴露的api进行声明。

declare是一个新的关键字,起码我们在以前只写js的生涯中,从来没有使用过。我们如下声明一个函数:

declare function plus(a: number, b: number): number;

在声明中,我们只提供了函数的类型描述(下文我们会用形状Shape来表达这一概念),而没有函数的具体内容。这就像接口(interface)一样,只有描述,没有实现。如果我们的库是以模块的形式提供给外部使用,那么,只需要在最前面加上export导出这个函数的描述:

export declare function plus(a: number, b: number): number;

这样,在这个库的外部,当我们通过import导入它时,ts就会把它当作一个ES模块,并从模块中提供暴露的plus接口给外部的这个项目使用。

在.d.ts文件中,我们不会存在任何js的具体实现。?真的吗?也不一定,有时候我们会独立声明一个enum,而此时,你需要给定具体的值,以方便在外部阅读。

export enum Colors {
  Red: 'red';
  Blue: 'blue';
  Yellow: 'yellow';
}

export declare function paint(color: Colors): void;

注意第一个export,倘若此处我们不导出enum,那么我们在外部只能通过硬编码的形式传入字符串的red/blue/yellow,但当我们导出之后,就可以在外部使用Colors.Red等:

import { Colors } from 'some-lib/index.d' // <- 把它当作一个普通的.ts导入
import { paint } from 'some-lib'

paint(Colors.Red)

.d.ts只是一个摘要文件,它不被作为真正的运行时代码进行编译,但同时,我们也可以把它作为一个.ts文件进行使用,使用时,通过declare声明的部分,不会被作为运行时进行编译。

当你读到这里的时候,我想,你应该对declare产生了兴趣,以及对带来这个新语法的新语言产生了兴趣。但是,不要着急,我们还有很多东西要聊。

&不是“交集”?

我们直观感受是,当看到&时,我们要得到一个交集。例如:

interface A {
  name: string;
  age: number;
}

interface B {
  name: string;
  weight: number;
}

我们直观感受是,A&B -> interface C { name: string },然而,事实恰恰相反,A&B的结果是:

interface D {
  name: string;
  age: number;
  weight: number;
}

咦……这……不是并集吗?为了便于理解,你可以这样想:D既符合A也符合B,所以是A和B的“交叉”。但是,如果只能通过这种方式来记忆TS,那么,真的毫无意义,掌握不到TS的皮毛。

此extends非彼extends

TS中的extends和JS里面的extends形式相同概念不同。例如:

interface Animal {
  name: string;
}

interface Snake extends Animal {
  length: number;
}

Snake是在Animal的基础上增加了length字段。我们可以换一种写法:

type Snake = Animal & {
  length: number,
}

两者在语义上是有差别的,虽然结果上一致。太不可思议了,我看到了感觉上完全不同的两种操作,竟然得到了相同的结果?

extends在TS中,代表着从一个类型扩展出另外一个新类型,这个新类型是原来这个类型的子类型。同时,extends在TS中具有条件属性,它用于判断一个类型是否是另外一个类型的子类型:

type Some = A extends B ? C : D

在这一意义上,TS和JS中的extends具有完全不同的性质。JS中extends代表继承(inherit),而TS中extends就是它的字面意思“扩展”。

Subtyping子类型

子类型是一个庞大的话题,涉及到抽象概念、(推导)规则、协变、逆变等等,你可以阅读这篇文章深入了解,本文只会聊其中很小的一部分。子类型揭示了TS类型系统的核心实质,它是一个推导系统,推导即基于某些定理、公理、定律进行演算的过程(在TS中主要是基于内建的一些规则用于检查值的类型)。

TS的类型基于“集合”的概念。一个类型,代表一个集合,例如string类型代表的是所有字符串的集合。在检查过程中,如何决定一个值属于这个“集合”呢?它的依据在于这个值的“形状(Shape)”。怎么定义值的形状呢?它由两部分组成,一部分是基于JS的基础类型,得到该值的数据类型,另一部分是基于TS的另外一个核心Structural(结构化的),得到该值的结构。基于数据类型和结构这两个概念,TS获得值的形状,基于“推导”的运行方式,决定该值是否符合某个类型。

正是这样,那么下面两个类型,在TS里面,竟然是“相等”的:

class A {
  name: string;
}

class B {
  name: string;
}

这在Java或C#这样的语言中,完全不能被理解,它俩怎么可能相等?而在TS中,它们代表着形状为 { name: string } 的对象(JS中一切复合类型皆是对象)的集合。一个值,在TS中,它和集合的对应关系不是一对一的,它可以同时属于多个集合中,是一对多的关系。而同时,两个不同的集合,却可能表达相同的形状。如果你看它像鸭子,那么它就是鸭子。于是,A和B相等了,只是取了不同的名字而已,就像一个人在这个杂志上叫鲁迅,在另一个杂志上叫润土。

TS是怎么对待(treat)这些集合的呢?它基于一种推导的范式确定两个集合之间的关系。两个集合存在什么关系呢?只存在两种关系:一种是A是B的子类型,另一种是A不是B的子类型。(A和B可交换位置。)子类型,是TS对待类型集合的唯一方式。在TS中,所有类型的总和,都处在子类型体系中,这个子类型体系是一个树状网络,它的根是一个叫unknow的类型,而它的底是一个叫never的类型(never是所有类型的子类型,是树状的所有叶子)。

子类型用于表达类型与类型的二元关系,当一个值的类型属于某一类型时,它同时属于该类型的父类型。它的产生方式又有多种,一种是基于父类型扩展,也就是使用extends,一种是基于一种叫交叉(A & B)的操作得到,一种则是基于一种叫联合(A | B)的操作得到。曾经有这样一个预言,让一只猴子坐在一台电脑前敲击键盘,总有一天它能敲出莎士比亚的所有著作(猴子不懂艺术)。同样的道理,只要给定条件,你永远可以在TS的子类型体系中找到对应的类型,而这个过程基于“推导”完成。因此,实际上,子类型的产生方式只有一种而非三种或更多,这种方式就是基于某一类型(never除外)扩展出新类型。

字面量类型

基于“形状”我们确实可以做类型的断言,但是这套方法会有个例外:字面量类型。特别是基础类型的字面量类型,比如string, number等的字面量。字面量类型只有结构(structure)没有数据类型,这听上去有点反常识,且往下读。

type Str = 'hello' | 'world'
let a: Str = 'hello'

我们在用字面量类型时,常常并不是按照我们所想的那样工作,例如:

type Source = {
  name: string,
  ext: 'mp3' | 'mp4',
}
function play(source: Source): void {
  ...
}
const source = { 
  name: 'xxx',
  ext: 'mp3',
}
play(source) // <- error

此时却会抛出错误。这是因为当TS在断言时,是以形参source的形状进行推导,对实参source的形状进行断言。因此,接收到的参数在形状上是 { name: string, ext: string } 并不是Source的子类型,所以TS认为此处检查不通过。解决办法是在实参source.ext后面跟上as const,告诉编译器此处我强制'mp3'为常量,因此就符合Source的约束。

但这个问题不是由字面量本身引起的,我们看另外一个case:

type Ext = 'mp3' | 'mp4'

const mp3 = 'mp3'

function play(ext: Ext): void {}

play(mp3) // <- ok

字面量本身并不会带来问题,问题在于mut(可变)。假如我上面把const mp3改为let mp3,此时就会报错。在play接收source的时候,虽然此时source.ext的值为mp3,但是,并不代表source.ext的值永远为mp3,因为它是可变的。假如它是不可变的,那么就没有问题。

问题解决了,现在,让我们回到类型系统的讨论上来。

上文提到TS基于推导进行类型断言,推导就是寻找子类型二元关系,如果不存在父子类型关系,就断言失败,抛出错误。那么,'mp3' | 'mp4' 的子类型是谁呢?'mp3', 'mp4' 和 never,以及它自身。

现在,'mp3' & 'mp4'的子类型时谁呢?就是它的本身never。为什么它的本身是never呢?我们来看,'mp3'的子类型是什么?'mp3'和never。'mp4'的子类型呢?'mp4'和never。只有never满足'mp3'&'mp4'。

我们回过头来看文章前面提到的A&B的例子。

interface A {
  name: string;
} // -> { name: string }

interface A1 extends A {
  age: number;
} // -> { name: string, age: number }

interface A2 extends A {
  weight: number;
} // -> { name: string, weight: number }

interface B {
  sex: string;
} // -> ???

谁是A的子类型一目了然了吧。所有含有name:string的形状都是A的子类型,包括A本身,以及never。那么,谁是B的子类型呢?所有包含sex:string的形状都是B的子类型,包括B本身,以及never。

现在,我们知道了A&B本身是A&B的子类型,那么A&B是什么?是指“既是A的子类型,也是B的子类型”的类型,也就是A的子类型的集合与B的子类型的集合的交集。所以,A&B表达的是这样的“交集”,而实际产生的结果是形状的“并集”,这并不是矛盾的,而是推导结果。

纯类型编程

TS的类型系统几乎快要成为图灵完备的一门语言,你可以用它来写出一门新语言。我们要理解的是,纯类型编程和作为JS超集的TS编程的边界。我们几乎不会只写类型,而不写JS代码……等一下,真的不会吗?我们有的时候,会把项目中反复用到的一些类型,提取到公用的typings目录下进行管理,在其他地方引入这些类型。当我们脱离JS单纯写类型的时候,我们开始进入另外一个世界,这个世界叫类型空间。

我们写JS处于一个叫值空间的世界,面向运行时编程。而在类型空间,我们面向编译时编程。大多数情况下,两个空间是隔绝的(虽然在写代码的时候大部分情况下它们被写在一起),但偶尔也有例外,也就是字面量类型出现的时候,TS会在两个世界传送字面量(的结构而非值),以完成类型识别。所以严格讲,值,永远不会出现在类型空间。

在官方网站有这样一句话:别名只是别名。它的意思是,你并非在用type关键字定义一个类型,你只是给一个类型取了一个别名。无论你给一个类型取了多少个别名,它还是它自己,没有发生任何变化。

联合类型或交叉类型不具备存储类型的功能。例如type C = A & B,C并不能存储一个具体的类型,而是存储一个推导逻辑。原因很简单,因为C是无数个类型的集合。而在前面我们讲过,一个类型是一个集合,所以,C是无数个集合的集合。你不可能存储无数个类型。C参与断言的方式,是将具体的形状,参与推导过程。举个例子:有一条这样的规则:S-Arrow: 对于任何类型T1,T2,S1,S2 ,如果T1<:S1, 而且S2<:T2,那么S1->S2 <: T1->T2

declare const foo: (x: unknown) => string; // S1->S2
const bar: (x: number) => unknown = foo; // T1->T2

在上面的这个例子中,TS可以根据S-Arrow规则,快速断言foo的类型是bar的类型的子类型,所以,将foo赋值给bar是完全ok的操作。类似这样的规则,是具有数学意义的公理、定理或定律,有的是前提条件,有的是推导结论,在TS的断言中,都可以直接使用。基于这些推导规则,TS并不需要确定一个别名的具体类型,而可以做到编译时实时且高效的推导和断言。

“类型”是TS世界的一等公民,是唯一的主角,TS类型编程无非是基于一个或多个类型,生成其他类型。但类型世界的运转规则和值世界的运转规则完全不同。值世界的新值由计算得到,计算规则有常见的运算、辅助运算规则、内存与数据结构、位运算等等。类型世界的新类型如上文所述,由父类型扩展而来,扩展规则有扩展、联合、交叉、推导、获取等。类型具有抽象性,TS没有命令指令,因此没有副作用,因此类型只能被创建无法被修改,因此TS是静态的系统。没有副作用并不代表无法实现编程,和值世界完全不同的运行规则,让TS可以基于推导完成复杂的编程,而我们常把这种需要动脑子找到推导路径的过程称为“类型体操”,例如,我们找出从A|B推导出A&B的路径是type UnionToIntersection<U> =
(U extends any ? (k: U)=>void : never) extends ((k: infer I)=>void) ? I : never

除了借用JS的typeof, in等指令关键字外,TS的keyof, infer, as等指令,都不具备副作用。同时,在TS中,也支持三目运算,根据条件选择使用类型,例如 T extends Some ? T : Some. TS直接支持递归,可配合泛型用于替代循环语句。keyof和in配合可用于支持迭代遍历效果。泛型,则是通往类型编程的高速公路,是实现类型编程的核心条件。

我在之前的一篇博客文章中有聊过自己第一次接触泛型时,如何用已知的知识理解它。但那种理解仍然是套用知识,而非认知。简单讲,泛型是TS类型编程中的“函数”,用以根据已有类型,按照给定推导路径,生成新的类型,可以简称为“类型生成函数”。泛型参数是TS中最有趣最灵活最强大最麻烦的存在。我们来看一下一个解构的例子:

const { name } = { name: 'yj' } // javascript

我们尝试用TS类型编程来做类似的事情(出自):

type NameType<T> = T extends { name: infer N } ? N : never;
type name = NameType<{ name: 'yj' }>; // name is 'yj'

NameType可以从给定的类型中解构出给定类型的name属性的类型'yj'。前文提到在类型空间没有值,但是此刻,我们却可以利用TS的类型编程能力,获得的是泛型参数类型的name属性类型(字面量)。

但是遗憾的是,TS没有输出指令,类型世界的结果也无法传递给值世界,所以,我们在类型世界的编程,最终无法产生效果。不过随着时间的推移,事情有了转机,TS官方提供了生成器接口,通过一些工厂方法,你可以修改TS的编译结果。而在这个过程中,我们可以尝试破坏TS的Erased特性,保留类型的某些信息,从而可以将类型世界的结果传送回值的世界,输出类型编程的结果。

结语

本文并没有展开typescript中关于类型的用法,本文从另外一个角度,探索typescript中“类型”的概念,其中很多表述可能并不准确甚至并不正确,但是,我努力抛开用法,从本源出发去思考typescript中最核心(甚至是唯一)的概念。我们在写TS代码的时候,或许也该意识到,我们在做一件在两个世界之间穿越的事情,听起来很魔幻。掌握TS中类型的规律,我们必须深入去思考子类型是什么,并且在子类型体系中,寻求我们的最短路径。

2021-06-27 4963

为价值买单,打赏一杯咖啡

本文价值49.63RMB
已有5条评论
  1. money 2021-07-17 21:31

    技术文章,学习了。

    文章真长

  2. 1188 2021-06-28 20:17

    很有价值的一文, 解释了为什么我一会儿觉得ts好写, 一会儿就觉得ts好难写.
    还有个小疑惑, as const解决完字面量的问题之后数组的类型又会报错, 这时候是怎么解决的?

    “`
    type Source = {
      name: string,
      ext: ‘mp3’ | ‘mp4’,
      list:{name:string}[]
    }
    function play(source: Source): void {
    }
    const source = {
      name: ‘xxx’,
      ext: ‘mp3’,
      list:[]
    } as const
    play(source) // <- error
    /**
    * Argument of type '{ readonly name: "xxx"; readonly ext: "mp3"; readonly list: readonly []; }' is not assignable to parameter of type 'Source'.
      Types of property 'list' are incompatible.
        The type 'readonly []' is 'readonly' and cannot be assigned to the mutable type '{ name: string; }[]'.(2345)
    */
    “`

    • 否子戈 2021-07-01 09:53

      const source = {
        name: ‘xxx’,
        ext: ‘mp3’ as const,
        list:[]
      }
      play(source)

      • 1188 2021-07-09 17:22

        感谢解惑, 回头看看, 其实文中已经给出了答案, 还是我对mut的理解不到位.

  3. rxliuli 2021-06-28 03:40

    类型体操可真是太秀了( ̄~ ̄)