container presentational pattern

Interested in our next book? Learn more about Building Large-scale JavaScript Web Apps with React

Design Pattern

Container/Presentational Pattern

In React, one way to enforce separation of concerns is by using the Container/Presentational pattern . With this pattern, we can separate the view from the application logic.

Let’s say we want to create an application that fetches 6 dog images, and renders these images on the screen.

Ideally, we want to enforce separation of concerns by separating this process into two parts:

• Presentational Components : Components that care about how data is shown to the user. In this example, that’s the rendering the list of dog images .
• Container Components : Components that care about what data is shown to the user. In this example, that’s fetching the dog images .

Fetching the dog images deals with application logic , whereas displaying the images only deals with the view .

Presentational Component

A presentational component receives its data through props . Its primary function is to simply display the data it receives the way we want them to, including styles, without modifying that data.

Let’s take a look at the example that displays the dog images. When rendering the dog images, we simply want to map over each dog image that was fetched from the API, and render those images. In order to do so, we can create a functional component that receives the data through props , and renders the data it received.

The DogImages component is a presentational component. Presentational components are usually stateless: they do not contain their own React state, unless they need a state for UI purposes. The data they receive, is not altered by the presentational components themselves.

Presentational components receive their data from container components .

Container Components

The primary function of container components is to pass data to presentational components, which they contain . Container components themselves usually don’t render any other components besides the presentational components that care about their data. Since they don’t render anything themselves, they usually do not contain any styling either.

In our example, we want to pass dog images to the DogsImages presentational component. Before being able to do so, we need to fetch the images from an external API. We need to create a container component that fetches this data, and passes this data to the presentational component DogImages in order to display it on the screen.

Combining these two components together makes it possible to separate handling application logic with the view.

In many cases, the Container/Presentational pattern can be replaced with React Hooks. The introduction of Hooks made it easy for developers to add statefulness without needing a container component to provide that state.

Instead of having the data fetching logic in the DogImagesContainer component, we can create a custom hook that fetches the images, and returns the array of dogs.

By using this hook, we no longer need the wrapping DogImagesContainer container component to fetch the data, and send this to the presentational DogImages component. Instead, we can use this hook directly in our presentational DogImages component!

By using the useDogImages hook, we still separated the application logic from the view. We’re simply using the returned data from the useDogImages hook, without modifying that data within the DogImages component.

Hooks make it easy to separate logic and view in a component, just like the Container/Presentational pattern. It saves us the extra layer that was necessary in order to wrap the presentational component within the container component.

There are many benefits to using the Container/Presentational pattern.

The Container/Presentational pattern encourages the separation of concerns. Presentational components can be pure functions which are responsible for the UI, whereas container components are responsible for the state and data of the application. This makes it easy to enforce the separation of concerns.

Presentational components are easily made reusable, as they simply display data without altering this data. We can reuse the presentational components throughout our application for different purposes.

Since presentational components don’t alter the application logic, the appearance of presentational components can easily be altered by someone without knowledge of the codebase, for example a designer. If the presentational component was reused in many parts of the application, the change can be consistent throughout the app.

Testing presentational components is easy, as they are usually pure functions. We know what the components will render based on which data we pass, without having to mock a data store.

The Container/Presentational pattern makes it easy to separate application logic from rendering logic. However, Hooks make it possible to achieve the same result without having to use the Container/Presentational pattern, and without having to rewrite a stateless functional component into a class component.Note that today, we don’t need to create class components to use state anymore.

Although we can still use the Container/Presentational pattern, even with React Hooks, this pattern can easily be an overkill in smaller sized application.

• Presentational and Container Components - Dan Abramov

DEV Community

Posted on Jun 3, 2023 • Updated on Jun 6, 2023

Mastering React Patterns: Presentational and Container Components

Introduction: In the world of React development, understanding patterns and best practices is crucial for building robust and maintainable applications. One essential pattern is the separation of components into Presentational and Container components. In this article, we will delve into the concepts of Presentational and Container components, explore their benefits, and provide real-world examples of how they can be used effectively.

Target Audience:

This article is suitable for both beginner and experienced React developers who want to enhance their understanding of React patterns and improve the structure of their applications.

Learning Objectives:

By the end of this article, you will gain the following skills:

Recognize the role of Presentational components and Container components.

Create Presentational components and Container components.

Understand how to use Presentational and Container components in a React application.

Comprehend the benefits and use cases of each component type.

Apply best practices for structuring React applications.

Presentational Components:

Presentational components focus on the visual representation of data and are responsible for how things look in a React application. They have the following characteristics:

Concerned with the user interface and rendering data.

Stateless components with no or minimal internal state.

Receive data exclusively through props.

Usually implemented as functional components.

Promote code reusability and maintainability.

Emphasize separation of concerns, readability, and testability.

Prefer composition over inheritance.

Follow declarative programming principles.

Encourage immutability for easier reasoning and preventing rendering errors.

Let's explore an example of a Presentational component:

In the above code, we have a Button component that represents a reusable button with a click event handler, and a Persons component that displays a list of names. These components receive data through props and are focused on rendering the UI.

Container Components:

Container components handle the logic and state management of a React application. They orchestrate the interaction between Presentational components and manage the flow of data. Key characteristics of Container components include:

Focus on the functionality and behavior of the application.

Render Presentational components and pass them data and callbacks.

Maintain the application's state and manage data flow.

Enable code reuse and maintainability.

Emphasize separation of concerns and readability.

Ease reasoning about component dependencies.

Let's examine an example of a Container component:

In this example, the ClickCounter component maintains its own state and renders the Button component as a child. The Form component manages form input, state, and data flow, rendering the Button and Persons components as children. The Container components handle the application logic while utilizing Presentational components for UI rendering.

Real-World Use Cases:

To illustrate the benefits of Presentational and Container components, let's consider a real-world scenario. Suppose you are building a complex application that requires displaying a list of products. The ProductList component, responsible for rendering the list, can be a Presentational component that receives the product data as props. The ProductPage component, responsible for fetching the product data and handling user interactions, can be a Container component that manages the state and data flow, rendering the ProductList component.

By separating concerns and encapsulating logic, Presentational and Container components promote reusability, maintainability, and code readability.

Best Practices and Tips:

To effectively implement Presentational and Container components in your React applications, consider the following best practices:

Maintain a clear separation between Presentational and Container components.

Keep Presentational components as simple as possible, focusing on rendering UI based on props.

Offload business logic and state management to Container components.

Utilize the props and callback functions to pass data and handle user interactions between components.

Follow naming conventions and folder structure that align with the component types.

Write comprehensive tests for both Presentational and Container components.

