Unit 7: React Hooks

Introduced in React 16.8 (February 2019) following a landmark presentation by Sophie Alpert and Dan Abramov at React Conf 2018, React Hooks fundamentally revolutionized the design, authorship, and maintenance of frontend architectures. Prior to hooks, React development suffered from a strict architectural bifurcation: developers had to choose between simple stateless functional components (which could only render props deterministically) and complex stateful class components (which had exclusive access to internal component state and lifecycle methods).

While class components served the ecosystem during React's formative years, enterprise-scale engineering revealed three deep structural bottlenecks inherent to the object-oriented class paradigm in modern JavaScript:

React Hooks resolve these challenges by allowing developers to use state and other React features without writing a class. Rather than thinking of a component as an object instance with lifecycle hooks, functional React conceptualizes a component as a pure mathematical projection from state and props into a virtual UI tree: UI = f(state, props). Hooks are the specialized functions that allow functional components to read and manipulate the internal memory cells managed by React's Fiber engine.

// 1. LEGACY CLASS COMPONENT: Verbose constructor, manual "this" binding, fragmented lifecycles
class LegacyCounter extends React.Component {
  constructor(props) {
    super(props);
    this.state = { count: 0 };
    this.handleIncrement = this.handleIncrement.bind(this);
  }

  handleIncrement() {
    this.setState((prev) => ({ count: prev.count + 1 }));
  }

  render() {
    return <button onClick={this.handleIncrement}>Count: {this.state.count}</button>;
  }
}

// 2. MODERN FUNCTIONAL COMPONENT: Direct, declarative, zero "this" boilerplate
import { useState } from 'react';

