全文共1740字，預計學習時長8分鐘

圖源：clearboxseo

首先必須要聲明：類型化JavaScript非常棒。

我使用過Flow，現在和將來也都將繼續使用TypeScript。不可否認，這是一個快速發展的強大工具。

然而，它是無所不能的嗎？顯然不是，這種強大力量背後的代價是什麼，值得我們思考，我們需要正視其利弊之處。

讓子彈先飛一會兒，來看看類型化JavaScript的缺陷吧~

代碼很容易變得冗長

事實上，TypeScript和Flow的手動類型化並不是一件好事！它使代碼更冗長，容易出錯並且更難管理。

圖源：unsplash

理想情況下，TypeScript會從數據庫以及已定義的語言中推斷類型。這樣，我們就可以從類型安全中受益，只需管理自定義對象類型。

但冗餘真的很難避免。來看看用TypeScript編寫的基於類的簡單React組件：

    
interface NameProviderProps {
                                   children: (state: NameProviderState) =>React.ReactNode;
                                 }
      
 
                                 interfaceNameProviderState {
                                   readonly name: string;
                                 }
      
 
                                 exportclassNameProviderextendsReact.Component {
                                   readonly state: NameProviderState= { name: 'Piotr' };
      
 
                                   render() {
                                     return this.props.children(this.state);
                                   }
                                 }  

view rawtypescriptComponent.js | GitHub

這是一個簡單的基於類的React組件：

    exportclassNameProviderextendsReact.Component {
                               state= { name: 'Piotr' };
      
 
                               render() {
                                 return this.props.children(this.state);
                               }
                             }  

view rawplainComponent.js | GitHub

TypeScript版本的代碼增加了248％。工具和運行狀態的確好了很多，但可讀性呢？

只需看一下處理Redux操作的類型示例，非常熟練且實用，你不必再擔心陷入類型轉換帶來的麻煩……

    typeInferValueTypes = T extends { [key: string]: infer U } ? U : never;

type Actions = ReturnType>  

手動寫入的類型很容易出錯

假設一個大團隊正在從事一個項目，John編寫了以下類型定義：

    typePropsA = {
 name: string,
 date: Date,
 url: string
}  

編寫之時，Pablo並未意識到類型已經存在，因此他創建了一個類似的類型：

    typePropsB = {
 name: string,
 date: string,
 url: string
}  

現在便有了冗餘類型，更糟糕的是，因PropsB的定義稍有不同，便很難再進行明確的類型定義。

這樣的事情不在少數，投入數百萬美元的大型項目中也時有發生。

圖源：unsplash

許多數據庫缺乏類型

儘管類型化生態系統發展迅速，但它還遠沒有達到100％應用。這意味着在許多情況下，你得自己上手。

但是，每個大型項目最終都會推出一些不規範的自定義類型（或從GitHub問題中複製它們）來應用於一些庫或用例。

即使是最流行的庫，例如Redux，一旦缺乏規範的類型，也很難管理好應用狀態、形式轉換程序等。

給予錯誤的安全感

雖然這可能不是最好的方法，但是假設你定義了一個redux操作，如下所示：

    exportconst MY_BASIC_ACTION: ‘MY_BASIC_ACTION’ = ‘MY_BASIC_ACTION’  

其中一些操作很簡單，但是當你面臨30種操作類型，在以舊操作作爲模板複製新操作時，很容易發生以下情況：

    exportconst MY_NEW_ACTION: ‘MY_BASIC_ACTION’ = ‘MY_BASIC_ACTION’  

看出問題了嗎？我們只是以第一種操作的類型定義了一個新操作。

這很難查詢，因爲你本應發送MY_NEW_ACTION，但實際上發送了MY_BASIC_ACTION。

在使用Flow / TypeScript時，你會感到非常安心，毫無防備。而等到你意識時問題已經變得非常棘手了，你可能會恨不得把頭撞在牆上幾個小時！

圖源：unsplash

類型管理本身就是一種技能

JavaScript已經很容易理解，但將類型添加到這種動態、不存在隱患的語言中時，只有具備高超的技能，才能正確而高效地編寫類型。

避免類型化JS並不能作爲逃避困難的理由，但是對於期限緊迫的現實項目或大部分初級開發人員來說，可能不得不這麼做。

在大多數情況下，你可能只需要給組件的屬性、狀態等分類。但是這個問題，總有一天你得面對。

強大的IDE可能就是你所需要的

VSCode中的IntelliSense與整理工具相結合，開發人員可能會從TypeScript和Flow中獲得更多便利。

IDE的支持會讓你獲頗豐。我敢打賭，你會驚訝於對TypeScript的疏忽之處如此之少。

圖源：creative-tim

沒有類型安全的編碼提供了JavaScript的全部功能——畢竟，它是基於設計的鬆散類型化編碼——並使你對此格外小心。

更多要管理的配置

建立類型化的操作系統並不簡單，需要使用構建工具，管理配置文件，並創建更多依賴項等。你需要在曾經易於集成的庫中尋找一個單獨的部分，用以與TypeScript搭配使用。

而最痛苦的是，你可能會花費大量時間在GitHub中搜索解決方案，以使LibraryZ與Flow或TypeScript一起使用。

圖源：unsplash

真正的成就是，沒有類型但仍然可以瀏覽和自記錄的項目。或許你會覺得我討厭TypeScript，但恰恰相反，我非常喜歡TypeScript，我對它的好處深有體會。

但是，工欲善其事必先利其器，理性探討它的缺陷也是必要的，不是嗎？

留言點贊關注

我們一起分享AI學習與發展的乾貨

如轉載，請後臺留言，遵守轉載規範