手寫TypeScript 時很多人常犯的幾個錯誤

2022-09-12 18:00:39

前言

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

1.沒有使用嚴格模式

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

使用嚴格模式後。

我們為什麼要使用嚴格模式？

嚴格模式可以消除語法裡一些不合理，不嚴謹的地方，可以讓TS往更合理、更安全、更嚴謹的方向去發展: 通過將一些TS的靜默錯誤更改為丟擲錯誤，消除了TS的一些靜默錯誤，能更加有效保障程式碼執行的安全；提高編譯器效率，增加執行速度；禁止一些可能在ECMAScript未來版本中定義的語法。

2. 使用 || 確定預設值

那它應該是什麼樣子的呢？

使用最新的??運運算元或者最好是在引數級別定義返回值。

這??運運算元去年才被引入，如果在長函數的中間使用值，可能很難將它們定義為引數預設值。

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

3.使用any作為型別

當我們不確定資料型別的時候，會使用any型別的資料。

在所有我們不確定型別的情況下，我們都應該使用unknown。

為什麼要這麼做呢？

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

為什麼不能用any？

它從根本上禁用所有型別檢查。通過 any 進入的所有值都將完全放棄任何型別檢查。這可能會變得非常難以捕捉錯誤，因為只有當我們對型別結構的假設符合執行時程式碼時，程式碼才會失敗。

4. val 作為 SomeType

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

這就是型別守衛的用途。

當我們想要從 JavaScript 轉換為 TypeScript 時，現有的程式碼庫經常對 TypeScript 編譯器無法自動得出的型別做出假設。在這些情況下，使用快速 as SomeOtherType 可以加快轉換速度，而無需放鬆 tsconfig 中的設定。

即使現在可以儲存斷言，但當有人移動程式碼時，這可能會改變。型別保護將確保所有檢查都是明確的。

5. any在測試用例中的表現

在編寫測試時

如果需要為測試模擬資料，需要將模擬邏輯移動到我們模擬的旁邊並使其可重用。

雖然在尚未有很好的測試覆蓋率的程式碼庫中編寫測試時，經常會出現複雜的巨量資料結構，但測試中的特定功能只需要其中的一部分。短期內無需擔心其他屬性更簡單。

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

6. 可選屬性

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

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

將屬性定義為可選而不是劃分型別更容易並且生成的程式碼更少。它還需要對正在開發的產品有充分的瞭解，並且可以在對產品的假設發生變化時限制程式碼的使用。

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

7. 使用一個字母作為泛型引數

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

應該給出一個完整的描述性型別名稱。

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

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