英文 | https://medium.com/@imranfarooq0306/10-bad-typescript-habits-to-get-rid-of-in-2022-909d054b31e7
TypeScript 和 JavaScript 在過去幾年中不斷進步,我們在過去幾十年中建立的一些實踐已經過時。有些可能永遠沒有意義。下面列出了我們都應該改掉的 9個習慣。
1.不要使用嚴格模式
它看起來像什麼
通過使用沒有嚴格模式的 tsconfig.json。
它應該是什麼樣子
使用嚴格模式後。
我們為什麼這樣做
在代碼庫中引入更嚴格的規則通常需要時間。
為什麼我們不應該
更嚴格的規則可以在未來更容易地更改代碼,是以修複代碼所花費的時間會被退回,之後在未來處理存儲庫時會花費一些時間。
2. 用 || 确定預設值
它看起來像什麼
它應該是什麼樣子
新的??運算符,或者更好的是,在參數級别定義折返權。
我們為什麼這樣做
這 ??運算符去年才被引入,如果在長函數的中間使用值,可能很難将它們定義為參數預設值。
為什麼我們不應該
?? 與 || 不同,它隻傳回 null 或 undefined,而不是所有 falsy 值。此外,如果你的函數很長,以至于你無法在一開始就定義預設值,那麼将它們分開可能是個好主意。
3.使用any作為類型
當我們不确定結構時,應該使用任何類型的資料。
它應該是什麼樣子
在幾乎所有我們鍵入任何内容的情況下,我們都應該将其鍵入為未知。
我們為什麼這樣做
any 很簡單,因為它從根本上禁用了所有類型檢查。通常,即使在官方類型中也使用 any(例如,上面示例中的 response.json() 被 TypeScript 團隊鍵入為 Promise<any>)。
為什麼我們不應該
它從根本上禁用所有類型檢查。通過 any 進入的所有内容都将完全放棄任何類型檢查。這可能會變得非常難以捕捉錯誤,因為隻有當我們對類型結構的假設符合運作時代碼時,代碼才會失敗。
4. val 作為 SomeType
它看起來像什麼
強制告訴編譯器它無法推斷的類型。
它應該是什麼樣子
這就是類型守衛的用途。
我們為什麼這樣做
當我們想要從 JavaScript 轉換為 TypeScript 時,現有的代碼庫經常對 TypeScript 編譯器無法自動得出的類型做出假設。在這些情況下,使用快速 as SomeOtherType 可以加快轉換速度,而無需放松 tsconfig 中的設定。
為什麼我們不應該
即使現在可以儲存斷言,但當有人移動代碼時,這可能會改變。類型保護将確定所有檢查都是明确的。
5. 和任何測試一樣
它看起來像什麼
在編寫測試時,它會建立不完整的替身。
它應該是什麼樣子
如果你需要為你的測試模拟資料,請将模拟邏輯移動到您模拟的事物旁邊并使其可重用。
我們為什麼這樣做
雖然在尚未有很好的測試覆寫率的代碼庫中編寫測試時,經常會出現複雜的大資料結構,但測試中的特定功能隻需要其中的一部分。短期内無需擔心其他屬性更簡單。
為什麼我們不應該
放棄測試,模拟開發,最近一次是當其中一個屬性發生變化時,我們必須在所有測試中更改它而不是一個中心位置。此外,在某些情況下,被測代碼依賴于我們之前認為不重要的屬性,然後必須更新該功能的所有測試。
6. 可選屬性
它看起來像什麼
将屬性定義為有時存在有時不存在的可選屬性。
它應該是什麼樣子
清楚地表達,模型哪些組合存在,哪些不存在。
我們為什麼這樣做
将屬性定義為可選而不是劃分類型更容易并且生成的代碼更少。它還需要對正在開發的産品有充分的了解,并且可以在對産品的假設發生變化時限制代碼的使用。
為什麼我們不應該
類型系統的最大好處是它們可以用編譯時檢查代替運作時檢查。通過更多的快速輸入,可以在編譯時檢查可能被忽視的錯誤,例如。G。通過確定每個 DigitalProduct 都有一個 sizeInMb。
7. 一個字母泛型
它看起來像什麼
用一個字母給名稱一個通用名稱
它應該是什麼樣子
應該給出一個完整的描述性類型名稱。
我們為什麼要這樣做
我猜這種習慣會養成,因為即使是官方文檔也使用一個字母的名稱。按 T 代替寫全名可以更快地鍵入,并且不需要考慮太多。
為什麼我們不應該這樣做
泛型類型變量是變量,就像其他變量一樣。當 IDE 開始向我們展示這些技術性時,我們已經放棄了在變量名稱中描述變量技術性的想法。例如。我們通常隻寫 const name = ‘Daniel’ 而不是 const strName = ‘Daniel’。此外,一個字母的變量名稱通常會讓人大吃一驚,因為如果不檢視它們的聲明,可能很難翻譯它們的含義。
8.非布爾布爾檢查
它看起來像什麼
通過将值直接傳遞給 if 語句來檢查值是否已定義。
它應該是什麼樣子
我們可以明确檢查我們關心的情況。
我們為什麼要這樣做
用簡短的方式編寫檢檢視起來更簡潔,并且可以讓我們避免思考我們真正想要檢查的内容。
為什麼我們不應該這樣做
也許我們應該考慮一下我們真正想要檢查的内容。例如,上面給出的示例以不同的方式處理 countOfNewMessages 為 0 的情況。
9. Bang Bang 算子
它看起來像什麼
将非布爾值轉換為布爾值。
它應該是什麼樣子
明确檢查我們關心的狀況。
我們為什麼要這樣做
對我們中的一些人來說,了解!就像開始對 JavaScript 宇宙的儀式一樣。它看起來簡短而簡潔,如果你已經熟悉它,那麼,你就會知道它是關于什麼的。這是将任何值轉換為布爾值的簡便方法。尤其是在代碼庫中,假值(如 null、undefined 和“”)之間沒有明确的語義分離。
為什麼我們不應該這樣做
像許多捷徑和啟動儀式一樣,使用 !!通過宣傳内部知識來混淆代碼的真正含義。這使得新開發人員更不容易通路代碼庫,無論是一般開發的新手,還是 JavaScript 的新手。引入細微的錯誤也很容易。來自“非布爾布爾檢查”的 countOfNewMessages 為 0 的問題仍然存在 !!。
總結
以上9種寫TypeScript的習慣,你有幾種?如果都沒有的話,那麼恭喜你,如果隻有其中一些的話,請嘗試着改掉它。
今天内容就先到這裡了,希望能夠幫助到你,如果你覺得有用的話,請記得點贊我,關注我,并将它分享給你身邊做開發的朋友,也許能夠幫助到他。
最後,感謝你的閱讀,祝程式設計愉快!
學習更多技能
請點選下方公衆号