爲何TypeScript是2019年編寫前端的最佳方式

有些人擔憂TypeScript是前端工具鏈的沒必要要依賴。是嗎？跟着我來了解現實是徹底相反的。

一個「動態類型語言專家」的故事:

在我編程生涯的10多年中，我從未喜歡過靜態類型的語言。自從2001年開始編程以來，我一直選擇動態選擇語言：PHP，JS，Ruby，Elixir。我處處都用C ++和Java編寫了一些程序，可是我一直討厭那些環境。（「爲何我須要在各處傳遞類型？這太糟了。我本身能夠照顧他們。」） 一切都在2年前發生了變化。那是我第一次使用TypeScript的時候。可是，從一開始我就沒有愛上它。在最初的幾天裏，這實際上讓我很煩。狀況很快改變了。我在代碼中輸入的類型定義越多，我越常常注意到它使我免於浪費時間在控制檯中手動調試愚蠢的bug。我開始欣賞這些類型。 在接下來的兩年中，不管什麼時候我在前端應用程序上進行協做，不管是Angular仍是React，我都注意到，不管我使用什麼框架，在全部.js項目中總會遺漏一件事：TypeScript 。 如今我必須認可。我不喜歡動態類型的語言了。我仍然能夠在其中高效地工做，可是當我不能只在IDE中查找類型定義或在對代碼進行原型設計時信任編譯器時，這使我感到不滿意。（我在Elixir中惟一仍然想念的是強類型。） 幸運的是，咱們沒必要等到Ecma TC39提交者將靜態類型系統引入JavaScript。咱們能夠改用TypeScript。特別是在新項目中，使用它的麻煩極少。

反TypeScript參數，儘管如此，仍然有人勇於爭辯說將TypeScript引入您的項目將：

增長新開發人員的入職時間

維護複雜化

與React發生不少衝突，

增長開發時間，

將項目鎖定到一年後將再也不存在的某些時髦技術中，

阻止招募優秀的JS人員，

使得不可能從非TS代碼庫中引入代碼，

使得在遙遠的未來很難編輯該應用。

我敢說他們都錯了。TypeScript將爲您解決以上全部狀況，我能夠爲您提供具體的論據，爲何會這樣。 這就是爲何我決定寫這篇文章的緣由。也許這將有助於說服您，您的朋友，同事或CTO使用這種出色的語言。 注意：在本文中，我不會解釋「 TypeScript是什麼」。我僅關注「 爲何」您應該使用它。

TypeScript的優點：

1.代碼更容易理解：一般，當您處理一段代碼（例如功能代碼）時，要徹底理解它，您須要掌握如下內容：

它接受什麼論點？

它返回什麼值？

須要什麼外部數據？

爲了產生返回值，這些參數和外部數據有什麼做用？

在動態類型語言中，一般很難回答前三個問題。若是一個函數收到 article 參數，那麼它究竟是什麼？它是具備某些商品屬性的對象嗎？有哪些確切的屬性？是否有一個 article.title 或 article.name ？我能夠始終假設 article.title 存在嗎？怎麼 article.isPublished 樣我可能知道此屬性article在應用程序的大多數位置都已合併到對象中，可是我能夠肯定，它始終也存在於此位置嗎？

要回答全部這些問題，一般須要執行如下操做之一：

console.log(article)在瀏覽器中放置一個，運行腳本，（也許單擊一下UI），而後閱讀日誌；

查看該函數的使用位置，並從那裏跟蹤將哪些數據放入全部出現的位置；

向您的同事詢問最近是否正在使用此代碼（但願他們仍然健在，在線並記住該代碼）；

假設它article與您所想的同樣，只是但願它能起做用。

這聽起來對您熟悉嗎？

對我來講，這聽起來像是任何動態類型化語言（例如JS，PHP，Ruby，Python，Elixir）中的典型Web開發工做流程。 在諸如TypeScript之類的靜態類型語言中，您能夠當即從IDE和編譯器中得到上述全部問題的答案。您再也不須要查看整個代碼庫，讓同事困擾於問題，也沒必要冒生產中的錯誤的風險。

2.代碼更容易實現

一般，當您必須建立新功能或新組件時，您的工做流程可能以下所示：

引導組件函數，組成其構造函數參數，編寫其他代碼。

若是它須要任何外部或複雜的數據（如user或articles），請猜想它的外觀，將其保存在本身的內存中，並像在代碼中那樣使用它。

將組件放到您的應用中，而後將道具傳遞給它。

對其進行手動或單元測試。（您須要確保它收到了它應該擁有的道具，並確保它應該如何工做。）

若是有什麼不對勁，請返回您的代碼，嘗試找出問題所在，進行修復，而後返回步驟no。4。

在TypeScript中，它是類似的，可是更容易，更快捷：

引導組件功能，定義其類型定義，並實現它。

若是須要任何外部或複雜數據，請查找它們的接口並重用它們（所有或部分）。

將組件放到您的應用中，而後將道具傳遞給它。

而已。（若是您在調用方和被調用方之間正確地匹配了typedef，則全部內容都應該能夠正常工做。如今惟一須要測試的就是組件的實際業務邏輯。）

所以，每當您以TypeScript編寫代碼時，它不只更具可讀性且不易出錯，並且主要是，更易於推理。

3.代碼更易於重構

您常常須要重構不少東西，可是因爲它們涉及不少東西和文件，所以您太懼怕更改它們了。

