2020-7-10 seo達人
為什么需要額外的類型檢查？
TypeScript 只在編譯期執行靜態類型檢查！實際運行的是從 TypeScript 編譯的 JavaScript，這些生成的 JavaScript 對類型一無所知。編譯期靜態類型檢查在代碼庫內部能發揮很大作用，但對不合規范的輸入（比如，從 API 處接收的輸入）無能為力。
運行時檢查的嚴格性
至少需要和編譯期檢查一樣嚴格，否則就失去了編譯期檢查提供的保證。
如有必要，可以比編譯期檢查更嚴格，例如，年齡需要大于等于 0。
運行時類型檢查策略
定制代碼手動檢查
靈活
可能比較枯燥，容易出錯
容易和實際代碼脫節
使用校驗庫手動檢查
比如使用 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()});
靈活
容易編寫
容易和實際代碼脫節
手動創建 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 } }}
使用標準格式，有大量庫可以校驗。
JSON 很容易存儲和復用。
可能會很冗長，手寫 JSON Schema 可能會很枯燥。
需要確保 Schema 和代碼同步更新。
自動創建 JSON Schema
基于 TypeScript 代碼生成 JSON Schema
-- 比如 typescript-json-schema 這個工具就可以做到這一點（同時支持作為命令行工具使用和通過代碼調用）。
-- 需要確保 Schema 和代碼同步更新。
基于 JSON 輸入示例生成
-- 沒有使用已經在 TypeScript 代碼中定義的類型信息。
-- 如果提供的 JSON 輸入示例和實際輸入不一致，可能導致錯誤。
-- 仍然需要確保 Schema 和代碼同步更新。
轉譯
例如使用 ts-runtime。
這種方式會將代碼轉譯成功能上等價但內置運行時類型檢查的代碼。
比如，下面的代碼：
interface Person { firstName: string; lastName: string; age: number;}const test: Person = { firstName: "Foo", lastName: "Bar", age: 55}
會被轉譯為：
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});
這一方式的缺陷是無法控制在何處進行運行時檢查（我們只需在輸入輸出的邊界處進行運行時類型檢查）。
順便提一下，這是一個實驗性的庫，不建議在生產環境使用。
運行時類型派生靜態類型
比如使用 io-ts 這個庫。
這一方式下，我們定義運行時類型，TypeScript 會根據我們定義的運行時類型推斷出靜態類型。
運行時類型示例：
import t from "io-ts";const PersonType = t.type({ firstName: t.string, lastName: t.string, age: t.refinement(t.number, n => n >= 0, 'Positive')})
從中提取相應的靜態類型：
interface Person extends t.TypeOf<typeof PersonType> {}
以上類型等價于：
interface Person { firstName: string; lastName: string; age: number;}
類型總是同步的。
io-ts 很強大，比如支持遞歸類型。
需要將類型定義為 io-ts 運行時類型，這在定義類時不適用：
-- 有一種變通的辦法是使用 io-ts 定義一個接口，然后讓類實現這個接口。然而，這意味著每次給類增加屬性的時候都要更新 io-ts 類型。
不容易復用接口（比如前后端之間使用同一接口），因為這些接口是 io-ts 類型而不是普通的 TypeScript 類型。
基于裝飾器的類校驗
比如使用 class-validator 這個庫。
基于類屬性的裝飾器。
和 Java 的 JSR-380 Bean Validation 2.0 （比如 Hibernate Validator 就實現了這一標準）很像。
-- 此類 Java EE 風格的庫還有 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 => { // 錯誤處理代碼});
類型總是同步的。
需要對類進行檢查時很有用。
可以用來檢查接口（定義一個實現接口的類）。
注意：class-validator 用于具體的類實例。在上面的代碼中，我們使用它的姊妹庫 class-transformer 將普通輸入轉換為 Person 實例。轉換過程本身不進行任何類型檢查。
藍藍設計( www.izc.net.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務