2022-09-23前沿技术00
请注意,本文编写于 527 天前,最后修改于 527 天前,其中某些信息可能已经过时。

Typescript 4.4 正式发布了!抓紧上车学习吧!

本周精读的文章:announcing-typescript-4-4

概述

更智能的自动类型收窄

类型收窄功能非常方便,它可以让 Typescript 尽可能的像 Js 一样自动智能判定类型,从而避免类型定义的工作,让你的 Typescript 写得更像 Js。

其实这个功能早就有了,在我们 精读《Typescript2.0 - 2.9》 就已经介绍过,当时用的名词是自动类型推导,这次用了更精确的自动类型收窄一词,因为只有类型收窄是安全的,比如:

function foo(arg: unknown) {
    if (typeof arg === "string") {
        // We know 'arg' is a string now.
        console.log(arg.toUpperCase());
    }
}

而在 Typescript 4.4 之前的版本,如果我们将这个判定赋值给一个变量,再用到 if 分支里,就无法正常收窄类型了:

function foo(arg: unknown) {
    const argIsString = typeof arg === "string";
    if (argIsString) {
        console.log(arg.toUpperCase());
        //              ~~~~~~~~~~~
        // Error! Property 'toUpperCase' does not exist on type 'unknown'.
    }
}

这个问题在 Typescript 4.4 得到了解决,实际上是把这种类型收窄判断逻辑加深了,即无论这个判断写在哪都可以生效。所以下面这种解构的用法判断也可以推断出类型收窄:

type Shape =
    | { kind: "circle", radius: number }
    | { kind: "square", sideLength: number };

function area(shape: Shape): number {
    // Extract out the 'kind' field first.
    const { kind } = shape;

    if (kind === "circle") {
        // We know we have a circle here!
        return Math.PI * shape.radius ** 2;
    }
    else {
        // We know we're left with a square here!
        return shape.sideLength ** 2;
    }
}

不仅是单一的判断,Typescript 4.4 还支持复合类型推导:

function doSomeChecks(
    inputA: string | undefined,
    inputB: string | undefined,
    shouldDoExtraWork: boolean,
) {
    const mustDoWork = inputA && inputB && shouldDoExtraWork;
    if (mustDoWork) {
        // We can access 'string' properties on both 'inputA' and 'inputB'!
        const upperA = inputA.toUpperCase();
        const upperB = inputB.toUpperCase();
        // ...
    }
}

mustDoWorktrue 的分支就意味着 inputAinputB 均收窄为 string 类型。

这种深层的判定还体现在,一个具备类型判断的变量进行再计算,生成的变量还具有类型判断功能:

function f(x: string | number | boolean) {
    const isString = typeof x === "string";
    const isNumber = typeof x === "number";
    const isStringOrNumber = isString || isNumber;
    if (isStringOrNumber) {
        x;  // Type of 'x' is 'string | number'.
    }
    else {
        x;  // Type of 'x' is 'boolean'.
    }
}

可以看到,我们几乎可以像写 Js 一样写 Typescript,4.4 支持了大部分符合直觉的推导非常方便。但要注意的是,Typescript 毕竟不是运行时,无法做到更彻底的自动推断,但足以支持绝大部分场景。

下标支持 Symbol 与模版字符串类型判定

原本我们定义一个用下标访问的对象是这样的:

interface Values {
  [key: string]: number
}

现在也支持 Symbol 拉:

interface Colors {
    [sym: symbol]: number;
}

const red = Symbol("red");
const green = Symbol("green");
const blue = Symbol("blue");

let colors: Colors = {};

colors[red] = 255;          // Assignment of a number is allowed
let redVal = colors[red];   // 'redVal' has the type 'number'

colors[blue] = "da ba dee"; // Error: Type 'string' is not assignable to type 'number'.

而且对于特定的字符串模版也支持类型匹配,比如希望以 data- 开头的下标是一种独立类型,可以这么定义:

interface Options {
    width?: number;
    height?: number;
}

let a: Options = {
    width: 100,
    height: 100,
    "data-blah": true, // Error! 'data-blah' wasn't declared in 'Options'.
};

