如何在React中處理組件交互?
譯文【51CTO.com快譯】每個React應用都是由交互組件組成的。這些組件如何通信是UI體系結構的一個重要一環。隨著應用程序變得更大、更復雜,組件交互變得更加重要。
React提供了多種方法來處理這種需求,每種方法都有其相應的用例。這次讓我們從最簡單的親子互動方法開始。
親子與道具
組件之間最簡單的通信形式是通過屬性——通常稱為道具(Props)。Props是由父組件傳遞給子組件的參數,類似于函數的參數。
Props允許將變量傳遞給子節點,當值發生更改時,它們會在子節點中自動更新,如Listing 1所示。
Listing 1. Props (class-based):
function App(){
return <div>
<AppChild name="Matt" />
</div>
}
function AppChild(props){
return <span>
My name is {props.name}
</span>
}
ReactDOM.render(<App />, document.getElementById('app'));
Listing 1顯示了如何在基于函數的組件樹中處理props。這個過程與類類似。這個基于函數的示例展示了函數樣式的更精簡的語法。
帶功能道具的子-父組件
Listing 1允許將值從父級傳遞給子級。當子節點需要更新父節點的變更時,它們不能僅修改屬性。
如果你試圖直接修改子進程的prop,你會在控制臺中看到以下類型的錯誤:
Uncaught TypeError: Cannot assign to read only property 'foo' of object '#<Object>'
相反,父進程可以傳入一個功能性道具,子進程可以調用這個函數。這種功能道具是一種面向事件的編程。您可以在Listing 2中看到這一點。
Listing 2. Functional props
function App(){
const [name, setName] = React.useState("Matt");
return <div>
<AppChild name={name} onChangeName={()=>{setName("John")}}/>
</div>
}
function AppChild(props){
return <span>
My name is {props.name}
<button onClick={props.onChangeName}>Change Name</button>
</span>
}
ReactDOM.render(<App />, document.getElementById('app'));
Listing 2介紹了用于管理狀態的useState。這是一個簡單的機制。functional prop的本質是當按鈕被點擊時,App組件傳入的函數就會被執行。這樣,就實現了子-父通信。
總的來說,要記住的概念是:道具流向子級,事件流向父級。這是一個有價值的設計原則,有助于保持應用程序的組織性和可管理性。
向父級傳遞信息
通常情況下,子組件需要隨它們的事件一起傳遞參數。這可以通過向函數道具回調添加參數來實現。如Listing 3所示。
function App(){
const [name, setName] = React.useState("Matt"); //test
return <div>
<AppChild name={name} onChangeName={(newName)=>{setName(newName)}}/>
</div>
}
function AppChild(props){
return <span>
My name is {props.name}
<button onClick={()=>props.onChangeName("Bill")}>Change Name</button>
</span>
}
ReactDOM.render(<App />, document.getElementById('app'));
注意 Listing 3中的 onClick={()=>props.onChangeName("Bill")}行。這里,我們使用箭頭語法創建一個匿名函數,其中包含我們想要的參數。傳遞一個由組件本身修改的變量也很簡單,語法如下:onClick={(myVar)=>prop . onchange (myVar)}。
順便說明一下,作為事件處理程序的內聯箭頭函數有時會因為性能問題而受到批評,盡管這可能被夸大其詞。
功能道具和React Router
另一個重要的用例是在 React Router 之間傳遞參數。Listing 4提供了如何實現這一點的示例。
Listing 4. Passing functional props through Router
// In the route definition:
<Route path=’/foopath’ render={(props) => <Child {…props} />} />
// In the child component:
<Route appProps={{ onTitleChange }} />
從本質上講,Listing 4通過覆蓋路由的呈現方式允許直接傳遞屬性。
同級溝通
到目前為止,我們看到的特性提供了處理同級通信的能力。這在React文檔中被稱為“提升狀態”。
這里的思想是,當組件樹的同一級別的子組件必須共享狀態時,該狀態將被推入父組件。然后父級通過道具將狀態分享給需要它的子級。子節點引發事件以更新父節點的狀態,這將自動在共享屬性中反映出來。
React Context API
React本身提供的另一個選項是Context API。Context API被設計用來管理簡單的、有全局意義的值。也就是說,這些值被應用程序中的許多組件使用。
文檔中給出的示例是一個主題設置。許多組件將會對這種設置感興趣(為了反映適當的主題),這與道具一起傳遞非常困難。
Context API不用于處理復雜的應用程序數據,它是專門針對在深度嵌套的組件中避免復雜的道具處理的。Listing 5給出了一個簡單的示例。
Listing 5. Context API
// defining the context value
<ThemeContext.Provider value="dark">
// Consuming the context value later on
<Button theme={this.context} />;
Redux的集中狀態
更復雜的應用程序可能需要更復雜的狀態架構。在React中處理這個問題最常見的庫仍然是Redux。Redux不僅僅是一個集中式存儲,它更是一個自以為是的結構化事件系統。
Redux的核心思想是,組件通過稱為dispatchers的特殊對象引發事件(在Redux中稱為動作)。這些動作事件由reducer觀察到,然后reducer將動作應用到狀態。然后,視圖中的組件會自動更新以反映狀態。
從這段簡短的描述可以看出,Redux為您的應用程序引入了相當多的復雜性和正式性。在使用Redux時,這應該與結構化和可理解性的好處進行謹慎的平衡。
還有其他管理集中商店的方法,包括MobX等。盡管這些解決方案可能比Redux有優勢,但必須權衡Redux的流行所帶來的優勢,即熟悉度和了解它的開發人員的可用性。
React通過props和function props提供了非常強大和簡單的組件交互。在更大,更復雜的應用程序中,這種方法可能會崩潰。利用諸如Context API和Redux之類的更復雜的選項可以解決這些更復雜的需求。
【51CTO譯稿,合作站點轉載請注明原文譯者和出處為51CTO.com】