React 代碼共享最佳實踐方式

任何一個項目發展到必定複雜性的時候，必然會面臨邏輯複用的問題。在React中實現邏輯複用一般有如下幾種方式：Mixin、高階組件(HOC)、修飾器(decorator)、Render Props、Hook。本文主要就以上幾種方式的優缺點做分析，幫助開發者針對業務場景做出更適合的方式。html

Mixin

這或許是剛從Vue轉向React的開發者第一個可以想到的方法。Mixin一直被普遍用於各類面向對象的語言中，其做用是爲單繼承語言創造一種相似多重繼承的效果。雖然如今React已將其放棄中，但Mixin的確曾是React實現代碼共享的一種設計模式。react

廣義的 mixin 方法，就是用賦值的方式將 mixin 對象中的方法都掛載到原對象上，來實現對象的混入，相似 ES6 中的 Object.assign()的做用。原理以下：segmentfault

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的屬性值：api

const ComponentOne = React.createClass({
  mixins: [DefaultNameMixin]
  render: function () {
    return <h2>Hello {this.props.name}</h2>
  }
})
複製代碼

寫好的mixin能夠在其餘組件裏重複使用。數組

因爲mixins屬性值是一個數組，意味着咱們能夠同一個組件裏調用多個mixin。在上述例子中稍做更改獲得：markdown

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。antd

好比寫一個新的mixin``DefaultProps包含以上的DefaultNameMixin和DefaultFriendMixin ：react-router

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至少擁有如下優點:app

能夠在多個組件裏使用相同的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而言，心智負擔或許要增長許多。只有切合自身業務的方式，纔是最佳方案。

參考文檔：