日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

RELATEED CONSULTING
相關(guān)咨詢
選擇下列產(chǎn)品馬上在線溝通
服務(wù)時(shí)間：8:30-17:00
你可能遇到了下面的問(wèn)題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營(yíng)銷解決方案
10個(gè)寫(xiě)TypeScript代碼的壞習(xí)慣

近幾年 TypeScript 和 JavaScript 一直在穩(wěn)步發(fā)展。我們?cè)谶^(guò)去寫(xiě)代碼時(shí)養(yǎng)成了一些習(xí)慣，而有些習(xí)慣卻沒(méi)有什么意義。以下是我們都應(yīng)該改正的 10 個(gè)壞習(xí)慣。

在怒江州等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強(qiáng)發(fā)展的系統(tǒng)性、市場(chǎng)前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務(wù)理念，為客戶提供網(wǎng)站建設(shè)、成都做網(wǎng)站 網(wǎng)站設(shè)計(jì)制作按需網(wǎng)站制作,公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),高端網(wǎng)站設(shè)計(jì),全網(wǎng)營(yíng)銷推廣,外貿(mào)網(wǎng)站建設(shè),怒江州網(wǎng)站建設(shè)費(fèi)用合理。

1. 不使用strict模式

(1) 這種習(xí)慣看起來(lái)是什么樣的

沒(méi)有用嚴(yán)格模式編寫(xiě) tsconfig.json。

 
 
 
 
    
  
  
  
  
  1. { 
    2. 
  
  
  
  
  2.   "compilerOptions": { 
    3. 
  
  
  
  
  3.     "target": "ES2015", 
    4. 
  
  
  
  
  4.     "module": "commonjs" 
    5. 
  
  
  
  
  5.   } 
    6. 
  
  
  
  
  6. } 
    7.

(2) 應(yīng)該怎樣

只需啟用 strict 模式即可：

 
 
 
 
    
  
  
  
  
  1. { 
    2. 
  
  
  
  
  2.   "compilerOptions": { 
    3. 
  
  
  
  
  3.     "target": "ES2015", 
    4. 
  
  
  
  
  4.     "module": "commonjs", 
    5. 
  
  
  
  
  5.     "strict": true 
    6. 
  
  
  
  
  6.   } 
    7. 
  
  
  
  
  7. } 
    8.

(3) 為什么會(huì)有這種壞習(xí)慣

在現(xiàn)有代碼庫(kù)中引入更嚴(yán)格的規(guī)則需要花費(fèi)時(shí)間。

(4) 為什么不該這樣做

更嚴(yán)格的規(guī)則使將來(lái)維護(hù)代碼時(shí)更加容易，使你節(jié)省大量的時(shí)間。

2. 用||定義默認(rèn)值

(1) 這種習(xí)慣看起來(lái)是什么樣的

使用舊的 || 處理后備的默認(rèn)值：

 
 
 
 
    
  
  
  
  
  1. function createBlogPost (text: string, author: string, date?: Date) { 
    2. 
  
  
  
  
  2.   return { 
    3. 
  
  
  
  
  3.     text: text, 
    4. 
  
  
  
  
  4.     author: author, 
    5. 
  
  
  
  
  5.     date: date || new Date() 
    6. 
  
  
  
  
  6.   } 
    7. 
  
  
  
  
  7. } 
    8.

(2) 應(yīng)該怎樣

使用新的 ?? 運(yùn)算符，或者在參數(shù)重定義默認(rèn)值。

 
 
 
 
    
  
  
  
  
  1. function createBlogPost (text: string, author: string, date: Date = new Date()) 
    2. 
  
  
  
  
  2.   return { 
    3. 
  
  
  
  
  3.     text: text, 
    4. 
  
  
  
  
  4.     author: author, 
    5. 
  
  
  
  
  5.     date: date 
    6. 
  
  
  
  
  6.   } 
    7. 
  
  
  
  
  7. } 
    8.

(3) 為什么會(huì)有這種壞習(xí)慣

?? 運(yùn)算符是去年才引入的，當(dāng)在長(zhǎng)函數(shù)中使用值時(shí)，可能很難將其設(shè)置為參數(shù)默認(rèn)值。

(4) 為什么不該這樣做

?? 與 || 不同，?? 僅針對(duì) null 或 undefined，并不適用于所有虛值。

3. 隨意使用any類型

(1) 這種習(xí)慣看起來(lái)是什么樣的