Conclusion:

In this article, we explored the concepts of Presentational and Container components, their characteristics, benefits, and use cases. By implementing these patterns in your React applications, you can achieve better code organization, maintainability, and reusability. Understanding the separation of concerns between Presentational and Container components empowers you to build scalable and well-structured React applications. Happy coding!

Top comments (0)

Templates let you quickly answer FAQs or store snippets for re-use.

Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink .

Hide child comments as well

For further actions, you may consider blocking this person and/or reporting abuse

Mastering Docker: A Journey Through Essential Practices 🚀

Labby - Jun 29

An Introduction to Frontend Technologies: HTML, CSS and React JS

Olamide Femi-Babatunde - Jun 29

Nextjs custom server with fastify

Marco - Jun 29

15 Funniest and Hilarious Python Coding Memes

CodeItBro - Jun 29

We're a place where coders share, stay up-to-date and grow their careers.

Container/Presentational Pattern

Enforce separation of concerns by separating the view from the application logic.

We can use the Container/Presentational pattern to separate the logic of a component from the view. To achieve this, we need to have a:

• Presentational Component, that cares about how data is shown to the user.
• Container Component, that cares about what data is shown to the user.

For example, if we wanted to show listings on the landing page, we could use a container component to fetch the data for the recent listings, and use a presentational component to actually render this data.

Implementation #

We can implement the Container/Presentational pattern using either Class Components or functional components.

Tradeoffs #

Separation of concerns : Presentational components can be pure functions which are responsible for the UI, whereas container components are responsible for the state and data of the application. This makes it easy to enforce the separation of concerns.

Reusability : We can easily reuse the presentational components throughout our application for different purposes.

Flexibility : Since presentational components don't alter the application logic, the appearance of presentational components can easily be altered by someone without knowledge of the codebase, for example a designer. If the presentational component was reused in many parts of the application, the change can be consistent throughout the app.

Testing : Testing presentational components is easy, as they are usually pure functions. We know what the components will render based on which data we pass, without having to mock a data store.

Not necessary with Hooks : Hooks make it possible to achieve the same result without having to use the Container/Presentational pattern.

For example, we can use SWR to easily fetch data and conditionally render the listings or the skeleton component. Since we can use hooks in functional components and keep the code small and maintainable, we don't have to split the component into a container and presentational component.

Overkill : The Container/Presentational pattern can easily be an overkill in smaller sized application.

We have a Listings component that both contains the fetching logic, as well as the rendering logic. In order to make the fetching logic more reusable, we can split this component up into a container and presentational component.

Challenge #

Remove the data fetching logic from the Listings component, and move this to a separate ListingsContainer component located in /components/container/Listings.tsx

On This Page

• Implementation

How-To Geek

What are presentational and container components in react.

Your changes have been saved

Email Is sent

Please verify your email address.

You’ve reached your account maximum for followed topics.

Today's NYT Connections Hints and Answer for June 30 (#385)

Top tips for creating quality meeting minutes in word, 20+ surprisingly good-looking games you can play on a potato gaming pc, quick links, is there any state, looking at examples, characteristics of each type, advantages of separating presentational and container components.

React has a component-based architecture that encourages you to split your codebase into reusable units of functionality. Not all components are created equal though. Let's look at the differences between two common types, Presentational and Container (also known as "Stateful") components.

To begin with, it should be stressed that these terms don't refer to any specific React feature. They describe a style of writing React components which helps to maintain modularity and separate out concerns. The existence of the two component types arises from choices made in your codebase.

There's only one distinguishing factor: container components have state and presentational components do not. In practice, this means that a container component always makes a call to React's

method. A presentational component will never make use of state.

Here's a simple presentational component:

import React from "react";

