摘要:組件有兩個關(guān)鍵的表明當(dāng)前是否應(yīng)高亮,自己被點擊時調(diào)用的回調(diào)函數(shù),由于是每個頁面的容器,它只負(fù)責(zé)把渲染出來,所以用函數(shù)式組件即可。
這種模式本質(zhì)上解決的是組件之間傳值的問題。但是它對于傳值以及一些內(nèi)部操控的邏輯封裝得更嚴(yán)密。
場景:希望減少上下級組件之間props的傳遞,簡單來說就是不用傳做顯式地傳值,來達(dá)到組件之間相互通信的目的
舉例來說,某些界面中應(yīng)該有Tabs這樣的組件,由Tab和TabItem組成,點擊每個TabItem,該TabItem會高亮,
那么Tab和TabItem自然要進行溝通。很自然的寫法是像下面這樣
One Two Three
這樣的缺點很明顯:
每次使用 TabItem 都要傳遞一堆 props
每增加一個新的 TabItem,都要增加對應(yīng)的 props
如果要增加 TabItem,就要去修改 Tabs 的 JSX 代碼
但是,組件之間的交互我們又不希望通過props或者context來實現(xiàn)。希望用法如下面一樣簡潔。
第一 第二 第三
組件之間通過隱秘的方式進行通信,但這里的隱秘實際上是對props的操作在一個地方進行管理。
實現(xiàn)明白了要實現(xiàn)的交互,和代碼層面要實現(xiàn)的效果,就可以開始動手了。
TabItem組件有兩個關(guān)鍵的props: active(表明當(dāng)前是否應(yīng)高亮),onTabClick(自己被點擊時調(diào)用的回調(diào)函數(shù)),
TabItem由于是每個Tab頁面的容器,它只負(fù)責(zé)把props.children渲染出來,所以用函數(shù)式組件即可。
export const TabItem = props => { const { active, onTabClick, children } = props const style = { color: active ? "red" : "green", cursor: "pointer" } return <>{children}
> }
我們再來回顧一下想到達(dá)到的效果:
第一 第二 第三
使用組件時要避免傳遞props的缺點,那么在哪里傳遞呢?自然是是Tabs組件。但上面并沒有傳入props啊。
Tabs 雖然可以訪問到props里邊的children,但是到手的children已經(jīng)是現(xiàn)成的如果直接改它的話,會出問題。
不可以直接改children的話,我們就把children復(fù)制一份,然后改這個復(fù)制過來的children,再渲染出去,就ok啦!
下面來看Tabs的實現(xiàn):
class Tabs extends React.Component { state={ activeIndex: 0 } render() { const { activeIndex } = this.state const newChildren = React.Children.map(this.props.children, (child, index) => { if (child.type) { // 復(fù)制并修改children return React.cloneElement(child, { active: activeIndex === index, onTabClick: () => this.setState({activeIndex: index}) }) } else { return child } }) return{newChildren}} }
這里需要用到React不常用的api:
React.Children.map
React.cloneElement
使用React.Children.map來對props.children進行遍歷。
而React.cloneElement可以復(fù)制某個元素,第一個參數(shù)是被復(fù)制的元素,第二個參數(shù)我們可以把想傳入的props加進去,也就是這個時機,
我們將active和onTabClick傳入。實現(xiàn)最終效果。
這種模式比較好的把復(fù)雜邏輯完全封裝起來了,抽象程度更好,比較適合開發(fā)組件開發(fā)者。針對props的擴展性也比較好,對于使用組件的開發(fā)者來說,也比較友好。
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://m.specialneedsforspecialkids.com/yun/104503.html
摘要:幸運的是,組合易于理解。組件的組合是自然而然的。高效用戶界面可組合的層次結(jié)構(gòu),因此,組件的組合是一種構(gòu)建用戶界面的有效的方式。這個原則建議避免重復(fù)。只有一個組件符合單一責(zé)任原則并且具有合理的封裝時,它是可復(fù)用的。 翻譯:劉小夕原文鏈接:https://dmitripavlutin.com/7-... 原文的篇幅非常長,不過內(nèi)容太過于吸引我,還是忍不住要翻譯出來。此篇文章對編寫可重用和...
摘要:單向數(shù)據(jù)流應(yīng)用的核心設(shè)計模式,數(shù)據(jù)流向自頂向下我也是性子急的人,按照技術(shù)界的慣例,在學(xué)習(xí)一個技術(shù)前,首先得說一句。然而的單向數(shù)據(jù)流的設(shè)計讓前端定位變得簡單,頁面的和數(shù)據(jù)的對應(yīng)是唯一的我們可以通過定位數(shù)據(jù)變化就可以定位頁面展現(xiàn)問題。 書籍完整目錄 1.1 React 介紹 showImg(https://segmentfault.com/img/bVvJgS); 1.1.1 React ...
摘要:一般這種情況會在類的構(gòu)造函數(shù)內(nèi)創(chuàng)建一個屬性,引用或詞法域的,但后面會看到我們有更好的辦法,避免這種手工代碼。 換句話說,StateUp模式把面向?qū)ο蟮脑O(shè)計方法應(yīng)用到了狀態(tài)對象的管理上,在遵循React的組件化機制和基于props實現(xiàn)組件通訊方式的前提之下做到了這一點。 ---- 少婦白潔 閱讀本文之前,請確定你讀過React的官方文檔中關(guān)于Lifting State Up的論述: ht...
摘要:高階函數(shù)我們都用過,就是接受一個函數(shù)然后返回一個經(jīng)過封裝的函數(shù)而高階組件就是高階函數(shù)的概念應(yīng)用到高階組件上使用接受一個組件返回一個經(jīng)過包裝的新組件。靈活性在組合階段相對更為靈活,他并不規(guī)定被增強組件如何使用它傳遞下去的屬性。 在接觸過React項目后,大多數(shù)人都應(yīng)該已經(jīng)了解過或則用過了HOC(High-Order-Components)和FaCC(Functions as Child ...
閱讀 1523·2021-08-09 13:47
閱讀 2780·2019-08-30 15:55
閱讀 3506·2019-08-29 15:42
閱讀 1127·2019-08-29 13:45
閱讀 3019·2019-08-29 12:33
閱讀 1752·2019-08-26 11:58
閱讀 995·2019-08-26 10:19
閱讀 2423·2019-08-23 18:00