TypeScript + React 類型安全三件套:Component、Redux、和Service類型化。ios
首先須要明確先後端交互的基本接口規範,例如,全部接口返回數據格式都應該遵循:git
interface AjaxResult<R extends any> {
/** 錯誤碼 */
code?: number | null;
/** 描述信息 */
message?: string | null;
/** 數據主體 */
result: R
}
複製代碼
而對應的,全部接口調用函數應該遵循這樣接口定義:github
interface AjaxFunction {
(...args: any[]): Promise<AjaxResult<any>>
}
複製代碼
業務邏輯裏須要明確的就是,接口定義裏入參和響應數據主體的類型。web
舉個獲取用戶信息接口例子,經過後端提供的任意格式的文檔,好比 swagger、yapi 甚至 wiki 得知:json
/api/user/info
id
手寫成 TypeScript 調用代碼:axios
/** 後端數據主體 */
interface UserResult {
/** id */
id: number;
/** 英文名 */
name: string;
}
/** 接口調用代碼 */
const getUserInfo = (id: number): AjaxResult<UserResult> => axios.get('/api/user/info', { id })
複製代碼
@tefe/service
】從前邊的例子,可知 Service 類型化真正的痛點在於基於接口文檔手寫 TypeScript 代碼,在已有 swagger 或者 yapi 文檔格式化數據的狀況下,這無異於重複的人力浪費,找到一套自動化生成技術方案,將極大的提高研發效率。後端
基於 Java 代碼註解提取文檔的 Swagger 體系裏,有提供了全套的 Java 註解、註解解析、文檔UI界面以及生成各類語言調用代碼的技術工具方案 Swagger-Codegen。api
該方案支持生成 TypeScript 類型、接口調用代碼,其核心數據轉換、生成規則以下:安全
基於以上規則,咱們很容易發現,該方案存在如下隱患:函數
這些隱患會致使當知足特定條件時,生成的代碼會發生不可控的變更,進而致使邏輯錯亂,形成十分嚴重的後果。
sm2tsservice 改造了 swagger-codegen,並在此基礎上進行了封裝,旨在解決業務使用上的痛點:
將 yapi 文檔轉換成 swagger 文檔,曲線支持 yapi 自動生成 service 代碼,轉換規則以下:
接口規範,旨在消除人爲形成的不肯定性,其中核心條目包括:
校驗 swagger 文檔是否符合規範,校訂 operationId 的生成方式,核心規則以下:
定製 swagger-codegen 代碼,修改調用函數格式:
將接口文檔分爲本地和遠端版本,本地版本跟隨 vcs 進行維護;每次生成代碼,會下載遠端版本,而後與本地版本進行 diff,將差別已 web 界面的形式顯示出來,供選擇任意差別、增量更新:
提供 proxy 插件,可在聯調階段對接口入參、後端返回,依照對應的 swagger 文檔約定進行校驗,默承認以打印出不符合約定的接口錯誤。