[[415751]]

本文轉(zhuǎn)載自微信公眾號(hào)「三分鐘學(xué)前端」，作者 sisterAn 。轉(zhuǎn)載本文請(qǐng)聯(lián)系三分鐘學(xué)前端公眾號(hào)。

any

在 TypeScript 中，任何類型的值都可以賦值給 any ， any 也可以賦值給任意類型，因此，any 類型通常也被稱為 top type

let notSure: any 
 
// 可以被賦值任意類型 
notSure = 'sisterAn!' 
notSure = 512 
notSure = { hello: () => 'Hello sisterAn!' } 
 
// 它也兼容任何類型 
let num: number = 12 
notSure = num 
num = notSure 

any 類型用于描述一個(gè)我們根本不知道類型的變量，或者說(shuō)可以是任意類型的變量，常用于用戶的輸入或第三方代碼庫(kù)(不確定用戶輸入值的類型，第三方代碼庫(kù)是如何工作的)，當(dāng)我們剛接觸 TypeScript 時(shí)， 或把 JavaScript 遷移至 TypeScript 時(shí)，經(jīng)常會(huì)使用它，畢竟一寫 any ，什么報(bào)錯(cuò)都沒(méi)了

但大量使用 any 類型并不好，any 類型會(huì)提供一個(gè)類型系統(tǒng)的「后門」，當(dāng)使用 any 時(shí)，你基本上是在告訴 TypeScript 編譯器不要進(jìn)行任何的類型檢查。沒(méi)有強(qiáng)制的類型檢查，這在項(xiàng)目開(kāi)發(fā)過(guò)程中可能會(huì)帶來(lái)一些問(wèn)題。

any 的問(wèn)題

1. 類型污染

any 類型的對(duì)象會(huì)導(dǎo)致后續(xù)的屬性類型都會(huì)變成 any ：

let user: any = { 
  sister: { 
    name: 'sisterAn' 
  } 
}; 
let sister = user.sister // any 
let url = sister.url // any 

2. 使用不存在的屬性或方法而不報(bào)錯(cuò)

const notSure: any = 'sisterAn' 
notSure.hello() // no error 

所以，建議能不用 any 別用 any ，盡量少的使用 any

使用 any 更簡(jiǎn)單的場(chǎng)景，如何停止使用?

1. 添加類型時(shí)，我必須編寫大量代碼，any 工作量較少

可能不是，如果編寫的代碼為 any 類型，我們可能需要添加防御性代碼，以確保參數(shù)和變量具有正確的類型，以使程序能夠按預(yù)期執(zhí)行。any 甚至無(wú)法防范 null 或 undefined

2. 我已經(jīng)通過(guò)必要的運(yùn)行時(shí)檢查以防御性的方式編寫了代碼，以確保沒(méi)有錯(cuò)誤

現(xiàn)在可能沒(méi)有錯(cuò)誤，但是除非你有很好的測(cè)試覆蓋率，否則以后來(lái)修改代碼的人不會(huì)相信他們不是在錯(cuò)誤中重構(gòu);就好像編譯器不會(huì)幫你，因?yàn)槲覀冋f(shuō)過(guò)它不會(huì)幫你。如果我們顯式地設(shè)置類型并更改系統(tǒng)中使用的API，編譯器將提供它的指導(dǎo)。

3. 有些參數(shù)很難正確輸入，但是 any 更容易

如果我們將一些很難確定類型的輸入定義為 any 類型，那么我們?cè)诤笃谌绻麤](méi)有正確地輸入，將會(huì)造成編寫錯(cuò)誤，比我們?cè)?JavaScript 會(huì)編寫更多的錯(cuò)誤，既然我們已經(jīng)強(qiáng)制使用了 TypeScript ，就應(yīng)該去利用它的特性，強(qiáng)制檢查不正確的類型

4. 我真的不知道參數(shù)是什么

沒(méi)關(guān)系! 我們可以用 unknown ; 它允許我們確實(shí)分配任何類型。但在確定特定類型之前，我們將不允許使用這些值。

function getName() { 
 return 'sisterAn' 
} 
 
let sisterAn: unknown = getName() 
sisterAn.hello() //Object is of type 'unknown' 

5. 類型增加了很多復(fù)雜性，有時(shí) any 更簡(jiǎn)單

使用 any 可能允許我們?cè)诓豢紤]數(shù)據(jù)如何流入邏輯的情況下更簡(jiǎn)單的開(kāi)發(fā)。但它將這個(gè)負(fù)擔(dān)會(huì)轉(zhuǎn)移到我們代碼的后期維護(hù)人、重構(gòu)人身上。他們將不得不在沒(méi)有上下文和編譯器幫助的情況下理解項(xiàng)目是如何運(yùn)行的，

總結(jié)

所以，我們能不用 any 別用 any ：

• 它使編譯器過(guò)時(shí)了，我們告訴編譯器：我不需要你的幫助
• 我們放棄了在編寫代碼時(shí)記錄代碼的機(jī)會(huì)
• 我們的第一道防線被攻破了
• 在動(dòng)態(tài)語(yǔ)言中，我們假設(shè)事物可以有 any 類型，我們采用的模式遵循這個(gè)假設(shè)。如果我們開(kāi)始使用靜態(tài)類型語(yǔ)言作為動(dòng)態(tài)語(yǔ)言，那么我們就是在與范式作斗爭(zhēng)
• 當(dāng)我們繼續(xù)對(duì)代碼庫(kù)進(jìn)行更改時(shí)，沒(méi)有什么可以指導(dǎo)/幫助我們。
• 自由越大，責(zé)任越大(編譯器)。不要變成一個(gè)編譯器，我們的目的是使用編譯器。

參考

TypeScript：請(qǐng)停止使用 any

來(lái)源：https://github.com/Advanced-Frontend/Daily-Interview-Question