當(dāng)你不確定結(jié)構(gòu)時(shí)，可以用 any 類型。

 
 
 
 
    
  
  
  
  
  1. async function loadProducts(): Promise { 
    2. 
  
  
  
  
  2.   const response = await fetch('https://api.mysite.com/products') 
    3. 
  
  
  
  
  3.   const products: any = await response.json() 
    4. 
  
  
  
  
  4.   return products 
    5. 
  
  
  
  
  5. } 
    6.

(2) 應(yīng)該怎樣

把你代碼中任何一個(gè)使用 any 的地方都改為 unknown

 
 
 
 
    
  
  
  
  
  1. async function loadProducts(): Promise { 
    2. 
  
  
  
  
  2.   const response = await fetch('https://api.mysite.com/products') 
    3. 
  
  
  
  
  3.   const products: unknown = await response.json() 
    4. 
  
  
  
  
  4.   return products as Product[] 
    5. 
  
  
  
  
  5. } 
    6.

(3) 為什么會(huì)有這種壞習(xí)慣

any 是很方便的，因?yàn)樗旧辖昧怂械念愋蜋z查。通常，甚至在官方提供的類型中都使用了 any。例如，TypeScript 團(tuán)隊(duì)將上面例子中的 response.json() 的類型設(shè)置為 Promise 。

(4) 為什么不該這樣做

它基本上禁用所有類型檢查。任何通過(guò) any 進(jìn)來(lái)的東西將完全放棄所有類型檢查。這將會(huì)使錯(cuò)誤很難被捕獲到。

4. val as SomeType

(1) 這種習(xí)慣看起來(lái)是什么樣的

強(qiáng)行告訴編譯器無(wú)法推斷的類型。

 
 
 
 
    
  
  
  
  
  1. async function loadProducts(): Promise { 
    2. 
  
  
  
  
  2.   const response = await fetch('https://api.mysite.com/products') 
    3. 
  
  
  
  
  3.   const products: unknown = await response.json() 
    4. 
  
  
  
  
  4.   return products as Product[] 
    5. 
  
  
  
  
  5. } 
    6.

(2) 應(yīng)該怎樣

這正是 Type Guard 的用武之地。

 
 
 
 
    
  
  
  
  
  1. function isArrayOfProducts (obj: unknown): obj is Product[] { 
    2. 
  
  
  
  
  2.   return Array.isArray(obj) && obj.every(isProduct) 
    3. 
  
  
  
  
  3. } 
    4. 
  
  
  
  
  4.  
    5. 
  
  
  
  
  5. function isProduct (obj: unknown): obj is Product { 
    6. 
  
  
  
  
  6.   return obj != null 
    7. 
  
  
  
  
  7.     && typeof (obj as Product).id === 'string' 
    8. 
  
  
  
  
  8. } 
    9. 
  
  
  
  
  9.  
    10. 
  
  
  
  
  10. async function loadProducts(): Promise { 
    11. 
  
  
  
  
  11.   const response = await fetch('https://api.mysite.com/products') 
    12. 
  
  
  
  
  12.   const products: unknown = await response.json() 
    13. 
  
  
  
  
  13.   if (!isArrayOfProducts(products)) { 
    14. 
  
  
  
  
  14.     throw new TypeError('Received malformed products API response') 
    15. 
  
  
  
  
  15.   } 
    16. 
  
  
  
  
  16.   return products 
    17. 
  
  
  
  
  17. } 
    18.

(3) 為什么會(huì)有這種壞習(xí)慣

從 JavaScript 轉(zhuǎn)到 TypeScript 時(shí)，現(xiàn)有的代碼庫(kù)通常會(huì)對(duì) TypeScript 編譯器無(wú)法自動(dòng)推斷出的類型進(jìn)行假設(shè)。在這時(shí)，通過(guò) as SomeOtherType 可以加快轉(zhuǎn)換速度，而不必修改 tsconfig 中的設(shè)置。

(4) 為什么不該這樣做

Type Guard 會(huì)確保所有檢查都是明確的。

5. 測(cè)試中的as any

(1) 這種習(xí)慣看起來(lái)是什么樣的

