What-什么是運行時類型檢查？?
編譯時類型檢查（靜態(tài)類型檢查）：?
在編譯階段對變量類型進行靜態(tài)檢查，編譯后的代碼不保留任何類型標注信息，對實際代碼運行沒有影響
運行時類型檢查（動態(tài)類型檢查）：
在代碼實際運行過程中對數(shù)據(jù)類型進行檢查，一般會用在約束函數(shù)參數(shù)、返回值這類內(nèi)外部之間傳遞數(shù)據(jù)
?Why-為什么需要運行時類型檢查？?TypeScript 對于前端項目可維護性提升很大，也能幫我們保障內(nèi)部編碼時的類型安全，但在和外部進行數(shù)據(jù)傳遞時，僅僅有編譯期類型檢查還是免不了出一些問題，以我遇過的兩次事故為例：
對內(nèi)輸入數(shù)據(jù)：線上接口返回的視頻id字段類型由 string 變?yōu)?number 后前端獲取后丟失精度，導致頁面異常
向外輸出數(shù)據(jù)：項目迭代需求時邏輯改動導致某個埋點字段丟失，過了很久要分析數(shù)據(jù)才發(fā)現(xiàn)，白白浪費了時間
如果我們在運行時做了相應(yīng)的類型檢查，發(fā)現(xiàn)異常上報監(jiān)控，問題就能更早解決了，還有其他能想到的一些需要運行時類型檢查的場景：
- 表單場景類型校驗
- 為API/JSB接口編寫測試
- 上報參數(shù)過濾敏感信息字段
可以看出，在涉及IO數(shù)據(jù)場景時額外的運行時檢查是有必要的，以使數(shù)據(jù)類型不符合預(yù)期時，我們能及時發(fā)現(xiàn)問題。
?How-怎么做運行時類型檢查？?
interface MyDataType {
video_id: string;
user_info: {
user_id: number;
email: string;
};
image_list: {
url: string
}[];
}
const data: MyDataType = await fetchMyData()
if (
typeof data.video_id === 'string' &&
data.user_info &&
typeof data.user_info.user_id === 'number' &&
typeof data.user_info.email === 'string' &&
Array.isArray(data.image_list) &&
data.image_list.every((image) => typeof image.url === 'string')
...
) {
// do something
}如上，我們可以手動編寫一份運行時類型檢查代碼，但這樣寫起來效率低、維護性差，而且沒有用上已有的TS類型，導致我們要同時維護兩份類型，保證之間的同步。
下面向大家介紹業(yè)內(nèi)幾種類型檢查方案，個人認為一個好方案至少要滿足兩點：
只需維護一份類型規(guī)則即可享有靜態(tài)類型提示和運行時檢查校驗
在靜態(tài)和運行時的類型檢查能力等價（起碼運行時不能比靜態(tài)檢查寬松，不然會出線上bug）
方案1-動態(tài) to 靜態(tài)
編寫運行時校驗規(guī)則，并從中提取出靜態(tài)類型
JSON 形式
通過編寫 JSON 來描述校驗規(guī)則，典型的有 ajv、tv4，用法如下：
import Ajv, { JTDDataType } from "ajv/dist/jtd"
const ajv = new Ajv()
const schema = {
properties: {
video_id: { type: "string" },
user_info: {
properties: {
user_id: { type: "int32" },
email: { type: "string" }
}
},
image_list: {
elements: {
properties: {
url: { type: "string" },
}
}
}
}
} as const
type MyDataType = JTDDataType<typeof schema>
// type MyDataType = {
// video_id: string;
// user_info: {
// user_id: number;
// email: string;
// } & {};
// image_list: ({
// url: string;
// } & {})[];
// } & {}
const data: MyDataType = await fetchMyData()
const validate = ajv.compile(schema)
validate(data)
if (validate.errors) {
// do something
}優(yōu)點：
JTD 支持從已有的schema提取TS類型，避免維護兩份類型定義
校驗庫都會提供一些常用的高級校驗規(guī)則（如日期范圍、郵箱格式等）
JSON 格式易存儲傳輸，甚至其他語言也能用，可以做到動態(tài)下發(fā)校驗規(guī)則
缺點：
Schema 格式有額外學習成本，JSON 寫起來太過冗長枯燥提示也不友好
實現(xiàn)原理：
類型檢查：根據(jù) schema 規(guī)則遍歷比較數(shù)據(jù)字段
提取類型：結(jié)合 extends、infer、in keyof、遞歸等語法
API 形式
通過調(diào)用API來描述組成校驗規(guī)則，典型例子有 zod 、superstruct、io-ts，用法如下：
import { z } from "zod";
const schema = z.object({
video_id: z.string(),
user_info: z.object({
user_id: z.number().positive(),
email: z.string().email()
}),
image_list: z.array(z.object({
url: z.string()
}))
});
type MyDataType = z.infer<typeof schema>
// type MyDataType = {
// video_id: string;
// user_info: {
// user_id: number;
// email: string;
// };
// image_list: {
// url: string;
// }[];
// }
const data: MyDataType = await fetchMyData()
const parseRes = schema.safeParse(data)
if (parseRes.error) {
// do something
}優(yōu)點：
通過API組裝類型的形式相比JSON更靈活和易編寫
提供一些常用的高級校驗規(guī)則（如日期范圍、郵箱格式等）
支持從已有的schema提取TS類型，避免維護兩份類型定義
缺點：
有一些額外學習成本，不能直接運用我們已掌握的TS語法描述類型
實現(xiàn)原理：
和JSON形式類似，但實現(xiàn)更輕量（ajv有35k，zod只有10k）
方案2-靜態(tài) + 動態(tài)
把靜態(tài)類型和動態(tài)類型檢查寫在一起
主要是基于類屬性裝飾器來生成校驗規(guī)則，典型例子有 class-validator、typeorm，用法如下：
import 'reflect-metadata'
import { plainToClass, Type } from "class-transformer";
import {
validate,
IsString,
IsInt,
IsEmail,
IsObject,
IsArray,
ValidateNested,
} from "class-validator";
class UserInfo {
@IsInt()
user_id: number;
@Length(10, 20,{message: 'name的長度不能小于10不能大于20'})
@IsEmail()
email: string;
}
class LargeImage {
@IsString()
url: string
}
class MyData {
@IsString()
@IsNotEmpty({message:'video_id 不能為空'})
video_id: string;
@IsObject()
@ValidateNested()
@Type(() => UserInfo)
user_info: UserInfo;
@IsArray({message:'數(shù)組 不能為空'})
@ValidateNested({each: true})
@Type(() => LargeImage)
image_list: LargeImage[];
}
const data: MyData = await fetchMyData()
const dataAsClassInstance = plainToClass(
MyData, data
);
validate(dataAsClassInstance).then(message => {
// do something
});
優(yōu)點：
強迫分原子類型，ORM風格，適合服務(wù)端場景使用
提供一些常用的高級校驗規(guī)則（如日期范圍、郵箱格式等）
校驗屬性值的報錯信息可以自定義，如@IsArray({message:'數(shù)組 不能為空'})
缺點：
運行時檢查類型和TS類型都要寫，但寫在一塊起碼方便同步
校驗規(guī)則需要聲明class，特別是有嵌套對象時，寫起來麻煩
只能檢查類的實例，普通對象要配合 class-transformer 轉(zhuǎn)換
實現(xiàn)原理：
裝飾器+反射（通過裝飾器給字段加入類型規(guī)則元數(shù)據(jù)，運行時再通過反射獲取這些元數(shù)據(jù)做校驗）
方案3-靜態(tài) to 動態(tài)
通過處理 TS 類型，使之在運行時可用
TS類型自動轉(zhuǎn)換JSON Schema
典型例子有 typescript-json-schema，用法如下：
優(yōu)點：
不需要手動維護兩份類型定義
缺點：
本身不提供檢查能力，需要配合額外校驗庫
部分TS類型語法不支持轉(zhuǎn)換（如聯(lián)合類型）
有些規(guī)則需要另外學習它的注釋語法，寫起來也不方便
實現(xiàn)原理：
解析處理 TypeScript AST https://github.com/YousefED/typescript-json-schema/blob/master/typescript-json-schema.ts
編譯期從TS類型生成檢查代碼
在編譯期將TS代碼轉(zhuǎn)成類型檢查能力等價的JS代碼，典型例子有 typescript-is、ts-auto-guard，用法如下：
配置 ts-loader 插件：
import typescriptIsTransformer from 'typescript-is/lib/transform-inline/transformer'
...
{
test: /.ts$/,
exclude: /node_modules/,
loader: 'ts-loader',
options: {
getCustomTransformers: program => ({
before: [typescriptIsTransformer(program)]
})
}
}
...
編譯前源代碼：
import { is } from "typescript-is"
interface MyDataType {
gid: number;
user_info: {
user_id: number;
email: string;
};
large_image_list: {
url: string;
}[];
}
const data: MyDataType = fetchMyData()
const isRightType = is<MyDataType>(data)編譯產(chǎn)物代碼：
Object.defineProperty(exports, "__esModule", { value: true });
const typescript_is_1 = require("typescript-is");
const data = (0, fetchMyData)();
const isRightType = (0, typescript_is_1.is)(data, object => { function _number(object) { ; if (typeof object !== "number")
return {};
else
return null; } function _string(object) { ; if (typeof object !== "string")
return {};
else
return null; } function _1(object) { ; if (typeof object !== "object" || object === null || Array.isArray(object))
return {}; {
if ("user_id" in object) {
var error = _number(object["user_id"]);
if (error)
return error;
}
else
return {};
} {
if ("email" in object) {
var error = _string(object["email"]);
if (error)
return error;
}
else
return {};
} return null; } function _4(object) { ; if (typeof object !== "object" || object === null || Array.isArray(object))
return {}; {
if ("url" in object) {
var error = _string(object["url"]);
if (error)
return error;
}
else
return {};
} return null; } function sa__4_ea_4(object) { ; if (!Array.isArray(object))
return {}; for (let i = 0; i < object.length; i++) {
var error = _4(object[i]);
if (error)
return error;
} return null; } function _0(object) { ; if (typeof object !== "object" || object === null || Array.isArray(object))
return {}; {
if ("video_id" in object) {
var error = _number(object["video_id"]);
if (error)
return error;
}
else
return {};
} {
if ("user_info" in object) {
var error = _1(object["user_info"]);
if (error)
return error;
}
else
return {};
} {
if ("image_list" in object) {
var error = sa__4_ea_4(object["image_list"]);
if (error)
return error;
}
else
return {};
} return null; } return _0(object); });優(yōu)點：
使用方便，無需維護兩份類型和學習額外校驗規(guī)則，只寫TS代碼就行
缺點：
每次會生成大片檢查代碼（即使類型存在復用），導致代碼產(chǎn)物體積膨脹
校驗?zāi)芰ν耆蕾嘥S類型檢查，不像校驗庫有一些高級規(guī)則（如日期范圍、郵箱格式等）
實現(xiàn)原理：
編寫 TypeScript Transformer Plugin，運行機制類似 babel 插件（源碼->解析語法樹->修改語法樹->轉(zhuǎn)換）
提取TS類型信息在運行時動態(tài)檢查
典型的方案有 DeepKit，基本上是把TS類型系統(tǒng)帶到了JS運行時：
編譯前源代碼：
import { is } from '@deepkit/type'
interface MyDataType {
video_id: string;
user_info: {
user_id: number;
email: string;
};
image_list: {
url: string;
}[];
}
const data: MyDataType = await fetchMyData()
const isRightType = is<MyDataType>(data)編譯產(chǎn)物代碼：
Object.defineProperty(exports, "__esModule", ({ value: true }));
const type_1 = __webpack_require__(/*! @deepkit/type */ "@deepkit/type");
const __ΩMyDataType = ['video_id', 'user_id', 'email', 'user_info', 'url', 'image_list', 'P&4!P&4"'4#&4$M4%P&4&MF4'M'];
const data = (0, fetchMyData)();
const isRes = (0, type_1.is)(data, undefined, undefined, [() => __ΩMyDataType, 'n!']);
console.log('deepkit', isRes);優(yōu)點：
- 使用方便，無需維護兩份類型，且提供郵箱格式等高級校驗?zāi)芰?/li>
- 類型校驗規(guī)則編譯后生成的運行時代碼很少，體積不容易膨脹
缺點：
- 項目較新，還沒有被大范圍使用，穩(wěn)定性未知
- 運行時的類型解釋器可能比較重，性能開銷未知
實現(xiàn)原理：
在編譯期將 TypeScript 類型信息轉(zhuǎn)換成字節(jié)碼（Bytecode），TS 類型信息都被完整保留到了運行時，之后在運行時用一個解釋器計算出類型信息，我們在運行時也能使用它提供的豐富 API 反射類型信息，用在如生成 Mock 數(shù)據(jù)的場景。
import { typeOf, ReflectionKind } from '@deepkit/type';
typeOf<string>(); // {kind: ReflectionKind.string}
typeOf<number>(); // {kind: ReflectionKind.number}
typeOf<boolean>(); // {kind: ReflectionKind.boolean}
typeOf<string | number>();
// {kind: ReflectionKind.union, types: [{kind: ReflectionKind.string}, {kind: ReflectionKind.number}]}
class MyClass {
id: number = 0;
}
typeOf<MyClass>();
//{kind: ReflectionKind.class, classType: MyClass, types: [
// {kind: ReflectionKind.property, name: 'id', type: {kind: ReflectionKind.number}, default: () => 0}
//]}
import { ReflectionClass } from '@deepkit/type';
class MyClass {
id: number = 0;
doIt(arg: string): void {}
}
const reflection = ReflectionClass.from(MyClass);
reflection.getProperty('id').type; // {kind: ReflectionKind.number}
reflection.getProperty('id').isOptional(); //false
reflection.getPropertyNames(): ['id'];
reflection.getMethod('doIt').getReturnType(); //{kind: ReflectionKind.void}
reflection.getMethod('doIt').getParameter('arg').type; //{kind: ReflectionKind.string}
//works with interfaces as well
interface User {
id: number;
}
const reflection = ReflectionClass.from<User>();?總結(jié)?
沒有十全十美的方案，綜合來看當下使用如 zod 這類 API 形式的校驗庫會比較好，既成熟強大，也兼具靈活和易。，著眼未來 deepkit 似乎很有潛力，它其實是一整套 Web 開發(fā)方案，校驗只是其中一部分，還有很多充分利用了運行時類型的功能特性。
那以后 TypeScript 會支持運行時類型檢查嗎？github 上也一直有人提相關(guān)的 issue，甚至有人專門建了一個請愿頁面，但基本不太可能，因為 design goal 中已明確表示過不會增加任何運行時代碼：
Add or rely on run-time type information in programs, or emit different code based on the results of the type system. Instead, encourage programming patterns that do not require run-time metadata.
