這篇文章主要講解了React中組件邏輯復(fù)用的使用方法，內(nèi)容清晰明了，對(duì)此有興趣的小伙伴可以學(xué)習(xí)一下，相信大家閱讀完之后會(huì)有幫助。
創(chuàng)新互聯(lián)建站長(zhǎng)期為1000多家客戶提供的網(wǎng)站建設(shè)服務(wù)，團(tuán)隊(duì)從業(yè)經(jīng)驗(yàn)10年，關(guān)注不同地域、不同群體，并針對(duì)不同對(duì)象提供差異化的產(chǎn)品和服務(wù)；打造開放共贏平臺(tái)，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為江津企業(yè)提供專業(yè)的成都做網(wǎng)站、網(wǎng)站建設(shè)，江津網(wǎng)站改版等技術(shù)服務(wù)。擁有十多年豐富建站經(jīng)驗(yàn)和眾多成功案例,為您定制開發(fā)。
1. Mixins
Mixins 事實(shí)上是 React.createClass 的產(chǎn)物了。當(dāng)然，如果你曾經(jīng)在低版本的 react 中使用過 Mixins，例如 react-timer-mixin， react-addons-pure-render-mixin，那么你可能知道，在 React 的新版本中我們其實(shí)還是可以使用 mixin，雖然 React.createClass 已經(jīng)被移除了，但是仍然可以使用第三方庫 create-react-class，來繼續(xù)使用 mixin。甚至，ES6 寫法的組件，也同樣有方式去使用 mixin。當(dāng)然啦，這不是本文討論的重點(diǎn)，就不多做介紹了，如果你維護(hù)的老項(xiàng)目在升級(jí)的過程中遇到這類問題，可以與我探討。
新的項(xiàng)目中基本不會(huì)出現(xiàn) Mixins，但是如果你們公司還有一些老項(xiàng)目要維護(hù)，其中可能就應(yīng)用了 Mixins，因此稍微花點(diǎn)時(shí)間，了解下 Mixins 的使用方法和原理，還是有必要的。倘若你完全沒有這方面的需求，那么跳過本節(jié)亦是可以的。
Mixins 的使用
React 15.3.0 版本中增加了 PureComponent。而在此之前，或者如果你使用的是 React.createClass 的方式創(chuàng)建組件，那么想要同樣的功能，就是使用 react-addons-pure-render-mixin，例如:
重慶分公司
重慶分公司
//下面代碼在新版React中可正常運(yùn)行，因?yàn)楝F(xiàn)在已經(jīng)無法使用 `React.createClass`，我就不使用 `React.createClass` 來寫了。
const createReactClass = require('create-react-class');
const PureRenderMixin = require('react-addons-pure-render-mixin');
const MyDialog = createReactClass({
displayName: 'MyDialog',
mixins: [PureRenderMixin],
//other code
render() {
return (
{/* other code */}
)
}
});首先，需要注意，mixins 的值是一個(gè)數(shù)組，如果有多個(gè) Mixins，那么只需要依次放在數(shù)組中即可，例如: mixins: [PureRenderMixin, TimerMixin]。
Mixins 的原理
Mixins 的原理可以簡(jiǎn)單理解為將一個(gè) mixin 對(duì)象上的方法增加到組件上。類似于 $.extend 方法，不過 React 還進(jìn)行了一些其它的處理，例如：除了生命周期函數(shù)外，不同的 mixins 中是不允許有相同的屬性的，并且也不能和組件中的屬性和方法同名，否則會(huì)拋出異常。另外即使是生命周期函數(shù)，constructor 、render 和 shouldComponentUpdate 也是不允許重復(fù)的。
而如 compoentDidMount 的生命周期，會(huì)依次調(diào)用 Mixins，然后再調(diào)用組件中定義的 compoentDidMount。
例如，上面的 PureRenderMixin 提供的對(duì)象中，有一個(gè) shouldComponentUpdate 方法，即是將這個(gè)方法增加到了 MyDialog 上，此時(shí) MyDialog 中不能再定義 shouldComponentUpdate，否則會(huì)拋出異常。
//react-addons-pure-render-mixin 源碼
var shallowEqual = require('fbjs/lib/shallowEqual');
module.exports = {
shouldComponentUpdate: function(nextProps, nextState) {
return (
!shallowEqual(this.props, nextProps) ||
!shallowEqual(this.state, nextState)
);
},
};Mixins 的缺點(diǎn)
Mixins 引入了隱式的依賴關(guān)系。
例如，每個(gè) mixin 依賴于其他的 mixin，那么修改其中一個(gè)就可能破壞另一個(gè)。
Mixins 會(huì)導(dǎo)致名稱沖突
如果兩個(gè) mixin 中存在同名方法，就會(huì)拋出異常。另外，假設(shè)你引入了一個(gè)第三方的 mixin，該 mixin 上的方法和你組件的方法名發(fā)生沖突，你就不得不對(duì)方法進(jìn)行重命名。
Mixins 會(huì)導(dǎo)致越來越復(fù)雜
mixin 開始的時(shí)候是簡(jiǎn)單的，但是隨著時(shí)間的推移，容易變得越來越復(fù)雜。例如，一個(gè)組件需要一些狀態(tài)來跟蹤鼠標(biāo)懸停，為了保持邏輯的可重用性，將 handleMouseEnter()、handleMouseLeave() 和 isHovering() 提取到 HoverMixin() 中。
然后其他人可能需要實(shí)現(xiàn)一個(gè)提示框，他們不想復(fù)制 HoverMixin() 的邏輯，于是他們創(chuàng)建了一個(gè)使用 HoverMixin 的 TooltipMixin，TooltipMixin 在它的 componentDidUpdate 中讀取 HoverMixin() 提供的 isHovering() 來決定顯示或隱藏提示框。
幾個(gè)月之后，有人想將提示框的方向設(shè)置為可配置的。為了避免代碼重復(fù)，他們將 getTooltipOptions() 方法增加到了 TooltipMixin 中。結(jié)果過了段時(shí)間，你需要再同一個(gè)組件中顯示多個(gè)提示框，提示框不再是懸停時(shí)顯示了，或者一些其他的功能，你需要解耦 HoverMixin() 和 TooltipMixin 。另外，如果很多組件使用了某個(gè) mixin，mixin 中新增的功能都會(huì)被添加到所有組件中，事實(shí)上很多組件完全不需要這些新功能。
漸漸地，封裝的邊界被侵蝕了，由于很難更改或移除現(xiàn)有的mixin，它們變得越來越抽象，直到?jīng)]有人理解它們是如何工作的。
React 官方認(rèn)為在 React 代碼庫中，Mixin 是不必要的，也是有問題的。推薦開發(fā)者使用高階組件來進(jìn)行組件邏輯的復(fù)用。
2. HOC
React 官方文檔對(duì) HOC 進(jìn)行了如下的定義：高階組件（HOC）是 React 中用于復(fù)用組件邏輯的一種高級(jí)技巧。HOC 自身不是 React API 的一部分，它是一種基于 React 的組合特性而形成的設(shè)計(jì)模式。
簡(jiǎn)而言之，高階組件就是一個(gè)函數(shù)，它接受一個(gè)組件為參數(shù)，返回一個(gè)新組件。
高階組件的定義形如下面這樣:
//接受一個(gè)組件 WrappedComponent 作為參數(shù)，返回一個(gè)新組件 Proxy
function withXXX(WrappedComponent) {
return class Proxy extends React.Component {
render() {
return
}
}
} 開發(fā)項(xiàng)目時(shí)，當(dāng)你發(fā)現(xiàn)不同的組件有相似的邏輯，或者發(fā)現(xiàn)自己在寫重復(fù)代碼的時(shí)候，這時(shí)候就需要考慮組件復(fù)用的問題了。
這里我以一個(gè)實(shí)際開發(fā)的例子來說明，近期各大APP都在適配暗黑模式，而暗黑模式下的背景色、字體顏色等等和正常模式肯定是不一樣的。那么就需要監(jiān)聽暗黑模式開啟關(guān)閉事件，每個(gè)UI組件都需要根據(jù)當(dāng)前的模式來設(shè)置樣式。
每個(gè)組件都去監(jiān)聽事件變化來 setState 肯定是不可能的，因?yàn)闀?huì)造成多次渲染。
這里我們需要借助 context API 來做，我以新的 Context API 為例。如果使用老的 context API 實(shí)現(xiàn)該功能，需要使用發(fā)布訂閱模式來做，最后利用 react-native / react-dom 提供的 unstable_batchedUpdates 來統(tǒng)一更新，避免多次渲染的問題（老的 context API 在值發(fā)生變化時(shí)，如果組件中 shouldComponentUpdate 返回了 false，那么它的子孫組件就不會(huì)重新渲染了）。
順便多說一句，很多新的API出來的時(shí)候，不要急著在項(xiàng)目中使用，比如新的 Context API，如果你的 react 版本是 16.3.1， react-dom 版本是16.3.3，你會(huì)發(fā)現(xiàn)，當(dāng)你的子組件是函數(shù)組件時(shí)，即是用 Context.Consumer 的形式時(shí)，你是能獲取到 context 上的值，而你的組件是個(gè)類組件時(shí)，你根本拿不到 context 上的值。
同樣的 React.forwardRef 在該版本食用時(shí)，某種情況下也有多次渲染的bug。都是血和淚的教訓(xùn)，不多說了，繼續(xù)暗黑模式這個(gè)需求。
我的想法是將當(dāng)前的模式(假設(shè)值為 light / dark)掛載到 context 上。其它組件直接從 context 上獲取即可。不過我們知道的是，新版的 ContextAPI 函數(shù)組件和類組件，獲取 context 的方法是不一致的。而且一個(gè)項(xiàng)目中有非常多的組件，每個(gè)組件都進(jìn)行一次這樣的操作，也是重復(fù)的工作量。于是，高階組件就派上用場(chǎng)啦（PS：React16.8 版本中提供了 useContext 的 Hook，用起來很方便）
當(dāng)然，這里我使用高階組件還有一個(gè)原因，就是我們的項(xiàng)目中還包含老的 context API （不要問我為什么不直接重構(gòu)下，牽扯的人員太多了，沒法隨便改），新老 context API 在一個(gè)項(xiàng)目中是可以共存的，不過我們不能在同一個(gè)組件中同時(shí)使用。所以如果一個(gè)組件中已經(jīng)使用的舊的 context API，要想從新的 context API 上獲取值，也需要使用高階組件來處理它。
于是，我編寫了一個(gè) withColorTheme 的高階組件的雛形(這里也可以認(rèn)為 withColorTheme 是一個(gè)返回高階組件的高階函數(shù))：
import ThemeContext from './context';
function withColorTheme(options={}) {
return function(WrappedComponent) {
return class ProxyComponent extends React.Component {
static contextType = ThemeContext;
render() {
return ()
}
}
}
} 包裝顯示名稱
上面這個(gè)雛形存在幾個(gè)問題，首先，我們沒有為 ProxyComponent 包裝顯示名稱，因此，為其加上:
import ThemeContext from './context';
function withColorTheme(options={}) {
return function(WrappedComponent) {
class ProxyComponent extends React.Component {
static contextType = ThemeContext;
render() {
return ()
}
}
}
function getDisplayName(WrappedComponent) {
return WrappedComponent.displayName || WrappedComponent.name || 'Component';
}
const displayName = `WithColorTheme(${getDisplayName(WrappedComponent)})`;
ProxyComponent.displayName = displayName;
return ProxyComponent;
} 我們來看一下，不包裝顯示名稱和包裝顯示名稱的區(qū)別:
React Developer Tools 中調(diào)試
.jpg)
ReactNative的紅屏報(bào)錯(cuò)
復(fù)制靜態(tài)方法
眾所周知，使用 HOC 包裝組件，需要復(fù)制靜態(tài)方法，如果你的 HOC 僅僅是某幾個(gè)組件使用，沒有靜態(tài)方法需要拷貝，或者需要拷貝的靜態(tài)方法是確定的，那么你手動(dòng)處理一下也可以。
因?yàn)?withColorTheme 這個(gè)高階組件，最終是要提供給很多業(yè)務(wù)使用的，無法限制別人的組件寫法，因此這里我們必須將其寫得通用一些。
hoist-non-react-statics 這個(gè)依賴可以幫助我們自動(dòng)拷貝非 React 的靜態(tài)方法，這里有一點(diǎn)需要注意，它只會(huì)幫助你拷貝非 React 的靜態(tài)方法，而非被包裝組件的所有靜態(tài)方法。我第一次使用這個(gè)依賴的時(shí)候，沒有仔細(xì)看，以為是將 WrappedComponent 上所有的靜態(tài)方法都拷貝到 ProxyComponent。然后就遇到了 XXX.propsTypes.style undefined is not an object 的紅屏報(bào)錯(cuò)(ReactNative調(diào)試)。因?yàn)槲覜]有手動(dòng)拷貝 propTypes，錯(cuò)誤的以為 hoist-non-react-statics 會(huì)幫我處理了。
hoist-non-react-statics 的源碼非常短，有興趣的話，可以看一下，我當(dāng)前使用的 3.3.2 版本。
因此，諸如 childContextTypes、contextType、contextTypes、defaultProps、displayName、getDefaultProps、getDerivedStateFromError、getDerivedStateFromProps
mixins、propTypes、type 等不會(huì)被拷貝，其實(shí)也比較容易理解，因?yàn)?ProxyComponent 中可能也需要設(shè)置這些，不能簡(jiǎn)單去覆蓋。
import ThemeContext from './context';
import hoistNonReactStatics from 'hoist-non-react-statics';
function withColorTheme(options={}) {
return function(WrappedComponent) {
class ProxyComponent extends React.Component {
static contextType = ThemeContext;
render() {
return ()
}
}
}
function getDisplayName(WrappedComponent) {
return WrappedComponent.displayName || WrappedComponent.name || 'Component';
}
const displayName = `WithColorTheme(${getDisplayName(WrappedComponent)})`;
ProxyComponent.displayName = displayName;
ProxyComponent.WrappedComponent = WrappedComponent;
ProxyComponent.propTypes = WrappedComponent.propTypes;
//contextType contextTypes 和 childContextTypes 因?yàn)槲疫@里不需要，就不拷貝了
return ProxyComponent;
} 現(xiàn)在似乎差不多了，不過呢，HOC 還有一個(gè)問題，就是 ref 傳遞的問題。如果不經(jīng)過任何處理，我們通過 ref 拿到的是 ProxyComponent 的實(shí)例，而不是原本想要獲取的 WrappedComponent 的實(shí)例。
ref 傳遞
雖然我們已經(jīng)用無關(guān)的 props 進(jìn)行了透?jìng)鳎?key 和 ref 不是普通的 prop，React 會(huì)對(duì)它進(jìn)行特別處理。
所以這里我們需要對(duì) ref 特別處理一下。如果你的 reac-dom 是 16.4.2 或者你的 react-native 版本是 0.59.9 以上，那么可以放心的使用 React.forwardRef 進(jìn)行 ref 轉(zhuǎn)發(fā)，這樣使用起來也是最方便的。
使用 React.forwardRef 轉(zhuǎn)發(fā)
import ThemeContext from './context';
import hoistNonReactStatics from 'hoist-non-react-statics';
function withColorTheme(options={}) {
return function(WrappedComponent) {
class ProxyComponent extends React.Component {
static contextType = ThemeContext;
render() {
const { forwardRef, ...wrapperProps } = this.props;
return 假設(shè)，我們對(duì) TextInput 進(jìn)行了裝飾，如 export default withColorTheme({forwardRef: true})(TextInput)。
使用：
如果要獲取 WrappedComponent 的實(shí)例，直接通過 this.textInput 即可，和未使用 withColorTheme 裝飾前一樣獲取。
通過方法調(diào)用 getWrappedInstance
import ThemeContext from './context';
import hoistNonReactStatics from 'hoist-non-react-statics';
function withColorTheme(options={}) {
return function(WrappedComponent) {
class ProxyComponent extends React.Component {
static contextType = ThemeContext;
getWrappedInstance = () => {
if (options.forwardRef) {
return this.wrappedInstance;
}
}
setWrappedInstance = (ref) => {
this.wrappedInstance = ref;
}
render() {
const { forwardRef, ...wrapperProps } = this.props;
let props = {
...this.props
};
if (options.forwardRef) {
props.ref = this.setWrappedInstance;
}
return 同樣的，我們對(duì) TextInput 進(jìn)行了裝飾，如 export default withColorTheme({forwardRef: true})(TextInput)。
使用：
如果要獲取 WrappedComponent 的實(shí)例，那么需要通過 this.textInput.getWrappedInstance() 獲取被包裝組件 TextInput 的實(shí)例。
最大化可組合
我先說一下，為什么我將它設(shè)計(jì)為下面這樣：
function withColorTheme(options={}) {
function(WrappedComponent) {
}
}而不是像這樣：
function withColorTheme(WrappedComponent, options={}) {
}主要是使用裝飾器語法比較方便，而且很多業(yè)務(wù)中也使用了 react-redux：
@connect(mapStateToProps, mapDispatchToProps)
@withColorTheme()
export default class TextInput extends Component {
render() {}
}這樣設(shè)計(jì)，可以不破壞原本的代碼結(jié)構(gòu)。否則的話，原本使用裝飾器語法的業(yè)務(wù)改起來就有點(diǎn)麻煩。
回歸到最大化可組合，看看官方文檔怎么說：
像 connect(react-redux 提供) 函數(shù)返回的單參數(shù) HOC 具有簽名 Component => Component。輸出類型與輸入類型相同的函數(shù)很容易組合在一起。
// ... 你可以編寫組合工具函數(shù) // compose(f, g, h) 等同于 (...args) => f(g(h(...args))) const enhance = compose( // 這些都是單參數(shù)的 HOC withRouter, connect(commentSelector) ) const EnhancedComponent = enhance(WrappedComponent)
compose 的源碼可以看下 redux 的實(shí)現(xiàn)，代碼很短。
再復(fù)雜化一下就是:
withRouter(connect(commentSelector)(withColorTheme(options)(WrappedComponent)));
我們的 enhance 可以編寫為:
const enhance = compose( withRouter, connect(commentSelector), withColorTheme(options) ) const EnhancedComponent = enhance(WrappedComponent)
如果我們是寫成 XXX(WrappedComponent, options) 的形式的話，那么上面的代碼將變成:
const EnhancedComponent = withRouter(connect(withColorTheme(WrappedComponent, options), commentSelector))
試想一下，如果還有更多的 HOC 要使用，這個(gè)代碼會(huì)變成什么樣子？
HOC的約定和注意事項(xiàng)
約定
注意事項(xiàng)
React 的 diff 算法（稱為協(xié)調(diào)）使用組件標(biāo)識(shí)來確定它是應(yīng)該更新現(xiàn)有子樹還是將其丟棄并掛載新子樹。 如果從 render 返回的組件與前一個(gè)渲染中的組件相同（===），則 React 通過將子樹與新子樹進(jìn)行區(qū)分來遞歸更新子樹。 如果它們不相等，則完全卸載前一個(gè)子樹。
這不僅僅是性能問題 —— 重新掛載組件會(huì)導(dǎo)致該組件及其所有子組件的狀態(tài)丟失。
如果在組件之外創(chuàng)建 HOC，這樣一來組件只會(huì)創(chuàng)建一次。因此，每次 render 時(shí)都會(huì)是同一個(gè)組件。
3. 反向繼承
React 官方文檔上有這樣一段描述: HOC 不會(huì)修改傳入的組件，也不會(huì)使用繼承來復(fù)制其行為。相反，HOC 通過將組件包裝在容器組件中來組成新組件。HOC 是純函數(shù)，沒有副作用。
因此呢，我覺得反向繼承不是 React 推崇的方式，這里我們可以做一下了解，某些場(chǎng)景下也有可能會(huì)用到。
反向繼承
function withColor(WrappedComponent) {
class ProxyComponent extends WrappedComponent {
//注意 ProxyComponent 會(huì)覆蓋 WrappedComponent 的同名函數(shù)，包括 state 和 props
render() {
//React.cloneElement(super.render(), { style: { color:'red' }})
return super.render();
}
}
return ProxyComponent;
}和上一節(jié)不同，反向繼承不會(huì)增加組件的層級(jí)，并且也不會(huì)有靜態(tài)屬性拷貝和 refs 丟失的問題。可以利用它來做渲染劫持，不過我目前沒有什么必須要使用反向繼承的場(chǎng)景。
雖然它沒有靜態(tài)屬性和 refs的問題，也不會(huì)增加層級(jí)，但是它也不是那么好用，會(huì)覆蓋同名屬性和方法這點(diǎn)就讓人很無奈。另外雖然可以修改渲染結(jié)果，但是不好注入 props。
4. render props
首先， render props 是指一種在 React 組件之間使用一個(gè)值為函數(shù)的 prop 共享代碼的簡(jiǎn)單技術(shù)。
具有 render prop 的組件接受一個(gè)函數(shù)，該函數(shù)返回一個(gè) React 元素并調(diào)用它而不是實(shí)現(xiàn)自己的渲染邏輯。
( )} />
ReactNative 的開發(fā)者，其實(shí) render props 的技術(shù)使用的很多，例如，F(xiàn)latList 組件:
import React, {Component} from 'react';
import {
FlatList,
View,
Text,
TouchableHighlight
} from 'react-native';
class MyList extends Component {
data = [{ key: 1, title: 'Hello' }, { key: 2, title: 'World' }]
render() {
return (
{
return (
{ alert(item.title) }}
>
{item.title}
)
}}
ListHeaderComponent={() => {
return (以下是一個(gè)List )
}}
ListFooterComponent={() => {
return 沒有更多數(shù)據(jù)
}}
/>
)
}
} 例如: FlatList 的 renderItem、ListHeaderComponent 就是render prop。
注意，render prop 是因?yàn)槟Ｊ讲疟环Q為 render prop ，你不一定要用名為 render 的 prop 來使用這種模式。render prop 是一個(gè)用于告知組件需要渲染什么內(nèi)容的函數(shù) prop。
其實(shí)，我們?cè)诜庋b組件的時(shí)候，也經(jīng)常會(huì)應(yīng)用到這個(gè)技術(shù)，例如我們封裝一個(gè)輪播圖組件，但是每個(gè)頁面的樣式是不一致的，我們可以提供一個(gè)基礎(chǔ)樣式，但是也要允許自定義，否則就沒有通用價(jià)值了：
//提供一個(gè) renderPage 的 prop
class Swiper extends React.PureComponent {
getPages() {
if(typeof renderPage === 'function') {
return this.props.renderPage(XX,XXX)
}
}
render() {
const pages = typeof renderPage === 'function' ? this.props.renderPage(XX,XXX) : XXXX;
return (
{pages}
)
}
}注意事項(xiàng)
Render Props 和 React.PureComponent 一起使用時(shí)要小心
如果在 render 方法里創(chuàng)建函數(shù)，那么 render props，會(huì)抵消使用 React.PureComponent 帶來的優(yōu)勢(shì)。因?yàn)闇\比較 props 的時(shí)候總會(huì)得到 false，并且在這種情況下每一個(gè) render 對(duì)于 render prop 將會(huì)生成一個(gè)新的值。
import React from 'react';
import { View } from 'react-native';
import Swiper from 'XXX';
class MySwiper extends React.Component {
render() {
return (
{
return (
這里應(yīng)該比較好理解，這樣寫，renderPage 每次都會(huì)生成一個(gè)新的值，很多 React 性能優(yōu)化上也會(huì)提及到這一點(diǎn)。我們可以將 renderPage 的函數(shù)定義為實(shí)例方法，如下:
import React from 'react';
import { View } from 'react-native';
import Swiper from 'XXX';
class MySwiper extends React.Component {
renderPage(pageDate, pageIndex) {
return (
如果你無法靜態(tài)定義 prop，則
5. Hooks
Hook 是 React 16.8 的新增特性，它可以讓你在不編寫 class 的情況下使用 state 以及其他的 React 特性。HOC 和 render props 雖然都可以
React 已經(jīng)內(nèi)置了一些 Hooks，如: useState、useEffect、useContext、useReducer、useCallback、useMemo、useRef 等 Hook，如果你還不清楚這些 Hook，那么可以優(yōu)先閱讀一下官方文檔。
我們主要是將如何利用 Hooks 來進(jìn)行組件邏輯復(fù)用。假設(shè)，我們有這樣一個(gè)需求，在開發(fā)環(huán)境下，每次渲染時(shí)，打印出組件的 props。
import React, {useEffect} from 'react';
export default function useLogger(componentName,...params) {
useEffect(() => {
if(process.env.NODE_ENV === 'development') {
console.log(componentName, ...params);
}
});
}使用時(shí):
import React, { useState } from 'react';
import useLogger from './useLogger';
export default function Counter(props) {
let [count, setCount] = useState(0);
useLogger('Counter', props);
return (
{`${props.title}, ${count}`}
)
}另外，官方文檔自定義 Hook 章節(jié)也一步一步演示了如何利用 Hook 來進(jìn)行邏輯復(fù)用。我因?yàn)榘姹鞠拗?，還沒有在項(xiàng)目中應(yīng)用 Hook ，雖然文檔已經(jīng)看過多次。讀到這里，一般都會(huì)有一個(gè)疑問，那就是 Hook 是否會(huì)替代 render props 和 HOC，關(guān)于這一點(diǎn)，官方也給出了答案：
通常，render props 和高階組件只渲染一個(gè)子節(jié)點(diǎn)。我們認(rèn)為讓 Hook 來服務(wù)這個(gè)使用場(chǎng)景更加簡(jiǎn)單。這兩種模式仍有用武之地，例如，F(xiàn)latList 組件的 renderItem 等屬性，或者是 一個(gè)可見的容器組件或許會(huì)有它自己的 DOM 結(jié)構(gòu)。但在大部分場(chǎng)景下，Hook 足夠了，并且能夠幫助減少嵌套。
HOC 最最最討厭的一點(diǎn)就是層級(jí)嵌套了，如果項(xiàng)目是基于新版本進(jìn)行開發(fā)，那么需要邏輯復(fù)用時(shí)，優(yōu)先考慮 Hook，如果無法實(shí)現(xiàn)需求，那么再使用 render props 和 HOC 來解決。
看完上述內(nèi)容，是不是對(duì)React中組件邏輯復(fù)用的使用方法有進(jìn)一步的了解，如果還想學(xué)習(xí)更多內(nèi)容，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。