編寫(xiě)測(cè)試時(shí)創(chuàng)建不完整的用例。

 
 
 
 
    
  
  
  
  
  1. interface User { 
    2. 
  
  
  
  
  2.   id: string 
    3. 
  
  
  
  
  3.   firstName: string 
    4. 
  
  
  
  
  4.   lastName: string 
    5. 
  
  
  
  
  5.   email: string 
    6. 
  
  
  
  
  6. } 
    7. 
  
  
  
  
  7.  
    8. 
  
  
  
  
  8. test('createEmailText returns text that greats the user by first name', () => { 
    9. 
  
  
  
  
  9.   const user: User = { 
    10. 
  
  
  
  
  10.     firstName: 'John' 
    11. 
  
  
  
  
  11.   } as any 
    12. 
  
  
  
  
  12.    
    13. 
  
  
  
  
  13.   expect(createEmailText(user)).toContain(user.firstName) 
    14. 
  
  
  
  
  14. } 
    15.

(2) 應(yīng)該怎樣

如果你需要模擬測(cè)試數(shù)據(jù)，請(qǐng)將模擬邏輯移到要模擬的對(duì)象旁邊，并使其可重用。

 
 
 
 
    
  
  
  
  
  1. interface User { 
    2. 
  
  
  
  
  2.   id: string 
    3. 
  
  
  
  
  3.   firstName: string 
    4. 
  
  
  
  
  4.   lastName: string 
    5. 
  
  
  
  
  5.   email: string 
    6. 
  
  
  
  
  6. } 
    7. 
  
  
  
  
  7.  
    8. 
  
  
  
  
  8. class MockUser implements User { 
    9. 
  
  
  
  
  9.   id = 'id' 
    10. 
  
  
  
  
  10.   firstName = 'John' 
    11. 
  
  
  
  
  11.   lastName = 'Doe' 
    12. 
  
  
  
  
  12.   email = 'john@doe.com' 
    13. 
  
  
  
  
  13. } 
    14. 
  
  
  
  
  14.  
    15. 
  
  
  
  
  15. test('createEmailText returns text that greats the user by first name', () => { 
    16. 
  
  
  
  
  16.   const user = new MockUser() 
    17. 
  
  
  
  
  17.  
    18. 
  
  
  
  
  18.   expect(createEmailText(user)).toContain(user.firstName) 
    19. 
  
  
  
  
  19. } 
    20.

(3) 為什么會(huì)有這種壞習(xí)慣

在給尚不具備廣泛測(cè)試覆蓋條件的代碼編寫(xiě)測(cè)試時(shí)，通常會(huì)存在復(fù)雜的大數(shù)據(jù)結(jié)構(gòu)，但要測(cè)試的特定功能僅需要其中的一部分。短期內(nèi)不必關(guān)心其他屬性。

(4) 為什么不該這樣做

在某些情況下，被測(cè)代碼依賴于我們之前認(rèn)為不重要的屬性，然后需要更新針對(duì)該功能的所有測(cè)試。

6. 可選屬性

(1) 這種習(xí)慣看起來(lái)是什么樣的

將屬性標(biāo)記為可選屬性，即便這些屬性有時(shí)不存在。

 
 
 
 
    
  
  
  
  
  1. interface Product { 
    2. 
  
  
  
  
  2.   id: string 
    3. 
  
  
  
  
  3.   type: 'digital' | 'physical' 
    4. 
  
  
  
  
  4.   weightInKg?: number 
    5. 
  
  
  
  
  5.   sizeInMb?: number 
    6. 
  
  
  
  
  6. } 
    7.

(2) 應(yīng)該怎樣

明確哪些組合存在，哪些不存在。

 
 
 
 
    
  
  
  
  
  1. interface Product { 
    2. 
  
  
  
  
  2.   id: string 
    3. 
  
  
  
  
  3.   type: 'digital' | 'physical' 
    4. 
  
  
  
  
  4. } 
    5. 
  
  
  
  
  5.  
    6. 
  
  
  
  
  6. interface DigitalProduct extends Product { 
    7. 
  
  
  
  
  7.   type: 'digital' 
    8. 
  
  
  
  
  8.   sizeInMb: number 
    9. 
  
  
  
  
  9. } 
    10. 
  
  
  
  
  10.  
    11. 
  
  
  
  
  11. interface PhysicalProduct extends Product { 
    12. 
  
  
  
  
  12.   type: 'physical' 
    13. 
  
  
  
  
  13.   weightInKg: number 
    14. 
  
  
  
  
  14. } 
    15.

(3) 為什么會(huì)有這種壞習(xí)慣

將屬性標(biāo)記為可選而不是拆分類型更容易，并且產(chǎn)生的代碼更少。它還需要對(duì)正在構(gòu)建的產(chǎn)品有更深入的了解，并且如果對(duì)產(chǎn)品的設(shè)計(jì)有所修改，可能會(huì)限制代碼的使用。

(4) 為什么不該這樣做

類型系統(tǒng)的最大好處是可以用編譯時(shí)檢查代替運(yùn)行時(shí)檢查。通過(guò)更顯式的類型，能夠?qū)赡懿槐蛔⒁獾腻e(cuò)誤進(jìn)行編譯時(shí)檢查，例如確保每個(gè) DigitalProduct 都有一個(gè) sizeInMb。

7. 用一個(gè)字母通行天下

(1) 這種習(xí)慣看起來(lái)是什么樣的

用一個(gè)字母命名泛型

 
 
 
 
    
  
  
  
  
  1. function head (arr: T[]): T | undefined { 
    2. 
  
  
  
  
  2.   return arr[0] 
    3. 
  
  
  
  
  3. } 
    4.

(2) 應(yīng)該怎樣

提供完整的描述性類型名稱。

 
 
 
 
    
  
  
  
  
  1. function head (arr: Element[]): Element | undefined { 
    2. 
  
  
  
  
  2.   return arr[0] 
    3. 
  
  
  
  
  3. } 
    4.

(3) 為什么會(huì)有這種壞習(xí)慣

這種寫(xiě)法最早來(lái)源于C++的范型庫(kù)，即使是 TS 的官方文檔也在用一個(gè)字母的名稱。它也可以更快地輸入，只需要簡(jiǎn)單的敲下一個(gè)字母 T 就可以代替寫(xiě)全名。

(4) 為什么不該這樣做

通用類型變量也是變量，就像其他變量一樣。當(dāng) IDE 開(kāi)始向我們展示變量的類型細(xì)節(jié)時(shí)，我們已經(jīng)慢慢放棄了用它們的名稱描述來(lái)變量類型的想法。例如我們現(xiàn)在寫(xiě)代碼用 const name ='Daniel'，而不是 const strName ='Daniel'。同樣，一個(gè)字母的變量名通常會(huì)令人費(fèi)解，因?yàn)椴豢绰暶骶秃茈y理解它們的含義。

