摘要：弄了一個持續更新的筆記，可以去看看，鏈接地址此篇文章的地址使用兩年后值得嗎基礎筆記的地址可以也可以。使用，你可以使用抽象類等功能。有關抽象類的更多信息支持，和方法，只讀屬性。

弄了一個持續更新的github筆記，可以去看看，鏈接地址：Front-End-Basics

此篇文章的地址：使用TypeScript兩年后-值得嗎？

基礎筆記的github地址：https://github.com/qiqihaobenben/Front-End-Basics ,可以watch,也可以star。

這是我的第一篇翻譯文章，想看這篇文章的時候，發現沒有中文翻譯版，無奈去讀了英文版，讀完發現可以試試翻譯出來。

本人英語水平不是一般的差，之前很排斥讀英文資料，現在努力轉變觀念，慢慢的開始不那么害怕讀英文資料了。這篇文章在磕磕絆絆的查單詞中讀了第一遍，然后在不查單詞的情況下順了兩遍，肯定會有錯誤，懇請指正。當然你也可以直接讀更準確的英文原文。

原文地址:https://ecom.software/en/afte...
作者：Kamil Zagrabski

差不多兩年前，我在一個創業團隊中開始了一個全新的項目。用到的全都是類似Microservices，docker，react，redux這些時髦的東西。

我在前端技術方面積累了一些類似的經驗，因為在更早的一年前我帶著20多名前端開發人員編寫了一個非常大的react應用程序。這對我來說非常具有挑戰性。當時我們遇到了很多問題：模型內聚的問題，代碼庫的增長，復雜且難以維護的api，接口不一致，難以跟蹤運行時異常。

在開始新項目之前，我決定找到解決這些問題的方法。我想也許我們遇到的這些問題是因為語言本身有點過于靈活和寬泛導致的。你輸入的內容幾乎沒有限制，再加上沒有編譯階段，沒有約束和運行前代碼驗證，這可能導致你的包存在嚴重錯誤。

然后我接觸到了Flowtype和TypeScript。經過短暫的評估后，我決定選擇TypeScript，并且一直用到現在。在兩年后的今天，我可以告訴你 - 決定使用TypeScript對項目和我的職業生涯來說是個不錯的選擇。但是，如果你認為TypeScript開發人員的生活總是稱心如意的，那么你最好繼續閱讀。

在本文中，我不想詳細說明TypeScripts的功能或深入項目設置。互聯網上有很多很好的資源（例如官方TS文檔：https://www.typescriptlang.or...）。當然，這篇文章也不是初學者的入門引導。

這是一個關于在使用TypeScript日常工作中感受到的優缺點的總結。我想描述一下我使用TypeScript的最糟糕體驗，另一方面，我也要說一下我認為最有用的功能。所以本文都是關于利弊好壞的權衡，讓我們開始吧。

正如我所提到的，我對react和redux有一些經驗，所以我想利用這些優勢，在新項目中使用類似的（自定義）配置。比如 - webpack，babel，npm scripts，jest，linter這些通用的東西，只需要額外做一件小事 - 支持TypeScript。

如果你現在處于同樣的境遇 - 我確切的告訴你：它不僅僅是在webpack配置中加一個loader。必須為TS提供一個聲明，用TSLint替換ESLint，集成TypeScript的loader和babel的配置，將TS插入Jest（測試平臺）。

一些操蛋的事情馬上就會發生。TS配置并不好搞，“簡單的復制并測試”這種策略并不是上手的最佳方法。

在將tsconfig.json放入項目之前，最好仔細閱讀文檔。

此外，Jest（轉換，模塊映射器）和css模塊存在一些問題。可能你遲早會面對它們。并且不要認為，你現在可以扔掉babel - TypeScript不會提供任何polyfill來讓你使用那些牛批閃閃的新語法和功能，也不會將你的新API轉換為舊瀏覽器可以理解的代碼。

所以我的建議是 - 如果可以的話，你應該使用一些入門工具或支持TS開箱即用的CLI（比如 angular cli），以避免無休止的項目配置。

另一個非常不愉快的經歷與TypeScript支持的類庫數量有關。

