[譯] Angular: 咱們爲何選擇TypeScript?

[譯] Angular: Why TypeScript?

做者：Victor Savkin
原文地址：https://vsavkin.com/writing-a...

關於做者

Victor Savkin 是 nrwl.io 的其中一位創始人，向企業團隊提供Angular的諮詢服務。他之前在谷歌的Angular核心團隊，並創建了依賴注入、變動檢測、表單和路由器模塊。

nrwl.io 是由Angular核心貢獻者建立，以幫助團隊成功實現充滿展望項目的諮詢服務。

正文

Angular使用TypeScript編寫，在這篇文章裏，我將告訴你，咱們爲何作了這樣的選擇。我還將分享我使用TypeScript的經驗：它如何影響我編寫和重構代碼的方式。

TypeScript 裏優秀的工具

TypeScript最大的賣點就是它的工具。它提供先進的自動完成，導航和重構工具，而以上工具，幾乎徹底知足了大型項目的需求。沒有他們的話，對於修改代碼的恐懼會將代碼置於半隻讀的狀態，而且使大規模的重構很是危險和昂貴。

TypeScript不是惟一能夠編譯爲JavaScript的類型語言，也有其餘更強類型系統的語言，而且在理論上也能夠提供絕對優秀的工具。但實際上，它們中的大多數除了編譯器以外沒有其餘任何東西。

這是由於想要構建出豐富的開發工具，必須從開發的第一天起就明確這個目標，這一點，TypeScript團隊早已準備好了。

這就是爲何他們構建的語言服務能夠被編輯用來提供類型檢查和自動完成。若是你想知道爲何有那麼多出色的編輯器具備TypeScript的支持，那麼答案就是語言服務。

可靠的智能感知和基本重構(例如:重命名一個符號)，對編寫，尤爲是重構代碼的過程產生了巨大的影響。儘管這很難衡量，但我以爲之前可能須要幾天的重構如今能夠在一天以內完成。

雖然TypeScript極大地提升了代碼編輯的經驗，但它使開發人員的設置更加複雜，尤爲在與在頁面上刪除ES5腳本相比時。此外，你不能使用分析JavaScript源代碼的工具：(如JSHint)，但一般有足夠的替代品。

TypeScript 是 JavaScript 的超集

由於TypeScript是JavaScript的超集，因此你不須要經過一個大的重寫來遷移到它。你能夠慢慢地作，一次一個模塊。

選擇一個模塊，重命名.js文件到.ts，而後增量地添加類型註釋。當你完成這個模塊時，選擇下一個模塊。一旦輸入了整個代碼庫，就能夠開始調整編譯器設置，使其更加嚴格。

這個過程可能須要一些時間，但對於Angular遷移到TypeScript時不是一個大問題，它逐漸讓咱們在過渡期間不斷開發新的功能和修復bug。

TypeScript 使得抽象清晰可見

一個好的設計就是定義良好的接口。並且，用支持它們的語言來表達接口的想法要容易得多。

例如，假設有一個圖書銷售應用程序，能夠經過一個註冊用戶經過UI或經過某種API經過外部系統進行購買。

正如您所看到的，這兩個類都扮演着購買者的角色。儘管對於應用程序很是重要，但購買者的概念在代碼中並無明確表達出來。沒有名爲購買者.js的文件。所以，修改代碼的人可能會忽略這個角色的存在。

僅僅經過查看代碼來判斷哪些對象能夠扮演購買者的角色，以及該角色的方法是困難的。
咱們不肯定，也不會從咱們的工具中獲得不少幫助。咱們必須手動推斷這些信息，這是緩慢且容易出錯的。

如今，將它與咱們明肯定義了 Purchaser 接口 的版本進行比較。

類型化的版本清楚地說明了咱們有 Purchaser 接口，而User和ExternalSystem類實現了它。因此TypeScript接口容許咱們定義抽象/協議/角色。

重要的是要認識到TypeScript並無強迫咱們引入額外的抽象。Purchaser 抽象在代碼的JavaScript版本中，可是沒有明肯定義。
在靜態類型語言中，子系統之間的邊界是使用接口定義的。因爲JavaScript缺少接口，因此在普通JavaScript中邊界不能很好地表達。因爲不能清楚地看到邊界，開發人員開始依賴於具體類型而不是抽象接口，從而致使緊密耦合。

TypeScript 使代碼更容易閱讀和理解

是的，我知道這看起來並不直觀。讓我用一個例子來講明個人意思。讓咱們來看看這個函數jQuery.ajax()。咱們能從它的簽名中獲得什麼信息?

咱們惟一能肯定的是這個函數有兩個參數。咱們能夠猜想這些類型。也許第一個是字符串，第二個是配置對象。但這只是猜想，咱們可能錯了。咱們不知道什麼選項進入設置對象(它們的名稱和類型)，或者該函數返回什麼。

