項目中使用 TypeScript 的一些感悟

上週發佈了一款名爲 Smartour 的工具，是徹底採用 TypeScript （如下簡稱 ts）來開發的。拋開之前作業務的時候的不徹底使用，此次實踐能夠算是我第一次真正意義上的使用 ts。因爲寫法上的不一樣，以及對不熟悉事物的新鮮感，在此次項目開發的過程當中着實有着許多感悟，因而打算寫篇小東西好好記錄下來。

TS 能讓人養成「先思考後動手」的好習慣

在以往的開發過程當中，個人習慣老是「先想好一個大概，而後邊作邊想再邊改」。這樣的好處是動做比較快，順利的時候效率會很高，但更多的時候是不斷地推翻本身先前的想法，相信很多的人也有跟我相似的體會。

而使用 ts，能夠在必定程度上減小這個問題。衆所周知 ts 是強類型的語言，這也意味着它能有效制約開發者在開發過程當中「爲所欲爲」的程度。就以定義一個函數的參數爲例，能夠看看我在寫 js 和 ts 的思考方式上有什麼不一樣。

寫 js 的時候，個人思考過程是這樣的。

1. 首先這個參數是一個對象，這個對象的屬性 el 是一個 css 選擇器；而對象的屬性 keyNodes 是一個數組，裏面的元素是一系列的 keyNode。
2. 這個所謂的 keyNode 也是一個對象，它也包含了一個 css 選擇器屬性 el，以及一個綁定在 dom 元素上的事件參數 event。
3. 我會把這個參數對象以註釋的形式寫下來，以便記住它的具體定義。

/** { el: '#demo-id', keyNodes: [{ el: '.item-1', event (e) { console.log(e) } }] } */
複製代碼

4. 之後任何地方要用到這個參數，我都要手動保證參數的結構要和這個註釋保持一致。

而換成 ts 的寫法之後，個人思路是這樣的：

1. 首先這個參數是一個對象，這個對象的屬性 el 是一個 css 選擇器；而對象的屬性 keyNodes 是一個數組，裏面的元素是一系列的 keyNode。
2. 而後我會經過 interface 把它給定義好：

interface HightlightElement {
    el: string,
    keyNodes: Array<KeyNode>
}
複製代碼

interface KeyNode {
    el: string,
    event: EventListener
}
複製代碼

3. 在須要用到這個參數的時候，只須要在定義形參的時候傳入這個 interface 便可。萬一參數結構或內容的類型有誤，VScode 編輯器都會馬上給予提示，省去了手動檢查的麻煩。

someFunction (param: HightlightElement) { ... }
複製代碼

能夠看到，在寫 js 的時候更多的是「本身和本身約定，本身判斷是否遵照了約定」，而 ts 則是「本身和本身約定之後，由第三方（編輯器）去判斷是否遵照了約定」。這樣的好處是除了老生常談的減小錯誤以外，更多的則是對思惟上的良性約束。這種良性約束可以讓咱們在思考的階段就定義好接下來要作的一系列事情，在操做的過程當中若是發現任何問題也可以在第一時間溯源回最初思考的起點，排查問題的時候會更加高效。

TS 擁有自成文檔的特性

在寫 js 的時候，咱們依賴註釋去判斷某個變量或參數的類型、結構和做用。若是沒有了註釋，只能經過閱讀源碼和不斷調試去搞清楚當中的細節。許多人在接手他人項目的時候都會有這麼一個經歷：「爲何不寫註釋！這個函數寫的啥！這參數又是啥！」沒有註釋的 js 代碼是讓人崩潰的，可是寫註釋不只須要時間，更考驗一我的的歸納能力。說了等於沒說甚至誤導性的註釋，也是足夠讓人崩潰。

在 ts 中，除了註釋之外咱們還有另一個選擇，就是查看某個變量或參數所對應的 interface 接口定義。在 interface 中咱們能夠很直觀地看到參數的結構，內部屬性的類型，是否爲可選等詳細信息。再加上VScode 的智能提示及跳轉，不論是查看他人的代碼仍是維護一個歷史項目，都能更加方便和規範——畢竟寫接口每每比寫註釋要順手，看接口每每比猜代碼要穩妥。

說到自成文檔的特性，我也聯想到了另一個熱門技術 GraphQL。藉助 GraphQL 社區配套的一系列工具，調用方在調用接口的時候就能直接讀到接口的標準定義；而接口的開發者也不須要額外編寫文檔，在定義接口的時候其實就至關於把文檔也寫好了。

自成文檔的特性對於多人維護的項目來講是很是有用的，它可以大大下降項目當中溝通和理解的成本。可是這句話也有一個前提，就是開發者要遵照併合理工具當中的約束規範，若是一個接口的任何參數類型都是 any ，那麼也就失去了使用 ts 的意義。

TS 可以下降搭建環境的時間成本

爲了同時使用 js 新穎的特性以及兼容陳舊的瀏覽器，咱們每每會藉助一系列的工具去搭建一套開發環境。也許咱們已經習慣了 webpack + babel 的開發方式，但是又有誰可以保證本身在不看文檔的狀況下可以本身去搭一套呢？且不說這些工具各有着複雜的文檔，就算好不容易把環境搭好了，還會發現有着更多「最佳實踐」。改來改去花了一天時間，才終於算是完成。

做爲 js 的超集，咱們能夠在 ts 中放心使用 js 的各類高級能力。因爲自帶命令行工具，咱們再也不須要去研究 babel 或者各類 preset-env 插件，只須要指定須要構建的版本，ts 命令行工具就會自動爲咱們生成對應版本的 js。

固然這並非說有了 ts 就可以徹底拋棄構建工具了，在構建複雜應用（如包含各類靜態資源，跨格式文件引用）場景的狀況下仍是離不開構建工具的，且在將來很長一段時間都會維持這種情況。可是秉承着「多一事不如少一事」的原則，只要可以減小哪怕是一個工具的使用，對開發者來講都是有好處的，畢竟咱們都期待着某一個可以只管代碼無論環境的日子。

尾聲

因爲不是 ts 的資深玩家，以上的碎碎念都是做爲一個初學者我的的新鮮感。在工做的這些日子裏，也深入體會到永遠沒有百分百理想化的東西。ts 當然是好，但也須要辯證地看待它。咱們是否真的須要 ts？它是否真的可以提升咱們的生產力？它是否真的如他人描述般理想？這些問題都須要通過實踐才能回答。說到底 ts 只是一個工具，何時用它，怎麼用它，仍是取決於具體的場合。一味地尬吹或者否定其餘的東西，只能說明思想仍是太狹隘了。