通常，如果你是某個人npm包的作者，你可以隨時使用有效的JavaScript包。有時，您還會公開包的ES6源代碼。如果你準備將庫用于TypeScript，你必須提供類型定義。簡單來說 - 是一個具有每個模塊，命名空間，類，方法，函數等的聲明的文件，TypeScript使用者需要用到這個。TypeScript模塊只能使用定義中描述的內容，并且只能以聲明中指定的方式使用。遺憾的是，通常源代碼和聲明之間沒有嚴格的聯系。并且它們可能還是不正確或過時的，或者根本就沒有。

就個人而言，我沒有找不到聲明這樣的問題。大多數流行的庫都有自己的作者或社區準備好的類型定義。如果您使用的包沒有這樣的文件 - 那就換一個，相同功能的npm包多的是。不過你可以搞一個“假的”聲明文件，或創建一個真實的聲明文件并發布出來，以此為開源社區做出貢獻。

不管怎樣，還有一個更嚴重的問題 - 正如我之前提到的，一些聲明是不正確的或過時的。如果你遇到這樣的問題，沒有簡單的解決方案。你可以使用聲明能正常工作的之前的版本，自己修復并貢獻出去或等待作者來解決。有時候他們會及時修復，有時候就沒那么快了。

順便說一句，我是一些簡單包的作者，相信我，即使想做好，但是我還是常常忘記將新功能與其類型定義同步。

現在該輪到高興點的部分了。一旦你配置了項目并選擇了具有良好TS支持的庫，就可以體會到類型語言的強大了。如果你沒有這種語言的背景，一開始可能有點奇怪。TypeScript中有許多功能在當前的JavaScript語法中找不到。讓我們談談其中對我來說最有用的那些。

如果大家所想，TS最常用的功能是靜態類型。沒有使用嚴格類型校驗也就沒有使用TypeScript的意義。當然你可以使用寬泛的“any”類型，這意味著“我不關心那個東西的類型，它可能是一個數字，它可能是一個字符串數組，只管用就行了”，嚴肅臉，如果你想用這樣方式編碼，那還不如用回舊的JavaScript。

類型將幫助你更快，更安全地編碼。你可以告訴編譯器“這個常量妥妥的是一個數字”，如果你嘗試將其用作數組或字符串，TS編譯器將始終提示你輸入錯誤。基本上，你仍然可以使用你的代碼做任何你想做的事情，就像常規JavaScript一樣，但現在你的操作比以前更安全，更易理解。

TypeScript中有幾種基本類型和一點點跟它們相關的高級類型和技術。

下面你可以看到一些基礎的但非常強大的東西，對于更高級的類型，請訪問文檔：https://www.typescriptlang.or...。

除了眾所周知的類型，如數字或字符串，TypeScript還提供了枚舉類型。

您可以使用內置類型，如Date或Error。嘗試代碼提示，以實現更快，更安全的編程。

如果你認為類型是“顛覆者”，那么你對接口有什么看法？接口可以幫助你編寫更好的代碼，因為它們最終允許你定義對象之間的約定好的實現方式。我創建了很多接口。他們無處不在。有時我專門為接口寫一個文件，因為這樣是值得的。

我主要用它來描述對象，類，函數和參數的形狀。你可以在模塊之間共享它們并像處理源代碼中的實例一樣對待，不過要記住 - 運行時接口不會出現在代碼里，這一點很容易忽略。這就是為什么有些情況下使用類而不是接口（如使用Angular Dependency Injection）更好。讓我們看一下接口的一些真實例子：

在左邊 - 返回類型的錯誤實現。在右側 - VS Code 立即通知你代碼中的錯誤。

在左側 - 一個類錯誤地實現了用戶擴展的接口（參見上一個屏幕）。在右邊 - 描述錯誤信息..

ES6中有類，所以你可能之前用過它。但是在TypeScript類中有一些額外的功能，可能EcmaScript的未來會實現這些功能。在TS中，您可以定義抽象類，你可以將類的屬性描述為靜態，私有或只讀，您可以擴展類并使類實現接口（沒毛病）。我不會比較TS類和ES6類之間的差異，因為最終它們都會產生類似的JavaScript代碼（在編譯和轉換之后）。在TS類中，只是用優雅而有效的方式封裝要使用的類，它們與其他語言實現（如Java）非常相似，這會產生一些影響（更多關于“代碼審查”部分的內容）。看一下例子就能知道怎么用TypeScript和優秀的代碼編輯器配合來讓你的工作更容易。