class Presentational extends React.Component {

return <h1>{this.props.title}</h1>;

export default Presentational;

The component is extremely simple. It renders a single

tag which displays text passed into the component via its

prop. Let's now look at a stateful container component:

class Container extends React.Component {

constructor(props) {

super(props);

this.state = {

time: (new Date()).toString()

componentDidMount() {

setInterval(() => {

this.setState({time: (new Date()).toString()});

return <h1>{this.state.time}</h1>;

export default Container;

The container component's

method is almost identical to that in the presentational component. The difference is the container component sources its text from inside itself, instead of relying on an outside value passed in as a prop.

Each second, the container component calls

to update the

key in its state. This causes React to re-render the component and display the new time. Our container possesses its own state.

Several unique characteristics tend to arise within both presentational and container components. Looking at presentational components first, the bulk of their code is likely to exist within the

method. They'll contain very little logic as their behaviour is defined by the outside world.

Presentational components are blissfully unaware of where their data is coming from. They don't know when (or whether) it will change. Some examples may not even accept props. Here's a decorational element which simply renders a specific image file:

Container components are much the opposite of their presentational counterparts. You'll typically find most of your site's logic ends up within a container component. The

method may be comparatively short as you'll be spending many more lines fetching data from external sources, transforming it to suit your needs and then storing it into state.

A container component's

method could consist of a single line that renders a presentational component. You've now got strong separation of concerns, with both components having a distinct role that fully respects the other's. The container component sources the data; the presentational component puts it on the screen.

Here's how this looks in practice:

const View = ({title, body}) => (

<div>

<h1>{title}</h1>

<p>{body}</p>

</div>

class BlogPostComponent extends React.Component {

fetch("/blog-post.json")

.then(response => response.json());

.then(blog => this.setState({blog}));

title={this.state.blog.headline}

body={this.state.blog.content} />

is our container component. It loads a post over the network. The data then gets given to the

component for rendering.

doesn't care where it gets its data from - in the future, we could reuse it to display posts fetched from a third-party API such as Facebook or Twitter.

Container components are so called because they tend to encapsulate entire functional areas of your app. They make your project work and represent the app's backend systems.

In a real codebase,

would have even more responsibility. It would need to track whether the post has loaded and handle errors during the network fetch. Consequently, the

method may incorporate some basic logic to alter what gets displayed - either an error message, a progress bar or our presentational

component. Presentational components never have any greater responsibility than rendering a specific section of the UI into the DOM.

Using this pattern helps you to organise your codebase and prevents components from becoming too unwieldy. Although it's not a hard-and-fast rule, diligent separation of the two types improves maintainability as your project's component count grows.

Try to look for opportunities to refactor as a container component's

method grows. It's likely you could take much of its contents and split it into a new presentational component. This makes it easier to reuse the presentational code in the future. It ends up self-contained and capable of operating independently of any specific data source.

Stateful components are less likely to be reused. Non-trivial behaviours naturally accumulate within them, resulting in dependencies on the outside world. That's not to say they can't be reused though - a two-stage confirmation button will contain internal state (to determine whether to display "Reset User's Password" or "Are You Sure?") but will also be deployed throughout your codebase.

Perhaps more than anything, intentionally distinguishing between Presentional and Container components keeps you aware of where your application's state lies. Minimising the number of components with state contributes towards a maintainable codebase and helps to separate concerns.

If you can't decide whether a component should hold state, keep coding and refactor later - it's probably too early in your project's lifecycle to know where the complexity (and hence the state) will congregate.

• Programming

An Intro to Container-Presenter Design Patterns in React

Too Long; Didn't Read

People mentioned.

Company Mentioned

The Container-Presenter design pattern was initially coined by  Dan Abramov  and has been highly adopted due to the rather clean implementation of the  Separation of Concerns  principle, as well as the elegant way it deals with complex ‘stateful’ logic and the consistency it maintains throughout an application.

Container-Presenter Pattern Philosophy

The philosophy behind the Container-Presenter design pattern is rather simple; components are split up into 2 categories based on a couple of loosely-defined factors:

Container Components

• Presentation/Presentational Components

How to distinguish between Container & Presenter Components

It’s important to understand that the distinction between the presentational components and the containers is not to be made from a technical standpoint, but rather, from the standpoint of the purpose that they aim to serve.

According to  Dan Abramov , there is some misunderstanding between various common technical distinctions, which shouldn’t necessarily be the driving factor when deciding what is and what is not a Container/Presenter Component:

Stateful and Stateless

Some components use React setState() method and some don’t. While container components tend to be stateful and presentational components tend to be stateless, this is not a hard rule. Presentational components can be stateful, and containers can be stateless too.

Classes and Functions

Since React 0.14 , components can be declared both as classes and as functions. Functional components are simpler to define but they lack certain features currently available only to class components. Some of these restrictions may go away in the future but they exist today. Because functional components are easier to understand, I suggest you to use them unless you need state, lifecycle hooks, or performance optimizations, which are only available to the class components at this time.

Pure and Impure

People say that a component is pure if it is guaranteed to return the same result given the same props and state. Pure components can be defined both as classes and functions, and can be both stateful and stateless. Another important aspect of pure components is that they don’t rely on deep mutations in props or state, so their rendering performance can be optimized by a shallow comparison in their  shouldComponentUpdate() hook . Currently only classes can define shouldComponentUpdate() but that may change in the future.

He strives to make it clear that there is a difference between the afore-mentioned dichotomies and where the line is actually drawn between what constitutes a Presentation or Container Component ( technical  vs  purpose  reference).

There are certain observations made by him from his experience, such as the fact that  Presentational Components tend to be pure, stateless functions , whilst  Container Components tend to be pure, stateful classes :

Both presentational components and containers can fall into either of those buckets. In my experience, presentational components tend to be stateless pure functions, and containers tend to be stateful pure classes. However this is not a rule but an observation, and I’ve seen the exact opposite cases that made sense in specific circumstances.

Ultimately, his last comment on this subject enforces the fact that the line between Presentation & Container components is to be drawn whenever the purpose of a certain component or block of components is clear:

Don’t take the presentational and container component separation as a dogma. Sometimes it doesn’t matter or it’s hard to draw the line. If you feel unsure about whether a specific component should be presentational or a container, it might be too early to decide. Don’t sweat it!

Benefits of the Container-Presenter Pattern

• Good Separation of Concerns
• Ease of reuse of components throughout the application, which not only speeds up development time but also improves the visual consistency between views/layouts
• More consistent applications
• Easier understanding of the project structure

Characteristics:

• Concerned with how data is processed
• Don’t usually have markup language as a direct child (They usually nest other components within with the use of wrapper divs or other semantic tags)
• Are often stateful (Store and handle React & Redux/Context/MobX state)
• Provide data & behavior to nested components (Container or Presenter) through props (data & callbacks)
• Views (Pages) , which would hold higher-up data and distribute it throughout the page’s components: Home page, Login page, Register page, blog post page, etc.
• CommentsSection ,  would be a component that fetches and stores comments in regards to a post or an article, and would distribute the contents throughout a generic list component, or map that data through a list of  Comment components
• PopularTopics , which would be a synced/real-time list of popular topics in regards to a Social Media platform that constantly fetches data in real-time to provide insightful information in regards to the most popular/relevant topics on the platform

Presentation Components

Are concerned with how things look

Depend exclusively on passed down data & callbacks (via props)

They mostly contain UI-related state (isDropdownOpen, isPopoverOpen, etc.)

Aren’t concerned with how data is loaded or mounted

• Navbar , a generic navigation bar component that has some predefined data (Links), or could have some nested dynamic links (Possibly dynamic relevant categories) which might be encapsulated within a Container Component
• Sidebar , similar to the previously mentioned  Navbar  component
• List , a generic component that takes an array as a prop and renders a list; its only concern is rendering the data accordingly (Semantics + Styles)

A simple and appropriate example of when and how to split up a component according to the Container/Presenter pattern could be found  here .

You might also find these articles useful:

• React Hooks Series
• What are Higher-Order Components (HoCs) in React?
• React, Gatsby, Next.js. What to choose for your next app’s Frontend?
• How to simplify your life as a React Developer

This article was originally published here.

About Author

THIS ARTICLE WAS FEATURED IN ...

RELATED STORIES

Container/Presentation Pattern

Lydia Hallie

Check out a free preview of the full A Tour of JavaScript & React Patterns course

The "Container/Presentation Pattern" Lesson is part of the full, A Tour of JavaScript & React Patterns course featured in this preview video. Here's what you'd learn in this lesson:

Lydia explains how the container presentation pattern enforces a separation of concerns by abstracting the view from the application logic. Presentational components focus on how the data is shown to the user. Container components are responsible for the data passed to the presentational component.

Transcript from the "Container/Presentation Pattern" Lesson

[00:00:00] >> Well, I think that kind of concludes the whole design patterns section of this workshop. So we talked about the module pattern, singleton pattern, proxy pattern, observer pattern, factory pattern and prototype pattern. But the next one is not so much on like the JavaScript design patterns are more on react patterns.

[00:00:15] And these, I'll talk about how we can use different components, how their data is shared and just their relationship to each other. So, first let's talk about the Container Presentational Pattern. So with the container presentational pattern, we essentially have two components. I'm just going to make this real quick.

[00:00:32] We have a container components, which is a component that's solely responsible for retrieving data. And then we have a presentational component which is solely responsible for showing data, rendering data. So because the container component is only fetching data, it usually doesn't like render any styled components, it just renders the presentational components.

[00:00:55] So, when we look at the implementation here, this is using React hooks. By the way most of my examples I will use React hooks. I will also cover the hooks pattern so you can kind of see how the different patterns relate to how we can implement hooks nowadays.

[00:01:10] So I do like assume that you know how hooks work. But if there are any questions about, like these basic like use of XQ state hooks, of course, do let me know. Yeah, so in this implementation, we have the listings container components and container components responsible for fetching data.

[00:01:24] And we can see that here because it's fetching, like listings from an API or like a CMS sets the state to have those listings and then passes them down to the listings component. Are like that the presentational component. I feel like this should have been the presentational component this may be a typo in my end.

[00:01:41] So what we have here is we have that listing container component that you saw before. So this one fetches listing from our API passes down to this listings component which here's just called listings which is probably why I made the mistake. But this is a presentational components. So in here it retrieves this the listings as props and the only thing he cares about is rendering that data in a styled way.

[00:02:05] I'm just getting roads screenly. Yeah, so that was the container presentational pattern. Now, there are many trade offs or benefits to using this pattern. As you can see, there's definitely a separation of concerns. Because the presentational components can be just responsible for the UI. Like just the styling of how are we going to render that data.

[00:02:29] Whereas like container components are just responsible for the state of the data of the application. Yeah, it's also super easy that way to like reuse these presentational components. Maybe they are using like different data sources different data but they're render the content the same way. So we can reuse this presentational components even though they like retrieve different data from props.

[00:02:53] It's also nice if you have many presentational components that don't really touch the fetching logic. So, if you just care about the design or you maybe you're a designer, you don't really know what gets returned from the API. You can make a lot of changes to these presentational components without maybe accidentally like making a mistake with that data how data is fetched and all that stuff.

[00:03:14] Now, of course like Hooks we will see later how Hooks kind of replace this pattern a lot of the time we don't really necessarily have to use this container presentational pattern anymore. Or as much as we had to when we used classes just because it was like more work to like create a class all that stuff but we will see that a bit later.

[00:03:31] All right, so the exercise even though I kind of already showed you the solution here but we see an exercise here. So right now, we just have one component it's called the listings components. But then this component, it's not split up into two separate parts. We don't have like a container part or a presentational part, it's just one big component.

[00:03:50] So what I would like you to do is to split this up into two components, a container components and a presentational components. So the container component responsible for fetching the data and then the presentational components responsible for showing the data. Now, you can I guess already kind of see I've already created the folder structure for you.

[00:04:09] So you have like presentational here and then container here. So you can just type the container code right in the container listings file.

Learn Straight from the Experts Who Shape the Modern Web

• In-depth Courses
• Industry Leading Experts
• Learning Paths
• Live Interactive Workshops

Container/presentational component pattern - and how it can be replaced with hooks

Last updated on January 2020

We often end up with huge apps that mutate state, run business logic, make API calls, and manage the UI rendering. This can sometimes be too much, with blurry separation of concerns. One pattern to address this is the container/presentational pattern - although I believe now it can be replaced with hooks.

• Introduction to the container/presentational pattern

This is a well known pattern, but the container/presentational pattern is also known as the smart/dumb or skinny/smart pattern.

A common pattern seen in React (and Vue) applications is the container/presentational pattern (also known as smart/dumb ). Even if you are not familiar with the name, you have almost definitely seen/implemented versions of this in your apps.

I'll go through it with a very simple example... I'll use an example with JSX / react, but the idea is the same for Vue apps.

I'll keep referring to "business logic" but my example is so simple there is none, except grabbing data from an API.

Imagine we had that previous component. It is a very simple example for this blog post, but you probably see versions on it in your apps.

• Some state logic
• Some logic to communicate with outside sources (API endpoint)
• and rendering logic.
• Example of a container/presentational component:

Converting this to container/presentational would look something like this:

• Ok, so what is so special about it?

On the face of it there is not much different.

But now we have a clear separation:

• container is where we can run business logic, update state, handle events
• and the presentational which should normally be stateless and is concerned only with the UI.
• Advantages of container/presentational (aka smart/dumb)

For larger apps this can make it easier to manage your application's state/business logic while decoupling it with the UI (presentational).

Its (almost) always a good idea to have nice boundaries and separation of concerns, and splitting up business logic (and state) with the UI is a good example.

Testing is also easier as you can test the business logic with a mocked UI (presentational), and test the UI by just passing in expected props.

It can also mean more team members can easier work on different things without hitting as many merge conflicts (although I think this shouldn't be a primary reason for adopting this model).

You can often also find ways to easily reuse the presentational components.

Or you can have multiple presentational components, for example:

• How it can be replaced with custom hooks

Now that we have hooks (composition API in Vue), we can sometimes split it up like this:

• Have a single component, which is (mostly) concerned about UI
• But that component uses a custom hook (such as usePosts() ) that can handle all of your business logic and state.

Then we can easily modify and test the hook in isolation, and keep the component almost entirely focused on the UI.

We can also easily test the logic in the hook, or test just the UI by mocking the hook.

Following on from the basic example above, converting it to use custom hooks would look something like:

In this very simple example we can now easily test a lot of the business logic (in the hook) without worrying about the UI.

Although if testing it like that, its going to be testing implementation details and I think should be avoided if possible, but sometimes its just much easier to test a small unit (in this case - the hook) like this.

• Further resources
• Dan Abramov's post

Quick navigation

Understanding the Container Component Pattern with React Hooks

Jan 14, 2022 · 7 min read

The modern web development era offers a plethora of libraries and frameworks. These libraries and frameworks aim to help in rapid application development, better managing source code, speed and performance of the app, and many more.

React (aka React.js and Reactjs) is a JavaScript library that helps in building interactive user interfaces keeping the following aspects in perspective,

• The developer focuses on the states of the application and can develop a view for each of the states .
• The developer can create components to manage the states. It allows separating the presentational part from the complex business logic.
• Virtual DOM usage helps create an in-memory cache to detect and compute the changes, and selectively update the DOM instead of performing a complete re-render. It helps in speed and performance.

While the library provides many useful features, developers need to know how to apply the solution to the well-known problems. Over the years, React developers have solved the problem of clean code , re-usability , and keeping things simple. All these solutions evolved as patterns . In this article, we will discuss a helpful and widely used pattern in React: Container Component pattern.

The Container Component Pattern

The Container Component pattern(or simply Component pattern) ensures to separate the data fetching logic, managing state from the presentational part. The presentational part has got a dumb name, dumb component . It is because the responsibility of the presentational part is just to render the information passed to it. The smart work of data fetching, working on it, and state management occurs elsewhere.

Traditionally, we used JavaScript classes to create containers. With the advent of hooks in React, the developer community has moved towards function-based components. We will take an example to understand the Container Component pattern end to end using React hooks.

The Movie App

We will build a movie app to fetch the movie information using an API call. We will create the user interface to show the movie details upon receiving the information.

Inslallation and Setup

Please use the Create React App tool to create an application. Let’s call it movie-app .

Please note, You’ll need to have Node version >= 14.0.0 to run the above command successfully. Once done, please perform the following steps to run the app locally.

Change to the project directory

Run the app

You can also use yarn

You should get the app running @ http://localhost:3000/

For simplicity, we will keep the movie data in a JSON file. You can also use an actual movie API to fetch the information.

Please create a data folder under the src folder. Now create a file called movies.js file with the following content,

This is a list of movies to use as an example. Please feel free to update it based on your choices.

The Movie Container

Now create a movies folder under the src folder. We will keep all the movies-app related source files under this folder.

Create a file MovieContainer.js under the movies folder with the following content,

Let’s understand what is in the above code. It is a simple React functional component.

• We first import the movies data to use it.
• The fetchMovies method pretends to create an abstraction to get the data from a store. In our case, it is JSON coming from a file.
• We define the functional component MovieContainer . It logs the movies information on the browser console. It also renders a heading in the browser.
• Finally, we export the component to import and use it elsewhere.

We will now use this component in the App.js file so that any changes we make in it reflect immediately in the UI. Please open the App.js and replace the content of it with the following code,

Here we import the MovieContainer and render it. Please visit the app in the browser. You should see the heading Movie Container to confirm our changes are working so far!

Also, if you observe the browser’s console, you will find the movies JSON data logged there.

Let’s now show the movies information in the UI.

Showing the Movie Information

Next, we will use the movies data to construct the user interface that will show the movie information. We will leverage React Hooks to manage the state and lifecycle using functional components.

React Hooks are a great addition to the library that allows managing state and many other features without writing JavaScript classes. You can read about the motivation of introducing hooks in React from here .

For the movie-app , we will use two built-in React hooks.

useState : It helps in managing the local state so that React can preserve and use the state between re-renders. The useState hook returns the current state value and a function to update the state value. We can also pass the initial state value as a parameter to the useState() hook.

Learn more about this hook from here .

useEffect : The useEffect hook helps in performing side-effects. The side-effect can be anything responsible for changing the state of your application. A typical example of a side-effect is making an API call and changing the local state to preserve the response data.

Let us get back to the movies-app with everything we have learned about the above hooks. Move over to the MovieContainer.js file and import the useState and useEffect hooks.

Next, we will create a local state using the useState hook. Please add the following line in the MovieContainer component function.

Here we create a local state called movies initialized with an empty array([]). The setMovies is a method to update the movie’s information. We will do that as a side-effect inside the useEffect hook.

Please add the following code snippet after the useState code you have added previously.

Here we are getting the movies data(from the JSON) and updating the state (movies) using the setMovies() method. A couple of things to note here,

• The fetchMovies() method is an abstraction. Here we are fetching the local JSON data. We can change the method’s logic to fetch it from an actual API.
• The empty array([]) we pass to useEffect hook to inform React about calling the side-effect only once when the component loads. The effect doesn’t depend on any states to re-run again in the future.

Now let us show the movies data in the UI. To do that, please use the following JSX code in the return.

Great!!! Now our movie-app should render the movies data.

We see the data in the UI but the look-and-feel is not that great. Let us add some CSS to fix that. Please create file called movies.css under src/movies folder with the following content.

The final thing is to import the movies.css file into the MovieContainer.js file

Bingo!!! The movie-app UI looks much better now.

Here is the complete code of the MovieContainer.js file so far.

All the code we have written so far helps us show the movie information in the UI. We have accomplished our goal, but we have plenty of room for improvement.

• First, we have the data fetching and the presentation code mixed together. It means, if we want to use the same presentation logic elsewhere, we have to repeat it. We need to avoid this.
• Can we make the data fetching logic a bit more abstract so that any presentation can use this data in various formats?

We will use the Container Component pattern to make the first improvement. We will discuss the second improvement when discussing the Higher-Order component pattern in a future article.

The Container Component Pattern Kicks in

We separate the data fetching logic from the presentational logic with the Container Component pattern. We create as many dumb presentational components as required and pass data to them. Let’s apply this pattern to the movie-app .

The core presentation logic of the movie-app iterates through the movie information and creates UI elements for each movie. We can create a new presentation (dumb) component called Movie and pass each movie information.

Please create a file called Movie.js under the src/movies folder with the following content,

This presentational component takes the details of each movie as props and uses the values to create the UI presentations. Now we will use the Movie component into the MovieContainer component.

First, import the Movie component at the top section of the MovieContainer component.

Now replace the <li>...</li> section of the MovieContainer.js file with the following code,

That’s all. Now the MovieContainer component is much smaller than before. We have also separated out the presentation logic from the data fetching part. After the changes, here is the complete code of the MovieComponent.js file.

If we see it in a pictorial representation, it may look like this:

Do you think we should refactor the code a bit more to create another parent-level presentation component? Well, we can. We can create a presentation component called MovieList (taking the <ul>...</ul> part), and that can use the Movie Component. Finally, we can use the MovieList component in the MovieContainer . It may look like this:

It all depends on how far you think you should go keeping the re-usability and separation of concern in mind. I hope we understand the idea behind the Container Component pattern.

Open Source Session Replay

OpenReplay is an open-source, session replay suite that lets you see what users do on your web app, helping you troubleshoot issues faster. OpenReplay is self-hosted for full control over your data.

Start enjoying your debugging experience - start using OpenReplay for free .

As we mentioned before, the patterns are evolved from the solution of repeated problems in the past. You can choose to adopt, tweak, or even not use it.

A pattern such as Container Component pattern helps in achieving the principles of,

• Separation of Concern(SoC) by keeping the data fetching and presentation away from each other.
• Don’t Repeat Yourself(DRY) by providing us the ability to reuse a component multiple times in different places.

Like this one, we have other patterns like Higher-Order Component(HoC) pattern, Render Props, and many more. We will see them soon in the upcoming articles. Stay tuned.

You can find all the source code used in this article from here,

The movie-app project on GitHUb

Before we end…

I hope you found this article insightful and informative. My DMs are open on Twitter if you want to discuss further.

Let’s connect. I share my learnings on JavaScript, Web Development, and Blogging on these platforms as well:

Follow me on Twitter

Subscribe to my YouTube Channel

Side projects on GitHub

More articles from OpenReplay Blog

Feb 7, 2024, 9 min read

App timeout in React: A Comprehensive Guide

{post.frontmatter.excerpt}

Sep 19, 2023, 14 min read

Applying Design Principles in React

• React Native
• CSS Frameworks
• JS Frameworks
• Web Development
• React Tutorial
• React Introduction
• React Environment Setup

React Fundamentals

• ReactJS Babel Introduction
• ReactJS Virtual DOM
• React JS ReactDOM
• React Lists
• React Forms
• ReactJS Keys
• ReactJS Refs
• ReactJS Rendering Elements
• React Conditional Rendering
• React Components
• Code Splitting in React
• ReactJS | Components - Set 2
• ReactJS Pure Components
• ReactJS Functional Components
• React Lifecycle
• Differences between Functional Components and Class Components

ReactJS Container and Presentational Pattern in Components

React props & states.

• ReactJS Methods as Props
• ReactJS PropTypes
• ReactJS Props - Set 1
• ReactJS Props - Set 2
• ReactJS Unidirectional Data Flow
• ReactJS State
• ReactJS State vs Props
• Implementing State in React Components
• React Hooks
• React useState Hook
• ReactJS useEffect Hook
• Context in React
• React Router
• React JS Types of Routers
• ReactJS Fragments
• Create ToDo App using ReactJS
• Create a Quiz App using ReactJS
• Create a Coin Flipping App using ReactJS
• How to create a Color-Box App using ReactJS?
• Dice Rolling App using ReactJS
• Guess the number with React

React Connection & Deployment

• How to Deploy Your React Websites on GitHub?
• How to Deploy React project on Firebase?
• How to deploy React app to Heroku?
• How to deploy React app to Surge ?
• How to deploy simple frontend server-less (static) React applications on Netlify

React Exercises

• React Exercises, Practice Questions and Solutions

React Questions

• How to connect Django with Reactjs ?
• 7 React Best Practices Every Web Developer Should Follow
• 8 Ways to Style React Components
• How to add Stateful component without constructor class in React?
• How to display a PDF as an image in React app using URL?
• React JS Toast Notification
• What is the use of data-reactid attribute in HTML ?
• How to zoom-in and zoom-out image using ReactJS?
• How to avoid binding by using arrow functions in callbacks in ReactJS?
• How to bind 'this' keyword to resolve classical error message 'state of undefined' in React?
• How to get the height and width of an Image using ReactJS?
• How to handle multiple input field in react form with a single function?
• How to handle states of mutable data types?
• How to change state continuously after a certain amount of time in React?
• How to change the state of react component on click?

In this article we will categorise the react components in two types depending on the pattern in which they are written in application and will learn briefly about these two categories. We will also discuss about alternatives to this pattern.

Presentational and Container Components

The type of components is decided by components pattern. If the component decides how the data will be presented on the screen it is called as presentational component . If the component focuses on what data is to be shown to the user then it is called as container component

We will discuss individually about these components in this article.

Presentational components:

• Mainly concerned with how things look.
• Have no major dependencies on the rest of the app.
• No connection with the specification of the data that is outside the component.
• Mainly receives data and callbacks exclusively via props.
• May contain both presentational and container components inside it considering the fact that it contains DOM markup and styles of their own.

Example: For example, the below code denotes a presentational component, and it gets its data from the props and just focuses on showing an element. 

Container components:

• Mainly concerned with how things work.
• May contain both presentational and container components but does not have DOM and markup of their own.
• Provide the data and behavior to presentational or other container components.
• Call flux actions and provides these as callbacks to the presentational component.

Benefits of Container/Presentational Pattern

• Creates pure functions
• Separates render and fetching logic
• Makes the components more reusable
• Testing the components is easier

Disadvantages of Container/Presentational Pattern

• It’s alternatives perform better
• Usage is decreased as we no longer need class components to create states.

Alternative to Presentational/Container Pattern

This pattern based approach can be easily replaced with using hooks in React. Instead, of creating different components based on the pattern we can create a single component which uses hooks to implement different functionality. Since the introduction of hooks in React the use of this pattern is reduced but it is still used in some cases as performing tests is easier in this pattern approach.

Please Login to comment...

Similar reads.

• Web Technologies

Improve your Coding Skills with Practice

What kind of Experience do you want to share?

How to develop your React superpowers with the Container Pattern

Hello everyone! ?

This time I’m going to tell you about this very useful pattern in React called the container pattern or container component pattern .

This is one of the first patterns I learned. It helped me a lot to separate problems in smaller ones and solve them one at a time.

Also, it definitely helped make my code much more reusable and self-contained at once.

It might seem a paradox! How you get your code to be reusable and self-contained at the same time?

Well, reusable because you learn to do small dummy (presentational) components that you can re-use a lot.

Self-contained because the container, view, or whatever you are using to keep all your logic can easily be detached from one place and attached to any other one without big changes/refactoring in your main app.

So this is a win-win and a secret superpower you need to acquire as soon as you can!

The truth is when you want to do a feature you always start simple and clean.

Days pass by and you get to add one more small feature here, one more feature there. You’re making a patch here, a patch there, and your whole code becomes messy and unmanageable.

Trust me, I’ve been there. And I’m still there nowadays! We all are, at a certain point, because programming is a craft. But we can minimize that a lot with practice and with this amazing design pattern.

But, what is a design pattern?

01. What is a Software Design Pattern?

A design pattern is nothing more than a general, reusable solution to a commonly occurring problem within a given context in software design. It’s not a finished design that can be transformed directly into source or machine code. It’s a description or template for how to solve a problem that can be used in many different situations.

Design patterns are formalized best practices that the programmer can use to solve common problems when designing an application or system.

You know the MVC software design pattern?

02. What is the MVC Design Pattern?

Well, MVC stands for Model-View-Controller . It is an architectural pattern used for developing user interfaces. It divides the application into three interconnected parts.

Traditionally it was used for desktop GUI (graphical user interfaces). This architecture has become popular for designing web applications and even mobile ones.

Imagine you have a triangle with three vertices: View , Controller, and Model .

The View is what user sees on screen (client side).

The User seeing the view can produce changes, can press a button, fulfill a form, press play to see a video, trigger a panoply of stuff together.

The Controller handles the changes the user promoted and all the logic behind. (It works as a relayer, it does requests and handles everything between the View and the Model.)

The Model is the manager. It contains what’s called the business logic, the data. The model receives information from the controller and proceeds to the changes needed. It gives the updates back to the Controller and the View.

React is “a JavaScript library to build user interfaces” (by definition ?). Most of the time you mix and handle the V and part of the C.

And that’s this V and this C that we want to separate distinctly from the container pattern.

03. What is the Container Pattern?

The Container Pattern is a solution to separate quite well the V from the C. Instead of doing only one <Component /> with the logic and the view, you separate it in two: <ComponentCon taine r /> and & lt;Component />. The former will do all the logical operations needed and promote communication with the business while the latter will be a dummy presentational component that will render whatever his parent Container demands.

Presentational components are concerned with how things look . While Container components are concerned with how things work .

04. Let’s get our hands dirty

Imagine we want to do a Superhero List component that shows some data about them. We’ll fetch the data from an API and we want to display it on screen.

Okay, to simulate our Model (database) I’ve created a fake data object. This object contains the info of the super heroes. It also has a fetchFarAwayAPI() function that will return that object.

Then I’ve created a stateful component to fetch the API, save the answer in the state of our component, and render the data in a bootstrap table on the screen.

Okay, we’ve totally separated the Controller from the view. This ?is the main idea you should keep in mind about the container pattern.

If you take a thoughtful look we’ve made one component where we fetch data, save it into state, and render it on screen. We’ve mixed the C and the V. Agree?

Okay, how do we solve this? Yup! Container Pattern!

The first step is to create a Presentational Component, to render the view. This component will receive props and render it. It’s completely dummy. Take a look:

To handle the Controller (logic) stuff I’ve refactored our old SuperHeroList renaming it to SuperHeroListContainer.

Okay, we’ve totally separated the Controller from the view and this ?is the main idea you should keep in mind about what’s the container pattern.

We can go further and take the row complexity out of the new SuperHeroList Component. How do we do it? Let’s create a new SuperHeroRow Component:

What have we done here? We’ve decoupled the row rendering complexity outside of the SuperHeroList Component. We let the former only render the table and invoking the SuperHeroRow to render each one of the rows alone.

We’ve extracted row complexity to another component. Always remember, the container pattern is there (inside SuperHeroListContainer). We’ve just spread the rendering into two parent/child components that are completely dummy and presentational using React preferred way of working: composition!

You have the freedom to extract responsibilities/complexities into smaller components. That’s how you should work with React! You need to adjust it to what’s best for the app, for the team, for the context you’re in.

Sometimes we can abstract the thing a little bit! I think by now we’re fine but… let’s go a little bit further…

Let’s create a second SuperHeroList this time using a HOC (Higher Order Component).

A higher-order component (HOC) is an advanced technique in React for reusing component logic. HOCs are not part of the React API, per se. They are a pattern that emerges from React’s compositional nature.

Concretely, a higher-order component is a function that takes a component and returns a new component.

The thing here is to refactor our SuperHeroListContainer into a vanilla JavaScript function. This function takes a component (commonly called the WrappedComponent) and returns a new component.

Just check how I’ve done it below:

We’ve refactored the <SuperHeroListContainer /> into this function called withContainer. It receives any Component you want to pass thru it and returns a class Component with all the logic inside!

In this case, the abstraction allows us to export multiple kinds of tables or reuse all the logic that we had in the container to invoke multiple/different presentational/dummy components.

That’s how we get self-containment and reusability together ?

Last But Not Least

Don’t worry if, at the beginning, you had difficulty determining how to apply the container pattern. It’s an iterative process. With practice, you’ll get there without thinking a lot. It will be intuitive and it will seem at first sight the best approach to almost (90%) anything you do in React.

React has a powerful composition model. They recommend using composition instead of inheritance to reuse code between components.

NOTE: For this article I’ve used Create React App 2.0 with Bootstrap. You can always pull my repo here and do some experimentations later on. You’ll find the two SuperHeroLists and the two examples we’ve done along the article.

Keep reading my articles and don’t forget: always Be Strong and Code On !

Bibliography

• React Documentation
• Container Components from Learn React with chantastic ;
• Software design pattern , from wikipedia, the free encyclopedia;
• Model-view-controller , from wikipedia, the free encyclopedia;
• Presentational and Container Patterns , by Dan Abramov;

Thank you very much!

evedes, Oct 2018

Read more posts .

If you read this far, thank the author to show them you care. Say Thanks

Learn to code for free. freeCodeCamp's open source curriculum has helped more than 40,000 people get jobs as developers. Get started

• TECHNOLOGIES
• An Interview Question

React Design Pattern Series: Container/Presentational Pattern

• Dhiraj Poojary
• Feb 14, 2024
• Other Artcile

Learn how to master the Container/Presentational Pattern in React with our comprehensive guide. This design pattern separates view and application logic, promoting improved code organization, reusability, and easier testing.

Introduction

React, a potent JavaScript library for UI development, offers the Container/Presentational Pattern, aiding in code organization. It segregates components into containers (handling logic) and presentational ones (focused on UI).

Promoting Modularity and Clarity

By separating components into logic-handling containers and UI-focused presentational ones, we improve code maintenance efficiency. Containers use hooks like useState and useEffect, and presentational components shape UI based on props. This pattern streamlines the codebase, ensuring each component has a clear role, promoting modularity and clarity.

Key Benefits of Container/Presentational Pattern

• Structured Code: Enhances the ease of locating and modifying specific functionalities without disrupting the application's overall structure.
• High Reusability: Allows for the efficient reuse of presentational components across different sections, fostering a modular development process.
• Simplified Testing: Streamlines testing with clear logic-UI separation. Containers can be unit-tested, and presentational components can be tested for rendering without complex scenarios.

Real-World Use Case

In a social media app, PostContainer manages state and logic, fetching and updating data. Post component renders UI based on props.

Code Example

This code defines a PostContainer managing state (post, comments, likes) and fetching data from an API. It uses the Post post-presentational component to render post details, allow liking, and display comments, demonstrating a practical implementation of the Container/Presentational Pattern for scalable and maintainable code.

Adopting the Container/Presentational Pattern in React ensures scalable and maintainable code, offering a structured and expressive approach. The pattern enhances modularity and clarity in development.

• Code Examples
• Code Organization
• Container/Presentational Patterns
• Design Patterns
• Functional Components

Frontend Developer Interview Questions and Answers

Find something to learn

Container and presentational pattern in react.

Containers are components that isolate the application logic, restricting their concerns about what data has to be shown . while presentation components focus on how the data has to be shown .

Beer.js, a container component

Beerlist.js, a presentational component, styling the presentational component, outcome of the container and presentational pattern, using a hook to replace the container component.

A custom hook can be created that will fetch the data .

Outcome of the hook and presentational pattern

Recommended posts:.

• Stack Overflow for Teams Where developers & technologists share private knowledge with coworkers
• Advertising & Talent Reach devs & technologists worldwide about your product, service or employer brand
• OverflowAI GenAI features for Teams
• OverflowAPI Train & fine-tune LLMs
• Labs The future of collective knowledge sharing
• About the company Visit the blog

Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Get early access and see previews of new features.

Regarding Dan Abramov's update about Presentational and Container Components, and hooks [closed]

Presentational/Container components are known as a good separation of concerns pattern in React, and if we search about the topic you'll definitely find Dan Abramov's post regarding that.

But quite some time ago he then updated that post with a statement that can be interpreted that due to the recent adaptability to using Hooks, the presentational/container components pattern is not as recommended as it was before. Since we can create custom hooks that contain that code instead.

How do you interpret what he meant by that?

Having a gigantic custom hook that does all that logic and returns a bunch of variables? And then calling that hook in a component?

Personally I still find container components useful as it separates what is business logic (calling apis and handling the result flow of that) from "UI logic" (storing state for a tab, an animation)

It's easier when you're working with a large scale app to find where the API, redux or graphql calls are being done if they're in its own place, and always following the same pattern. But if we didn't have that, how would we solve this problem and not having a mess of multiple components calling apis and doing its own thing everywhere in the app/tree?

I'm asking this because even when still using container components to only fetch an api and/or get the redux state, and keeping everything tidy, sometimes I still find useful for some components to call the API and do what a "container" would do themselves, to avoid having to pass down props or making a container TOO big/confusing. And it is kind of conflicting having just some components do that and the rest stay in a container component. How would you handle that?

• react-hooks

I think presentational components pattern is still relevant with hooks. You can still use the main logic in "Container" component, but in case of hooks, you can remove the concern of using not relevant state from the "Container" component.

For example, you have a list component that directs the main logic and each item has a drop-down in it, is drop-down shown or not is not relevant for the whole list, so its state should stay in the presentational component.

Also, custom hooks are just functions that allow you to re-use state and lifecycle features, so it has no relation to the pattern.

Not the answer you're looking for? Browse other questions tagged reactjs react-hooks or ask your own question .

• Featured on Meta
• Upcoming sign-up experiments related to tags
• Policy: Generative AI (e.g., ChatGPT) is banned
• The [lib] tag is being burninated
• What makes a homepage useful for logged-in users

Hot Network Questions

• Is it better to show fake sympathy to maintain a good atmosphere?
• Should I accept an offer of being a teacher assistant without pay?
• How to determine if gravity is roughly linear?
• Are both vocal cord and vocal chord correct?
• Folk stories and notions in mathematics that are likely false, inaccurate, apocryphal, or poorly founded?
• Navigation on Mars without Martian GPS
• D&D 3.5 Shadow Magic / Shadow Conjuration: Can an illusionist create a quasi-real shadow of ANY monster? Or only those on the summon monster lists?
• Determine the voltages Va and V1 for the circuit
• Sets of algebraic integers whose differences are units
• Is it possible to complete a Phd on your own?
• Can I route audio from a macOS Safari PWA to specific speakers, different from my system default?
• Geometry question about a six-pack of beer
• Does it matter if a fuse is on a positive or negative voltage?
• What to do if you disagree with a juror during master's thesis defense?
• How can I take apart a bookshelf?
• Can front gear be replaced on a Retrospec Judd folding bicycle?
• Have children's car seats not been proven to be more effective than seat belts alone for kids older than 24 months?
• They sold me a useless SIM card at Bali airport. What can I do?
• Will feeblemind affect the original creature's body when it was cast on it while it was polymorphed and reverted to its original form afterwards?
• Both my adult kids and their father (ex husband) dual citizens
• What’s the highest salary the greedy king can arrange for himself?
• How can I confirm for sure that a CVE has been mitigated on a RHEL system?
• No simple group or order 756 : Burnside's proof
• Summation not returning a timely result

Critics Clown Trump's 'IDIOTIC' Electric Planes Remarks: 'Dumb As A Box Of Rocks'

Donald Trump on Friday dropped some confusing remarks about electric planes while criticizing Democrats at a rally in Chesapeake, Virginia.

“All they know is electric. They want electric army tanks. They want electric planes. What happens if the sun isn’t shining while you’re up in the air?” asked the GOP’s presumptive presidential nominee, apparently referring to solar-powered aircraft.

Trump: All they know is electric. They want electric planes. What happens if the sun isn't shining while you're up in the air? pic.twitter.com/jeywjeGcZD — Acyn (@Acyn) June 28, 2024

The comments by the former president, who has previously ranted about possible electrocution from electric boats , inspired mockery from social media users like journalist James Fallows, who served as a speechwriter for President Jimmy Carter .

“OK, we know he is an idiot. But every now and then you have to say, this is GODDAMN IDIOTIC,” Fallows wrote on X , formerly Twitter.

“Electric planes run ON BATTERIES. His question is like asking, ‘How can you use an iPhone if it’s dark outside.’”

OK, we know he is an idiot. But every now and then you have to say, this is GODDAMN IDIOTIC. Electric planes run ON BATTERIES. His question is like asking, "How can you use an iPhone if it's dark outside." Oh, I forgot. I he "aced" his dementia-screening test. https://t.co/0wnm7tICDC — James Fallows (@JamesFallows) June 28, 2024

Others reacted by calling Trump — a frequent critic of electric vehicles who has opposed Biden’s push for them — “ Dumb as a box of rocks ,” among other things.

See what else they had to say in the tweets below:

Looking forward to the New York Times editorial board weighing in on this significant development. https://t.co/V8u8OewyYw — Rex Huppke (@RexHuppke) June 29, 2024

HE IS SO STUPID https://t.co/nr78G8o35n — Decoding Fox News (@DecodingFoxNews) June 29, 2024

Electricity, a technology that famously does not work in the dark. https://t.co/Qd87LhU1TM — Ashton Pittman (@ashtonpittman) June 29, 2024

Unsurprisingly, Trump lacks a grasp of basic science. https://t.co/CtmhqXb2hq — Republican Voters Against Trump (@AccountableGOP) June 28, 2024

Oh my god. Oh. My. God. 🤤🥴 https://t.co/6UYoT6Hgu3 — Spiro’s Ghost (@AntiToxicPeople) June 28, 2024

Trump clearly doesn’t understand how solar energy is stored. He’s unfit. — Art Candee 🍿🥤 (@ArtCandee) June 28, 2024

I often say to my friends that Donald Trump cured my imposter syndrome. https://t.co/BI5VkGJBlJ — Zerlina Maxwell (@ZerlinaMaxwell) June 28, 2024

Popular in the Community

From our partner, more in politics.