先別用 TypeScript了！
首先必須要聲明：類型化JavaScript非常棒。
我使用過Flow，現在和將來也都將繼續使用TypeScript。不可否認，這是一個快速發展的強大工具。
然而，它是無所不能的嗎?顯然不是，這種強大力量背后的代價是什么，值得我們思考，我們需要正視其利弊之處。
讓子彈先飛一會兒，來看看類型化JavaScript的缺陷吧~
代碼很容易變得冗長
事實上，TypeScript和Flow的手動類型化并不是一件好事!它使代碼更冗長，容易出錯并且更難管理。
理想情況下，TypeScript會從數據庫以及已定義的語言中推斷類型。這樣，我們就可以從類型安全中受益，只需管理自定義對象類型。
但冗余真的很難避免。來看看用TypeScript編寫的基于類的簡單React組件：
- interface NameProviderProps {
- children: (state: NameProviderState) =>React.ReactNode;
- }
- interfaceNameProviderState {
- readonly name: string;
- }
- exportclassNameProviderextendsReact.Component<NameProviderProps, NameProviderState> {
- readonly state: NameProviderState= { name: 'Piotr' };
- render() {
- return this.props.children(this.state);
- }
- }
這是一個簡單的基于類的React組件：
- exportclassNameProviderextendsReact.Component {
- state= { name: 'Piotr' };
- render() {
- return this.props.children(this.state);
- }
- }
view rawplainComponent.js | GitHub
TypeScript版本的代碼增加了248%。工具和運行狀態的確好了很多，但可讀性呢?
只需看一下處理Redux操作的類型示例，非常熟練且實用，你不必再擔心陷入類型轉換帶來的麻煩……
- typeInferValueTypes<T> = T extends { [key: string]: infer U } ? U : never;
- type Actions = ReturnType<InferValueTypes<typeof actions>>
手動寫入的類型很容易出錯
假設一個大團隊正在從事一個項目，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的疏忽之處如此之少。
沒有類型安全的編碼提供了JavaScript的全部功能——畢竟，它是基于設計的松散類型化編碼——并使你對此格外小心。
更多要管理的配置
建立類型化的操作系統并不簡單，需要使用構建工具，管理配置文件，并創建更多依賴項等。你需要在曾經易于集成的庫中尋找一個單獨的部分，用以與TypeScript搭配使用。
而最痛苦的是，你可能會花費大量時間在GitHub中搜索解決方案，以使LibraryZ與Flow或TypeScript一起使用。
真正的成就是，沒有類型但仍然可以瀏覽和自記錄的項目。或許你會覺得我討厭TypeScript，但恰恰相反，我非常喜歡TypeScript，我對它的好處深有體會。
但是，工欲善其事必先利其器，理性探討它的缺陷也是必要的，不是嗎?
