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

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

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

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

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

運行時類型檢查策略

定制代碼手動檢查

靈活

可能比較枯燥，容易出錯

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

使用校驗庫手動檢查

比如使用 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()});

靈活

容易編寫

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

手動創(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)格式，有大量庫可以校驗。

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

可能會很冗長，手寫 JSON Schema 可能會很枯燥。

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

自動創(chuàng)建 JSON Schema

基于 TypeScript 代碼生成 JSON Schema

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

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

基于 JSON 輸入示例生成

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

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

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

轉(zhuǎn)譯

例如使用 ts-runtime。

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

比如，下面的代碼：

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

會被轉(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});

這一方式的缺陷是無法控制在何處進行運行時檢查（我們只需在輸入輸出的邊界處進行運行時類型檢查）。

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

運行時類型派生靜態(tài)類型

比如使用 io-ts 這個庫。

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

運行時類型示例：

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> {}

以上類型等價于：

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

類型總是同步的。

io-ts 很強大，比如支持遞歸類型。

需要將類型定義為 io-ts 運行時類型，這在定義類時不適用：

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

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

基于裝飾器的類校驗

比如使用 class-validator 這個庫。

基于類屬性的裝飾器。

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

-- 此類 Java EE 風(fēng)格的庫還有 typeorm （ORM 庫，類似 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 => {    // 錯誤處理代碼});

類型總是同步的。

需要對類進行檢查時很有用。

可以用來檢查接口（定義一個實現(xiàn)接口的類）。

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

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