先別用 TypeScript了！
首先必須要聲明：類型化JavaScript非常棒。
我使用過(guò)Flow，現(xiàn)在和將來(lái)也都將繼續(xù)使用TypeScript。不可否認(rèn)，這是一個(gè)快速發(fā)展的強(qiáng)大工具。
然而，它是無(wú)所不能的嗎?顯然不是，這種強(qiáng)大力量背后的代價(jià)是什么，值得我們思考，我們需要正視其利弊之處。
讓子彈先飛一會(huì)兒，來(lái)看看類型化JavaScript的缺陷吧~
代碼很容易變得冗長(zhǎng)
事實(shí)上，TypeScript和Flow的手動(dòng)類型化并不是一件好事!它使代碼更冗長(zhǎng)，容易出錯(cuò)并且更難管理。
理想情況下，TypeScript會(huì)從數(shù)據(jù)庫(kù)以及已定義的語(yǔ)言中推斷類型。這樣，我們就可以從類型安全中受益，只需管理自定義對(duì)象類型。
但冗余真的很難避免。來(lái)看看用TypeScript編寫的基于類的簡(jiǎn)單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);
- }
- }
這是一個(gè)簡(jiǎn)單的基于類的React組件：
- exportclassNameProviderextendsReact.Component {
- state= { name: 'Piotr' };
- render() {
- return this.props.children(this.state);
- }
- }
view rawplainComponent.js | GitHub
TypeScript版本的代碼增加了248%。工具和運(yùn)行狀態(tài)的確好了很多，但可讀性呢?
只需看一下處理Redux操作的類型示例，非常熟練且實(shí)用，你不必再擔(dān)心陷入類型轉(zhuǎn)換帶來(lái)的麻煩……
- typeInferValueTypes<T> = T extends { [key: string]: infer U } ? U : never;
- type Actions = ReturnType<InferValueTypes<typeof actions>>
手動(dòng)寫入的類型很容易出錯(cuò)
假設(shè)一個(gè)大團(tuán)隊(duì)正在從事一個(gè)項(xiàng)目，John編寫了以下類型定義：
- typePropsA = {
- name: string,
- date: Date,
- url: string
- }
編寫之時(shí)，Pablo并未意識(shí)到類型已經(jīng)存在，因此他創(chuàng)建了一個(gè)類似的類型：
- typePropsB = {
- name: string,
- date: string,
- url: string
- }
現(xiàn)在便有了冗余類型，更糟糕的是，因PropsB的定義稍有不同，便很難再進(jìn)行明確的類型定義。
這樣的事情不在少數(shù)，投入數(shù)百萬(wàn)美元的大型項(xiàng)目中也時(shí)有發(fā)生。
圖源：unsplash
許多數(shù)據(jù)庫(kù)缺乏類型
盡管類型化生態(tài)系統(tǒng)發(fā)展迅速，但它還遠(yuǎn)沒有達(dá)到100%應(yīng)用。這意味著在許多情況下，你得自己上手。
但是，每個(gè)大型項(xiàng)目最終都會(huì)推出一些不規(guī)范的自定義類型(或從GitHub問題中復(fù)制它們)來(lái)應(yīng)用于一些庫(kù)或用例。
即使是最流行的庫(kù)，例如Redux，一旦缺乏規(guī)范的類型，也很難管理好應(yīng)用狀態(tài)、形式轉(zhuǎn)換程序等。
給予錯(cuò)誤的安全感
雖然這可能不是最好的方法，但是假設(shè)你定義了一個(gè)redux操作，如下所示：
- exportconst MY_BASIC_ACTION: ‘MY_BASIC_ACTION’ = ‘MY_BASIC_ACTION’
其中一些操作很簡(jiǎn)單，但是當(dāng)你面臨30種操作類型，在以舊操作作為模板復(fù)制新操作時(shí)，很容易發(fā)生以下情況：
- exportconst MY_NEW_ACTION: ‘MY_BASIC_ACTION’ = ‘MY_BASIC_ACTION’
看出問題了嗎?我們只是以第一種操作的類型定義了一個(gè)新操作。
這很難查詢，因?yàn)槟惚緫?yīng)發(fā)送MY_NEW_ACTION，但實(shí)際上發(fā)送了MY_BASIC_ACTION。
在使用Flow / TypeScript時(shí)，你會(huì)感到非常安心，毫無(wú)防備。而等到你意識(shí)時(shí)問題已經(jīng)變得非常棘手了，你可能會(huì)恨不得把頭撞在墻上幾個(gè)小時(shí)!
圖源：unsplash
類型管理本身就是一種技能
JavaScript已經(jīng)很容易理解，但將類型添加到這種動(dòng)態(tài)、不存在隱患的語(yǔ)言中時(shí)，只有具備高超的技能，才能正確而高效地編寫類型。
避免類型化JS并不能作為逃避困難的理由，但是對(duì)于期限緊迫的現(xiàn)實(shí)項(xiàng)目或大部分初級(jí)開發(fā)人員來(lái)說(shuō)，可能不得不這么做。
在大多數(shù)情況下，你可能只需要給組件的屬性、狀態(tài)等分類。但是這個(gè)問題，總有一天你得面對(duì)。
強(qiáng)大的IDE可能就是你所需要的
VSCode中的IntelliSense與整理工具相結(jié)合，開發(fā)人員可能會(huì)從TypeScript和Flow中獲得更多便利。
IDE的支持會(huì)讓你獲頗豐。我敢打賭，你會(huì)驚訝于對(duì)TypeScript的疏忽之處如此之少。
沒有類型安全的編碼提供了JavaScript的全部功能——畢竟，它是基于設(shè)計(jì)的松散類型化編碼——并使你對(duì)此格外小心。
更多要管理的配置
建立類型化的操作系統(tǒng)并不簡(jiǎn)單，需要使用構(gòu)建工具，管理配置文件，并創(chuàng)建更多依賴項(xiàng)等。你需要在曾經(jīng)易于集成的庫(kù)中尋找一個(gè)單獨(dú)的部分，用以與TypeScript搭配使用。
而最痛苦的是，你可能會(huì)花費(fèi)大量時(shí)間在GitHub中搜索解決方案，以使LibraryZ與Flow或TypeScript一起使用。
真正的成就是，沒有類型但仍然可以瀏覽和自記錄的項(xiàng)目?；蛟S你會(huì)覺得我討厭TypeScript，但恰恰相反，我非常喜歡TypeScript，我對(duì)它的好處深有體會(huì)。
但是，工欲善其事必先利其器，理性探討它的缺陷也是必要的，不是嗎?
