任何一個專案發展到一定複雜性的時候，必然會面臨邏輯複用的問題。在React中實現邏輯複用通常有以下幾種方式：Mixin、高階元件(HOC)、修飾器(decorator)、Render Props、Hook。本文主要就以上幾種方式的優缺點作分析，幫助開發者針對業務場景作出更適合的方式。
Mixin
這或許是剛從Vue轉向React的開發者第一個能夠想到的方法。Mixin一直被廣泛用於各種物件導向的語言中，其作用是為單繼承語言創造一種類似多重繼承的效果。雖然現在React已將其放棄中，但Mixin的確曾是React實現程式碼共享的一種設計模式。
廣義的 mixin 方法，就是用賦值的方式將 mixin 物件中的方法都掛載到原物件上，來實現物件的混入，類似 ES6 中的 Object.assign()的作用。原理如下：
const mixin = function (obj, mixins) {
const newObj = obj
newObj.prototype = Object.create(obj.prototype)
for (let prop in mixins) {
// 遍歷mixins的屬性
if (mixins.hasOwnPrototype(prop)) {
// 判斷是否為mixin的自身屬性
newObj.prototype[prop] = mixins[prop]; // 賦值
}
}
return newObj
};
在 React 中使用 Mixin
假設在我們的專案中，多個元件都需要設定預設的name屬性，使用mixin可以使我們不必在不同的元件裡寫多個同樣的getDefaultProps方法，我們可以定義一個mixin：
const DefaultNameMixin = {
getDefaultProps: function () {
return {
name: "Joy"
}
}
}
為了使用mixin，需要在元件中加入mixins屬性，然後把我們寫好的mixin包裹成一個陣列，將它作為mixins的屬性值：
const ComponentOne = React.createClass({
mixins: [DefaultNameMixin]
render: function () {
return <h2>Hello {this.props.name}</h2>
}
})
寫好的mixin可以在其他元件裡重複使用。
由於mixins屬性值是一個陣列，意味著我們可以同一個元件裡呼叫多個mixin。在上述例子中稍作更改得到：
const DefaultFriendMixin = {
getDefaultProps: function () {
return {
friend: "Yummy"
}
}
}
const ComponentOne = React.createClass({
mixins: [DefaultNameMixin, DefaultFriendMixin]
render: function () {
return (
<div>
<h2>Hello {this.props.name}</h2>
<h2>This is my friend {this.props.friend}</h2>
</div>
)
}
})
我們甚至可以在一個mixin裡包含其他的mixin。
比如寫一個新的mixin``DefaultProps包含以上的DefaultNameMixin和DefaultFriendMixin ：
const DefaultPropsMixin = {
mixins: [DefaultNameMixin, DefaultFriendMixin]
}
const ComponentOne = React.createClass({
mixins: [DefaultPropsMixin]
render: function () {
return (
<div>
<h2>Hello {this.props.name}</h2>
<h2>This is my friend {this.props.friend}</h2>
</div>
)
}
})
至此，我們可以總結出mixin至少擁有以下優勢:
- 可以在多個元件裡使用相同的
mixin； - 可以在同一個元件裡使用多個
mixin； - 可以在同一個
mixin裡巢狀多個mixin；
但是在不同場景下，優勢也可能變成劣勢：
- 破壞原有元件的封裝，可能需要去維護新的
state和props等狀態； - 不同
mixin裡的命名不可知，非常容易發生衝突； - 可能產生遞迴呼叫問題，增加了專案複雜性和維護難度；
除此之外，mixin在狀態衝突、方法衝突、多個生命週期方法的呼叫順序等問題擁有自己的處理邏輯。感興趣的同學可以參考一下以下文章：
高階元件
由於mixin存在上述缺陷，故React剝離了mixin，改用高階元件來取代它。
高階元件本質上是一個函式，它接受一個元件作為引數，返回一個新的元件。
React官方在實現一些公共元件時，也用到了高階元件，比如react-router中的withRouter，以及Redux中的connect。在這以withRouter為例。
預設情況下，必須是經過Route路由匹配渲染的元件才存在this.props、才擁有路由引數、才能使用函式式導航的寫法執行this.props.history.push('/next')跳轉到對應路由的頁面。高階元件中的withRouter作用是將一個沒有被Route路由包裹的元件，包裹到Route裡面，從而將react-router的三個物件history、location、match放入到該元件的props屬性裡，因此能實現函式式導航跳轉。
withRouter的實現原理：
const withRouter = (Component) => {
const displayName = `withRouter(${Component.displayName || Component.name})`
const C = props => {
const { wrappedComponentRef, ...remainingProps } = props
return (
<RouterContext.Consumer>
{context => {
invariant(
context,
`You should not use <${displayName} /> outside a <Router>`
);
return (
<Component
{...remainingProps}
{...context}
ref={wrappedComponentRef}
/>
)
}}
</RouterContext.Consumer>
)
}
使用程式碼：
import React, { Component } from "react"
import { withRouter } from "react-router"
class TopHeader extends Component {
render() {
return (
<div>
導航欄
{/* 點選跳轉login */}
<button onClick={this.exit}>退出</button>
</div>
)
}
exit = () => {
// 經過withRouter高階函式包裹，就可以使用this.props進行跳轉操作
this.props.history.push("/login")
}
}
// 使用withRouter包裹元件，返回history,location等
export default withRouter(TopHeader)
由於高階元件的本質是獲取元件並且返回新元件的方法，所以理論上它也可以像mixin一樣實現多重巢狀。
例如：
寫一個賦能唱歌的高階函式
import React, { Component } from 'react'
const widthSinging = WrappedComponent => {
return class HOC extends Component {
constructor () {
super(...arguments)
this.singing = this.singing.bind(this)
}
singing = () => {
console.log('i am singing!')
}
render() {
return <WrappedComponent />
}
}
}
寫一個賦能跳舞的高階函式
import React, { Component } from 'react'
const widthDancing = WrappedComponent => {
return class HOC extends Component {
constructor () {
super(...arguments)
this.dancing = this.dancing.bind(this)
}
dancing = () => {
console.log('i am dancing!')
}
render() {
return <WrappedComponent />
}
}
}
使用以上高階元件
import React, { Component } from "react"
import { widthSing, widthDancing } from "hocs"
class Joy extends Component {
render() {
return <div>Joy</div>
}
}
// 給Joy賦能唱歌和跳舞的特長
export default widthSinging(withDancing(Joy))
由上可見，只需使用高階函式進行簡單的包裹，就可以把原本單純的 Joy 變成一個既能唱歌又能跳舞的夜店小王子了！
使用 HOC 的約定
在使用HOC的時候，有一些墨守成規的約定：
- 將不相關的 Props 傳遞給包裝元件（傳遞與其具體內容無關的 props）；
- 分步組合（避免不同形式的 HOC 串聯呼叫）；
- 包含顯示的 displayName 方便除錯（每個 HOC 都應該符合規則的顯示名稱）；
- 不要在
render函式中使用高階元件（每次 render，高階都返回新元件，影響 diff 效能）； - 靜態方法必須被拷貝（經過高階返回的新元件，並不會包含原始元件的靜態方法）；
- 避免使用 ref（ref 不會被傳遞）;
HOC 的優缺點
至此我們可以總結一下高階元件(HOC)的優點：
HOC是一個純函式，便於使用和維護；- 同樣由於
HOC是一個純函式，支援傳入多個引數，增強其適用範圍； HOC返回的是一個元件，可組合巢狀，靈活性強；
當然HOC也會存在一些問題：
- 當多個
HOC巢狀使用時，無法直接判斷子元件的props是從哪個HOC負責傳遞的； - 當父子元件有同名
props，會導致父元件覆蓋子元件同名props的問題，且react不會報錯，開發者感知性低； - 每一個
HOC都返回一個新元件，從而產生了很多無用元件，同時加深了元件層級，不便於排查問題；
修飾器和高階元件屬於同一模式，在此不展開討論。
Render Props
Render Props是一種非常靈活複用性非常高的模式，它可以把特定行為或功能封裝成一個元件，提供給其他元件使用讓其他元件擁有這樣的能力。
The term “render prop” refers to a technique for sharing code between React components using a prop whose value is a function.
這是React官方對於Render Props的定義，翻譯成大白話即：“Render Props是實現React Components之間程式碼共享的一種技術，元件的props裡邊包含有一個function型別的屬性，元件可以呼叫該props屬性來實現元件內部渲染邏輯”。
官方示例：
<DataProvider render={(data) => <h1>Hello {data.target}</h1>} />
如上，DataProvider元件擁有一個叫做render（也可以叫做其他名字）的props屬性，該屬性是一個函式，並且這個函式返回了一個React Element，在元件內部通過呼叫該函式來完成渲染，那麼這個元件就用到了render props技術。
讀者或許會疑惑，“我們為什麼需要呼叫props屬性來實現元件內部渲染，而不直接在元件內完成渲染”？借用React官方的答覆，render props並非每個React開發者需要去掌握的技能，甚至你或許永遠都不會用到這個方法，但它的存在的確為開發者在思考元件程式碼共享的問題時，提供了多一種選擇。
Render Props使用場景
我們在專案開發中可能需要頻繁的用到彈窗，彈窗 UI 可以千變萬化，但是功能卻是類似的，即開啟和關閉。以antd為例：
import { Modal, Button } from "antd"
class App extends React.Component {
state = { visible: false }
// 控制彈窗顯示隱藏
toggleModal = (visible) => {
this.setState({ visible })
};
handleOk = (e) => {
// 做點什麼
this.setState({ visible: false })
}
render() {
const { visible } = this.state
return (
<div>
<Button onClick={this.toggleModal.bind(this, true)}>Open</Button>
<Modal
title="Basic Modal"
visible={visible}
onOk={this.handleOk}
onCancel={this.toggleModal.bind(this, false)}
>
<p>Some contents...</p>
</Modal>
</div>
)
}
}
以上是最簡單的Model使用例項，即便是簡單的使用，我們仍需要關注它的顯示狀態，實現它的切換方法。但是開發者其實只想關注與業務邏輯相關的onOk，理想的使用方式應該是這樣的：
<MyModal>
<Button>Open</Button>
<Modal title="Basic Modal" onOk={this.handleOk}>
<p>Some contents...</p>
</Modal>
</MyModal>
可以通過render props實現以上使用方式：
import { Modal, Button } from "antd"
class MyModal extends React.Component {
state = { on: false }
toggle = () => {
this.setState({
on: !this.state.on
})
}
renderButton = (props) => <Button {...props} onClick={this.toggle} />
renderModal = ({ onOK, ...rest }) => (
<Modal
{...rest}
visible={this.state.on}
onOk={() => {
onOK && onOK()
this.toggle()
}}
onCancel={this.toggle}
/>
)
render() {
return this.props.children({
Button: this.renderButton,
Modal: this.renderModal
})
}
}
這樣我們就完成了一個具備狀態和基礎功能的Modal，我們在其他頁面使用該Modal時，只需要關注特定的業務邏輯即可。
以上可以看出，render props是一個真正的React元件，而不是像HOC一樣只是一個可以返回元件的函式，這也意味著使用render props不會像HOC一樣產生元件層級巢狀的問題，也不用擔心props命名衝突產生的覆蓋問題。
render props使用限制
在render props中應該避免使用箭頭函式，因為這會造成效能影響。
比如：
// 不好的示例
class MouseTracker extends React.Component {
render() {
return (
<Mouse render={mouse => (
<Cat mouse={mouse} />
)}/>
)
}
}
這樣寫是不好的，因為render方法是有可能多次渲染的，使用箭頭函式，會導致每次渲染的時候，傳入render的值都會不一樣，而實際上並沒有差別，這樣會導致效能問題。
所以更好的寫法應該是將傳入render裡的函式定義為例項方法，這樣即便我們多次渲染，但是繫結的始終是同一個函式。
// 好的示例
class MouseTracker extends React.Component {
renderCat(mouse) {
return <Cat mouse={mouse} />
}
render() {
return (
<Mouse render={this.renderTheCat} />
)
}
}
render props的優缺點
-
優點
- props 命名可修改，不存在相互覆蓋；
- 清楚 props 來源；
- 不會出現元件多層巢狀；
-
缺點
-
寫法繁瑣；
-
無法在
return語句外訪問資料； -
容易產生函式回撥巢狀；
如下程式碼：
const MyComponent = () => { return ( <Mouse> {({ x, y }) => ( <Page> {({ x: pageX, y: pageY }) => ( <Connection> {({ api }) => { // yikes }} </Connection> )} </Page> )} </Mouse> ) }
-
Hook
React的核心是元件，因此，React一直致力於優化和完善宣告元件的方式。從最早的類元件，再到函式元件，各有優缺點。類元件可以給我們提供一個完整的生命週期和狀態（state）,但是在寫法上卻十分笨重，而函式元件雖然寫法非常簡潔輕便，但其限制是必須是純函式，不能包含狀態，也不支援生命週期，因此類元件並不能取代函式元件。
而React團隊覺得元件的最佳寫法應該是函式，而不是類，由此產生了React Hooks。
React Hooks 的設計目的，就是加強版函式元件，完全不使用"類"，就能寫出一個全功能的元件。
為什麼說類元件“笨重”，借用React官方的例子說明：
import React, { Component } from "react"
export default class Button extends Component {
constructor() {
super()
this.state = { buttonText: "Click me, please" }
this.handleClick = this.handleClick.bind(this)
}
handleClick() {
this.setState(() => {
return { buttonText: "Thanks, been clicked!" }
})
}
render() {
const { buttonText } = this.state
return <button onClick={this.handleClick}>{buttonText}</button>
}
}
以上是一個簡單的按鈕元件，包含最基礎的狀態和點選方法，點選按鈕後狀態發生改變。
本是很簡單的功能元件，但是卻需要大量的程式碼去實現。由於函式元件不包含狀態，所以我們並不能用函式元件來宣告一個具備如上功能的元件。但是我們可以用Hook來實現：
import React, { useState } from "react"
export default function Button() {
const [buttonText, setButtonText] = useState("Click me, please")
function handleClick() {
return setButtonText("Thanks, been clicked!")
}
return <button onClick={handleClick}>{buttonText}</button>
}
相較而言，Hook顯得更輕量，在貼近函式元件的同時，保留了自己的狀態。
在上述例子中引入了第一個鉤子useState()，除此之外，React官方還提供了useEffect()、useContext()、useReducer()等鉤子。具體鉤子及其用法詳情請見官方。
Hook的靈活之處還在於，除了官方提供的基礎鉤子之外，我們還可以利用這些基礎鉤子來封裝和自定義鉤子，從而實現更容易的程式碼複用。
Hook 優缺點
- 優點
- 更容易複用程式碼；
- 清爽的程式碼風格；
- 程式碼量更少；
- 缺點
- 狀態不同步（函式獨立執行，每個函式都有一份獨立的作用域）
- 需要更合理的使用
useEffect - 顆粒度小，對於複雜邏輯需要抽象出很多
hook
總結
除了Mixin因為自身的明顯缺陷而稍顯落後之外，對於高階元件、render props、react hook而言，並沒有哪種方式可稱為最佳方案，它們都是優勢與劣勢並存的。哪怕是最為最熱門的react hook，雖然每一個hook看起來都是那麼的簡短和清爽，但是在實際業務中，通常都是一個業務功能對應多個hook，這就意味著當業務改變時，需要去維護多個hook的變更，相對於維護一個class而言，心智負擔或許要增加許多。只有切合自身業務的方式，才是最佳方案。
參考文件：
- React Mixin 的使用
- Mixins Considered Harmful
- Higher-Order Components
- Render Props
- React 拾遺：Render Props 及其使用場景
- Hook 簡介
歡迎關注凹凸實驗室部落格：aotu.io
或者關注凹凸實驗室公眾號（AOTULabs），不定時推送文章：
