React 程式碼共享最佳實踐方式

凹凸實驗室發表於2021-05-11

任何一個專案發展到一定複雜性的時候,必然會面臨邏輯複用的問題。在React中實現邏輯複用通常有以下幾種方式:Mixin高階元件(HOC)修飾器(decorator)Render PropsHook。本文主要就以上幾種方式的優缺點作分析,幫助開發者針對業務場景作出更適合的方式。

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包含以上的DefaultNameMixinDefaultFriendMixin

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

但是在不同場景下,優勢也可能變成劣勢:

  • 破壞原有元件的封裝,可能需要去維護新的stateprops等狀態
  • 不同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的三個物件historylocationmatch放入到該元件的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 propsreact hook而言,並沒有哪種方式可稱為最佳方案,它們都是優勢與劣勢並存的。哪怕是最為最熱門的react hook,雖然每一個hook看起來都是那麼的簡短和清爽,但是在實際業務中,通常都是一個業務功能對應多個hook,這就意味著當業務改變時,需要去維護多個hook的變更,相對於維護一個class而言,心智負擔或許要增加許多。只有切合自身業務的方式,才是最佳方案


參考文件:


歡迎關注凹凸實驗室部落格:aotu.io

或者關注凹凸實驗室公眾號(AOTULabs),不定時推送文章:

歡迎關注凹凸實驗室公眾號

相關文章