function ModernCounter() {
  const [count, setCount] = useState(0);

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

Because React does not require developers to pass unique identification keys or string identifiers when declaring hooks (unlike traditional key-value dictionaries), React relies entirely on the chronological call order of hooks during component rendering. Each hook invocation corresponds sequentially to an index in an internal singly linked list attached to the component's Fiber node.

To preserve this deterministic call sequence, developers must adhere to two fundamental, non-negotiable rules of hooks:

Why Top-Level Order is Required: The Internal Pointer Traversal

When a functional component mounts for the first time, React executes the component function and instantiates a linked list of hook records (managed by the internal dispatcher HooksDispatcherOnMount). Each hook call allocates a cell and appends it to fiber.memoizedState.

On every subsequent re-render, React switches to HooksDispatcherOnUpdate. An internal pointer (currentHook) is initialized at the head of the linked list. As each hook executes in the component body, React reads the current cell, runs update logic, and advances the pointer: currentHook = currentHook.next.

If a hook call is wrapped inside an if statement that evaluates to false on a subsequent render, that hook call is skipped. Consequently, the internal pointer fails to advance at the expected moment. The next hook in line is paired with the wrong memory cell, catastrophically shifting all remaining state variables and producing silent data corruption or fatal type errors.

// ❌ FATAL ERROR: Conditional hook call alters chronological sequence
function CorruptedUserProfile({ isAdmin }) {
  if (isAdmin) {
    const [auditLog, setAuditLog] = useState([]); // BROKEN: Breaks hook list pointer!
  }
  const [userName, setUserName] = useState('');   // Receives auditLog cell if isAdmin flips!
  return <div>{userName}</div>;
}

// ❌ FATAL ERROR: Early return prevents subsequent hooks from executing
function FlawedComponent({ data }) {
  if (!data) {
    return <p>No data available.</p>; // Early return exits before theme hook!
  }
  const [theme, setTheme] = useState('dark'); // BROKEN: Skipped when data is null!
  return <div className={theme}>{data.title}</div>;
}

// ✅ IDIOMATIC & ROBUST: Unconditional top-level declarations
function CorrectUserProfile({ isAdmin, data }) {
  // 1. All hooks execute in identical chronological order on EVERY render
  const [auditLog, setAuditLog] = useState([]);
  const [userName, setUserName] = useState('');
  const [theme, setTheme] = useState('dark');

  // 2. Conditional rendering is completely safe AFTER all hooks have executed
  if (!data) {
    return <p>No data available.</p>;
  }

  return (
    <div className={theme}>
      <h3>{userName}</h3>
      {isAdmin && <p>Audit Records: {auditLog.length}</p>}
    </div>
  );
}

In modern development pipelines, these rules are statically validated at authoring time by the official ESLint plugin, eslint-plugin-react-hooks. It exposes two essential rules:

• react-hooks/rules-of-hooks: Enforces that hooks are only called at the top level of React functions.
• react-hooks/exhaustive-deps: Verifies that every reactive value referenced inside an effect, memo, or callback is explicitly declared in its dependency array.

The useState hook is the foundational primitive for declaring reactive state within functional components. Invoking useState returns an array tuple containing exactly two elements: [currentState, dispatchUpdater].

The Render Snapshot Mental Model

A common point of confusion for beginners is treating state variables as mutable variables that update immediately in place. In React, a state variable is an immutable snapshot tied to a specific render pass. When a component renders:

1. React calls your component function.
2. The function calculates a snapshot of the UI corresponding to that render pass.
3. Variables, event handlers, and inline functions inside that component scope "capture" the state values of that specific render pass via JavaScript lexical closures.

Calling a state setter does not mutate the variable in the running execution context; it schedules a state update with React and requests a new render pass.

Functional State Updates & The Stale Closure Problem

Because state is captured in closures, executing multiple state updates synchronously against the captured value can lead to lost updates:

Lazy State Initialization

If your initial state requires expensive computation (such as reading from window.localStorage, parsing complex JSON structures, or transforming large arrays), passing the computed value directly to useState(expensiveCalculation()) executes the calculation on every single render, even though React only uses the initial value during the first mount.

By passing an initializer function—useState(() => expensiveCalculation())—React executes the function strictly once during the initial mounting phase, discarding the initializer on subsequent renders.

import { useState } from 'react';

// Pure helper function for heavy computation
function loadInitialSettings() {
  const stored = localStorage.getItem('user_prefs');
  return stored ? JSON.parse(stored) : { theme: 'system', fontSize: 14, notifications: true };
}

function SettingsController() {
  // 1. Lazy Initialization: Passed as function reference, evaluated strictly on mount
  const [settings, setSettings] = useState(loadInitialSettings);
  const [clickCount, setClickCount] = useState(0);

  // 2. Functional Updates: Guarantees sequential resolution during rapid dispatches
  const handleTripleIncrement = () => {
    setClickCount((prev) => prev + 1);
    setClickCount((prev) => prev + 1);
    setClickCount((prev) => prev + 1); // Accurately increments by 3
  };

  // 3. Object Immutability: State updaters replace rather than merge
  const updateFontSize = (newSize) => {
    setSettings((prev) => ({
      ...prev,           // Shallow copy all existing keys
      fontSize: newSize  // Overwrite specific target key
    }));
  };

  return (
    <div className="card">
      <p>Configured Font Size: <strong>{settings.fontSize}px</strong></p>
      <p>Total Dispatched Clicks: <strong>{clickCount}</strong></p>
      <button onClick={() => updateFontSize(settings.fontSize + 2)}>Enlarge Font</button>
      <button onClick={handleTripleIncrement}>+3 Clicks Safely</button>
    </div>
  );
}

In software engineering, a function is considered pure if it consistently returns the same output for identical inputs and produces no observable side effects outside its lexical boundary. In React, component rendering functions are expected to remain pure: evaluating props and state to produce a tree of Virtual DOM descriptors.

Defining "Side Effects" in Frontend Engineering

A side effect (or simply "effect") is any program operation that interacts with or modifies state outside the current component render calculation. Examples include:

• Host DOM Mutations: Programmatically altering document.title, manually triggering element focus, or scrolling a container.
• External Network Communication: Dispatching HTTP REST requests, GraphQL queries, or WebSocket messages.
• Browser Scheduling APIs: Initializing timers via setInterval or setTimeout.
• Global System Subscriptions: Attaching listeners to window resize, orientation change, scroll, or online/offline status events.
• Application Telemetry: Logging diagnostic metrics to analytics servers when a view appears on screen.

Declarative Synchronization vs Imperative Lifecycles

Class components approached side effects through an imperative, lifecycle-centric paradigm: "Now that I have mounted, what should I execute? Now that I received new props, what should I update?"

The useEffect hook shifts this paradigm from temporal lifecycles to declarative synchronization. Instead of asking when a lifecycle event occurs, the developer asks: "Which external system must this component remain synchronized with, and which state or prop values determine that synchronization boundary?"

The second parameter passed to useEffect is the dependency array. It acts as a guard condition, specifying the reactive variables on which the effect depends.

The Cleanup Function Lifecycle Protocol

If an effect establishes an ongoing subscription, allocates system resources, or initializes a timer, it must return a cleanup function. Failing to provide a cleanup function causes catastrophic memory leaks, zombie event listeners, and attempts to update state on unmounted components.

import { useState, useEffect } from 'react';

function ViewportDimensions() {
  const [dimensions, setDimensions] = useState({
    width: window.innerWidth,
    height: window.innerHeight
  });

  useEffect(() => {
    // 1. Setup Phase: Event listener definition and subscription
    const handleResize = () => {
      setDimensions({
        width: window.innerWidth,
        height: window.innerHeight
      });
    };

    window.addEventListener('resize', handleResize);

    // 2. Cleanup Phase: Mandatory unsubscription to prevent memory leaks
    return () => {
      window.removeEventListener('resize', handleResize);
    };
  }, []); // Empty dependency array: Setup once on mount, clean up once on unmount

  return (
    <p>
      Viewport: <strong>{dimensions.width}px × {dimensions.height}px</strong>
    </p>
  );
}

Data fetching is among the most frequent applications of useEffect. However, asynchronous operations in React introduce significant concurrency challenges that must be handled systematically.

The Network Race Condition Dilemma

When an effect depends on an external parameter (such as a search query or user ID), rapid user input triggers multiple network requests in rapid succession. Because network latency is non-deterministic:

• Request A (initiated first for query "Re") may take 800ms due to network congestion.
• Request B (initiated second for query "React") may take 150ms due to edge caching.

If unmanaged, Request B will resolve first and update the UI with "React" results. Moments later, Request A resolves late and blindly overwrites the state with stale "Re" results. This critical bug is known as a network race condition.

The production-grade solution is to utilize the browser's native AbortController API within the effect's cleanup function, cancelling in-flight HTTP requests when dependencies mutate or when the component unmounts.

import { useState, useEffect } from 'react';

function UserProfileCard({ userId }) {
  const [user, setUser] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    // 1. Initialize browser AbortController for network cancellation
    const controller = new AbortController();
    const { signal } = controller;

    // 2. Define self-contained async helper inside effect closure
    async function fetchUserData() {
      setLoading(true);
      setError(null);

      try {
        const response = await fetch(`https://jsonplaceholder.typicode.com/users/${userId}`, { signal });
        if (!response.ok) {
          throw new Error(`HTTP Error: ${response.status}`);
        }
        const data = await response.json();
        setUser(data);
      } catch (err) {
        // Silently ignore expected user-aborted request errors
        if (err.name !== 'AbortError') {
          setError(err.message || 'An unexpected network error occurred.');
        }
      } finally {
        if (!signal.aborted) {
          setLoading(false);
        }
      }
    }

    fetchUserData();

    // 3. Return cleanup to abort in-flight fetch when userId changes or component unmounts
    return () => {
      controller.abort();
    };
  }, [userId]); // Re-fetch whenever userId changes

  if (loading) return <p>Loading user profile...</p>;
  if (error) return <p style={{ color: 'red' }}>Error: {error}</p>;
  if (!user) return null;

  return (
    <div className="card">
      <h3>{user.name}</h3>
      <p>Email: {user.email}</p>
      <p>Company: {user.company?.name}</p>
    </div>
  );
}

