Functional components are plain JavaScript functions that accept props and return JSX, and are the standard, recommended way to write React components today.

Syntax

function MyComponent(props) {
  return <div>{props.text}</div>;
}

Deep Dive Course

A functional component is just a regular JavaScript function following React's component convention: it accepts a single props object and returns JSX. Since the introduction of hooks in React 16.8, functional components can do everything class components can, manage state with useState, run side effects with useEffect, and more, without needing the more verbose class syntax, constructor, this binding, and lifecycle methods that class components require. This is why functional components with hooks are now the standard, recommended approach for essentially all new React code.

1Understanding Functional Components

💡

There's no capability gap left between functional and class components since hooks were introduced — new code should be written as functional components with hooks by default, reserving class components only for maintaining pre-existing legacy code.

editor.html

function Greeting({ name }) {
  return <h1>Hello, {name}!</h1>;
}

// <Greeting name="Ana" />

localhost:3000

2Practical Example

Here is a real-world application of Functional Components showing how it is used in production React code.

editor.html

import { useState } from 'react';

function Counter() {
  const [count, setCount] = useState(0);
  return <button onClick={() => setCount(count + 1)}>Count: {count}</button>;
}

localhost:3000

3Best Practices

Follow these guidelines when working with Functional Components:

1. Write new components as functional components with hooks by default, rather than reaching for the class component syntax

2. Use useState and useEffect, or other hooks, inside functional components for state and side effects that class components would previously have needed lifecycle methods for

3. Avoid mixing class and functional component styles unnecessarily within the same codebase, for consistency

⚠️

Tip: There's no capability gap left between functional and class components since hooks were introduced — new code should be written as functional components with hooks by default, reserving class components only for maintaining pre-existing legacy code.

editor.html

function Greeting({ name }) {
  return <h1>Hello, {name}!</h1>;
}

// <Greeting name="Ana" />

localhost:3000

Examples

Example 01Basic Usage

function Greeting({ name }) {
  return <h1>Hello, {name}!</h1>;
}

// <Greeting name="Ana" />

Example 02Advanced Example

import { useState } from 'react';

function Counter() {
  const [count, setCount] = useState(0);
  return <button onClick={() => setCount(count + 1)}>Count: {count}</button>;
}

Best Practices

Write new components as functional components with hooks by default, rather than reaching for the class component syntax
Use useState and useEffect, or other hooks, inside functional components for state and side effects that class components would previously have needed lifecycle methods for
Avoid mixing class and functional component styles unnecessarily within the same codebase, for consistency
Always declare component functions at a module's top level — never define one inside another component's render logic, or it gets recreated (and loses its state) on every render

Interview Question

Why did the introduction of hooks in React 16.8 lead to functional components largely replacing class components as the standard way to write React code?▼

Hint: Think about what class components could do that functional components originally couldn't, before hooks existed.

Before hooks, only class components could hold internal state or run side effects tied to a component's lifecycle, using this.state and lifecycle methods like componentDidMount, since a plain function had no built-in mechanism to persist a value across multiple calls or hook into React's rendering lifecycle. Hooks specifically closed that gap by giving functional components their own mechanism, useState, useEffect, and others, for exactly the same capabilities, persistent state and lifecycle-tied side effects, without requiring the class syntax, its more verbose constructor and this-binding boilerplate, or its sometimes-confusing behavior around how methods are bound. Since functional components with hooks can now do everything class components can, generally with less code and fewer common pitfalls like incorrect this bindings, the React team and community converged on recommending functional components as the default approach for new code, leaving class components relevant mainly for maintaining existing legacy code that predates hooks.

Exercises

MediumPractice using Functional Components in a real scenario.

View Solution

function Greeting({ name }) {
  return <h1>Hello, {name}!</h1>;
}

// <Greeting name="Ana" />

Frequently Asked Questions

Why did the introduction of hooks in React 16.8 lead to functional components largely replacing class components as the standard way to write React code?▼

Why does a child component defined inside a parent component's function body lose its state every time the parent re-renders?▼

React identifies which component 'instance' owns a particular piece of state by the component function's identity, not just its name — when a component is declared inside another component's body, a brand-new function object is created every time the parent's function runs, which happens on every render. From React's perspective, that's a completely different component type than the one rendered a moment ago, even though the code looks identical, so React unmounts the old instance (discarding all its state and running any cleanup) and mounts what it considers a fresh, new component. Declaring the child component at the module's top level instead means the exact same function reference is used across every render, letting React correctly recognize it as the same component and preserve its state.

Related Functions

class-componentsusestateuseeffect