1. 引言
如果你在使用 React 16，可以嘗試 Function Component 風格，享受更大的靈活性。但在嘗試之前，最好先閱讀本文，對 Function Component 的思維模式有一個初步認識，防止因思維模式不同步造成的困擾。
2. 精讀
什麼是 Function Component？
Function Component 就是以 Function 的形式建立的 React 元件：
function App() {
return (
<div>
<p>App</p>
</div>
);
}也就是，一個返回了 JSX 或 createElement 的 Function 就可以當作 React 元件，這種形式的元件就是 Function Component。
所以我已經學會 Function Component 了嗎？
別急，故事才剛剛開始。
什麼是 Hooks？
Hooks 是輔助 Function Component 的工具。比如 useState 就是一種 Hook，它可以用來管理狀態：
function Counter() {
const [count, setCount] = useState(0);
return (
<div>
<p>You clicked {count} times</p>
<button onClick={() => setCount(count + 1)}>Click me</button>
</div>
);
}useState 返回的結果是陣列，陣列的第一項是 值，第二項是 賦值函式，useState 函式的第一個引數就是 預設值，也支援回撥函式。更詳細的介紹可以參考 Hooks 規則解讀。
先賦值再 setTimeout 列印
我們再將 useState 與 setTimeout 結合使用，看看有什麼發現。
建立一個按鈕，點選後讓計數器自增，但是延時 3 秒後再列印出來：
function Counter() {
const [count, setCount] = useState(0);
const log = () => {
setCount(count + 1);
setTimeout(() => {
console.log(count);
}, 3000);
};
return (
<div>
<p>You clicked {count} times</p>
<button onClick={log}>Click me</button>
</div>
);
}如果我們 在三秒內連續點選三次，那麼 count 的值最終會變成 3，而隨之而來的輸出結果是。。？
0
1
2嗯，好像對，但總覺得有點怪？
使用 Class Component 方式實現一遍呢？
敲黑板了，回到我們熟悉的 Class Component 模式，實現一遍上面的功能：
class Counter extends Component {
state = { count: 0 };
log = () => {
this.setState({
count: this.state.count + 1
});
setTimeout(() => {
console.log(this.state.count);
}, 3000);
};
render() {
return (
<div>
<p>You clicked {this.state.count} times</p>
<button onClick={this.log}>Click me</button>
</div>
);
}
}嗯，結果應該等價吧？3 秒內快速點選三次按鈕，這次的結果是：
3
3
3怎麼和 Function Component 結果不一樣？
這是用好 Function Component 必須邁過的第一道坎，請確認完全理解下面這段話：
首先對 Class Component 進行解釋：
- 首先 state 是 Immutable 的，
setState後一定會生成一個全新的 state 引用。 - 但 Class Component 通過
this.state方式讀取 state，這導致了每次程式碼執行都會拿到最新的 state 引用，所以快速點選三次的結果是3 3 3。
那麼對 Function Component 而言：
useState產生的資料也是 Immutable 的，通過陣列第二個引數 Set 一個新值後，原來的值會形成一個新的引用在下次渲染時。- 但由於對 state 的讀取沒有通過
this.的方式，使得 每次setTimeout都讀取了當時渲染閉包環境的資料，雖然最新的值跟著最新的渲染變了，但舊的渲染裡，狀態依然是舊值。
為了更容易理解，我們來模擬三次 Function Component 模式下點選按鈕時的狀態：
第一次點選，共渲染了 2 次，setTimeout 生效在第 1 次渲染，此時狀態為：
function Counter() {
const [0, setCount] = useState(0);
const log = () => {
setCount(0 + 1);
setTimeout(() => {
console.log(0);
}, 3000);
};
return ...
}第二次點選，共渲染了 3 次，setTimeout 生效在第 2 次渲染，此時狀態為：
function Counter() {
const [1, setCount] = useState(0);
const log = () => {
setCount(1 + 1);
setTimeout(() => {
console.log(1);
}, 3000);
};
return ...
}第三次點選，共渲染了 4 次，setTimeout 生效在第 3 次渲染，此時狀態為：
function Counter() {
const [2, setCount] = useState(0);
const log = () => {
setCount(2 + 1);
setTimeout(() => {
console.log(2);
}, 3000);
};
return ...
}可以看到，每一個渲染都是一個獨立的閉包，在獨立的三次渲染中，count 在每次渲染中的值分別是 0 1 2，所以無論 setTimeout 延時多久，列印出來的結果永遠是 0 1 2。
理解了這一點，我們就能繼續了。
如何讓 Function Component 也列印 3 3 3？
所以這是不是代表 Function Component 無法覆蓋 Class Component 的功能呢？完全不是，我希望你讀完本文後，不僅能解決這個問題，更能理解為什麼用 Function Component 實現的程式碼更佳合理、優雅。
第一種方案是藉助一個新 Hook - useRef 的能力：
function Counter() {
const count = useRef(0);
const log = () => {
count.current++;
setTimeout(() => {
console.log(count.current);
}, 3000);
};
return (
<div>
<p>You clicked {count.current} times</p>
<button onClick={log}>Click me</button>
</div>
);
}這種方案的列印結果就是 3 3 3。
想要理解為什麼，首先要理解 useRef 的功能：通過 useRef 建立的物件，其值只有一份，而且在所有 Rerender 之間共享。
所以我們對 count.current 賦值或讀取，讀到的永遠是其最新值，而與渲染閉包無關，因此如果快速點選三下，必定會返回 3 3 3 的結果。
但這種方案有個問題，就是使用 useRef 替代了 useState 建立值，那麼很自然的問題就是，如何不改變原始值的寫法，達到同樣的效果呢？
如何不改造原始值也列印 3 3 3？
一種最簡單的做法，就是新建一個 useRef 的值給 setTimeout 使用，而程式其餘部分還是用原始的 count:
function Counter() {
const [count, setCount] = useState(0);
const currentCount = useRef(count);
useEffect(() => {
currentCount.current = count;
});
const log = () => {
setCount(count + 1);
setTimeout(() => {
console.log(currentCount.current);
}, 3000);
};
return (
<div>
<p>You clicked {count} times</p>
<button onClick={log}>Click me</button>
</div>
);
}通過這個例子，我們引出了一個新的，也是 最重要的 Hook - useEffect，請務必深入理解這個函式。
useEffect 是處理副作用的，其執行時機在 每次 Render 渲染完畢後，換句話說就是每次渲染都會執行，只是實際在真實 DOM 操作完畢後。
我們可以利用這個特性，在每次渲染完畢後，將 count 此時最新的值賦給 currentCount.current，這樣就使 currentCount 的值自動同步了 count 的最新值。
為了確保大家準確理解 useEffect，筆者再囉嗦一下，將其執行週期拆解到每次渲染中。假設你在三秒內快速點選了三次按鈕，那麼你需要在大腦中模擬出下面這三次渲染都發生了什麼：
第一次點選，共渲染了 2 次，useEffect 生效在第 2 次渲染：
function Counter() {
const [1, setCount] = useState(0);
const currentCount = useRef(0);
useEffect(() => {
currentCount.current = 1; // 第二次渲染完畢後執行一次
});
const log = () => {
setCount(1 + 1);
setTimeout(() => {
console.log(currentCount.current); // 此時 currentCount.current: 3
}, 3000);
};
return ...
}第二次點選，共渲染了 3 次，useEffect 生效在第 3 次渲染：
function Counter() {
const [2, setCount] = useState(0);
const currentCount = useRef(0);
useEffect(() => {
currentCount.current = 2; // 第三次渲染完畢後執行一次
});
const log = () => {
setCount(2 + 1);
setTimeout(() => {
console.log(currentCount.current); // 此時 currentCount.current: 3
}, 3000);
};
return ...
}第三次點選，共渲染了 4 次，useEffect 生效在第 4 次渲染：
function Counter() {
const [3, setCount] = useState(0);
const currentCount = useRef(0);
useEffect(() => {
currentCount.current = 3; // 第四次渲染完畢後執行一次
});
const log = () => {
setCount(3 + 1);
setTimeout(() => {
console.log(currentCount.current); // 此時 currentCount.current: 3
}, 3000);
};
return ...
}注意對比與上面章節展開的 setTimeout 渲染時有什麼不同。
要注意的是，useEffect 也隨著每次渲染而不同的，同一個元件不同渲染之間，useEffect 內閉包環境完全獨立。對於本次的例子，useEffect 共執行了 四次，經歷瞭如下四次賦值最終變成 3:
currentCount.current = 0; // 第 1 次渲染
currentCount.current = 1; // 第 2 次渲染
currentCount.current = 2; // 第 3 次渲染
currentCount.current = 3; // 第 4 次渲染請確保理解了這句話再繼續往下閱讀：
setTimeout的例子，三次點選觸發了四次渲染，但setTimeout分別生效在第 1、2、3 次渲染中，因此值是0 1 2。useEffect的例子中，三次點選也觸發了四次渲染，但useEffect分別生效在第 1、2、3、4 次渲染中，最終使currentCount的值變成3。
用自定義 Hook 包裝 useRef
是不是覺得每次都寫一堆 useEffect 同步資料到 useRef 很煩？是的，想要簡化，就需要引出一個新的概念：自定義 Hooks。
首先介紹一下，自定義 Hooks 允許建立自定義 Hook，只要函式名遵循以 use 開頭，且返回非 JSX 元素，就是 Hooks 啦！自定義 Hooks 內還可以呼叫包括內建 Hooks 在內的所有自定義 Hooks。
也就是我們可以將 useEffect 寫到自定義 Hook 裡：
function useCurrentValue(value) {
const ref = useRef(0);
useEffect(() => {
ref.current = value;
}, [value]);
return ref;
}這裡又引出一個新的概念，就是 useEffect 的第二個引數，dependences。dependences 這個引數定義了 useEffect 的依賴，在新的渲染中，只要所有依賴項的引用都不發生變化，useEffect 就不會被執行，且當依賴項為 [] 時，useEffect 僅在初始化執行一次，後續的 Rerender 永遠也不會被執行。
這個例子中，我們告訴 React：僅當 value 的值變化了，再將其最新值同步給 ref.current。
那麼這個自定義 Hook 就可以在任何 Function Component 呼叫了：
function Counter() {
const [count, setCount] = useState(0);
const currentCount = useCurrentValue(count);
const log = () => {
setCount(count + 1);
setTimeout(() => {
console.log(currentCount.current);
}, 3000);
};
return (
<div>
<p>You clicked {count} times</p>
<button onClick={log}>Click me</button>
</div>
);
}封裝以後程式碼清爽了很多，而且最重要的是將邏輯封裝起來，我們只要理解 useCurrentValue 這個 Hook 可以產生一個值，其最新值永遠與入參同步。
看到這裡，也許有的小夥伴已經按捺不住迸發的靈感了：將 useEffect 第二個引數設定為空陣列，這個自定義 Hook 就代表了 didMount 生命週期！
是的，但筆者建議大家 不要再想生命週期的事情，這樣會阻礙你更好的理解 Function Component。因為下一個話題，就是要告訴你：永遠要對 useEffect 的依賴誠實，被依賴的引數一定要填上去，否則會產生非常難以察覺與修復的 BUG。
將 setTimeout 換成 setInterval 會怎樣
我們回到起點，將第一個 setTimeout Demo 中換成 setInterval，看看會如何：
function Counter() {
const [count, setCount] = useState(0);
useEffect(() => {
const id = setInterval(() => {
setCount(count + 1);
}, 1000);
return () => clearInterval(id);
}, []);
return <h1>{count}</h1>;
}這個例子將引發學習 Function Component 的第二個攔路虎，理解了它，才深入理解了 Function Component 的渲染原理。
首先介紹一下引入的新概念，useEffect 函式的返回值。它的返回值是一個函式，這個函式在 useEffect 即將重新執行時，會先執行上一次 Rerender useEffect 第一個回撥的返回函式，再執行下一次渲染的 useEffect 第一個回撥。
以兩次連續渲染為例介紹，展開後的效果是這樣的：
第一次渲染：
function Counter() {
useEffect(() => {
// 第一次渲染完畢後執行
// 最終執行順序：1
return () => {
// 由於沒有填寫依賴項，所以第二次渲染 useEffect 會再次執行，在執行前，第一次渲染中這個地方的回撥函式會首先被呼叫
// 最終執行順序：2
}
});
return ...
}第二次渲染：
function Counter() {
useEffect(() => {
// 第二次渲染完畢後執行
// 最終執行順序：3
return () => {
// 依此類推
}
});
return ...
}然而本 Demo 將 useEffect 的第二個引數設定為了 []，那麼其返回函式只會在這個元件被銷燬時執行。
讀懂了前面的例子，應該能想到，這個 Demo 希望利用 [] 依賴，將 useEffect 當作 didMount 使用，再結合 setInterval 每次時 count 自增，這樣期望將 count 的值每秒自增 1。
然而結果是：
1
1
1
...理解了 setTimeout 例子的讀者應該可以自行推匯出原因：setInterval 永遠在第一次 Render 的閉包中，count 的值永遠是 0，也就是等價於：
function Counter() {
const [count, setCount] = useState(0);
useEffect(() => {
const id = setInterval(() => {
setCount(0 + 1);
}, 1000);
return () => clearInterval(id);
}, []);
return <h1>{count}</h1>;
}然而罪魁禍首就是 沒有對依賴誠實 導致的。例子中 useEffect 明明依賴了 count，依賴項卻非要寫 []，所以產生了很難理解的錯誤。
所以改正的辦法就是 對依賴誠實。
永遠對依賴項誠實
一旦我們對依賴誠實了，就可以得到正確的效果：
function Counter() {
const [count, setCount] = useState(0);
useEffect(() => {
const id = setInterval(() => {
setCount(count + 1);
}, 1000);
return () => clearInterval(id);
}, [count]);
return <h1>{count}</h1>;
}我們將 count 作為了 useEffect 的依賴項，就得到了正確的結果：
1
2
3
...既然漏寫依賴的風險這麼大，自然也有保護措施，那就是 eslint-plugin-react-hooks 這個外掛，會自動訂正你的程式碼中的依賴，想不對依賴誠實都不行！
然而對這個例子而言，程式碼依然存在 BUG：每次計數器都會重新例項化，如果換成其他費事操作，效能成本將不可接受。
如何不在每次渲染時重新例項化 setInterval?
最簡單的辦法，就是利用 useState 的第二種賦值用法，不直接依賴 count，而是以函式回撥方式進行賦值：
function Counter() {
const [count, setCount] = useState(0);
useEffect(() => {
const id = setInterval(() => {
setCount(c => c + 1);
}, 1000);
return () => clearInterval(id);
}, []);
return <h1>{count}</h1>;
}這這寫法真正做到了：
- 不依賴
count，所以對依賴誠實。 - 依賴項為
[]，只有初始化會對setInterval進行例項化。
而之所以輸出還是正確的 1 2 3 ...，原因是 setCount 的回撥函式中，c 值永遠指向最新的 count 值，因此沒有邏輯漏洞。
但是聰明的同學仔細一想，就會發現一個新問題：如果存在兩個以上變數需要使用時，這招就沒有用武之地了。
同時使用兩個以上變數時？
如果同時需要對 count 與 step 兩個變數做累加，那 useEffect 的依賴必然要寫上一種某一個值，頻繁例項化的問題就又出現了：
function Counter() {
const [count, setCount] = useState(0);
const [step, setStep] = useState(0);
useEffect(() => {
const id = setInterval(() => {
setCount(c => c + step);
}, 1000);
return () => clearInterval(id);
}, [step]);
return <h1>{count}</h1>;
}這個例子中，由於 setCount 只能拿到最新的 count 值，而為了每次都拿到最新的 step 值，就必須將 step 申明到 useEffect 依賴中，導致 setInterval 被頻繁例項化。
這個問題自然也困擾了 React 團隊，所以他們拿出了一個新的 Hook 解決問題：useReducer。
什麼是 useReducer
先別聯想到 Redux。只考慮上面的場景，看看為什麼 React 團隊要將 useReducer 列為內建 Hooks 之一。
先介紹一下 useReducer 的用法:
const [state, dispatch] = useReducer(reducer, initialState);useReducer 返回的結構與 useState 很像，只是陣列第二項是 dispatch，而接收的引數也有兩個，初始值放在第二位，第一位就是 reducer。
reducer 定義瞭如何對資料進行變換，比如一個簡單的 reducer 如下：
function reducer(state, action) {
switch (action.type) {
case "increment":
return {
...state,
count: state.count + 1
};
default:
return state;
}
}這樣就可以通過呼叫 dispatch({ type: 'increment' }) 的方式實現 count 自增了。
那麼回到這個例子，我們只需要稍微改寫一下用法即可：
function Counter() {
const [state, dispatch] = useReducer(reducer, initialState);
const { count, step } = state;
useEffect(() => {
const id = setInterval(() => {
dispatch({ type: "tick" });
}, 1000);
return () => clearInterval(id);
}, [dispatch]);
return <h1>{count}</h1>;
}
function reducer(state, action) {
switch (action.type) {
case "tick":
return {
...state,
count: state.count + state.step
};
}
}可以看到，我們通過 reducer 的 tick 型別完成了對 count 的累加，而在 useEffect 的函式中，竟然完全繞過了 count、step 這兩個變數。所以 useReducer 也被稱為解決此類問題的 “黑魔法”。
其實不管被怎麼稱呼也好，其本質是讓函式與資料解耦，函式只管發出指令，而不需要關心使用的資料被更新時，需要重新初始化自身。
仔細的讀者會發現這個例子還是有一個依賴的，那就是 dispatch，然而 dispatch 引用永遠也不會變，因此可以忽略它的影響。這也體現了無論如何都要對依賴保持誠實。
這也引發了另一個注意項：儘量將函式寫在 useEffect 內部。
將函式寫在 useEffect 內部
為了避免遺漏依賴，必須將函式寫在 useEffect 內部，這樣 eslint-plugin-react-hooks 才能通過靜態分析補齊依賴項：
function Counter() {
const [count, setCount] = useState(0);
useEffect(() => {
function getFetchUrl() {
return "https://v?query=" + count;
}
getFetchUrl();
}, [count]);
return <h1>{count}</h1>;
}getFetchUrl 這個函式依賴了 count，而如果將這個函式定義在 useEffect 外部，無論是機器還是人眼都難以看出 useEffect 的依賴項包含 count。
然而這就引發了一個新問題：將所有函式都寫在 useEffect 內部豈不是非常難以維護？
如何將函式抽到 useEffect 外部？
為了解決這個問題，我們要引入一個新的 Hook：useCallback，它就是解決將函式抽到 useEffect 外部的問題。
我們先看 useCallback 的用法：
function Counter() {
const [count, setCount] = useState(0);
const getFetchUrl = useCallback(() => {
return "https://v?query=" + count;
}, [count]);
useEffect(() => {
getFetchUrl();
}, [getFetchUrl]);
return <h1>{count}</h1>;
}可以看到，useCallback 也有第二個引數 - 依賴項，我們將 getFetchUrl 函式的依賴項通過 useCallback 打包到新的 getFetchUrl 函式中，那麼 useEffect 就只需要依賴 getFetchUrl 這個函式，就實現了對 count 的間接依賴。
換句話說，我們利用了 useCallback 將 getFetchUrl 函式抽到了 useEffect 外部。
為什麼 useCallback 比 componentDidUpdate 更好用
回憶一下 Class Component 的模式，我們是如何在函式引數變化時進行重新取數的：
class Parent extends Component {
state = {
count: 0,
step: 0
};
fetchData = () => {
const url =
"https://v?query=" + this.state.count + "&step=" + this.state.step;
};
render() {
return <Child fetchData={this.fetchData} count={count} step={step} />;
}
}
class Child extends Component {
state = {
data: null
};
componentDidMount() {
this.props.fetchData();
}
componentDidUpdate(prevProps) {
if (
this.props.count !== prevProps.count &&
this.props.step !== prevProps.step // 別漏了！
) {
this.props.fetchData();
}
}
render() {
// ...
}
}上面的程式碼經常用 Class Component 的人應該很熟悉，然而暴露的問題可不小。
我們需要理解 props.count props.step 被 props.fetchData 函式使用了，因此在 componentDidUpdate 時，判斷這兩個引數發生了變化就觸發重新取數。
然而問題是，這種理解成本是不是過高了？如果父級函式 fetchData 不是我寫的，在不讀原始碼的情況下，我怎麼知道它依賴了 props.count 與 props.step 呢？更嚴重的是，如果某一天 fetchData 多依賴了 params 這個引數，下游函式將需要全部在 componentDidUpdate 覆蓋到這個邏輯，否則 params 變化時將不會重新取數。可以想象，這種方式維護成本巨大，甚至可以說幾乎無法維護。
換成 Function Component 的思維吧！試著用上剛才提到的 useCallback 解決問題：
function Parent() {
const [ count, setCount ] = useState(0);
const [ step, setStep ] = useState(0);
const fetchData = useCallback(() => {
const url = 'https://v/search?query=' + count + "&step=" + step;
}, [count, step])
return (
<Child fetchData={fetchData} />
)
}
function Child(props) {
useEffect(() => {
props.fetchData()
}, [props.fetchData])
return (
// ...
)
}可以看出來，當 fetchData 的依賴變化後，按下儲存鍵，eslint-plugin-react-hooks 會自動補上更新後的依賴，而下游的程式碼不需要做任何改變，下游只需要關心依賴了 fetchData 這個函式即可，至於這個函式依賴了什麼，已經封裝在 useCallback 後打包透傳下來了。
不僅解決了維護性問題，而且對於 只要引數變化，就重新執行某邏輯，是特別適合用 useEffect 做的，使用這種思維思考問題會讓你的程式碼更 “智慧”，而使用分裂的生命週期進行思考，會讓你的程式碼四分五裂，而且容易漏掉各種時機。
useEffect 對業務的抽象非常方便，筆者舉幾個例子：
- 依賴項是查詢引數，那麼
useEffect內可以進行取數請求，那麼只要查詢引數變化了，列表就會自動取數重新整理。注意我們將取數時機從觸發端改成了接收端。 - 當列表更新後，重新註冊一遍拖拽響應事件。也是同理，依賴引數是列表，只要列表變化，拖拽響應就會重新初始化，這樣我們可以放心的修改列表，而不用擔心拖拽事件失效。
- 只要資料流某個資料變化，頁面標題就同步修改。同理，也不需要在每次資料變化時修改標題，而是通過
useEffect“監聽” 資料的變化，這是一種 “控制反轉” 的思維。
說了這麼多，其本質還是利用了 useCallback 將函式獨立抽離到 useEffect 外部。
那麼進一步思考，可以將函式抽離到整個元件的外部嗎？
這也是可以的，需要靈活運用自定義 Hooks 實現。
將函式抽到元件外部
以上面的 fetchData 函式為例，如果要抽到整個元件的外部，就不是利用 useCallback 做到了，而是利用自定義 Hooks 來做：
function useFetch(count, step) {
return useCallback(() => {
const url = "https://v/search?query=" + count + "&step=" + step;
}, [count, step]);
}可以看到，我們將 useCallback 打包搬到了自定義 Hook useFetch 中，那麼函式中只需要一行程式碼就能實現一樣的效果了：
function Parent() {
const [count, setCount] = useState(0);
const [step, setStep] = useState(0);
const [other, setOther] = useState(0);
const fetch = useFetch(count, step); // 封裝了 useFetch
useEffect(() => {
fetch();
}, [fetch]);
return (
<div>
<button onClick={() => setCount(c => c + 1)}>setCount {count}</button>
<button onClick={() => setStep(c => c + 1)}>setStep {step}</button>
<button onClick={() => setOther(c => c + 1)}>setOther {other}</button>
</div>
);
}隨著使用越來越方便，我們可以將精力放到效能上。觀察可以發現，count 與 step 都會頻繁變化，每次變化就會導致 useFetch 中 useCallback 依賴的變化，進而導致重新生成函式。然而實際上這種函式是沒必要每次都重新生成的，反覆生成函式會造成大量效能損耗。
換一個例子就可以看得更清楚：
function Parent() {
const [count, setCount] = useState(0);
const [step, setStep] = useState(0);
const [other, setOther] = useState(0);
const drag = useDraggable(count, step); // 封裝了拖拽函式
}假設我們使用 Sortablejs 對某個區域進行拖拽監聽，這個函式每次都重複執行的效能損耗非常大，然而這個函式內部可能因為僅僅要上報一些日誌，所以依賴了沒有實際被使用的 count step 變數：
function useDraggable(count, step) {
return useCallback(() => {
// 上報日誌
report(count, step);
// 對區域進行初始化，非常耗時
// ... 省略耗時程式碼
}, [count, step]);
}這種情況，函式的依賴就特別不合理。雖然依賴變化應該觸發函式重新執行，但如果函式重新執行的成本非常高，而依賴只是可有可無的點綴，得不償失。
利用 Ref 保證耗時函式依賴不變
一種辦法是通過將依賴轉化為 Ref：
function useFetch(count, step) {
const countRef = useRef(count);
const stepRef = useRef(step);
useEffect(() => {
countRef.current = count;
stepRef.current = step;
});
return useCallback(() => {
const url =
"https://v/search?query=" + countRef.current + "&step=" + stepRef.current;
}, [countRef, stepRef]); // 依賴不會變，卻能每次拿到最新的值
}這種方式比較取巧，將需要更新的區域與耗時區域分離，再將需更新的內容通過 Ref 提供給耗時的區域，實現效能優化。
然而這樣做對函式的改動成本比較高，有一種更通用的做法解決此類問題。
通用的自定義 Hooks 解決函式重新例項化問題
我們可以利用 useRef 創造一個自定義 Hook 代替 useCallback，使其依賴的值變化時，回撥不會重新執行，卻能拿到最新的值！
這個神奇的 Hook 寫法如下：
function useEventCallback(fn, dependencies) {
const ref = useRef(null);
useEffect(() => {
ref.current = fn;
}, [fn, ...dependencies]);
return useCallback(() => {
const fn = ref.current;
return fn();
}, [ref]);
}再次體會到自定義 Hook 的無所不能。
首先看這一段：
useEffect(() => {
ref.current = fn;
}, [fn, ...dependencies]);當 fn 回撥函式變化時， ref.current 重新指向最新的 fn 這個邏輯中規中矩。重點是，當依賴 dependencies 變化時，也重新為 ref.current 賦值，此時 fn 內部的 dependencies 值是最新的，而下一段程式碼：
return useCallback(() => {
const fn = ref.current;
return fn();
}, [ref]);又僅執行一次（ref 引用不會改變），所以每次都可以返回 dependencies 是最新的 fn，並且 fn 還不會重新執行。
假設我們對 useEventCallback 傳入的回撥函式稱為 X，則這段程式碼的含義，就是使每次渲染的閉包中，回撥函式 X 總是拿到的總是最新 Rerender 閉包中的那個，所以依賴的值永遠是最新的，而且函式不會重新初始化。
React 官方不推薦使用此正規化，因此對於這種場景，利用
useReducer，將函式通過dispatch中呼叫。 還記得嗎？dispatch是一種可以繞過依賴的黑魔法，我們在 “什麼是 useReducer” 小節提到過。
隨著對 Function Component 的使用，你也漸漸關心到函式的效能了，這很棒。那麼下一個重點自然是關注 Render 的效能。
用 memo 做 PureRender
在 Fucntion Component 中，Class Component 的 PureComponent 等價的概念是 React.memo，我們介紹一下 memo 的用法：
const Child = memo((props) => {
useEffect(() => {
props.fetchData()
}, [props.fetchData])
return (
// ...
)
})使用 memo 包裹的元件，會在自身重渲染時，對每一個 props 項進行淺對比，如果引用沒有變化，就不會觸發重渲染。所以 memo 是一種很棒的效能優化工具。
下面就介紹一個看似比 memo 難用，但真正理解後會發現，其實比 memo 更好用的渲染優化函式：useMemo。
用 useMemo 做區域性 PureRender
相比 React.memo 這個異類，React.useMemo 可是正經的官方 Hook：
const Child = (props) => {
useEffect(() => {
props.fetchData()
}, [props.fetchData])
return useMemo(() => (
// ...
), [props.fetchData])
}可以看到，我們利用 useMemo 包裹渲染程式碼，這樣即便函式 Child 因為 props 的變化重新執行了，只要渲染函式用到的 props.fetchData 沒有變，就不會重新渲染。
這裡發現了 useMemo 的第一個好處：更細粒度的優化渲染。
所謂更細粒度的優化渲染，是指函式 Child 整體可能用到了 A、B 兩個 props，而渲染僅用到了 B，那麼使用 memo 方案時，A 的變化會導致重渲染，而使用 useMemo 的方案則不會。
而 useMemo 的好處還不止這些，這裡先留下伏筆。我們先看一個新問題：當引數越來越多時，使用 props 將函式、值在元件間傳遞非常冗長：
function Parent() {
const [count, setCount] = useState(0);
const [step, setStep] = useState(0);
const fetchData = useFetch(count, step);
return <Child fetchData={fetchData} setCount={setCount} setStep={setStep} />;
}雖然 Child 可以通過 memo 或 useMemo 進行優化，但當程式複雜時，可能存在多個函式在所有 Function Component 間共享的情況 ，此時就需要新 Hook: useContext 來拯救了。
使用 Context 做批量透傳
在 Function Component 中，可以使用 React.createContext 建立一個 Context:
const Store = createContext(null);其中 null 是初始值，一般置為 null 也沒關係。接下來還有兩步，分別是在根節點使用 Store.Provider 注入，與在子節點使用官方 Hook useContext 拿到注入的資料：
在根節點使用 Store.Provider 注入：
function Parent() {
const [count, setCount] = useState(0);
const [step, setStep] = useState(0);
const fetchData = useFetch(count, step);
return (
<Store.Provider value={{ setCount, setStep, fetchData }}>
<Child />
</Store.Provider>
);
}在子節點使用 useContext 拿到注入的資料（也就是拿到 Store.Provider 的 value）：
const Child = memo((props) => {
const { setCount } = useContext(Store)
function onClick() {
setCount(count => count + 1)
}
return (
// ...
)
})這樣就不需要在每個函式間進行引數透傳了，公共函式可以都放在 Context 裡。
但是當函式多了，Provider 的 value 會變得很臃腫，我們可以結合之前講到的 useReducer 解決這個問題。
使用 useReducer 為 Context 傳遞內容瘦身
使用 useReducer，所有回撥函式都通過呼叫 dispatch 完成，那麼 Context 只要傳遞 dispatch 一個函式就好了：
const Store = createContext(null);
function Parent() {
const [state, dispatch] = useReducer(reducer, { count: 0, step: 0 });
return (
<Store.Provider value={dispatch}>
<Child />
</Store.Provider>
);
}這下無論是根節點的 Provider，還是子元素呼叫都清爽很多：
const Child = useMemo((props) => {
const dispatch = useContext(Store)
function onClick() {
dispatch({
type: 'countInc'
})
}
return (
// ...
)
})你也許很快就想到，將 state 也通過 Provider 注入進去豈不更妙？是的，但此處請務必注意潛在效能問題。
將 state 也放到 Context 中
稍稍改造下，將 state 也放到 Context 中，這下賦值與取值都非常方便了！
const Store = createContext(null);
function Parent() {
const [state, dispatch] = useReducer(reducer, { count: 0, step: 0 });
return (
<Store.Provider value={{ state, dispatch }}>
<Count />
<Step />
</Store.Provider>
);
}對 Count Step 這兩個子元素而言，可需要謹慎一些，假如我們這麼實現這兩個子元素：
const Count = memo(() => {
const { state, dispatch } = useContext(Store);
return (
<button onClick={() => dispatch("incCount")}>incCount {state.count}</button>
);
});
const Step = memo(() => {
const { state, dispatch } = useContext(Store);
return (
<button onClick={() => dispatch("incStep")}>incStep {state.step}</button>
);
});其結果是：無論點選 incCount 還是 incStep，都會同時觸發這兩個元件的 Rerender。
其問題在於：memo 只能擋在最外層的，而通過 useContext 的資料注入發生在函式內部，會 繞過 memo。
當觸發 dispatch 導致 state 變化時，所有使用了 state 的元件內部都會強制重新重新整理，此時想要對渲染次數做優化，只有拿出 useMemo 了！
useMemo 配合 useContext
使用 useContext 的元件，如果自身不使用 props，就可以完全使用 useMemo 代替 memo 做效能優化：
const Count = () => {
const { state, dispatch } = useContext(Store);
return useMemo(
() => (
<button onClick={() => dispatch("incCount")}>
incCount {state.count}
</button>
),
[state.count, dispatch]
);
};
const Step = () => {
const { state, dispatch } = useContext(Store);
return useMemo(
() => (
<button onClick={() => dispatch("incStep")}>incStep {state.step}</button>
),
[state.step, dispatch]
);
};對這個例子來說，點選對應的按鈕，只有使用到的元件才會重渲染，效果符合預期。 結合 eslint-plugin-react-hooks 外掛使用，連 useMemo 的第二個引數依賴都是自動補全的。
讀到這裡，不知道你是否聯想到了 Redux 的 Connect?
我們來對比一下 Connect 與 useMemo，會發現驚人的相似之處。
一個普通的 Redux 元件：
const mapStateToProps = state => (count: state.count);
const mapDispatchToProps = dispatch => dispatch;
@Connect(mapStateToProps, mapDispatchToProps)
class Count extends React.PureComponent {
render() {
return (
<button onClick={() => this.props.dispatch("incCount")}>
incCount {this.props.count}
</button>
);
}
}一個普通的 Function Component 元件：
const Count = () => {
const { state, dispatch } = useContext(Store);
return useMemo(
() => (
<button onClick={() => dispatch("incCount")}>
incCount {state.count}
</button>
),
[state.count, dispatch]
);
};這兩段程式碼的效果完全一樣，Function Component 除了更簡潔之外，還有一個更大的優勢：全自動的依賴推導。
Hooks 誕生的一個原因，就是為了便於靜態分析依賴，簡化 Immutable 資料流的使用成本。
我們看 Connect 的場景：
由於不知道子元件使用了哪些資料，因此需要在 mapStateToProps 提前寫好，而當需要使用資料流內新變數時，元件裡是無法訪問的，我們要回到 mapStateToProps 加上這個依賴，再回到元件中使用它。
而 useContext + useMemo 的場景：
由於注入的 state 是全量的，Render 函式中想用什麼都可直接用，在按儲存鍵時，eslint-plugin-react-hooks 會通過靜態分析，在 useMemo 第二個引數自動補上程式碼裡使用到的外部變數，比如 state.count、dispatch。
另外可以發現，Context 很像 Redux，那麼 Class Component 模式下的非同步中介軟體實現的非同步取數怎麼利用 useReducer 做呢？答案是：做不到。
當然不是說 Function Component 無法實現非同步取數，而是用的工具錯了。
使用自定義 Hook 處理副作用
比如上面丟擲的非同步取數場景，在 Function Component 的最佳做法是封裝成一個自定義 Hook：
const useDataApi = (initialUrl, initialData) => {
const [url, setUrl] = useState(initialUrl);
const [state, dispatch] = useReducer(dataFetchReducer, {
isLoading: false,
isError: false,
data: initialData
});
useEffect(() => {
let didCancel = false;
const fetchData = async () => {
dispatch({ type: "FETCH_INIT" });
try {
const result = await axios(url);
if (!didCancel) {
dispatch({ type: "FETCH_SUCCESS", payload: result.data });
}
} catch (error) {
if (!didCancel) {
dispatch({ type: "FETCH_FAILURE" });
}
}
};
fetchData();
return () => {
didCancel = true;
};
}, [url]);
const doFetch = url => setUrl(url);
return { ...state, doFetch };
};可以看到，自定義 Hook 擁有完整生命週期，我們可以將取數過程封裝起來，只暴露狀態 - 是否在載入中：isLoading 是否取數失敗：isError 資料：data。
在元件中使用起來非常方便：
function App() {
const { data, isLoading, isError } = useDataApi("https://v", {
showLog: true
});
}如果這個值需要儲存到資料流，在所有元件之間共享，我們可以結合 useEffect 與 useReducer：
function App(props) {
const { dispatch } = useContext(Store);
const { data, isLoading, isError } = useDataApi("https://v", {
showLog: true
});
useEffect(() => {
dispatch({
type: "updateLoading",
data,
isLoading,
isError
});
}, [dispatch, data, isLoading, isError]);
}到此，Function Component 的入門概念就講完了，最後附帶一個彩蛋：Function Component 的 DefaultProps 怎麼處理？
Function Component 的 DefaultProps 怎麼處理？
這個問題看似簡單，實則不然。我們至少有兩種方式對 Function Component 的 DefaultProps 進行賦值，下面一一說明。
首先對於 Class Component，DefaultProps 基本上只有一種大家都認可的寫法：
class Button extends React.PureComponent {
defaultProps = { type: "primary", onChange: () => {} };
}然而在 Function Component 就五花八門了。
利用 ES6 特性在引數定義階段賦值
function Button({ type = "primary", onChange = () => {} }) {}這種方法看似很優雅，其實有一個重大隱患：沒有命中的 props 在每次渲染引用都不同。
看這種場景：
const Child = memo(({ type = { a: 1 } }) => {
useEffect(() => {
console.log("type", type);
}, [type]);
return <div>Child</div>;
});只要 type 的引用不變，useEffect 就不會頻繁的執行。現在通過父元素重新整理導致 Child 跟著重新整理，我們發現，每次渲染都會列印出日誌，也就意味著每次渲染時，type 的引用是不同的。
有一種不太優雅的方式可以解決：
const defaultType = { a: 1 };
const Child = ({ type = defaultType }) => {
useEffect(() => {
console.log("type", type);
}, [type]);
return <div>Child</div>;
};此時不斷重新整理父元素，只會列印出一次日誌，因為 type 的引用是相同的。
我們使用 DefaultProps 的本意必然是希望預設值的引用相同， 如果不想單獨維護變數的引用，還可以借用 React 內建的 defaultProps 方法解決。
利用 React 內建方案
React 內建方案能較好的解決引用頻繁變動的問題：
const Child = ({ type }) => {
useEffect(() => {
console.log("type", type);
}, [type]);
return <div>Child</div>;
};
Child.defaultProps = {
type: { a: 1 }
};上面的例子中，不斷重新整理父元素，只會列印出一次日誌。
因此建議對於 Function Component 的引數預設值，建議使用 React 內建方案解決，因為純函式的方案不利於保持引用不變。
最後補充一個父元件 “坑” 子元件的經典案例。
不要坑了子元件
我們做一個點選累加的按鈕作為父元件，那麼父元件每次點選後都會重新整理：
function App() {
const [count, forceUpdate] = useState(0);
const schema = { b: 1 };
return (
<div>
<Child schema={schema} />
<div onClick={() => forceUpdate(count + 1)}>Count {count}</div>
</div>
);
}另外我們將 schema = { b: 1 } 傳遞給子元件，這個就是埋的一個大坑。
子元件的程式碼如下：
const Child = memo(props => {
useEffect(() => {
console.log("schema", props.schema);
}, [props.schema]);
return <div>Child</div>;
});只要父級 props.schema 變化就會列印日誌。結果自然是，父元件每次重新整理，子元件都會列印日誌，也就是 子元件 [props.schema] 完全失效了，因為引用一直在變化。
其實 子元件關心的是值，而不是引用，所以一種解法是改寫子元件的依賴：
const Child = memo(props => {
useEffect(() => {
console.log("schema", props.schema);
}, [JSON.stringify(props.schema)]);
return <div>Child</div>;
});這樣可以保證子元件只渲染一次。
可是真正罪魁禍首是父元件，我們需要利用 Ref 優化一下父元件：
function App() {
const [count, forceUpdate] = useState(0);
const schema = useRef({ b: 1 });
return (
<div>
<Child schema={schema.current} />
<div onClick={() => forceUpdate(count + 1)}>Count {count}</div>
</div>
);
}這樣 schema 的引用能一直保持不變。如果你完整讀完了本文，應該可以充分理解第一個例子的 schema 在每個渲染快照中都是一個新的引用，而 Ref 的例子中，schema 在每個渲染快照中都只有一個唯一的引用。
3. 總結
所以使用 Function Component 你入門了嗎？
本次精讀留下的思考題是：Function Component 開發過程中還有哪些容易犯錯誤的細節？
如果你想參與討論，請 點選這裡，每週都有新的主題，週末或週一釋出。前端精讀 - 幫你篩選靠譜的內容。
關注 前端精讀微信公眾號
special Sponsors
版權宣告：自由轉載-非商用-非衍生-保持署名（創意共享 3.0 許可證）