In standard React component hierarchies, data flows strictly downward via props (unidirectional data flow). However, global or semi-global application concerns—such as the authenticated user session, UI color theme, localization dictionaries, or routing contexts—need to be accessible by dozens of leaf components distributed across deeply nested component trees.

Manually threading props down through five, six, or more intermediary components that have no operational interest in the data is known as prop drilling. Prop drilling degrades code readability, tightly couples component contracts, and turns refactoring into an arduous chore.

The Context Architecture

React's Context API provides a mechanism to establish an "ambient data broadcast" across a subtree:

1. createContext(defaultValue): Instantiates a unique context token.
2. <Context.Provider value={data}>: Wraps a component subtree and broadcasts data to all descendants.
3. useContext(Context): A hook invoked by any descendant component to subscribe directly to the nearest ancestor provider's broadcast value.

import { createContext, useContext, useState } from 'react';

// 1. Create Context token with explicit fallback default value
const ThemeContext = createContext({
  theme: 'light',
  toggleTheme: () => {}
});

// 2. Encapsulated Provider Component
export function ThemeProvider({ children }) {
  const [theme, setTheme] = useState('light');

  const toggleTheme = () => {
    setTheme((prev) => (prev === 'light' ? 'dark' : 'light'));
  };

  return (
    <ThemeContext.Provider value={{ theme, toggleTheme }}>
      {children}
    </ThemeContext.Provider>
  );
}

