這篇文章主要介紹“TypeScript之為什么停止使用any”，在日常操作中，相信很多人在TypeScript之為什么停止使用any問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”TypeScript之為什么停止使用any”的疑惑有所幫助！接下來，請跟著小編一起來學(xué)習(xí)吧！

創(chuàng)新互聯(lián)建站-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價(jià)比梁平網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式梁平網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋梁平地區(qū)。費(fèi)用合理售后完善，10余年實(shí)體公司更值得信賴。

什么是 any

因此 any  不是通配符，也不是基類型，它是明確地與第三方庫進(jìn)行交互。那它為什么經(jīng)常出現(xiàn)你呢?它對我們的系統(tǒng)有害嗎?我們應(yīng)該逃避它還是擁抱它?

any 類型是使用現(xiàn)有 JavaScript 的強(qiáng)大方法，可讓您在編譯期間逐漸選擇加入和選擇退出類型檢查。

TypeScript 文檔明確表達(dá)了當(dāng)我們使用any類型時(shí)，我們正在告訴編譯器：

當(dāng)超過500名該語言的貢獻(xiàn)者提供幫助時(shí)，我們說 no thank  you。這聽起來像是選擇退出類型檢查器，有了它，就不能輕易地放棄對類型系統(tǒng)的所有安全性和信心。我們應(yīng)該使用它來與無類型的第三方(或第一方) Javascript  代碼交互，或者當(dāng)我們只知道類型的一部分時(shí)。

但是等等我還有很多其他原因

(1) TypeScript 不會轉(zhuǎn)換為 Javascript 嗎?Javascript  不是動態(tài)的嗎?那我為什么要考慮我的類型呢?

是的!但是我們用 TypeScript 寫代碼，這是一種靜態(tài)類型語言。有人可能會說靜態(tài)類型語言不會比動態(tài)語言產(chǎn)生更少的 bug 。不過，在使用 any  之類的靜態(tài)類型語言中，這是兩種情況中最糟糕的。

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

如果我們沒有正確地輸入，我們將會編寫錯(cuò)誤，比我們在動態(tài)語言中會編寫更多的錯(cuò)誤，因?yàn)槲覀儚?qiáng)制 TypeScript  ，一種靜態(tài)類型語言，去檢查不正確的類型。

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

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

type ParsedType = {   id: number }  const parseApiResponse(   response: Record ): ParsedType => {   const convertedResponse = (response as ParsedType)    // without doing the type cast we would   // get a type error here   if(convertedResponse.id >= 0) {     return convertedResponse   } else {     throw Error.new("Invalid response"   } }

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

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

// version 1 with `any` const fullName = (user: any) => {   if (user?.firstName && user?.lastName) {     return `${user.lastName}, ${user.firstName}`   }    return user?.firstName || "" }  // version 1 without `any`  interface User {   firstName: string   lastName?: string }  const fullName = ({ firstName, lastName }: User) => {   if (lastName === undefined) {     return firstName   }    return `${lastName}, ${firstName}`; }

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

使用 any  可能允許我們在不考慮數(shù)據(jù)如何流入邏輯的情況下更簡單的開發(fā)。但它將這個(gè)負(fù)擔(dān)會轉(zhuǎn)移到我們代碼的未來讀者身上。他們將不得不在沒有上下文和編譯器幫助的情況下解釋發(fā)生了什么。

(6) 有了文檔，我可以提供所有上下文

添加類型時(shí)，我們會從編譯器獲得幫助，并且會獲得不會隨時(shí)間推移而衰減的文檔，因?yàn)槿绻^時(shí)了，我們的代碼將無法編譯。

const intersection = (a: any, b: any): any => { ... } const intersection = (   a: Set, b: Set ): Set => { ... }

它們都是等效的，但是讀者會更好地了解后面的函數(shù)在做什么，而不是從第一個(gè)函數(shù)開始。

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

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

(8) 如果以后我改變主意怎么辦?我可能會為此重構(gòu)幾個(gè)小時(shí)

我們總是可以修改和適應(yīng)新的類型定義， TypeScript 為此提供了一組實(shí)用功能。我們可以 Pick 習(xí)慣從先前定義的類型中選擇所需的屬性。Omit  得到除少數(shù)幾個(gè)以外的所有東西。Partial 使所有屬性都是可選的，或進(jìn)行完整的180并使其全部Requireds。

type User = {   id: number;   firstName: string;   lastName: string;   age: number; }  type UserParams =   Pick & Partial>  const updateUser = (   { id, ...newUserParams }: UserParams ) => {   {...} }

(9) 很好，從TypeScript中刪除 any，立即打開PR

讓我們深吸一口氣， any 它在正確的情況下非常強(qiáng)大且有用。

• 與使用它的庫接口;確保在將數(shù)據(jù)移至系統(tǒng)之前盡快將其轉(zhuǎn)換為正確的類型。

• 解決 TypeScript 類型錯(cuò)誤;如果我們發(fā)現(xiàn)自己無法輸入某些內(nèi)容，則 any  可能有必要。但是只有在嘗試其他所有方法之后才推薦使用。如果使用它，我們應(yīng)該將其重新轉(zhuǎn)換為可預(yù)測的類型。

• 如果我們的函數(shù)可以真正處理任何類型，那么這種情況很少見，并且是偶然的(例如調(diào)試或日志記錄函數(shù))。在這些情況下，我們需要 100%  確保不存在會導(dǎo)致函數(shù)失敗的類型。我們應(yīng)該檢查函數(shù)的主體，并根據(jù)輸入確定最基本的形狀并加以限制。例如，如果我們要打印某些內(nèi)容，則至少應(yīng)驗(yàn)證它是否響應(yīng)  toString 。

到此，關(guān)于“TypeScript之為什么停止使用any”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識，請繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！