Hooks是新的功能提案，出現在v16.7.0-alpha版本中，使用Hooks可以讓你在不使用類的情況下使用狀態和其他的一些react功能。可在此討論

看下面程式碼：

import { useState } from 'react';

function Example() {
  // Declare a new state variable, which we'll call "count"
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>You clicked {
 
count} times</p>
      <button onClick={() : setCount(count + 1)}>
        Click me
      </button>
    </div>
  );
}

可以看到上面有個useState,這個就是我們將要學習的第一個Hook.

在具體瞭解之前，先得知道這些變化對你的影響。

無重大改變

• 完全選擇加入： 你可以在幾個元件中嘗試Hooks，而無需重寫任何現有程式碼。但是如果你不想這樣，你現在可以不用學習或使用Hooks。
• 100％向後相容: Hooks
  不包含任何重大更改。
• 現在可使用: Hook目前處於alpha版本，更希望在收到社群反饋後將它們包含在React 16.7中

沒有計劃從React中刪除class。 你可以在本頁底部閱讀有關Hooks逐步採用策略的更多資訊。

Hook不會取代你對React概念的瞭解。 相反，Hooks為你已經知道的React概念提供了更直接的API：props，state，context，refs和lifecycle。正如我們稍後將展示的，Hooks還提供了一種新的強大方式來組合它們。

如果只是想開始學習Hooks，直接跳到下一頁。 你仍然可以繼續閱讀此頁面，詳細瞭解為什麼要新增Hooks

動機

Hook解決了React中各種看似無關的問題，我們在編寫和維護數以萬計的元件時遇到了這些問題。無論你是在學習React，每天使用它，還是更喜歡使用具有類似元件模型的不同庫，你都可能會發現其中的一些問題。

在元件之間重用有狀態邏輯很困難

React沒有提供將可重用行為“附加”到元件的方法（例如，將其連線到store）。如果你已經使用React一段時間，你可能熟悉渲染道具和高階元件等模式，試圖解決這個問題。但是這些模式要求你在使用它們時重構元件，這可能很麻煩並且使程式碼更難以遵循。如果你看一下React DevTools中一個典型的React應用程式，你可能會發現一個由包含提供者，消費者，高階元件，渲染道具和其他抽象層的元件組成的“包裝器地獄”。雖然我們可以在DevTools中過濾它們，但這指出了一個更深層次的基本問題：React需要一個更好的原語來共享有狀態邏輯。

使用Hook，你可以從元件中提取有狀態邏輯，以便可以獨立測試並重用。Hook允許您在不更改元件層次結構的情況下重用有狀態邏輯。 這樣可以輕鬆地在許多元件之間或與社群共享Hook。

我們將在編寫自定義鉤子中進行更多討論。

複雜的元件變得難以理解

我們經常不得不維護一些開始簡單的元件，但最後卻變成了無法管理的狀態邏輯和副作用的情況。每個生命週期方法通常包含不相關邏輯的混合。例如，元件可能會在componentDidMount和componentDidUpdate中執行一些資料提取。並且，相同的componentDidMount方法可能還包含一些設定事件偵聽器的無關邏輯，並在componentWillUnmount中執行清理。這樣，相互關聯的程式碼被拆分，但完全不相關的程式碼最終組合在一個方法中。這很容易引入錯誤和不一致。

在許多情況下，不可能將這些元件分解為較小的元件，因為狀態邏輯遍佈整個地方。測試它們也很困難。這是許多人更喜歡將React與單獨的狀態管理庫相結合的原因之一。但是，這通常會引入太多的抽象，要求在不同的檔案之間跳轉，並使重用元件變得更加困難。

為了解決這個問題，Hooks允許根據相關的部分（例如設定訂閱或獲取資料）將一個元件拆分為較小的函式， 而不是基於生命週期方法強制拆分。你還可以選擇使用reducer管理元件的本地狀態，以使其更具可預測性。

更多地關於Effect Hook討論

class混淆了人和機器

在我們的觀察中，class是學習React的最大障礙。你必須瞭解this在JavaScript中是如何工作的，這與它在大多數語言中的工作方式有很大不同。你必須記住bind事件處理程式。沒有不穩定的語法提議，程式碼非常冗長。開發者可以很好地理解props，state和自上而下的資料流，但仍然很難與類鬥爭。React中的函式和類元件之間的區別以及何時使用每個元件導致即使在經驗豐富的React開發人員之間也存在分歧。

此外，React已經推出了大約五年，我們希望確保它在未來五年內保持相關性。正如Svelte，Angular，Glimmer和其他人所表明的那樣，提前編譯元件在未來有很大潛力。特別是如果它不限於模板。最近，我們一直在嘗試使用Prepack進行元件摺疊，我們已經看到了有希望的早期結果。但是，我們發現類元件可能會增長無意識的模式，使這些優化迴歸到較慢的路徑。類也為今天的工具提出了問題。例如，類不會很好地縮小，並且它們使得熱載入片狀和不可靠。我們希望提供一種API，使程式碼更有可能保持可優化途徑。

為了解決這些問題，Hooks允許你在沒有類的情況下使用更多React的功能。 從概念上講，React元件一直更接近功能(function)。 Hooks擁抱功能，但不會犧牲React的實踐精神。鉤子提供了對命令式逃生艙口的訪問，並且不需要你學習複雜的功能或反應式程式設計技術。

Hooks概覽是開始學習Hooks的好地方。

逐步採用策略

沒有計劃從React中刪除類。

我們知道React開發人員專注於釋出產品，沒有時間研究正在釋出的每個新API。鉤子是非常新的，在考慮學習或採用它們之前等待更多示例和教程可能會更好。

我們也理解為React新增新東西的標準非常高。對於好奇的讀者，我們已經準備了一個詳細的RFC，其中包含更多細節的動機，並提供有關特定設計決策和相關現有技術的額外視角。

至關重要的是，Hooks與現有程式碼並行工作，因此您可以逐步採用它們。 我們正在分享這個實驗性的API，以便從社群中那些有興趣塑造React未來的人那裡獲得早期反饋 - 我們將在公開場合迭代Hooks。

最後，沒有急於遷移到Hooks。我們建議避免任何“重大改寫”，特別是對於現有的複雜類元件。根據我們的經驗，最好先在新的和非關鍵元件中練習使用Hooks，並確保團隊中的每個人都對它們感到滿意。在嘗試Hooks之後，請隨時向我們傳送反饋，無論是好的還是不好的。

我們打算讓Hooks涵蓋所有現有的類用例，但 我們將在可預見的未來繼續支援類元件。 在Facebook，我們有數萬個元件作為類編寫，我們絕對沒有計劃重寫它們。相反，我們開始在新程式碼中使用Hooks與類並排。

後續將繼續介紹對應的api,如需瞭解，可watch倉庫。

本文原始出處
原譯文