摘要:高階函數我們都用過,就是接受一個函數然后返回一個經過封裝的函數而高階組件就是高階函數的概念應用到高階組件上使用接受一個組件返回一個經過包裝的新組件。靈活性在組合階段相對更為靈活,他并不規定被增強組件如何使用它傳遞下去的屬性。
在接觸過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 => () // 使用 const Header = text => ( {text} ) 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 returnFaCC} } }
同樣FaCC也是用于增強原有組件能力的一種模式,其主要功能的實現在于react的props.children可以是任何東西,包括函數。我們可以拿上面class的例子用FaCC再實現一遍:
const ClassNameWrapper = ({ children }) => children("demo-class") // 使用 const HeadWithClass = (props) => ({(class) => )}
在FaCC中你也可以像HOC一樣在生命周期中做很多事對原有的組件進行封裝,基本上HOC能做的FaCC也都能做。我所在的項目之前都是大范圍的使用HOC,再經過一番討論后,開始大范圍的轉變成FaCC。
區別兩者都是用來增強原有組件的,具體該使用那種?那種是正確的模式?社區關于這一點也有很多討論,比如就有人說FaCC是反模式:Function as Child Components Are an Anti-Pattern。他給出的理由是children并不語義化,會造成困惑,然后他提出了Component Injection的模式,有興趣的同學可以讀一讀。
具體從幾個方面做一下對比:
組合階段
組合階段意思就是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 => ({ data => ( )) }
如果在上面再增加2個HOC,上面組合的過程就變得十分難看。而FaCC相對而言,如何封裝,數據源來自那里,組件接受了那些數據都比較顯眼。
性能優化
在HOC中我們能接受到宿主的prop,因為props是從HOC往下傳遞的,所以我們也有完整的生命周期,我們可以使用shouldComponentUpdate優化。而FaCC則不然,無法在其內部做比較props,除非在組合的時候外部在包一個組件才能進行比較props。
靈活性
FaCC 在組合階段相對HOC更為靈活,他并不規定被增強組件如何使用它傳遞下去的屬性。而HOC基本上在編寫完后就定死了。
另外,FaCC不會再去創建一個新的Component,而HOC會創建一個新的Component然后傳遞props下去。
總結社區中很多開源庫已經使用了兩種模式,也有很多的文章進行比較。也有很多激烈討論,當然對于最后解決問題而言,兩種模式都有好處。出于不同的考慮,可能選擇不一樣。
參考文章:
http://rea.tech/functions-as-...
http://rea.tech/reactjs-real-...
https://medium.com/merrickchr...
http://www.ituring.com.cn/boo... 第四章
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/97387.html
摘要:本文并不逐行地對源碼進行細致分析,不如說是基于以下幾個問題,對源碼進行大致的掃覽。我們已經知道,中,允許用戶注冊監聽器,這些監聽器會在每次執行結束后遍歷觸發。省略一些無關代碼其中,是為了在嵌套的中嵌套執行。 react-redux 源碼解讀 [TOC] 前置知識 閱讀本篇文章前,請先確認你是否了解以下知識: react redux 高階組件 react diff 機制 其中高階組件...
摘要:高階組件的概念,是里面經常提到的,類似于高階函數。高階函數高階組件高階組件用是代碼復用的優秀工具,主要在處理邏輯方面和普適性上,有著奇效。 前言 在web開發上,我們都對數據采用分頁加載的機制,一種變形就是在頁面采用循環加載的機制,拉到頁面最下方有個加載更多的按鈕。問題在于,當不同的數據要展示時,就要寫很多這種列表,但是其中的邏輯都是相似的。 維護一組數據 加載更多數據 將數據用對應...
摘要:裝飾者模式參與者裝飾者和被裝飾者共同的父類,是一個接口或者抽象類,用來定義基本行為定義具體對象,即被裝飾者抽象裝飾者,繼承自,從外類來擴展。三裝飾器高階組件可以看做是裝飾器模式在的實現。 一 裝飾者模式 優先使用對象組合而不是類繼承。 --《設計模式》 1.什么是裝飾者模式 定義:動態的給對象添加一些額外的屬性或行為。相比于使用繼承,裝飾者模式更加靈活。 2.裝飾者模式參與者 Co...
摘要:比如有個組件,它用來實時的獲取鼠標的位置。命名空間,多個修改同一個導致的命名沖突。據說源碼里面為每個組件增加路由屬性就是通過該方法好了大功完成了,歡迎一起討論學習個人博客地址意卿 1.mixins 寫過react項目的應該都碰到過,不同組件復用相同代碼的問題,在react早期使用React.createClass創建組件的時代,我們經常使用的是mixins來實現代碼復用。比如有個組件A...
摘要:組件渲染首先我們來了解組件返回的虛擬是怎么渲染為真實,來看一下的組件是如何構造的可能我們會想當然地認為組件的構造函數定義將會及其復雜,事實上恰恰相反,的組件定義代碼極少。 前言 首先歡迎大家關注我的掘金賬號和Github博客,也算是對我的一點鼓勵,畢竟寫東西沒法獲得變現,能堅持下去也是靠的是自己的熱情和大家的鼓勵。 之前分享過幾篇關于React的文章: React技術內幕: k...
閱讀 1618·2021-11-22 13:53
閱讀 2848·2021-11-15 18:10
閱讀 2755·2021-09-23 11:21
閱讀 2491·2019-08-30 15:55
閱讀 475·2019-08-30 13:02
閱讀 752·2019-08-29 17:22
閱讀 1659·2019-08-29 13:56
閱讀 3455·2019-08-29 11:31