// 3. Leaf Consumer Component calling useContext
export function ThemeToggleButton() {
  const { theme, toggleTheme } = useContext(ThemeContext);

  return (
    <button onClick={toggleTheme}>
      Active Theme: <strong>{theme}</strong> (Click to Toggle)
    </button>
  );
}

The useRef hook returns a persistent, mutable JavaScript container object featuring a single property: .current. Unlike standard variables declared inside a component function (which are recreated on every render), the reference object returned by useRef maintains its identity and holds its stored value across the entire lifecycle of the component.

The Dual Identity of useRef

import { useState, useRef, useEffect } from 'react';

function PrecisionStopwatch() {
  const [seconds, setSeconds] = useState(0);

  // 1. DOM Handle Reference: Linked to physical input element
  const searchInputRef = useRef(null);

  // 2. Mutable Value Reference: Stores interval ID without triggering re-renders
  const intervalIdRef = useRef(null);

  // Focus input element automatically upon mounting
  useEffect(() => {
    searchInputRef.current?.focus();
  }, []);

  const handleStart = () => {
    if (intervalIdRef.current !== null) return; // Prevent multiple concurrent timers

    intervalIdRef.current = setInterval(() => {
      setSeconds((prev) => prev + 1);
    }, 1000);
  };

  const handleStop = () => {
    clearInterval(intervalIdRef.current);
    intervalIdRef.current = null; // Clean up reference
  };

  return (
    <div className="card">
      <input ref={searchInputRef} placeholder="Focused automatically on mount" />
      <div style={{ marginTop: '12px' }}>
        <p>Elapsed Time: <strong>{seconds} seconds</strong></p>
        <button onClick={handleStart}>Start</button>
        <button onClick={handleStop}>Stop</button>
      </div>
    </div>
  );
}

While useState is ideal for simple independent values, components frequently accumulate state that is interdependent, hierarchical, or driven by multi-step state transitions. As state logic grows, spreading state updater calls across multiple event handlers scatters business rules throughout the component.

The useReducer hook provides an alternative, formal state architecture inspired by the Redux pattern and finite state machines:
const [state, dispatch] = useReducer(reducer, initialState);

The Formal Reducer Architecture

• State: An immutable JavaScript object representing the complete current condition of the component.
• Action: A plain JavaScript object describing an event that occurred (conventionally with a type string and optional payload data).
• Reducer: A pure mathematical function with the signature (currentState, action) => newState. It calculates and returns the next state without mutating the previous state.
• Dispatch: A stable dispatch function used by event handlers to dispatch actions to the reducer.

import { useReducer } from 'react';

const initialCartState = {
  items: [],
  totalPrice: 0
};

// Pure reducer function: encapsulates all transition logic outside the component
function cartReducer(state, action) {
  switch (action.type) {
    case 'ADD_PRODUCT':
      return {
        ...state,
        items: [...state.items, action.payload],
        totalPrice: state.totalPrice + action.payload.price
      };

    case 'REMOVE_PRODUCT': {
      const filtered = state.items.filter((item) => item.id !== action.payload.id);
      return {
        ...state,
        items: filtered,
        totalPrice: Math.max(0, state.totalPrice - action.payload.price)
      };
    }

    case 'CLEAR_CART':
      return initialCartState;

    default:
      throw new Error(`Unhandled action type: ${action.type}`);
  }
}

