React中的函式子元件(FaCC)和高階元件(HOC)

hiluluke發表於2018-09-04
React函式元件

在接觸過React專案後，大多數人都應該已經瞭解過或則用過了HOC(High-Order-Components)和FaCC(Functions as Child Components)，因為這兩個模式在大多數react的開源庫裡都存在。比如react-router裡面的withRouter 就是典型的高階元件，接受一個元件返回另外一個經過增強後的元件。而react-motion中的Motion就是典型的FaCC的應用。

HOC和FaCC兩者做的事也是非常相似的，都是類似設計模式裡面的裝飾者模式。都是在原有的例項或則單元上進行功能的增強。

當然不只是一些開源庫中會使用，在平常的程式碼編寫中，也有很多地方是適用於使用HOC和FaCC去封裝一些邏輯。比如資料埋點，新特性的toggle，獲取轉換資料等。對於增強程式碼可讀性和邏輯複用來說，非常有用的。

HOC

高階函式我們都用過，就是接受一個函式然後返回一個經過封裝的函式：

const plus = first => second => (first + second)
plus(1)(2) // 3

而高階元件就是高階函式的概念應用到高階元件上:

const withClassName = ComposedComponent => props => (
   <ComposedComponent {...props} className='demo-class' />
)

const Header = text => (<header>{text}</header>)
const headerWitheClass = withClassName(Header)

接受一個元件返回一個經過包裝的新元件。在我們經常使用的withRouter就是在原有元件props上面在加上localtion等屬性。除了新增props以外高階元件還能做到：

  • 在真正呼叫元件前後做一些事，比如埋點資料等
  • 判斷元件是否該render，或則應該render其他的東西，比如出錯之後render錯誤頁面
  • 傳遞props並增加新的props
  • 不render元件，轉而做一些其他的事情，比如渲染一個外部的dom

對於上面的前三點都比較好理解，解釋一下第4點。比如你在render了一個頁面之後，需要改變一下頁面的title.這是單頁應用普遍存在的一個需求，通常你可以在具體router庫中使用hook去實現。當然也可以通過HOC來實現：

const withTitleChange = ComposedComponent => {
  return class extends React.Component {
    componentDidMount () {
      const { title } = this.props
      document.title = title
    }
    render () {
      const props = this.props
      return <ComposedComponent {...props} />
    }
  }
}

FaCC

同樣FaCC也是用於增強原有元件能力的一種模式，其主要功能的實現在於react的props.children可以是任何東西，包括函式。我們可以拿上面class的例子用FaCC再實現一遍：

const ClassNameWrapper = ({ children }) => children('demo-class')

// 使用

const HeadWithClass = (props) => (
  <ClassNameWrapper>
    {(class) => <header classNmae={class} ></header>}
  </ClassNameWrapper>
)

在FaCC中你也可以像HOC一樣在生命週期中做很多事對原有的元件進行封裝，基本上HOC能做的FaCC也都能做。我所在的專案之前都是大範圍的使用HOC，再經過一番討論後，開始大範圍的轉變成FaCC。

區別

兩者都是用來增強原有元件的，具體該使用那種？那種是正確的模式？社群關於這一點也有很多討論，比如就有人說FaCC是反模式：Function as Child Components Are an Anti-Pattern。他給出的理由是children並不語義化，會造成困惑，然後他提出了Component Injection的模式，有興趣的同學可以讀一讀。

具體從幾個方面做一下對比：

  1. 組合階段

組合階段意思就是HOC，FaCC和要被增強的元件的組合時候。可以很明顯發現，FaCC對於前後元件對接依賴資訊顯示的更多，相對而言更容易理解。而HOC，相互之間如何橋接，你必須得深入到HOC內部讀程式碼才可以知道這個HOC具體幹了啥。

// HOC example
import View from './View'

const DetailPage = withServerData(withNavigator(View))

.

// FaCC example

import View from './View'

const DetailPage = props => (
  <FetchServerData>
    {
      data => (
        <Navigator>
          <View data={data} {...props} />
        </Navigator>
      )
    }
  </FetchServerData>
)

如果在上面再增加2個HOC，上面組合的過程就變得十分難看。而FaCC相對而言，如何封裝，資料來源來自那裡，元件接受了那些資料都比較顯眼。

  1. 效能優化

在HOC中我們能接受到宿主的prop，因為props是從HOC往下傳遞的，所以我們也有完整的生命週期，我們可以使用shouldComponentUpdate優化。而FaCC則不然，無法在其內部做比較props，除非在組合的時候外部在包一個元件才能進行比較props。

  1. 靈活性

FaCC 在組合階段相對HOC更為靈活，他並不規定被增強元件如何使用它傳遞下去的屬性。而HOC基本上在編寫完後就定死了。

另外，FaCC不會再去建立一個新的Component，而HOC會建立一個新的Component然後傳遞props下去。

總結

社群中很多開源庫已經使用了兩種模式，也有很多的文章進行比較。也有很多激烈討論，當然對於最後解決問題而言，兩種模式都有好處。出於不同的考慮，可能選擇不一樣。

參考文章： 1. http://rea.tech/functions-as-child-components-and-higher-order-components/

  1. http://rea.tech/reactjs-real-world-examples-of-higher-order-components/#the-relationship-between-hocs-and-decorator-design-pattern

  2. https://medium.com/merrickchristensen/function-as-child-components-5f3920a9ace9

  3. http://www.ituring.com.cn/book/2007 第四章

相關文章