前言

TypeScript 和 JavaScript 在過去幾年中不斷進步，我們在過去點時間中建立的一些實踐可能已經(jīng)過時。有些可能永遠沒有意義，下面我列出了很多=開發(fā)者可能會犯的幾個錯誤！

1.沒有使用嚴格模式

通過使用沒有嚴格模式的 tsconfig.json。

使用嚴格模式后。

我們?yōu)槭裁匆褂脟栏衲Ｊ剑?/h3>

嚴格模式可以消除語法里一些不合理，不嚴謹?shù)牡胤?，可以讓TS往更合理、更安全、更嚴謹?shù)姆较蛉グl(fā)展: 通過將一些TS的靜默錯誤更改為拋出錯誤，消除了TS的一些靜默錯誤，能更加有效保障代碼運行的安全； 提高編譯器效率，增加運行速度； 禁止一些可能在ECMAScript未來版本中定義的語法。

2. 使用 || 確定默認值

那它應(yīng)該是什么樣子的呢？

使用最新的??運算符或者最好是在參數(shù)級別定義返回值。

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

?? 與 || 不同，它只返回 null 或 undefined，而不是所有 falsy 值。

3.使用any作為類型

當我們不確定數(shù)據(jù)類型的時候，會使用any類型的數(shù)據(jù)。

在所有我們不確定類型的情況下，我們都應(yīng)該使用unknown。

為什么要這么做呢？

any 很簡單，因為它從根本上禁用了所有類型檢查。通常，即使在官方類型中也使用 any（例如，上面示例中的 response.json() 被 TypeScript 團隊鍵入為 Promise<any>）。

為什么不能用any？

它從根本上禁用所有類型檢查。通過 any 進入的所有值都將完全放棄任何類型檢查。這可能會變得非常難以捕捉錯誤，因為只有當我們對類型結(jié)構(gòu)的假設(shè)符合運行時代碼時，代碼才會失敗。

4. val 作為 SomeType

強制告訴編譯器它無法推斷的類型。

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

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

即使現(xiàn)在可以保存斷言，但當有人移動代碼時，這可能會改變。類型保護將確保所有檢查都是明確的。

5. any在測試用例中的表現(xiàn)

在編寫測試時

如果需要為測試模擬數(shù)據(jù)，需要將模擬邏輯移動到我們模擬的旁邊并使其可重用。

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

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

6. 可選屬性

將屬性定義為有時存在，有時不存在的可選屬性。

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

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

類型系統(tǒng)的最大好處是它們可以用編譯時檢查代替運行時檢查。通過更多的快速輸入，可以在編譯時檢查可能被忽視的錯誤。

7. 使用一個字母作為泛型參數(shù)

用一個字母給作為名稱，比如常用的T作為泛型名稱！

應(yīng)該給出一個完整的描述性類型名稱。

我猜很多人有這種壞習(xí)慣，因為即使是官方文檔也使用一個字母的名稱。按 T 代替寫全名可以更快地鍵入，并且不需要考慮太多。

泛型類型是變量，就像其他變量一樣。當 IDE 開始向我們展示這些技術(shù)性時，我們已經(jīng)放棄了在變量名稱中描述變量技術(shù)性的想法。例如。我們通常只寫 const name = ‘Daniel’ 而不是 const strName = ‘Daniel’。此外，一個字母的變量名通常會引起轟動，因為如果不看它們的聲明，可能很難翻譯它們的含義。

8.非布爾檢查

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

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

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

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

9. ！！操作符

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

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

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

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

到此這篇關(guān)于手寫TypeScript 時很多人常犯的幾個錯誤的文章就介紹到這了,更多相關(guān)TypeScript 錯誤內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論