React components - Part I

Aktualisiert: 17. März 2019

Stateful components, functional ones, class components or pure components. Oh, and controlled vs uncontrolled. What, why and when to use which one?

Developers new to React can get overwhelmed by various different approaches of creating a component. Which ones should I use, should I use different ones for different situations or is one type better than the others? First, let me just list down the component types we will go through in this 2 parts of the article:

Part I

  • Class vs. functional components

  • Stateful vs. Stateless components

  • Pure component vs. “Non Pure component”

Part II

  • Controlled vs. uncontrolled components

So let’s go through them one by one and outline the differences.

As you probably know React is mainly about the state and props. And the distinction basically comes down to those 2 concepts.

For me, it took a while to realize, that the technical difference between class and functional component is reflected in the conceptual difference between Stateful and Stateless component. Or simply put, a class component is stateful and functional component is stateless.

Class vs. functional components

As the name suggests, class components make use of the ES6 class syntax, whereas functional components are just plain JavaScript functions with a render method returning the markup. Here are examples for each one:

Class component

Functional component

What are the differences?

The main differences are the following:

  • Class component can have state, whereas a functional component cannot. So, when React developers are talking about stateless components they mean functional components.

  • Furthermore, as class components are extending React.Component they are provided with all the lifecycle methods (e.g. “componentDidMount” or “componentDidUpdate”) of React, while functional components don’t have access to them.

  • Class components have instances, and therefore can access the props via this.props”.

When to use which one and why?

Obviously, when you need internal state or need access to lifecycle methods, you have to declare the component as a class. If you don’t, like in the second example it might be better to convert this class component into a functional component.

You may ask, why not always use class components, when they are provided with all those extended possibilities?

Well, the benefits of having functional components are that you don’t have the heavy lifting of class components and you don’t need a constructor, which results in less code. Moreover, there is no "this" keyword and binding of it. It’s just the simplest way to define a component. In terms of performance, however, there is no particular advantage with functional components.

Connection to other component types:

Now you've seen how those two component types differ, it's important to note that

a functional component is always a stateless component. But a class component can be a stateful or stateless.

Stateful vs. Stateless components

A stateful component has its own internal state, which you can manage and update via “this.setState()”, whereas a stateless component does not.

The above example for a class component, is also a stateful component:

Stateful component

Technically, however, if you don't define "this.state" for a class component, it will be stateless.

Stateless component


So how does stateless component get data? Stateless components only have access to "this.props" so they get the data passed down from a parent via props. Like this:

Stateless component getting its data only via props

When to use them?

It’s generally better to have stateless components due to the following reasons:

  • Stateless components depends solely on props for their data and therefore the same input will always result in the same output.

  • You should use a stateless component when your logic is outside of the view layer.

  • Both contribute to reusability, fewer bugs and easier testing.

Designing the state of your components correctly, based on their individual requirements, can actually help in avoiding some of the side effects you could otherwise produce by spreading the data all across your components.

Last but not least there are pure components.


Technically, pure components are components which extend React.PureComponent, instead of React.Component and look like this.



They are mainly like normal React.Components, also having the lifecycle methods. The important difference is that React.PureComponent implements the “shouldComponentUpdate” lifecycle method with a prop and state comparison. Because of this implementation, the performance can be improved, as the component will only re-render when its props or state changes.

You probably ask yourself why shouldn't you always use PureComponents. The limitation here is, that all its child components need to be pure as well, as stated in React docs:

“Furthermore, React.PureComponent’s shouldComponentUpdate() skips prop updates for the whole component subtree. Make sure all the children components are also “pure”.”

And the second limitation is, that you need to be careful when having complex data structures, because the object comparison is only shallow. So don’t mutate objects, which is always good anyway.

Connection to other component types:

PureComponents are class components and therefore can be stateful or stateless.

When to use them?

As PureComponents can give you a performance boost, you should use PureComponents over components declared with React.Component. But because of the shallow comparison, it’s best to only use it, when you have simple state and prop data structures.

I should note, that you can of course, implement your own “shouldComponentUpdate” logic for your normal React.Components and get the same performance improvement this way.

As you can see, like always in software development, you can get the thing done - in this case creating a component - in different ways and one is not necessarily better than the other. But you should know your options.

If you are not confused yet, good, because there are 2 more component types to be discussed. In the next part we will look into controlled vs. uncontrolled components.

Nicole Hiller  |  Nana Janashia


©2018 by nnSoftware