下面列出了我們都應(yīng)該改掉的 9個(gè)習(xí)慣。

1.不要使用嚴(yán)格模式

它看起來像什么

通過使用沒有嚴(yán)格模式的 tsconfig.json。

?它應(yīng)該是什么樣子

使用嚴(yán)格模式后。

?我們?yōu)槭裁催@樣做

?在代碼庫中引入更嚴(yán)格的規(guī)則通常需要時(shí)間。

為什么我們不應(yīng)該

更嚴(yán)格的規(guī)則可以在未來更容易地更改代碼，因此修復(fù)代碼所花費(fèi)的時(shí)間會(huì)被退回，之后在未來處理存儲(chǔ)庫時(shí)會(huì)花費(fèi)一些時(shí)間。

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

它看起來像什么

它應(yīng)該是什么樣子

?新的？？運(yùn)算符，或者更好的是，在參數(shù)級(jí)別定義折返權(quán)。

我們?yōu)槭裁催@樣做

這 ？？運(yùn)算符去年才被引入，如果在長函數(shù)的中間使用值，可能很難將它們定義為參數(shù)默認(rèn)值。

為什么我們不應(yīng)該?

?? 與 || 不同，它只返回 null 或 undefined，而不是所有 falsy 值。此外，如果你的函數(shù)很長，以至于你無法在一開始就定義默認(rèn)值，那么將它們分開可能是個(gè)好主意。

3.使用any作為類型

當(dāng)我們不確定結(jié)構(gòu)時(shí)，應(yīng)該使用任何類型的數(shù)據(jù)。

?它應(yīng)該是什么樣子

在幾乎所有我們鍵入任何內(nèi)容的情況下，我們都應(yīng)該將其鍵入為未知。

?我們?yōu)槭裁催@樣做

?any 很簡單，因?yàn)樗鼜母旧辖昧怂蓄愋蜋z查。通常，即使在官方類型中也使用 any（例如，上面示例中的 response.json() 被 TypeScript 團(tuán)隊(duì)鍵入為 Promise<any>）。

為什么我們不應(yīng)該

?它從根本上禁用所有類型檢查。通過 any 進(jìn)入的所有內(nèi)容都將完全放棄任何類型檢查。這可能會(huì)變得非常難以捕捉錯(cuò)誤，因?yàn)橹挥挟?dāng)我們對(duì)類型結(jié)構(gòu)的假設(shè)符合運(yùn)行時(shí)代碼時(shí)，代碼才會(huì)失敗。

4. val 作為 SomeType

它看起來像什么

強(qiáng)制告訴編譯器它無法推斷的類型。

?它應(yīng)該是什么樣子

這就是類型守衛(wèi)的用途。

?我們?yōu)槭裁催@樣做

?當(dāng)我們想要從 JavaScript 轉(zhuǎn)換為 TypeScript 時(shí)，現(xiàn)有的代碼庫經(jīng)常對(duì) TypeScript 編譯器無法自動(dòng)得出的類型做出假設(shè)。在這些情況下，使用快速 as SomeOtherType 可以加快轉(zhuǎn)換速度，而無需放松 tsconfig 中的設(shè)置。

為什么我們不應(yīng)該

?即使現(xiàn)在可以保存斷言，但當(dāng)有人移動(dòng)代碼時(shí)，這可能會(huì)改變。類型保護(hù)將確保所有檢查都是明確的。

5. 和任何測(cè)試一樣

它看起來像什么

在編寫測(cè)試時(shí)，它會(huì)創(chuàng)建不完整的替身。

?它應(yīng)該是什么樣子

?如果你需要為你的測(cè)試模擬數(shù)據(jù)，請(qǐng)將模擬邏輯移動(dòng)到您模擬的事物旁邊并使其可重用。

?我們?yōu)槭裁催@樣做?

雖然在尚未有很好的測(cè)試覆蓋率的代碼庫中編寫測(cè)試時(shí)，經(jīng)常會(huì)出現(xiàn)復(fù)雜的大數(shù)據(jù)結(jié)構(gòu)，但測(cè)試中的特定功能只需要其中的一部分。短期內(nèi)無需擔(dān)心其他屬性更簡單。

為什么我們不應(yīng)該?

