React functional components vs classical components

2022 Update

You only need a class component when you:

• need to create an error boundary using componentDidCatch

---

Original 2016 Answer

You only need a class component when you:

• need the component state or
• need the lifecycle methods. such as componentDidMount etc.

This answer is deprecated.

With react hooks, a functional component can also have a state.

---

1. When do we use each kind of component?

If we use Redux, there will be two kinds of Components:

• Presentational Components: concern about the UI
• Container Components: manage the state

Redux's creator Dan Abramov has written an article Presentational and Container Components:

Presentational Components are written as functional components unless they need state, lifecycle hooks, or performance optimizations.

Even though we don't use Redux. We can also separate the components as Presentational Components and Container Components.

• Presentational Components use Functional Components and are only concerned with the UI.
• Container Components use Class Components and concern state and behaviour.

2. Benefits of Functional Components

Cory House's article React Stateless Functional Components: Nine Wins You Might Have Overlooked let me know the Functional Components' advantages, Functional Components are more:

• simple
• readable
• testable

3. Limits of Functional Components

Functional Components are stateless, which is its limit.

But fortunately, most of the time, we don't need a state.

4. Functional Components Enforced Best Practices

Stateless functional components are useful for dumb/presentational components. Presentational components focus on the UI rather than behaviour, so it’s important to avoid using state in presentational components. Instead, the state should be managed by higher-level “container” components, or via Flux/Redux/etc. Stateless functional components don’t support state or lifecycle methods. This is a good thing. Why? Because it protects from laziness.

See, it’s always tempting to add state to a presentational component when you’re in a hurry. It’s a quick way to hack into a feature. Since stateless functional components don’t support local states, you can’t easily hack into some state in a moment of laziness. Thus, stateless functional components programmatically enforce keeping the component pure. You’re forced to put state management where it belongs: in higher-level container components.