function CartManager() {
  const [state, dispatch] = useReducer(cartReducer, initialCartState);

  return (
    <div className="card">
      <h3>Cart Items: {state.items.length} | Total: ${state.totalPrice}</h3>
      <button onClick={() => dispatch({ type: 'ADD_PRODUCT', payload: { id: Date.now(), name: 'Book', price: 25 } })}>
        Add Book ($25)
      </button>
      <button onClick={() => dispatch({ type: 'CLEAR_CART' })}>
        Clear Cart
      </button>
    </div>
  );
}

In React's standard execution model, whenever a parent component re-renders, every child component in its subtree is re-rendered recursively, regardless of whether that child's props actually changed. While React's Virtual DOM reconciliation is remarkably fast, large lists, complex SVG visualizations, or heavy computational algorithms can introduce noticeable user interface stutter.

The Referential Equality Problem

In JavaScript, functions and objects are compared by reference memory identity, not structural content:
{ a: 1 } !== { a: 1 } and (() => {}) !== (() => {}).

Every time a parent component re-renders, any function or object declared inline inside its body receives a brand-new memory address. When passed as props to child components optimized with React.memo, the child's shallow prop comparison fails, forcing an unnecessary re-render pass.

import React, { useState, useMemo, useCallback } from 'react';

// Memoized Child: Skips re-render if items and onDelete references are unchanged
const ProductList = React.memo(function ProductList({ items, onDelete }) {
  console.log('ProductList rendered');
  return (
    <ul>
      {items.map((item) => (
        <li key={item.id}>
          {item.name} (${item.price})
          <button onClick={() => onDelete(item.id)}>Delete</button>
        </li>
      ))}
    </ul>
  );
});

function StoreDashboard() {
  const [products, setProducts] = useState([
    { id: 1, name: 'Mechanical Keyboard', price: 120 },
    { id: 2, name: '4K IPS Monitor', price: 500 }
  ]);
  const [themeDark, setThemeDark] = useState(false);

  // 1. useMemo: Caches expensive computation so theme toggling doesn't recalculate
  const grandTotal = useMemo(() => {
    return products.reduce((acc, curr) => acc + curr.price, 0);
  }, [products]);

  // 2. useCallback: Preserves function identity so ProductList skips re-render on theme toggle
  const handleDelete = useCallback((idToDelete) => {
    setProducts((prev) => prev.filter((p) => p.id !== idToDelete));
  }, []);

  return (
    <div style={{ background: themeDark ? '#1e293b' : '#ffffff', padding: '16px' }}>
      <h3>Inventory Value: ${grandTotal}</h3>
      <button onClick={() => setThemeDark((prev) => !prev)}>Toggle Theme</button>
      <ProductList items={products} onDelete={handleDelete} />
    </div>
  );
}

A custom hook is a JavaScript function whose name starts with use and that can invoke other React hooks. Custom hooks represent the pinnacle of modular engineering in functional React: they allow developers to extract complex, stateful business logic into reusable, testable functions without introducing wrapper components or restructuring the component hierarchy.

import { useState, useEffect } from 'react';

// Reusable custom hook synchronizing component state with browser localStorage
export function useLocalStorage(key, fallbackValue) {
  // 1. Lazy state initializer: reads localStorage strictly on initial mount
  const [value, setValue] = useState(() => {
    try {
      const item = window.localStorage.getItem(key);
      return item ? JSON.parse(item) : fallbackValue;
    } catch (err) {
      console.warn(`Failed reading localStorage key "${key}":`, err);
      return fallbackValue;
    }
  });

  // 2. Synchronize to localStorage whenever the key or value mutates
  useEffect(() => {
    try {
      window.localStorage.setItem(key, JSON.stringify(value));
    } catch (err) {
      console.warn(`Failed writing localStorage key "${key}":`, err);
    }
  }, [key, value]);

  return [value, setValue];
}

// Consumer Component: Interacting with useLocalStorage as cleanly as useState
function UserProfileSettings() {
  const [userName, setUserName] = useLocalStorage('profile_name', 'Student');

  return (
    <div className="card">
      <label>
        Persisted Username:
        <input
          value={userName}
          onChange={(e) => setUserName(e.target.value)}
          style={{ marginLeft: '8px' }}
        />
      </label>
    </div>
  );
}