在不檢查源代碼或文檔的狀況下，咱們不可能調用這個函數。檢查源代碼並非一個好的選擇——擁有函數和類的目的，是在不知道如何實現它們的狀況下使用它們。換句話說，咱們應該依賴於他們的接口，而不是他們的實現。咱們能夠檢查文檔，但這並非最好的開發經驗——它須要額外的時間，並且文檔常常過時。

所以，儘管很容易閱讀jQuery.ajax(url,settings)，真正理解如何調用這個函數，咱們須要閱讀它的實現或它的文檔。

如下是一個類型版本：

它給了咱們更多的信息。

• 這個函數的第一個參數是一個字符串。

• 設置參數是可選的。咱們能夠看到全部能夠傳遞到函數中的選項，不只是它們的名稱，還包括它們的類型。

• 函數返回一個JQueryXHR對象，咱們能夠看到它的屬性和函數。

類型化簽名確定比未類型化的簽名長，可是:string，:JQueryAjaxSettings和JQueryXHR並非混亂的。
它們是提升代碼的可理解性的重要文檔。咱們能夠更深刻地理解代碼，而沒必要深刻到實現或讀取文檔中。
個人我的經驗是，我能夠更快地閱讀類型化代碼，由於類型提供了更多的上下文來理解代碼。
但若是讀者能找到一項關於類型如何影響代碼可讀性的研究，請留下評論。

與編譯到JavaScript的許多其餘語言相比，TypeScript的不一樣之處在於它的類型註釋是可選的，而 jQuery.ajax(url, settings)仍然是有效的TypeScript。所以，TypeScript的類型不是一個開關，而是一個錶盤。
若是您發現代碼沒有類型註釋，這對於閱讀和理解來講是微不足道的，那麼請不要使用它們。僅當它們添加值時才使用類型。

TypeScript 限制表達嗎?

動態類型的語言有較落後的工具，但它們更具可塑性和表現力。我認爲使用TypeScript可使您的代碼更加嚴格，可是比人們認爲的要寬鬆得多。
讓我告訴你個人意思，假設我使用ImmutableJS來定義Person記錄。

咱們如何類型record?讓咱們從定義一個名爲Person的接口開始:

若是咱們嘗試如下代碼

TypeScript編譯器會指出，他不知道PersonRecord，可是其實PersonRecord是由Person反射建立的，兩者是相容的。
一些有FP背景的人可能會說:「是否只有TypeScript有從屬類型!」但事實並不是如此。TypeScript的類型系統並非最早進的。

但它的目標是不一樣的。並非爲了證實這個程序是100%正確的。它是關於給你更多信息並啓用更大的工具。所以，當類型系統不夠靈活時，可使用快捷方式。所以，咱們能夠將建立的記錄轉換爲以下:

它之因此有效是由於類型系統是結構化的。只要建立的對象具備正確的字段——名稱和年齡。

你須要接受這樣一種心態:在TypeScript走捷徑是能夠的。
只有這樣，你纔會發現使用語言是使人愉快的。

例如，不要嘗試將類型添加到某些funky元編程代碼中——極可能您沒法靜態地表達它。
類型化代碼周圍的全部內容，並告訴typechecker忽略funky位。在這種狀況下，您將不會失去大量的表現力，並且您的大部分代碼將保持工具和可分析性。

這相似於試圖得到100%的單元測試代碼覆蓋率。而得到95%一般不是那麼困難，得到100%是具備挑戰性的，而且可能會對應用程序的架構產生負面影響。

可選的類型系統還保留了JavaScript開發工做流。您的應用程序的大部分代碼庫能夠「斷開」，但您仍然能夠運行它。TypeScript將繼續生成JavaScript，甚至當類型檢查器發出警告或報錯時。這在開發過程當中很是有用。

爲何選擇TypeScript

如今有不少能夠選擇的選項:ES五、ES6(Babel)、打字稿、Dart、PureScript、Elm等。那麼，咱們爲何選擇了TypeScript?

讓咱們先從ES5開始比較。
ES5比TypeScript有一個明顯的優點:它不須要一個轉流機。這容許您保持構建設置的簡單性。您不須要設置文件觀察者、transpile代碼、生成源映射。它只是工做。

ES6須要一個轉換設備，所以構建設置與TypeScript沒有太大區別。但它是一個標準，這意味着每個編輯器和構建工具要麼支持ES6，要麼支持它。這是一個較弱的論據，在這一點上，有優秀的TypeScript支持，它能被用於大多數編輯者。

Elm和PureScript是優雅的語言，具備強大的類型系統，能夠證實您的程序比TypeScript多得多。在Elm和PureScript中編寫的代碼比在ES5中編寫的代碼要多得多。

每一個選項都有優勢和缺點，但我認爲TypeScript在一個很好的地方，使它成爲大多數項目的最佳選擇。
TypeScript佔了良好的靜態語言的95%的有用性，並將其引入到JavaScript生態系統中。您仍然以爲本身編寫ES6:您一直使用相同的標準庫、相同的第三方庫、相同的習語和許多相同的工具(例如:Chrome開發工具)。它會給你不少東西，但不會強迫你離開JavaScript生態系統。