React中的函數子組件和高階組件的詳解

這篇文章給大家帶來的內容是關於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 exampleimport View from './View'const DetailPage = withServerData(withNavigator(View))

// FaCC exampleimport 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下去。

總結

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