這篇“手寫TypeScript時常犯的錯誤有哪些”文章的知識點大部分人都不太理解,所以小編給大家總結(jié)了以下內(nèi)容,內(nèi)容詳細(xì),步驟清晰,具有一定的借鑒價值,希望大家閱讀完這篇文章能有所收獲,下面我們一起來看看這篇“手寫TypeScript時常犯的錯誤有哪些”文章吧。
創(chuàng)新互聯(lián)公司長期為近1000家客戶提供的網(wǎng)站建設(shè)服務(wù),團(tuán)隊從業(yè)經(jīng)驗10年,關(guān)注不同地域、不同群體,并針對不同對象提供差異化的產(chǎn)品和服務(wù);打造開放共贏平臺,與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為叢臺企業(yè)提供專業(yè)的成都網(wǎng)站設(shè)計、做網(wǎng)站,叢臺網(wǎng)站改版等技術(shù)服務(wù)。擁有10余年豐富建站經(jīng)驗和眾多成功案例,為您定制開發(fā)。
通過使用沒有嚴(yán)格模式的 tsconfig.json。
使用嚴(yán)格模式后。
嚴(yán)格模式可以消除語法里一些不合理,不嚴(yán)謹(jǐn)?shù)牡胤剑梢宰孴S往更合理、更安全、更嚴(yán)謹(jǐn)?shù)姆较蛉グl(fā)展: 通過將一些TS的靜默錯誤更改為拋出錯誤,消除了TS的一些靜默錯誤,能更加有效保障代碼運行的安全; 提高編譯器效率,增加運行速度; 禁止一些可能在ECMAScript未來版本中定義的語法。
使用最新的??
運算符或者最好是在參數(shù)級別定義返回值。
這??
運算符去年才被引入,如果在長函數(shù)的中間使用值,可能很難將它們定義為參數(shù)默認(rèn)值。
?? 與 || 不同,它只返回 null 或 undefined,而不是所有 falsy 值。
當(dāng)我們不確定數(shù)據(jù)類型的時候,會使用any類型的數(shù)據(jù)。
在所有我們不確定類型的情況下,我們都應(yīng)該使用unknown。
any 很簡單,因為它從根本上禁用了所有類型檢查。通常,即使在官方類型中也使用 any(例如,上面示例中的 response.json() 被 TypeScript 團(tuán)隊鍵入為 Promise
)。
它從根本上禁用所有類型檢查。通過 any 進(jìn)入的所有值都將完全放棄任何類型檢查。這可能會變得非常難以捕捉錯誤,因為只有當(dāng)我們對類型結(jié)構(gòu)的假設(shè)符合運行時代碼時,代碼才會失敗。
當(dāng)我們想要從 JavaScript 轉(zhuǎn)換為 TypeScript 時,現(xiàn)有的代碼庫經(jīng)常對 TypeScript 編譯器無法自動得出的類型做出假設(shè)。在這些情況下,使用快速 as SomeOtherType 可以加快轉(zhuǎn)換速度,而無需放松 tsconfig 中的設(shè)置。
即使現(xiàn)在可以保存斷言,但當(dāng)有人移動代碼時,這可能會改變。類型保護(hù)將確保所有檢查都是明確的。
如果需要為測試模擬數(shù)據(jù),需要將模擬邏輯移動到我們模擬的旁邊并使其可重用。
雖然在尚未有很好的測試覆蓋率的代碼庫中編寫測試時,經(jīng)常會出現(xiàn)復(fù)雜的大數(shù)據(jù)結(jié)構(gòu),但測試中的特定功能只需要其中的一部分。短期內(nèi)無需擔(dān)心其他屬性更簡單。
最近一次是當(dāng)其中一個屬性發(fā)生變化時,我們必須在所有測試中更改它而不是一個中心位置。此外,在某些情況下,被測代碼依賴于我們之前認(rèn)為不重要的屬性,然后必須更新該功能的所有測試。
將屬性定義為可選而不是劃分類型更容易并且生成的代碼更少。它還需要對正在開發(fā)的產(chǎn)品有充分的了解,并且可以在對產(chǎn)品的假設(shè)發(fā)生變化時限制代碼的使用。
類型系統(tǒng)的最大好處是它們可以用編譯時檢查代替運行時檢查。通過更多的快速輸入,可以在編譯時檢查可能被忽視的錯誤。
我猜很多人有這種壞習(xí)慣,因為即使是官方文檔也使用一個字母的名稱。按 T 代替寫全名可以更快地鍵入,并且不需要考慮太多。
泛型類型是變量,就像其他變量一樣。當(dāng) IDE 開始向我們展示這些技術(shù)性時,我們已經(jīng)放棄了在變量名稱中描述變量技術(shù)性的想法。例如。我們通常只寫 const name = ‘Daniel’ 而不是 const strName = ‘Daniel’。此外,一個字母的變量名通常會引起轟動,因為如果不看它們的聲明,可能很難翻譯它們的含義。
用簡短的方式編寫檢查看起來更簡潔,并且可以讓我們避免思考我們真正想要檢查的內(nèi)容。
也許我們應(yīng)該考慮一下我們真正想要檢查的內(nèi)容。例如,上面給出的示例以不同的方式處理 countOfNewMessages 為 0 的情況。
對我們中的一些人來說,理解!
很簡單。它看起來簡短而簡潔,如果您已經(jīng)熟悉它,那么您就會知道它是關(guān)于什么的。這是將任何值轉(zhuǎn)換為布爾值的簡便方法。尤其是在代碼庫中,假值(如 null
、undefined
和“”
)之間沒有明確的語義分離。
使用 !!
通過宣傳內(nèi)部知識來混淆代碼的真正含義。這使得新開發(fā)人員更不容易訪問代碼庫,無論是一般開發(fā)的新手,還是 JavaScript 的新手。引入細(xì)微的錯誤也很容易。來自“非布爾布爾檢查”的 countOfNewMessages
為 0
的問題仍然存在 !!
。
以上就是關(guān)于“手寫TypeScript時常犯的錯誤有哪些”這篇文章的內(nèi)容,相信大家都有了一定的了解,希望小編分享的內(nèi)容對大家有幫助,若想了解更多相關(guān)的知識內(nèi)容,請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。