為什么需要額外的類型檢查？

TypeScript 只在編譯期執(zhí)行靜態(tài)類型檢查！實(shí)際運(yùn)行的是從 TypeScript 編譯的 JavaScript，這些生成的 JavaScript 對(duì)類型一無(wú)所知。編譯期靜態(tài)類型檢查在代碼庫(kù)內(nèi)部能發(fā)揮很大作用，但對(duì)不合規(guī)范的輸入（比如，從 API 處接收的輸入）無(wú)能為力。

運(yùn)行時(shí)檢查的嚴(yán)格性

至少需要和編譯期檢查一樣嚴(yán)格，否則就失去了編譯期檢查提供的保證。

如有必要，可以比編譯期檢查更嚴(yán)格，例如，年齡需要大于等于 0。

運(yùn)行時(shí)類型檢查策略

定制代碼手動(dòng)檢查

靈活

可能比較枯燥，容易出錯(cuò)

容易和實(shí)際代碼脫節(jié)

使用校驗(yàn)庫(kù)手動(dòng)檢查

比如使用 joi：

import Joi from "@hapi/joi"const schema = Joi.object({    firstName: Joi.string().required(),    lastName: Joi.string().required(),    age: Joi.number().integer().min(0).required()});

靈活

容易編寫

容易和實(shí)際代碼脫節(jié)

手動(dòng)創(chuàng)建 JSON Schema

例如：

{  "$schema": "http://json-schema.org/draft-07/schema#",  "required": [    "firstName",    "lastName",    "age"  ],  "properties": {    "firstName": {      "type": "string"    },    "lastName": {      "type": "string"    },    "age": {      "type": "integer",      "minimum": 0    }  }}

使用標(biāo)準(zhǔn)格式，有大量庫(kù)可以校驗(yàn)。

JSON 很容易存儲(chǔ)和復(fù)用。

可能會(huì)很冗長(zhǎng)，手寫 JSON Schema 可能會(huì)很枯燥。

需要確保 Schema 和代碼同步更新。

自動(dòng)創(chuàng)建 JSON Schema

基于 TypeScript 代碼生成 JSON Schema

-- 比如 typescript-json-schema 這個(gè)工具就可以做到這一點(diǎn)（同時(shí)支持作為命令行工具使用和通過代碼調(diào)用）。

-- 需要確保 Schema 和代碼同步更新。

基于 JSON 輸入示例生成

-- 沒有使用已經(jīng)在 TypeScript 代碼中定義的類型信息。

-- 如果提供的 JSON 輸入示例和實(shí)際輸入不一致，可能導(dǎo)致錯(cuò)誤。

-- 仍然需要確保 Schema 和代碼同步更新。

轉(zhuǎn)譯

例如使用 ts-runtime。

這種方式會(huì)將代碼轉(zhuǎn)譯成功能上等價(jià)但內(nèi)置運(yùn)行時(shí)類型檢查的代碼。

比如，下面的代碼：

interface Person {    firstName: string;    lastName: string;    age: number;}const test: Person = {    firstName: "Foo",    lastName: "Bar",    age: 55}

會(huì)被轉(zhuǎn)譯為：

import t from "ts-runtime/lib";const Person = t.type(    "Person",    t.object(        t.property("firstName", t.string()),        t.property("lastName", t.string()),        t.property("age", t.number())    ));const test = t.ref(Person).assert({    firstName: "Foo",    lastName: "Bar",    age: 55});

這一方式的缺陷是無(wú)法控制在何處進(jìn)行運(yùn)行時(shí)檢查（我們只需在輸入輸出的邊界處進(jìn)行運(yùn)行時(shí)類型檢查）。

順便提一下，這是一個(gè)實(shí)驗(yàn)性的庫(kù)，不建議在生產(chǎn)環(huán)境使用。

運(yùn)行時(shí)類型派生靜態(tài)類型

比如使用 io-ts 這個(gè)庫(kù)。

這一方式下，我們定義運(yùn)行時(shí)類型，TypeScript 會(huì)根據(jù)我們定義的運(yùn)行時(shí)類型推斷出靜態(tài)類型。

運(yùn)行時(shí)類型示例：

import t from "io-ts";const PersonType = t.type({  firstName: t.string,  lastName: t.string,  age: t.refinement(t.number, n => n >= 0, 'Positive')})

從中提取相應(yīng)的靜態(tài)類型：

interface Person extends t.TypeOf<typeof PersonType> {}

以上類型等價(jià)于：

interface Person {    firstName: string;    lastName: string;    age: number;}

類型總是同步的。

io-ts 很強(qiáng)大，比如支持遞歸類型。

需要將類型定義為 io-ts 運(yùn)行時(shí)類型，這在定義類時(shí)不適用：

-- 有一種變通的辦法是使用 io-ts 定義一個(gè)接口，然后讓類實(shí)現(xiàn)這個(gè)接口。然而，這意味著每次給類增加屬性的時(shí)候都要更新 io-ts 類型。

不容易復(fù)用接口（比如前后端之間使用同一接口），因?yàn)檫@些接口是 io-ts 類型而不是普通的 TypeScript 類型。

基于裝飾器的類校驗(yàn)

比如使用 class-validator 這個(gè)庫(kù)。

基于類屬性的裝飾器。

和 Java 的 JSR-380 Bean Validation 2.0 （比如 Hibernate Validator 就實(shí)現(xiàn)了這一標(biāo)準(zhǔn)）很像。

-- 此類 Java EE 風(fēng)格的庫(kù)還有 typeorm （ORM 庫(kù)，類似 Java 的 JPA）和 routing-controllers （用于定義 API，類似 Java 的 JAX-RS）。

代碼示例：

import { plainToClass } from "class-transformer";import {     validate, IsString, IsInt, Min } from "class-validator";class Person {    @IsString()    firstName: string;    @IsString()    lastName: string;    @IsInt()    @Min(0)    age: number;}const input: any = {    firstName: "Foo",    age: -1};const inputAsClassInstance = plainToClass(    Person, input as Person);validate(inputAsClassInstance).then(errors => {    // 錯(cuò)誤處理代碼});

類型總是同步的。

需要對(duì)類進(jìn)行檢查時(shí)很有用。

可以用來(lái)檢查接口（定義一個(gè)實(shí)現(xiàn)接口的類）。

注意：class-validator 用于具體的類實(shí)例。在上面的代碼中，我們使用它的姊妹庫(kù) class-transformer 將普通輸入轉(zhuǎn)換為 Person 實(shí)例。轉(zhuǎn)換過程本身不進(jìn)行任何類型檢查。

藍(lán)藍(lán)設(shè)計(jì)( m.sdgs6788.com )是一家專注而深入的界面設(shè)計(jì)公司，為期望卓越的國(guó)內(nèi)外企業(yè)提供卓越的UI界面設(shè)計(jì)、BS界面設(shè)計(jì) 、 cs界面設(shè)計(jì) 、 ipad界面設(shè)計(jì) 、 包裝設(shè)計(jì) 、 圖標(biāo)定制 、 用戶體驗(yàn) 、交互設(shè)計(jì)、 網(wǎng)站建設(shè) 、平面設(shè)計(jì)服務(wù)