在TypeScript中，一般只需在IDE中單擊「 重命名符號 」命令便可重構這些東西。

在動態類型的語言中，能夠幫助您同時重構多個文件的最佳方法是使用RegExp搜索和替換。

在靜態類型語言中，再也不須要「搜索和替換」。使用諸如「查找全部事件」和「重命名符號」之類的IDE命令，您能夠在應用程序中查看給定功能，類或對象接口屬性的全部事件。

每當您想要稍微改善構建系統，重命名組件，更改user對象或刪除不推薦使用的屬性時，您都沒必要擔憂會再發生問題。TypeScript將幫助您查找重構位的全部用法，重命名它，並在重構後代碼有任何類型不匹配的狀況下向您發出編譯錯誤警告。

4.更少的錯誤

在多年的前端Web開發中，我注意到，只要有一我的坐在我旁邊，每當我作錯字時都會對我大喊大叫，我能夠節省大約50％的錯誤修復時間。可能爲null的值，或者將對象傳遞到應該爲數組的位置。

我很高興地說，我終於遇到了那個夥伴：它叫作TypeScript

多虧了它，如今編寫無效代碼變得更加困難。若是編譯成功，您可能會肯定它確實有效。

5.更少的樣板測試

當您肯定將變量正確地傳遞到全部給定位置時，就無需再對全部變量進行測試了。 與編寫簡單的樣板單元/集成測試不一樣，您能夠將更多的精力放在測試應用程序的業務邏輯上，而不是測試函數參數是否在彼此之間正確傳遞。 更少的測試意味着更短的時間來開發新功能，以及更小的代碼庫，從而減小了代碼的複雜性，出錯率而且易於維護。

6.代碼更易於合併

您團隊中的新初級開發人員剛剛發佈了PR，引入了新代碼。乍一看，一切都還不錯：代碼看起來不錯，單元測試在那裏，一切都經過了綠色。

您如今能夠肯定它能夠正常工做嗎？若是沒有適當的單元測試該怎麼辦？（是的。讓咱們認識現實中的人們，咱們不少人仍然沒有寫足夠的數量。）您會信任公關創做者嗎？仍是您會花費寶貴的5分鐘時間自行運行代碼並進行測試？

若是您的工具鏈中包含TypeScript，它將爲您提供另外一項保證檢查：typedef編譯檢查。

若是代碼看起來不錯，就能夠進行單元測試，而且整個程序均可以編譯，如今您能夠肯定整個程序能夠正常工做。

使用TypeScript能夠更輕鬆地信任其餘開發人員。它可能會提升您查看和合並PR的速度。

（反之亦然：因爲類型定義，對於新開發人員而言， 無需深刻研究或本身運行代碼，就更容易看到其餘人的代碼部分真正在作什麼。）

7.幫助開發人員擁有正確的工做流程

用靜態類型的語言編寫代碼時，首先須要考慮將要接收的數據類型，而後考慮要生成的數據類型。一般只有在那以後，您才坐下來進行實際的實現。

許多人會賭命，這是正確的編碼工做流程。

例如，不管什麼時候開發算法，都應首先考慮其理論公式，而後加以實施。

或者，不管什麼時候進行TDD，您首先須要考慮代碼在現實中的工做方式（它將接收什麼數據以及它將產生什麼數據），將其編寫爲測試，而後實施實際代碼。

一樣適用於TypeScript。它鼓勵您在坐下來執行代碼的內部實現以前，先考慮一下代碼的接口。

TypeScript缺點

1.須要編譯步驟

個人一些後端Node.js朋友告訴我，爲他們介紹TS只是不值得的，由於在將.ts它們運行在Node上以前，須要對全部文件進行預編譯會帶來不少麻煩。 雖然能夠確定您能夠經過良好的構建和開發設置來處理該問題，但我不能不一樣意它會爲您的Node.js應用程序增長一些開銷。 我在前端環境中對此表示不一樣。現在，每一個人都在編譯JS。您須要舊版瀏覽器支持嗎？ES7的功能？CSS-in-JS？對於全部這些，您可能已經使用了babel。 可使用Babel編譯TypeScript ,就像JS的任何其餘語法（包括ES7或JSX）同樣。

將TypeScript帶到您的前端項目中幾乎不會給構建設置帶來任何開銷。（僅在根本不編譯JS的狀況下，這可能會帶來開銷，可是這種狀況不多發生在前端。）

2.設置有點困難

我能夠贊成這一點。例如，TypeScript中的Next.js應用程序和Next.js應用程序之間有什麼區別？在第二種狀況下，您須要使Node.js服務器，webpack和jest測試運行程序可以與TypeScript一塊兒使用。另外，每當添加諸如React，Redux，Styled-Components之類的庫時，還須要爲其添加typedef，例如npm i @types/styled-components（除非lib中包含TS typedefs文件）。

您須要回答本身的問題是，您多久作一次這樣的事情？值得放棄TypeScript的全部優點嗎？

摘要

我是說咱們全部人都應該忽然切換到TypeScript嗎？不。例如，在一個現有項目中切換到它確定是不少工做，而且在這樣作以前，應該認真考慮一下。

可是，若是您要建立一個新的前端應用程序（必須隨時間進行維護），那麼狀況就很清楚了。使用TypeScript。老實說，我很想聽聽在您的下一個前端項目中使用TS的緣由是什麼。

我只想這樣說：經過使用TypeScript，您將得到許多強大的優點，而一開始只需付出不多的精力。 讓咱們來作TypeScript的人吧