【譯】使用TypeScript兩年後-值得嗎？

弄了一個持續更新的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服務）的最佳工具。請記住上面提到的一些缺點，解決了它們就能深刻探索靜態類型語言的多彩世界了。