8. 對(duì)非布爾類型的值進(jìn)行布爾檢查

(1) 這種習(xí)慣看起來(lái)是什么樣的

通過(guò)直接將值傳給 if 語(yǔ)句來(lái)檢查是否定義了值。

 
 
 
 
    
  
  
  
  
  1. function createNewMessagesResponse (countOfNewMessages?: number) { 
    2. 
  
  
  
  
  2.   if (countOfNewMessages) { 
    3. 
  
  
  
  
  3.     return `You have ${countOfNewMessages} new messages` 
    4. 
  
  
  
  
  4.   } 
    5. 
  
  
  
  
  5.   return 'Error: Could not retrieve number of new messages' 
    6. 
  
  
  
  
  6. } 
    7.

(2) 應(yīng)該怎樣

明確檢查我們所關(guān)心的狀況。

 
 
 
 
    
  
  
  
  
  1. function createNewMessagesResponse (countOfNewMessages?: number) { 
    2. 
  
  
  
  
  2.   if (countOfNewMessages !== undefined) { 
    3. 
  
  
  
  
  3.     return `You have ${countOfNewMessages} new messages` 
    4. 
  
  
  
  
  4.   } 
    5. 
  
  
  
  
  5.   return 'Error: Could not retrieve number of new messages' 
    6. 
  
  
  
  
  6. } 
    7.

(3) 為什么會(huì)有這種壞習(xí)慣

編寫(xiě)簡(jiǎn)短的檢測(cè)代碼看起來(lái)更加簡(jiǎn)潔，使我們能夠避免思考實(shí)際想要檢測(cè)的內(nèi)容。

(4) 為什么不該這樣做

也許我們應(yīng)該考慮一下實(shí)際要檢查的內(nèi)容。例如上面的例子以不同的方式處理 countOfNewMessages 為 0 的情況。

9. ”棒棒“運(yùn)算符

(1) 這種習(xí)慣看起來(lái)是什么樣的