放棄測(cè)試，模擬開發(fā)，最近一次是當(dāng)其中一個(gè)屬性發(fā)生變化時(shí)，我們必須在所有測(cè)試中更改它而不是一個(gè)中心位置。此外，在某些情況下，被測(cè)代碼依賴于我們之前認(rèn)為不重要的屬性，然后必須更新該功能的所有測(cè)試。

6. 可選屬性

它看起來像什么

將屬性定義為有時(shí)存在有時(shí)不存在的可選屬性。

?它應(yīng)該是什么樣子

清楚地表達(dá)，模型哪些組合存在，哪些不存在。

?我們?yōu)槭裁催@樣做?

將屬性定義為可選而不是劃分類型更容易并且生成的代碼更少。它還需要對(duì)正在開發(fā)的產(chǎn)品有充分的了解，并且可以在對(duì)產(chǎn)品的假設(shè)發(fā)生變化時(shí)限制代碼的使用。

為什么我們不應(yīng)該

類型系統(tǒng)的最大好處是它們可以用編譯時(shí)檢查代替運(yùn)行時(shí)檢查。通過更多的快速輸入，可以在編譯時(shí)檢查可能被忽視的錯(cuò)誤，例如。G。通過確保每個(gè) DigitalProduct 都有一個(gè) sizeInMb。

7. 一個(gè)字母泛型

它看起來像什么

用一個(gè)字母給名稱一個(gè)通用名稱

?它應(yīng)該是什么樣子應(yīng)該給出一個(gè)完整的描述性類型名稱。

?我們?yōu)槭裁匆@樣做

?我猜這種習(xí)慣會(huì)養(yǎng)成，因?yàn)榧词故枪俜轿臋n也使用一個(gè)字母的名稱。按 T 代替寫全名可以更快地鍵入，并且不需要考慮太多。

為什么我們不應(yīng)該這樣做

?泛型類型變量是變量，就像其他變量一樣。當(dāng) IDE 開始向我們展示這些技術(shù)性時(shí)，我們已經(jīng)放棄了在變量名稱中描述變量技術(shù)性的想法。例如。我們通常只寫 const name = ‘Daniel’ 而不是 const strName = ‘Daniel’。此外，一個(gè)字母的變量名稱通常會(huì)讓人大吃一驚，因?yàn)槿绻徊榭此鼈兊穆暶?，可能很難翻譯它們的含義。

8.非布爾布爾檢查

它看起來像什么

通過將值直接傳遞給 if 語句來檢查值是否已定義。

它應(yīng)該是什么樣子

我們可以明確檢查我們關(guān)心的情況。

我們?yōu)槭裁匆@樣做

用簡短的方式編寫檢查看起來更簡潔，并且可以讓我們避免思考我們真正想要檢查的內(nèi)容。

為什么我們不應(yīng)該這樣做

也許我們應(yīng)該考慮一下我們真正想要檢查的內(nèi)容。例如，上面給出的示例以不同的方式處理 countOfNewMessages 為 0 的情況。

9. Bang Bang 算子

它看起來像什么

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

?它應(yīng)該是什么樣子

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

?我們?yōu)槭裁匆@樣做

?對(duì)我們中的一些人來說，理解！就像開始對(duì) JavaScript 宇宙的儀式一樣。它看起來簡短而簡潔，如果你已經(jīng)熟悉它，那么，你就會(huì)知道它是關(guān)于什么的。這是將任何值轉(zhuǎn)換為布爾值的簡便方法。尤其是在代碼庫中，假值（如 null、undefined 和“”）之間沒有明確的語義分離。

為什么我們不應(yīng)該這樣做?

像許多捷徑和啟動(dòng)儀式一樣，使用 !!通過宣傳內(nèi)部知識(shí)來混淆代碼的真正含義。這使得新開發(fā)人員更不容易訪問代碼庫，無論是一般開發(fā)的新手，還是 JavaScript 的新手。引入細(xì)微的錯(cuò)誤也很容易。來自“非布爾布爾檢查”的 countOfNewMessages 為 0 的問題仍然存在 !!。

總結(jié)

以上9種寫TypeScript的習(xí)慣，你有幾種？如果都沒有的話，那么恭喜你，如果只有其中一些的話，請(qǐng)嘗試著改掉它。

今天內(nèi)容就先到這里了，希望能夠幫助到你，如果你覺得有用的話，請(qǐng)記得點(diǎn)贊我，關(guān)注我，并將它分享給你身邊做開發(fā)的朋友，也許能夠幫助到他。最后，感謝你的閱讀，祝編程愉快！