前言

在群里看到一些問題和言論：為什么你們這么喜歡“類型體操”？為什么我根本學(xué)不下去 TypeScript？我最討厭那些做類型體操的了；為什么我學(xué)了沒過多久馬上又忘了？

有感于這些問題，我想從最簡單的一個角度來切入介紹一下 TypeScript，并向大家介紹并不是只要是個類型運(yùn)算就是體操。并在文中介紹一種基本思想作為你使用類型系統(tǒng)的基本指引。

引子

我將從一個相對簡單的 API 的設(shè)計過程中闡述關(guān)于類型的故事。在這里我們可以假設(shè)我們現(xiàn)在是一個工具的開發(fā)者，然后我們需要設(shè)計一個 API 用于從對象中拿取指定的一些 key 作為一個新的對象返回給外面使用。

垃圾 TypeScript

一個人說：我才不用什么破類型，我寫代碼就是要沒有類型，我就是要隨心所欲的寫。然后寫下了這段代碼。

declare function pick(target: any, ...keys: any): any

他的用戶默默的寫下了這段代碼：

pick(undefined, 'a', 1).b

寫完運(yùn)行，發(fā)現(xiàn)問題大條了，控制臺一堆報錯，接口數(shù)據(jù)也提交不上去了，怎么辦呢？

剛學(xué) TypeScript

一個人說：稍微檢查一下傳入類型就好了，別讓人給我亂傳參數(shù)就行。

declare function pick(target: Record<string, unknown>, ...keys: string[]): unknown

很好，上面的問題便不復(fù)存在了，API 也是基本可用的了。但是！當(dāng)對象復(fù)雜的時候，以及字段并不是短單詞長度的時候就會發(fā)現(xiàn)了一個沒解決的問題。

pick({ abcdefghijkl: '123' }, 'abcdefghikjl')

從肉眼角度上，我們很難發(fā)現(xiàn)這前后的不一致，所以我們?yōu)槭裁匆屨{(diào)用方的用戶自己去 check 自己的字段有沒有寫對呢？

不就 TypeScript

一個人說：這還不簡單，用個泛型加 keyof 不就行了。

declare function pick<
  T extends Record<string, unknown>
>(target: T, ...keys: (keyof T)[]): unknown

我們又進(jìn)一步解決的上面的問題，但是！還是有著相似的問題，雖然我們不用檢查 keys 是不是傳入的是一個正確的值了，但是我們實際上對返回的值也存在一個類似的問題。

pick({ abcdefghijkl: '123' }, 'abcdefghijkl').abcdefghikjl

一點小小的拓展

在這里我們看起來似乎是一個很簡單的功能，但實際上蘊(yùn)含著一個比較重要的信息。

為什么我們之前的方式都拿不到用戶傳入進(jìn)來的類型信息呢？是有原因的，當(dāng)我們設(shè)計的 API 的時候，前面的角度是從，如何校驗類型方向進(jìn)行的思考。

而這里是嘗試去通過約定好的一種規(guī)則，通過 TypeScript 的隱式類型推斷獲得到傳入的類型，再通過約定的規(guī)則轉(zhuǎn)化出一種新的類型約束來對用戶的輸入進(jìn)行限制。

算算 TypeScript

一個人說：好辦，算出來一個新的類型就好了。

declare function pick<
  T extends Record<string, unknown>,
  Keys extends keyof T
>(target: T, ...keys: Keys[]): {
  [K in Keys]: T[K]
}

到這里已經(jīng)是對類型的作用有了基礎(chǔ)的了解了，能寫出來符合開發(fā)者所能接受的類型相對友好的代碼了。我們可以再來思考一些更特殊的情況：

// 輸入了重復(fù)的 key
pick({ a: '' }, 'a', 'a')

完美 TypeScript

到這里，我們便是初步開始了類型“體操”。但是在本篇里，我們不去分析它。

export type L2T<L, LAlias = L, LAlias2 = L> = [L] extends [never]
  ? []
  : L extends infer LItem
    ? [LItem?, ...L2T<Exclude<LAlias2, LItem>, LAlias>]
    : never

declare function pick<
  T extends Record<string, unknown>,
  Keys extends L2T<keyof T>
>(target: T, ...keys: Keys): Pick<T, Keys[number] & keyof T>

const x0 = pick({ a: '1', b: '2' }, 'a')
console.log(x0.a)
// @ts-expect-error
console.log(x0.b)

const x1 = pick({ a: '1', b: '2' }, 'a', 'a')
//                                  ^^^^^^^^
// TS2345: Argument of type '["a", "a"]' is not assignable to parameter of type '["a"?, "b"?] | ["b"?, "a"?]'.
//   Type '["a", "a"]' is not assignable to type '["a"?, "b"?]'.
//     Type at position 1 in source is not compatible with type at position 1 in target.
//       Type '"a"' is not assignable to type '"b"'.

一個相對來說比較完美的 pick 函數(shù)便完成了。

總結(jié)

我們再來回到我們的標(biāo)題吧，從我對大多數(shù)人的觀察來說，很多的人開始來使用 TypeScript 有幾種原因：

看到大佬們都在玩，所以自己也想來“玩”，然后為了過類型校驗而去寫
看到一些成熟的項目在使用 TypeScript ，想?yún)⑴c貢獻(xiàn)，參與過程中為了讓類型通過而想辦法去解決類型報錯
公司整體技術(shù)棧采用的是 TypeScript ，要用 TypeScript 進(jìn)行業(yè)務(wù)編寫，從而為了過類型檢查和 review 而去解決類型問題

諸如此類的問題還有很多，我將這種都劃分為「為了解決類型檢查的問題」而進(jìn)行的類型編程，這也是大多數(shù)人為什么非常不適應(yīng) TypeScript，甚至不喜歡他的一個原因。這其實對學(xué)習(xí) TypeScript 并不是一個很好的思路，在這里我覺得我們需要站在設(shè)計者的角度去對類型系統(tǒng)進(jìn)行思考。我覺得有以下幾個角度：