將非布爾值轉(zhuǎn)換為布爾值。

 
 
 
 
    
  
  
  
  
  1. function createNewMessagesResponse (countOfNewMessages?: number) { 
    2. 
  
  
  
  
  2.   if (!!countOfNewMessages) { 
    3. 
  
  
  
  
  3.     return `You have ${countOfNewMessages} new messages` 
    4. 
  
  
  
  
  4.   } 
    5. 
  
  
  
  
  5.   return 'Error: Could not retrieve number of new messages' 
    6. 
  
  
  
  
  6. } 
    7.

(2) 應(yīng)該怎樣明

確檢查我們所關(guān)心的狀況。

 
 
 
 
    
  
  
  
  
  1. function createNewMessagesResponse (countOfNewMessages?: number) { 
    2. 
  
  
  
  
  2.   if (countOfNewMessages !== undefined) { 
    3. 
  
  
  
  
  3.     return `You have ${countOfNewMessages} new messages` 
    4. 
  
  
  
  
  4.   } 
    5. 
  
  
  
  
  5.   return 'Error: Could not retrieve number of new messages' 
    6. 
  
  
  
  
  6. } 
    7.

(3) 為什么會(huì)有這種壞習(xí)慣

對(duì)某些人而言，理解 !! 就像是進(jìn)入 JavaScript 世界的入門(mén)儀式。它看起來(lái)簡(jiǎn)短而簡(jiǎn)潔，如果你對(duì)它已經(jīng)非常習(xí)慣了，就會(huì)知道它的含義。這是將任意值轉(zhuǎn)換為布爾值的便捷方式。尤其是在如果虛值之間沒(méi)有明確的語(yǔ)義界限時(shí)，例如 null、undefined 和 ''。

(4) 為什么不該這樣做

與很多編碼時(shí)的便捷方式一樣，使用 !! 實(shí)際上是混淆了代碼的真實(shí)含義。這使得新開(kāi)發(fā)人員很難理解代碼，無(wú)論是對(duì)一般開(kāi)發(fā)人員來(lái)說(shuō)還是對(duì) JavaScript 來(lái)說(shuō)都是新手。也很容易引入細(xì)微的錯(cuò)誤。在對(duì)“非布爾類型的值”進(jìn)行布爾檢查時(shí) countOfNewMessages為 0 的問(wèn)題在使用 !! 時(shí)仍然會(huì)存在。

10. != null

(1) 這種習(xí)慣看起來(lái)是什么樣的

棒棒運(yùn)算符的小弟 ! = null使我們能同時(shí)檢查 null 和 undefined。

 
 
 
 
    
  
  
  
  
  1. function createNewMessagesResponse (countOfNewMessages?: number) { 
    2. 
  
  
  
  
  2.   if (countOfNewMessages != null) { 
    3. 
  
  
  
  
  3.     return `You have ${countOfNewMessages} new messages` 
    4. 
  
  
  
  
  4.   } 
    5. 
  
  
  
  
  5.   return 'Error: Could not retrieve number of new messages' 
    6. 
  
  
  
  
  6. } 
    7.

(2) 應(yīng)該怎樣

明確檢查我們所關(guān)心的狀況。

 
 
 
 
    
  
  
  
  
  1. function createNewMessagesResponse (countOfNewMessages?: number) { 
    2. 
  
  
  
  
  2.   if (countOfNewMessages !== undefined) { 
    3. 
  
  
  
  
  3.     return `You have ${countOfNewMessages} new messages` 
    4. 
  
  
  
  
  4.   } 
    5. 
  
  
  
  
  5.   return 'Error: Could not retrieve number of new messages' 
    6.

(3) 為什么會(huì)有這種壞習(xí)慣

如果你的代碼在 null 和 undefined 之間沒(méi)有明顯的區(qū)別，那么 != null 有助于簡(jiǎn)化對(duì)這兩種可能性的檢查。

(4) 為什么不該這樣做

盡管 null 在 JavaScript早期很麻煩，但 TypeScript 處于 strict 模式時(shí)，它卻可以成為這種語(yǔ)言中寶貴的工具。一種常見(jiàn)模式是將 null 值定義為不存在的事物，將 undefined 定義為未知的事物，例如 user.firstName === null 可能意味著用戶實(shí)際上沒(méi)有名字，而 user.firstName === undefined 只是意味著我們尚未詢問(wèn)該用戶(而 user.firstName === 的意思是字面意思是 '' 。


分享名稱：10個(gè)寫(xiě)TypeScript代碼的壞習(xí)慣
網(wǎng)站地址：http://www.5511xx.com/article/djecgdd.html