Introduction to React Hooks

Analogy categoryAnalogies

Introduction

Hooks are special functions, introduced in React 16.8, that let you 'hook into' React features like state and lifecycle from function components. Before Hooks, state and lifecycle methods (componentDidMount, componentDidUpdate, componentWillUnmount) were only available in class components, forcing developers to write verbose classes even for simple stateful logic. Hooks solve this by letting plain functions manage state, side effects, context, and more, while keeping components easier to read, test, and reuse.

🏏

Cricket analogy: Before Hooks, only class components (like only all-rounders) could hold state; Hooks let any specialist function component bat and bowl state logic too, without retraining as a full class.

Syntax

jsx

import { useState, useEffect } from 'react';

function Example() {
  // useState hook: returns [value, setterFunction]
  const [count, setCount] = useState(0);

  // useEffect hook: runs a side effect after render
  useEffect(() => {
    document.title = `Count: ${count}`;
  }, [count]);

  return <button onClick={() => setCount(count + 1)}>{count}</button>;
}

Explanation

Every Hook is a function whose name starts with 'use' (useState, useEffect, useContext, useRef, and so on). Hooks do not work inside classes; they are designed exclusively for function components and other custom Hooks. React associates each Hook call with the component instance currently being rendered, using the order in which Hooks are called to know which piece of state or effect belongs to which useState/useEffect call. This is why Hooks must always run in the same order on every render (see Rules of Hooks). Hooks were built to solve three long-standing React problems: reusing stateful logic between components without wrapper hell (render props/HOCs), splitting complex components into smaller functions based on related logic rather than lifecycle name, and avoiding the confusion of the 'this' keyword in classes.

🏏

Cricket analogy: The 'use' prefix on every Hook is like every fielding signal starting with the captain's raised hand, a consistent convention, and React tracking call order is like an umpire relying strictly on over sequence to know whose delivery counts where.

Example

jsx

// Before Hooks: a class component
class Counter extends React.Component {
  state = { count: 0 };
  componentDidMount() {
    console.log('Mounted with count', this.state.count);
  }
  render() {
    return (
      <button onClick={() => this.setState({ count: this.state.count + 1 })}>
        {this.state.count}
      </button>
    );
  }
}

// After Hooks: a function component
function Counter() {
  const [count, setCount] = useState(0);
  useEffect(() => {
    console.log('Mounted with count', count);
  }, []);
  return <button onClick={() => setCount(count + 1)}>{count}</button>;
}

Output

Both components render a button that increments a count when clicked, and both log a message when the component first mounts. The function-component version achieves the same behavior with less boilerplate, no 'this' binding concerns, and logic that can be extracted into a reusable custom Hook if needed elsewhere.

🏏

Cricket analogy: Both versions score the same runs (increment count on click) and log the same commentary on debut (mount), but the Hooks version fields the ball with a lighter glove, no need to manage 'this' like adjusting a heavy pad every time.

Key Takeaways

Hooks let function components use state, effects, context, and refs without writing a class.
Hooks were introduced in React 16.8 and all start with the prefix 'use'.
Hooks rely on consistent call order across renders to correctly associate state with each call.
Hooks enable reusable stateful logic via custom Hooks, replacing render props and higher-order components in many cases.
Hooks can only be called inside function components or other custom Hooks, not in regular JavaScript functions or classes.