本文章是我在團隊日常開發中發現的一些問題的總結，有不對的地方歡迎大家指出，互相學習、共同進步~~

類型不會復用

在日常開發中，一般我們對于每個接口都要定義好請求參數的類型和返回參數的類型。而對于一些比較常見的功能，我們一般會有固定的參數和一些固定的返回字段。

例如列表接口，我們一定會帶上page和rows,這個時候我們就可以先寫一個基礎的列表請求類型如:

interface ReqPage {
  current?: number;
  size?: number;
}

這樣在后續其他列表的請求參數，我們在定義的時候就可以繼承這個ReqPage去復用。假設我們現在有一個UserList接口，我們定義請求參數的類型就可以這樣寫：

interface UserListParams extends ReqPage {
  name: string;
  id: string | number;
}

另外對象類型也有喜歡用type定義的小伙伴，那么對于type我們同樣可以復用，但是形式上稍微有點不同，還是上面的例子

type ReqPage =  { current?: number; size?: number };

type UserListParams = { 
    name: string;
    id: string | number;
} & ReqPage

對于返回參數的類型定義也一樣，后端接口一般有幾個字段例如creatTime, updateTime等是必定返回的，我們可以提前定義一個基類用于其他返回類型去繼承復用。

不會使用工具類型

TypeScipt內部提供了很多工具類型如:Partial、Pick、Exclude、Omit等

舉個在日常工作中經常遇到的例子，還是后臺管理系統中常見的列表功能。一般我們的表格會有一些搜索字段，這個時候我們就可以用上我們的工具類型了

假如我們現在有一個用戶列表，他的返回格式如下：

interface ResUser {
    name: string;
    id: string | number;
    age: number;
    grade: number;
}

如果我們要將name作為搜索條件，那么你的請求參數類型應該怎么定義呢？我們可以使用工具類: Pick 或者 Exclude

type ReqUser = Pick<ResUser, "name"> & ReqPage;

如果搜索條件的字段較多的時候我們就可以考慮使用Exclude方法

個人認為使用工具類有兩個好處:

1. 將兩個有關聯的類型關聯起來，而不是憑空創造一個新的類型。讓團隊中的其他人知道她們是屬于一個功能模塊的。
2. 增加復用性，而不是單純的copy yourself

不會使用泛型

還是上面列表接口的例子，我們一般列表分頁接口的返回會包含幾個通用的字段，例如: records-當前頁數的數據, total-總頁數， pages-總頁數等等。但是對于不同的接口我們所需要定義的類型是肯定不一樣的，就是說records對應的類型肯定是不同的。

這時候就有小伙伴想起上面的復用了。但是除此之外我們還有更好的方法實現-就是泛型

// 分頁響應參數
interface ResPage<T> {
  records: T[];
  current: number;
  size: number;
  total: number;
}

通過泛型我們就可以很好的定義。我個人認為泛型就是一個 “類型變量”，它在代碼編寫階段可以代表多種類型，在實際使用時再確定具體類型。再看下面的例子：

function handle<T>(input: T): T {}

const author = "test"; // 使用 const 聲明，被推導為 "tst"

let authorAge = 18; // 使用 let 聲明，被推導為 number

handle(author); // 填充為字面量類型 "test"
handle(authorAge); // 填充為基礎類型 number

泛型對于我們開發中寫一些公用的基礎類型、公用方法、公用hooks很有用，大家可以多學習一下。

圖方便亂用any

相信AnyScript的名號大家都嗤之以鼻，但是在實際開發中，還是有很多場景會因為一時的方便，而使用了any跳過校驗。

// 片段1
const onChange = (value: any) => {
  emit("change", value);
};

// 片段2 
let provinceCode: any = "";

上面這兩段代碼都是我在我們團隊的項目中找出來的，類似的代碼還有很多。

其實我覺得用any偷懶這個問題，并不是技術水平上的問題而是自己的態度問題。像上面例子中的provinceCode，我們有必要用any去定義類型嗎？

我們應該在每次想使用any之前多問自己一下，這個類型真的無法定義嗎？能用unknown代替嗎？我相信就會有結果。

不會使用框架或組件庫里的類型

我的項目中常用到的是vue3,element-plus和uni-app等

舉個最簡單的例子，我發現有的開發小伙伴居然不知道vue3里面的ref,computed是可以定義類型的~~

// ref
const userName = ref<string>("");

// computed
const userName = computed<string>(() => {
    return "haha";
});

同樣的對element-plus,使用的時候可以多看下文檔，看下怎么定義類型：

對于一些第三方庫文檔上沒有的類型定義，可以自己翻查一下node_modules/types或者對應第三方庫的d.ts文件。

舉個例子這是uni對應的類型定義，看一下學習一下對于自己的水平也會大有提升。

不會使用枚舉和字面量類型

在項目中，我們可以定義一些枚舉，然后在定義新的類型時，可以使用這些枚舉使我們的類型更加準確：

enum SideDeptFlagEnum {
  INSIDE = 1, // 內部單位
  OUTSIDE = 2 // 外部單位
}

interface Dept {
    name: string;
    flag: SideDeptFlagEnum;
}

這樣子定義的話，我們在賦值的時候就會獲得準確的提示。如果我們定義成普通的number類型的話，則無法校驗是否1或者2.當然我們也可以定義成字面量類型~~

寫在最后

其實t本質上與js沒有區別，我們要把它當作是一個工具，去幫助我們提升代碼的健壯性，不要產生抵觸情緒。既然用了就要用好，擁抱它。