interface OptionsWithDataProps extends Options {
    // Permit any property starting with 'data-'.
    [optName: `data-${string}`]: unknown;
}

let b: OptionsWithDataProps = {
    width: 100,
    height: 100,
    "data-blah": true,       // Works!

    "unknown-property": true,  // Error! 'unknown-property' wasn't declared in 'OptionsWithDataProps'.
};

这个对于 HTML 的 data- 属性非常有帮助。

同时还支持联合类型定义,下面两种类型定义方式是等价的:

interface Data {
    [optName: string | symbol]: any;
}

// Equivalent to

interface Data {
    [optName: string]: any;
    [optName: symbol]: any;
}

更严格的错误捕获类型

unknown 类型出来之前,Typescript 以 any 作为抛出错误的默认类型,毕竟谁也不知道抛出错误的类型是什么:

try {
    // Who knows what this might throw...
    executeSomeThirdPartyCode();
}
catch (err) { // err: any
    console.error(err.message); // Allowed, because 'any'
    err.thisWillProbablyFail(); // Allowed, because 'any' :(
}

Who knows what this might throw... 这句话很有意思,一个函数任何地方都可能出现运行时错误,这根本不是静态分析可以解决的,所以不可能自动推断错误类型,所以只能用 any

在 Typescript 4.4 的 --useUnknownInCatchVariables--strict 模式下都将以 unknown 作为捕获到错误的默认类型。

相比不存在的类型 neverunknown 仅仅是不知道是什么类型而已,所以不能像 any 一样当作任何类型使用,但我们可以将其随意推断为任意类型:

try {
    executeSomeThirdPartyCode();
}
catch (err) { // err: unknown
    // Error! Property 'message' does not exist on type 'unknown'.
    console.error(err.message);

    // Works! We can narrow 'err' from 'unknown' to 'Error'.
    if (err instanceof Error) {
        console.error(err.message);
    }
}

如果觉得这样做麻烦,也可以重新申明类型为 any

try {
    executeSomeThirdPartyCode();
}
catch (err: any) {
    console.error(err.message); // Works again!
}

但这样做其实并不合适,因为即便是考虑了运行时因素,理论上还是可能发生意外错误,所以对错误过于自信的类型推断是不太合适的,最好保持其 unknown 类型,对所有可能的边界情况做处理。

明确的可选属性

对象的可选属性在类型描述时有个含糊不清的地方,比如:

interface Person {
    name: string,
    age?: number;
}

其实 Typescript 对其的类型定义的是:

interface Person {
    name: string,
    age?: number | undefined;
}

为什么要这么定义呢?因为很多情况下,没有这个 key,与这个 key 的值为 undefined 的表现是等价的。但比如 Object.keys 场景下这两种表现却又不等价,所以理论上对于 age?: number 的确切表述是:要么没有 age,要么有 age 且类型为 number,也就是说下面的写法应该是错误的:

// With 'exactOptionalPropertyTypes' on:
const p: Person = {
    name: "Daniel",
    age: undefined, // Error! undefined isn't a number
};

在 Typescript 4.4 中同时开启 --exactOptionalPropertyTypes--strictNullChecks 即可生效。

仔细想想这是合理的,既然定义的类型不是 undefined,就算对象是可选类型,也不能认为赋值 undefined 是合理的,因为 age?: number 的心理预期是,要么没有这个 key,要么有但是类型为 number,所以当 Object.keys 发现 age 这个 key 时,值就应该是 number

支持 Static Block

Typescript 4.4 支持了 class static blocks,并且在代码块作用域内可以访问私有变量。

还有一些性能提升与体验优化杂项就不一一列举了,感兴趣可以直接看原文档:perf-improvements

总结

从 Typescript 4.4 特性可以看出,Typescript 正在往 “更具备原生 JS 亲和性” 方向作出努力,这无疑会使 Typescript 变得越来越好用。

本文作者:前端小毛

本文链接:

版权声明:本博客所有文章除特别声明外,均采用 BY-NC-SA 许可协议。转载请注明出处!