詳解React 程式碼共享最佳實踐方式
任何一個專案發展到一定複雜性的時候,必然會面臨邏輯複用的問題。在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:http://www.cppcns.com [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
在狀態衝突、方法衝突、多個生命週期方法的呼叫順序等問題擁有自己的處理邏輯。感興趣的同學可以參考一下以下文章:
React Mixin 的使用
Mixins Considered Harmful
高階元件
由於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) mRjxhwfbf=> { const displayName = `withRouter(${Component.displayName || Component.name})` mRjxhwfbf 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 "r程式設計客棧eact"
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> www.cppcns.com)} </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 簡介
到此這篇關於React 程式碼共享最佳實踐方式的文章就介紹到這了,更多相關React 程式碼共享內容請搜尋我們以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援我們!