日本综合一区二区|亚洲中文天堂综合|日韩欧美自拍一区|男女精品天堂一区|欧美自拍第6页亚洲成人精品一区|亚洲黄色天堂一区二区成人|超碰91偷拍第一页|日韩av夜夜嗨中文字幕|久久蜜综合视频官网|精美人妻一区二区三区

RELATEED CONSULTING
相關(guān)咨詢
選擇下列產(chǎn)品馬上在線溝通
服務(wù)時(shí)間：8:30-17:00
你可能遇到了下面的問題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案
先別用TypeScript了！

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

我使用過Flow，現(xiàn)在和將來也都將繼續(xù)使用TypeScript。不可否認(rèn)，這是一個(gè)快速發(fā)展的強(qiáng)大工具。

然而，它是無所不能的嗎?顯然不是，這種強(qiáng)大力量背后的代價(jià)是什么，值得我們思考，我們需要正視其利弊之處。

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

代碼很容易變得冗長

事實(shí)上，TypeScript和Flow的手動(dòng)類型化并不是一件好事!它使代碼更冗長，容易出錯(cuò)并且更難管理。

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

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

 
 
 
    
  
  
  
  1. interface NameProviderProps {
    2. 
  
  
  
  2.                                    children: (state: NameProviderState) =>React.ReactNode;
    3. 
  
  
  
  3.                                  }
    4. 
  
  
  
  4.       
    5. 
  
  
  
  5.  
    6. 
  
  
  
  6.                                  interfaceNameProviderState {
    7. 
  
  
  
  7.                                    readonly name: string;
    8. 
  
  
  
  8.                                  }
    9. 
  
  
  
  9.       
    10. 
  
  
  
  10.  
    11. 
  
  
  
  11.                                  exportclassNameProviderextendsReact.Component {
    12. 
  
  
  
  12.                                    readonly state: NameProviderState= { name: 'Piotr' };
    13. 
  
  
  
  13.       
    14. 
  
  
  
  14.  
    15. 
  
  
  
  15.                                    render() {
    16. 
  
  
  
  16.                                      return this.props.children(this.state);
    17. 
  
  
  
  17.                                    }
    18. 
  
  
  
  18.                                  }
    19.

這是一個(gè)簡單的基于類的React組件：

 
 
 
    
  
  
  
  1. exportclassNameProviderextendsReact.Component {
    2. 
  
  
  
  2.                                state= { name: 'Piotr' };
    3. 
  
  
  
  3.       
    4. 
  
  
  
  4.  
    5. 
  
  
  
  5.                                render() {
    6. 
  
  
  
  6.                                  return this.props.children(this.state);
    7. 
  
  
  
  7.                                }
    8. 
  
  
  
  8.                              }
    9.

view rawplainComponent.js | GitHub

TypeScript版本的代碼增加了248%。工具和運(yùn)行狀態(tài)的確好了很多，但可讀性呢?

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

 
 
 
    
  
  
  
  1. typeInferValueTypes = T extends { [key: string]: infer U } ? U : never;
    2. 
  
  
  
  2. 
  
  
  
  3. type Actions = ReturnType>
    4.

手動(dòng)寫入的類型很容易出錯(cuò)

假設(shè)一個(gè)大團(tuán)隊(duì)正在從事一個(gè)項(xiàng)目，John編寫了以下類型定義：

 
 
 
    
  
  
  
  1. typePropsA = {
    2. 
  
  
  
  2.  name: string,
    3. 
  
  
  
  3.  date: Date,
    4. 
  
  
  
  4.  url: string
    5. 
  
  
  
  5. }
    6.

編寫之時(shí)，Pablo并未意識(shí)到類型已經(jīng)存在，因此他創(chuàng)建了一個(gè)類似的類型：

 
 
 
    
  
  
  
  1. typePropsB = {
    2. 
  
  
  
  2.  name: string,
    3. 
  
  
  
  3.  date: string,
    4. 
  
  
  
  4.  url: string
    5. 
  
  
  
  5. }
    6.

現(xiàn)在便有了冗余類型，更糟糕的是，因PropsB的定義稍有不同，便很難再進(jìn)行明確的類型定義。

這樣的事情不在少數(shù)，投入數(shù)百萬美元的大型項(xiàng)目中也時(shí)有發(fā)生。

圖源：unsplash

許多數(shù)據(jù)庫缺乏類型

盡管類型化生態(tài)系統(tǒng)發(fā)展迅速，但它還遠(yuǎn)沒有達(dá)到100%應(yīng)用。這意味著在許多情況下，你得自己上手。

但是，每個(gè)大型項(xiàng)目最終都會(huì)推出一些不規(guī)范的自定義類型(或從GitHub問題中復(fù)制它們)來應(yīng)用于一些庫或用例。

即使是最流行的庫，例如Redux，一旦缺乏規(guī)范的類型，也很難管理好應(yīng)用狀態(tài)、形式轉(zhuǎn)換程序等。

給予錯(cuò)誤的安全感

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

 
 
 
    
  
  
  
  1. exportconst MY_BASIC_ACTION: ‘MY_BASIC_ACTION’ = ‘MY_BASIC_ACTION’
    2.

其中一些操作很簡單，但是當(dāng)你面臨30種操作類型，在以舊操作作為模板復(fù)制新操作時(shí)，很容易發(fā)生以下情況：

 
 
 
    
  
  
  
  1. exportconst MY_NEW_ACTION: ‘MY_BASIC_ACTION’ = ‘MY_BASIC_ACTION’
    2.

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

這很難查詢，因?yàn)槟惚緫?yīng)發(fā)送MY_NEW_ACTION，但實(shí)際上發(fā)送了MY_BASIC_ACTION。

在使用Flow / TypeScript時(shí)，你會(huì)感到非常安心，毫無防備。而等到你意識(shí)時(shí)問題已經(jīng)變得非常棘手了，你可能會(huì)恨不得把頭撞在墻上幾個(gè)小時(shí)!

圖源：unsplash

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

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

避免類型化JS并不能作為逃避困難的理由，但是對于期限緊迫的現(xiàn)實(shí)項(xiàng)目或大部分初級(jí)開發(fā)人員來說，可能不得不這么做。

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

強(qiáng)大的IDE可能就是你所需要的

VSCode中的IntelliSense與整理工具相結(jié)合，開發(fā)人員可能會(huì)從TypeScript和Flow中獲得更多便利。

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

沒有類型安全的編碼提供了JavaScript的全部功能——畢竟，它是基于設(shè)計(jì)的松散類型化編碼——并使你對此格外小心。

更多要管理的配置

建立類型化的操作系統(tǒng)并不簡單，需要使用構(gòu)建工具，管理配置文件，并創(chuàng)建更多依賴項(xiàng)等。你需要在曾經(jīng)易于集成的庫中尋找一個(gè)單獨(dú)的部分，用以與TypeScript搭配使用。

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

真正的成就是，沒有類型但仍然可以瀏覽和自記錄的項(xiàng)目?；蛟S你會(huì)覺得我討厭TypeScript，但恰恰相反，我非常喜歡TypeScript，我對它的好處深有體會(huì)。

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


網(wǎng)站欄目：先別用TypeScript了！
文章分享：http://www.dlmjj.cn/article/cdgepgs.html