當然，TypeScript中還有很多新東西，比如泛型（你會使用它們），枚舉（對于內部事物可能會用到），命名空間，JSX支持等等。但你一開始不需要知道的面面俱到，只需使用上面提到的基本功能，你將看到，你的代碼質量得到了提高。

使用TypeScript，你可以使用抽象類等功能。有關抽象類的更多信息：https://www.typescriptlang.or...

TypeScript支持private，public和protected方法，只讀屬性。類可以實現接口或擴展其他類。

我剛才提到代碼質量了嗎？當然提到了，因為我們都關心代碼質量（除此之外還有客戶需求，截止日期和排期，以及...）。

那么為什么應該使用TypeScript呢？（在代碼質量這個層面）

代碼中沒有與參數或變量名的拼寫錯誤相關的一些非常煩人的運行時錯誤

您可以建立清晰明了的對象之間的約定

不用hack的手段就能實現類似在class中使用private的事情

有來自編譯器的即時反饋，很多錯誤都是在編譯階段捕獲的，而不是在運行時

讓非JS開發人員更容易閱讀和理解代碼

你可以使用JavaScript未來版本中的功能

為單元測試編寫mocks，stubs和fakes要容易得多，因為你知道他們的確切接口。

此外，由于出色的IDE支持，編寫可維護代碼要容易得多。老實說 - 即使你多帶帶寫一個不大的應用程序，幾周后你也會忘了你必須傳給服務的參數類型或新創建用戶包含什么樣的數據。你當然可以翻源碼，過一遍代碼然后找到有用的信息（假設你的代碼總是簡潔的），但在你喜歡的編輯器中將鼠標hover到函數名上就能看到你要的信息豈不更好？例如，它接受“age”，這是一個“number”，并返回具有“age”和“name”屬性的用戶實例。

代碼審查是我想提到的另一件事。當你在小團隊中工作時，有時候你是唯一的前端開發人員，在做.net或Java的同事真的不喜歡看原生的JavaScript。由于語言的動態和簡潔性，他們會覺得可讀性很差，沒有類型意味著沒有提示。例如 - 名稱為“user”的對象具有“ID”屬性，但ID是數字還是字符串？如果是一個字符串，為什么你只需要調用“toString（）”就可以了？如果是一個數字，為什么你剛剛在它前面添加字符串“id_”呢？TypeScript代碼看起來很像其他流行的類型語言，并且你有可能將獲得更好，更準確的代碼審查。更好的代碼審查意味著更好的代碼，這個不需要我再多說了吧。

左側 - TypeScript中的代碼。右邊 - Java中的代碼。如您所見，語法非常相似，這意味著比起原生的JavaScript,Java開發人員應該更容易理解你的TypeScript代碼。

最后關于TypeScript我還要多說一點。與往常一樣，當你嘗試新事物時，會有一些學習曲線。放到TS下看，它不是非常陡峭，但是要避免TypeScript和新框架一起用，這兩樣加起來就會讓學習曲線變得足夠陡峭。特別是在大型或缺乏經驗的團隊中。這就是為什么我兩年前選擇了這個項目作為我的第一個TypeScript應用 - 我對react那套技術棧非常熟悉，所以這是一個學習一種有前途的新語言很好的機會。我敢保證，如果我同時選擇了一個新框架（比如說Angular）和一種新語言，我會被按在地上摩擦。

我會向你推薦TypeScript嗎？當然會。它將幫助你在更短的時間內寫出更好的代碼。IDE支持現在非常棒，社區充滿活力，具有TS定義的庫的數量很龐大而且還在不斷增長，用過的程序員都說好（來自編譯器的快速反饋）。這是我所知道的用于創建現代和可擴展的Web應用程序（當然還有Node.js服務）的最佳工具。請記住上面提到的一些缺點，解決了它們就能深入探索靜態類型語言的多彩世界了。