INTRO

JavaScript's popular React library is known for its unopinionated nature.

No matter how you view React, there is no denying that it is hands-off approach to how developers should build their applications, giving developers and developer teams the freedom to build the apps the way they want.

As you study other React applications and work on different React applications built with different teams, you notice some common design patterns.

Let's take a look at a popular design pattern for building React applications, you are gonna love it.

Presentation Components

The look and feel of the UI depends on these components. Besides displaying data, they have no dependencies within the application. Consider a list:

const ListOfItems = (props) => {     return (     <ul>         {props.items.map((item) => (         <li key={item.id}>             <a href={item.url}>{item.name}</a>         </li>         ))}     </ul>     ); }; 

It is only responsible for displaying the data passed as props on the User interface in the example above. These components can be written as class components or as stateless functional components that can be tied to UI state

class TextInput extends React.Component {   constructor(props) {     super(props);     this.state = {       value: null     };   }   render() {     return (       <input         value={this.state.value}         onChange={(e) => this.setState({ value:          e.target.value })}       />     );   } } 

Managing its state in the example above is the responsibility of the TextInput class component.

Container Components

The Container components have a greater impact on the way things work than Presentational components. They typically contain presentation methods and methods for the lifecycle. They also fetch data.

class SeriesContainer extends React.Component {       constructor(props) {         super(props);         this.state = {           series: [],           loading: false,           error: ""         };       }       componentDidMount() {         this.setState({ loading: true, error: "" });         fetch("https://api.tvmaze.com/schedule/web?date=2020-05-29")           .then((res) => res.json())           .then((data) => this.setState({ loading: false, series: data }))           .catch((error) =>             this.setState({ loading: false, error: error.message || error })           );       }       render() {         const { loading, error, series } = this.state;         return (           <div>             <h1> Tv Series </h1>             {loading && <p>Loading...</p>}             {!loading && series && <ListOfItems items={series} />}             {!loading && error && <p>{error}</p>}           </div>         );       }     } 

In the example above, we created a SeriesContainer component that fetches data from an API when it mounts. Furthermore, that data is passed to the presentational component ListOfItems. This pattern has the advantage of separating concerns and reusing components. The ListOfItems presentational component is not closely coupled with the SeriesContainer, so any Container component can use it to display data

Final take away

Dan Abramov came up with this design pattern to distinguish presentational components from container components. The presentational ones are responsible for the look, while the container ones are in charge of managing the state. Despite being more popular before, you can still use this pattern wherever you see fit.