In React, do you have a file with a lot of code, both reading and processing of application data and displaying data, and each component cannot be reused?
First let’s look at an example of a container component with a presentation component.
class TodoList extends React.Component{
constructor(props){
super(props);
this.state ={
todos:[]
}
this.fetchData = this.fetchData.bind(this);
}
componentDidMount(){
this.fetchData();
}
fetchData(){
fetch('/api/todos').then(data =>{
this.setState({
todos:data
})
})
}
render(){
const {todos} = this.state;
return (<div>
<ul>
{todos.map((item,index)=>{
return <li key={item.id}>{item.name}</li>
})}
</ul>
</div>)
}
}
Copy the codeAs you can see, there is no way to reuse this example, because both the request and presentation of the data are done in one component. To reuse the component, we need to separate the presentation component from the container component.
The specific code is as follows:
Class TodoList extends React.Component{constructor(props){super(props); }render(){
const {todos} = this.props;
return (<div>
<ul>
{todos.map((item,index)=>{
return<li key={item.id}>{item.name}</li>})} </ul> </div>)} constructor(props){ super(props); this.state = { todos:[] } this.fetchData = this.fetchData.bind(this); }componentDidMount(){
this.fetchData();
}
fetchData(){
fetch('/api/todos').then(data =>{
this.setState({
todos:data
})
})
}
render() {return (<div>
<TodoList todos={this.state.todos} />
</div>)
}
}
Copy the codeWhen we separate components into container components and presentation components, you will find that they are easy to reuse.
Presentational Component
- Focus on the presentation (appearance) of the page
- The interior can contain presentation and container components, usually with some of their own DOM tags and styles.
- It is usually possible to include other components in this.props. Children mode.
- There are no dependencies on other parts of the application, such as Flux operations or stores.
- Don’t worry about how the data is loaded and changed.
- Only props can be used to receive data and perform callbacks.
- Few have their own state, and those that do are used to show UI state.
- Is written as a functional component unless the component needs its own state, lifecycle, or performance tuning.
Example:
The List Page, the Header, Sidebar, the UserInfo
Container Component
- How does the application work
- The interior can contain container components and presentation components, but usually doesn’t have any DOM tags of its own, except for some wrapped divs, and never has any styles.
- Provide data and behavior to other presentation components or container components.
- Invoke the Flux operations and provide them as callback functions to the presentation component.
- They tend to be stateful because they tend to act as data sources
- It is usually generated using higher-order components, such as Connect () for React Redux, createContainer () for Relay, or container.create () for Flux Utils, rather than written by hand.
Example:
UserPage, FollowersSidebar, StoryContainer, FollowedUserList
Advantages (Benifit)
- Better separation of presentation and container components helps to better understand the application and UI
- High reuse, demonstrating that components can be used with multiple different data sources.
- Presentation components are your palette and can be placed on separate pages, allowing designers to tweak the UI without impacting the application.
- This forces you to extract “layout components” such as sidebars, pages, context menus, and so on and use this.props. Children instead of copying the same markup and layout across multiple container components.
When to introduce container components
I recommend that you start creating components using only presentation components, and eventually realize that you pass a lot of props to intermediate components that don’t use the props they received, just pass them down. When the child components need more data, you need to reconfigure the intermediate components. This is where the container component comes in. Using the container component approach, you can pass data and behavior to leaf components through props without having to bother with some unrelated intermediate components.
It’s a refactoring process, so you don’t have to get it right the first time. When you try this model. You’ll have an intuitive sense of when to extract as container components. Just as you know when to extract a function
dichotomy
It’s important to understand that the difference between a container component and a presentation component is not a technical one, but a purpose one.
In contrast, here are a few related (but different) technical differences:
-
γ δΎ γ Stateful and Stateless:
Container components tend to be stateful, and presentation components tend to be stateless. This is not a hard and fast rule, because both container components and presentation components can be stateful.
-
Classes and Functions:
Components can be expressed as classes or functions. Function components are simple to define, but they lack some functionality that is currently available only for classes. Although function components have many limitations, they are still used today because they are easy to understand and are recommended without the need for their own state, Lifecycle hooks, or performance optimizations. These only apply to class components.
// We can rewrite the above presentation component as a function component as followsfunction TodoList(props){
return (<div>
<ul>
{props.todos.map((item,index)=>{
return <li key={item.id}>{item.name}</li>
})}
</ul>
</div>)
}
Copy the codeIf you don’t know the difference between a function component and a class component, check out the React website
-
2. Pure and Impure:
Purity: what is input is output, and there is no change in it. They can be defined as classes or functions, they can be stateless or stateful. Another important aspect of pure components is that they don’t rely on depth changes in props or state, so their rendering performance can be optimized by shallow comparisons in shouldComponentUpdate () hooks. Currently only classes can define the shouldComponentUpdate () method.
Both presentation and container components have the above binary properties. In my opinion, presentation components tend to be pure functions with no state and container components tend to be stateful pure classes. This is a personal opinion and not a rule.
Don’t make it a dogma to separate container components from presentation components when they are not important or difficult to tell apart. If you are not sure whether a component is a container component or a presentation component, just leave it as a presentation component for now.
https://medium.com/@dan_abramov/ smart-and-dumb-component-7ca2f9a7C7d0