有什麼是 HOC 適合做而 React Hooks 不適合的場景？

1樓：joe06102

其實有很多。我認為對於比較純粹的抽離邏輯和渲染的hoc/render-props，hooks是可以替代他們的，但是如果涉及到渲染，hooks其實沒啥辦法。

Hooks主要還是抽離和狀態相關的邏輯。

2樓：

之前 HOC 大量用於注入一些新的 props，這種情況更適合用 hooks。

如果有些 HOC 你不會改變 props，那麼很有可能它就不能用 hooks 做了。比如純檢視上的改變（顯示隱藏，或者在原元件基礎上新增邊框，header 等），還有控制重新整理（比如 React.memo 實際上也是個 HOC）等

3樓：張立理

對props的處理的HOC寫成Hooks都會有很詭異的感覺，比如最簡單的：

const ErrorLabel = withClass('error')('span');

請輸入使用者名稱

寫成Hooks的話……嗯沒得寫，寫完就是普通的元件

在React的元件裡，props是分為「生產」和「使用」兩個階段的，對props進行操作的HOC能夠完成「隱式地生產」這一目的，以至於消費方不需要主動地為此做一些什麼

而Hooks在生產和消費上都是需要使用者主動的，比如對useState的呼叫，以及將呼叫後的value放到某乙個元件上去。這致使在HOC對props處理的場景下，基於Hooks也就能用個useMemo

4樓：程墨Morgan

先說HoC做得到但Hooks做不到的。

如果擴充套件了React的生命週期，那就只有HoC才能做了，因為Hooks說到底還只是在React自帶的生命週期裡玩，多出來的生命週期，Hooks就沒辦法了。

next.js擴充套件了生命週期，增加getInitialProps函式，在沒有Suspense之前，這的確是乙個創舉，用於獲取非同步資料，雖然getInitialProps是乙個static函式，表面上看起來函式式元件也可以用，但是，如果你要提取一些可重用邏輯，就非要HoC才行了。

const Page = () => (

hoc = (PageComponent) => ;

再說，有一些場合適合HoC而不適合Hooks。

Hooks至今（React v16.7.0-alpha.

0）依然缺乏一種完全替換shouldComponentUpdate的機制，也就是在開始渲染過程之後，元件根據state和props計算出乙個結果，告訴React「我挺好，不用重畫了」。

HoC很容易定製shouldComponentUpdate，但目前Hooks沒提供這種方法，React.memo只能做到根據props計算，用不到state。

不過，React官方已經意識到這個問題，有這個issue Provide more ways to bail out inside Hooks · Issue #14110 · facebook/react 在跟蹤這個問題。