The Problem with useState in Complex Forms

Before writing a single line of useReducer, here's what a typical multi-field form looks like with useState:

const [name, setName] = useState('');
const [email, setEmail] = useState('');
const [password, setPassword] = useState('');
const [errors, setErrors] = useState({});
const [isSubmitting, setIsSubmitting] = useState(false);
const [submitStatus, setSubmitStatus] = useState(null);

Six separate state variables that all need to move together — especially during submission. When isSubmitting is true, you want to clear errors, lock fields, and show a spinner. You're now coordinating six set* calls scattered across your handlers. This is where bugs live.

useReducer centralises all of that into a single, predictable state machine.

The State Shape

Design the state first, before writing any reducer logic. This single decision defines everything else.

const initialState = {
  values: {
    name: '',
    email: '',
    password: '',
    confirmPassword: '',
  },
  errors: {
    name: null,
    email: null,
    password: null,
    confirmPassword: null,
  },
  touched: {
    name: false,
    email: false,
    password: false,
    confirmPassword: false,
  },
  isSubmitting: false,
  submitStatus: null, // 'success' | 'error' | null
};

Three sub-objects matter here: values holds raw input, errors holds validation messages (or null when clean), and touched tracks whether the user has interacted with a field. Showing errors only on touched fields is the behaviour users actually expect.

The Action Types

Keep these as constants. String literals scattered across a codebase are a maintenance hazard.

const ACTIONS = {
  SET_FIELD: 'SET_FIELD',
  SET_TOUCHED: 'SET_TOUCHED',
  SET_ERROR: 'SET_ERROR',
  SET_ERRORS: 'SET_ERRORS',
  SUBMIT_START: 'SUBMIT_START',
  SUBMIT_SUCCESS: 'SUBMIT_SUCCESS',
  SUBMIT_FAILURE: 'SUBMIT_FAILURE',
  RESET: 'RESET',
};

The Reducer

This is the core. Every state transition lives here, nowhere else.

function formReducer(state, action) {
  switch (action.type) {
    case ACTIONS.SET_FIELD:
      return {
        ...state,
        values: {
          ...state.values,
          [action.field]: action.value,
        },
        // Clear the error as soon as the user starts correcting
        errors: {
          ...state.errors,
          [action.field]: null,
        },
      };

    case ACTIONS.SET_TOUCHED:
      return {
        ...state,
        touched: {
          ...state.touched,
          [action.field]: true,
        },
      };

    case ACTIONS.SET_ERROR:
      return {
        ...state,
        errors: {
          ...state.errors,
          [action.field]: action.message,
        },
      };

    case ACTIONS.SET_ERRORS:
      return {
        ...state,
        errors: {
          ...state.errors,
          ...action.errors,
        },
      };

    case ACTIONS.SUBMIT_START:
      return {
        ...state,
        isSubmitting: true,
        submitStatus: null,
        errors: Object.fromEntries(
          Object.keys(state.errors).map((k) => [k, null])
        ),
      };

    case ACTIONS.SUBMIT_SUCCESS:
      return {
        ...initialState,
        submitStatus: 'success',
      };

    case ACTIONS.SUBMIT_FAILURE:
      return {
        ...state,
        isSubmitting: false,
        submitStatus: 'error',
        errors: action.errors || state.errors,
      };

    case ACTIONS.RESET:
      return initialState;

    default:
      return state;
  }
}

Notice what SUBMIT_START does: it clears all errors in one shot and sets isSubmitting atomically. With useState, this is four separate calls. Here it's one dispatch, one render cycle. The SUBMIT_SUCCESS case resets to initialState but preserves submitStatus: 'success' so you can show a confirmation message.

The Validation Layer

Keep validation completely separate from state logic. It's a pure function — same input, same output, no side effects.

function validate(values) {
  const errors = {};

  if (!values.name.trim()) {
    errors.name = 'Name is required.';
  } else if (values.name.trim().length < 2) {
    errors.name = 'Name must be at least 2 characters.';
  }

  const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
  if (!values.email) {
    errors.email = 'Email is required.';
  } else if (!emailRegex.test(values.email)) {
    errors.email = 'Please enter a valid email address.';
  }

  if (!values.password) {
    errors.password = 'Password is required.';
  } else if (values.password.length < 8) {
    errors.password = 'Password must be at least 8 characters.';
  } else if (!/[A-Z]/.test(values.password)) {
    errors.password = 'Password must contain at least one uppercase letter.';
  }

  if (!values.confirmPassword) {
    errors.confirmPassword = 'Please confirm your password.';
  } else if (values.password !== values.confirmPassword) {
    errors.confirmPassword = 'Passwords do not match.';
  }

  return errors; // Empty object = no errors
}

The Custom Hook

Wrap all the dispatch logic into a custom hook. Your component should never know what dispatch is — it should only see named, intention-revealing handlers.

import { useReducer, useCallback } from 'react';

function useSignupForm() {
  const [state, dispatch] = useReducer(formReducer, initialState);

  const handleChange = useCallback((field, value) => {
    dispatch({ type: ACTIONS.SET_FIELD, field, value });
  }, []);

  const handleBlur = useCallback(
    (field) => {
      dispatch({ type: ACTIONS.SET_TOUCHED, field });

      // Validate the single field on blur
      const errors = validate(state.values);
      if (errors[field]) {
        dispatch({
          type: ACTIONS.SET_ERROR,
          field,
          message: errors[field],
        });
      }
    },
    [state.values]
  );

  const handleSubmit = useCallback(
    async (e) => {
      e.preventDefault();

      const errors = validate(state.values);
      const hasErrors = Object.keys(errors).length > 0;

      if (hasErrors) {
        // Mark all fields as touched so every error becomes visible
        dispatch({ type: ACTIONS.SET_ERRORS, errors });
        Object.keys(state.values).forEach((field) => {
          dispatch({ type: ACTIONS.SET_TOUCHED, field });
        });
        return;
      }

      dispatch({ type: ACTIONS.SUBMIT_START });

      try {
        // Replace this with your actual API call
        await fakeApiCall(state.values);
        dispatch({ type: ACTIONS.SUBMIT_SUCCESS });
      } catch (apiError) {
        dispatch({
          type: ACTIONS.SUBMIT_FAILURE,
          errors: apiError.fieldErrors || {},
        });
      }
    },
    [state.values]
  );

  const handleReset = useCallback(() => {
    dispatch({ type: ACTIONS.RESET });
  }, []);

  // Derived values — computed, not stored in state
  const isFormDirty = Object.values(state.values).some((v) => v !== '');
  const hasVisibleErrors = Object.entries(state.errors).some(
    ([field, msg]) => msg && state.touched[field]
  );

  return {
    values: state.values,
    errors: state.errors,
    touched: state.touched,
    isSubmitting: state.isSubmitting,
    submitStatus: state.submitStatus,
    isFormDirty,
    hasVisibleErrors,
    handleChange,
    handleBlur,
    handleSubmit,
    handleReset,
  };
}

isFormDirty and hasVisibleErrors are derived values — computed on every render from existing state. Never put derived values into state itself; that's how you get stale data. The only things that belong in state are values that can't be calculated — raw user input, server responses, async flags like isSubmitting. Everything else is fair game to derive.

The Component

With the hook doing all the heavy lifting, the component becomes almost entirely declarative.

function FieldError({ message, touched }) {
  if (!touched || !message) return null;
  return (
    <span role="alert" style={{ color: 'var(--color-text-danger)', fontSize: 13 }}>
      {message}
    </span>
  );
}

export default function SignupForm() {
  const {
    values,
    errors,
    touched,
    isSubmitting,
    submitStatus,
    isFormDirty,
    handleChange,
    handleBlur,
    handleSubmit,
    handleReset,
  } = useSignupForm();

  return (
    <form onSubmit={handleSubmit} noValidate>
      <div>
        <label htmlFor="name">Full name</label>
        <input
          id="name"
          type="text"
          value={values.name}
          onChange={(e) => handleChange('name', e.target.value)}
          onBlur={() => handleBlur('name')}
          disabled={isSubmitting}
          aria-invalid={touched.name && !!errors.name}
          aria-describedby={errors.name ? 'name-error' : undefined}
        />
        <FieldError message={errors.name} touched={touched.name} />
      </div>

      <div>
        <label htmlFor="email">Email</label>
        <input
          id="email"
          type="email"
          value={values.email}
          onChange={(e) => handleChange('email', e.target.value)}
          onBlur={() => handleBlur('email')}
          disabled={isSubmitting}
          aria-invalid={touched.email && !!errors.email}
        />
        <FieldError message={errors.email} touched={touched.email} />
      </div>

      <div>
        <label htmlFor="password">Password</label>
        <input
          id="password"
          type="password"
          value={values.password}
          onChange={(e) => handleChange('password', e.target.value)}
          onBlur={() => handleBlur('password')}
          disabled={isSubmitting}
          aria-invalid={touched.password && !!errors.password}
        />
        <FieldError message={errors.password} touched={touched.password} />
      </div>

      <div>
        <label htmlFor="confirmPassword">Confirm password</label>
        <input
          id="confirmPassword"
          type="password"
          value={values.confirmPassword}
          onChange={(e) => handleChange('confirmPassword', e.target.value)}
          onBlur={() => handleBlur('confirmPassword')}
          disabled={isSubmitting}
          aria-invalid={touched.confirmPassword && !!errors.confirmPassword}
        />
        <FieldError message={errors.confirmPassword} touched={touched.confirmPassword} />
      </div>

      {submitStatus === 'success' && (
        <p role="status" style={{ color: 'var(--color-text-success)' }}>
          Account created successfully!
        </p>
      )}

      {submitStatus === 'error' && (
        <p role="alert" style={{ color: 'var(--color-text-danger)' }}>
          Something went wrong. Please try again.
        </p>
      )}

      <button type="submit" disabled={isSubmitting}>
        {isSubmitting ? 'Creating account…' : 'Create account'}
      </button>

      {isFormDirty && (
        <button type="button" onClick={handleReset} disabled={isSubmitting}>
          Clear form
        </button>
      )}
    </form>
  );
}

The component contains zero business logic. It maps state to UI, and UI events to handlers. That's its entire job.

The State Machine, Visualised

Here's how the form moves through its lifecycle:Every box here corresponds to a distinct shape of your state object. The reducer enforces that you can only move along the valid arrows — there's no code path that accidentally leaves isSubmitting: true when an error happens.

Production Patterns Worth Noting

Why useCallback on every handler?

The custom hook returns new function references on every render by default. If you pass handleChange as a prop to a child field component wrapped in React.memo, a new reference breaks memoisation. useCallback with accurate dependency arrays prevents that.

Why clear errors on SET_FIELD?

The UX expectation is "error disappears the moment you start fixing it." If you only clear on re-blur, the user sees the error while they're typing the correction — that's friction with no payoff.

Why not store derived values in state?

isFormDirty is always computable from values. If you stored it separately, you'd need to remember to update it every time SET_FIELD fires. That's a coordination bug waiting to happen. Compute it, don't store it.

Why batch all touches on failed submit?

When a user clicks submit without touching any field, no errors are visible yet (because no field is touched). The submit handler marks all fields as touched at once, so every unfilled field suddenly shows its error. This is the standard behaviour users expect from production forms.

Why does SUBMIT_SUCCESS return { ...initialState, submitStatus: 'success' }?

If you returned initialState directly, submitStatus would be null and you'd have no way to show a success message. Spreading initialState and then overriding one key is the clean pattern.

Fake API for Testing

Here's a simple async stub you can swap out for a real call:

async function fakeApiCall(values) {
  await new Promise((res) => setTimeout(res, 1500));

  // Simulate a server-side email-taken error
  if (values.email === 'taken@example.com') {
    const err = new Error('Email already registered');
    err.fieldErrors = { email: 'This email is already in use.' };
    throw err;
  }
}

Notice err.fieldErrors — the reducer's SUBMIT_FAILURE case reads action.errors and spreads it into state.errors, so server-side field errors land in exactly the right place and show up under the right input.

What This Buys You

The architecture you now have is testable in complete isolation — you can import formReducer and validate and unit-test every transition without mounting a single component. The component itself is a thin presentation layer. The custom hook is the interface. The reducer is the contract.

When requirements change — add a username field, add async email-availability checks, add a progress stepper — you add to the state shape, add an action, and update the reducer. Nothing else needs to change.

Before writing a single line of code, let's build the right mental model.

You already know useState. It's clean, it's simple, and it works great when a piece of state is self-contained — like a toggle, a string input, or a counter. But as your component grows, you'll notice something uncomfortable: the logic for how state changes starts spreading everywhere. One button calls setCount(count + 1), another calls setCount(0), another calls setCount(count - 1), and suddenly your JSX is littered with little inline decisions about how state should change.

useReducer says: what if all those decisions lived in one place?

That one place is called a reducer — a pure function (returns same results with same set of inputs) that takes your current state and an action, and returns the new state. That's the whole pattern. Everything else is just details.

The Counter Example

Let's start with the simplest possible example: a counter with increment, decrement, and reset.

Step 1: Define Your State and Actions

First, think about what your state looks like and what can happen to it. For a counter, the state is just a number. The things that can happen are: go up, go down, reset.

// This is what our state looks like
const initialState = { count: 0 };

// These are the "things that can happen" — we call them actions.
// Each action is just a plain object with a 'type' field.
// { type: 'INCREMENT' }
// { type: 'DECREMENT' }
// { type: 'RESET' }

Step 2: Write the Reducer

The reducer is a function with a simple contract: given the current state and an action, return the next state. It never mutates — it always returns a fresh value.

function counterReducer(state, action) {
  switch (action.type) {
    case 'INCREMENT':
      return { count: state.count + 1 };

    case 'DECREMENT':
      return { count: state.count - 1 };

    case 'RESET':
      return { count: 0 };

    default:
      // If we receive an unknown action, return state unchanged.
      // This is a safety net — never throw away state accidentally.
      return state;
  }
}

Notice what's happening here: the reducer is a map from (state, action) → new state. It has no side effects. It doesn't call any APIs, doesn't touch the DOM, and doesn't depend on anything outside its arguments. This purity is what makes reducers so predictable and easy to test.

Step 3: Wire It Into the Component

Now you use useReducer(reducer, initialState). It hands you back two things — the current state, and a dispatch function. When you call dispatch({ type: 'INCREMENT' }), React runs your reducer with that action and re-renders the component with the new state.

import { useReducer } from 'react';

function counterReducer(state, action) {
  switch (action.type) {
    case 'INCREMENT':
      return { count: state.count + 1 };
    case 'DECREMENT':
      return { count: state.count - 1 };
    case 'RESET':
      return { count: 0 };
    default:
      return state;
  }
}

const initialState = { count: 0 };

export default function Counter() {
  // useReducer returns [currentState, dispatchFunction]
  const [state, dispatch] = useReducer(counterReducer, initialState);

  return (
    <div>
      <h2>Count: {state.count}</h2>

      {/* Each button just dispatches an action — it doesn't know HOW state changes */}
      <button onClick={() => dispatch({ type: 'INCREMENT' })}>+</button>
      <button onClick={() => dispatch({ type: 'DECREMENT' })}>−</button>
      <button onClick={() => dispatch({ type: 'RESET' })}>Reset</button>
    </div>
  );
}

Take a moment to notice how the JSX is now clean. The buttons don't contain logic — they just declare intent. "I want to increment." The reducer decides what that means.

The Key Mental Shift: Events vs. Mutations

Here's the most important idea behind the reducer pattern, and it's worth sitting with.

With useState, you think like this: "When this button is clicked, set the count to count + 1." You're thinking about mutations — directly manipulating the value.

With useReducer, you think like this: "When this button is clicked, something happened — an INCREMENT event occurred." You're thinking about events (or actions), and you're letting the reducer decide what the state should look like in response to that event.

This is the same shift that makes Redux, Flux, and even event-sourced databases so powerful. Your component becomes a sender of events, not a manager of state. The reducer owns all the logic.

Actions with Payloads

Real-world actions often carry data. Suppose you want an "add by N" button. You'd pass the number as a payload inside the action object:

// Dispatching an action with a payload
dispatch({ type: 'ADD_BY', payload: 5 });

// And in the reducer...
case 'ADD_BY':
  return { count: state.count + action.payload };

The convention is to use type for the action name and payload for the data it carries. This isn't enforced by React — it's just a widely adopted community pattern that keeps things readable.

When to Prefer useReducer Over useState

The React docs themselves give a clear rule of thumb here, and it maps well to real experience.

Reach for useReducer when your state has multiple sub-values that change together (like a form with name, email, and password), when the next state depends on the previous state in complex ways, or when you have many different ways to update state and the component is getting hard to read. If you ever find yourself writing three or four setState calls in a single event handler to keep things in sync, that's a strong signal to consolidate into a reducer.

On the other hand, useState remains the right tool for simple, isolated values. A modal's isOpen flag doesn't need a reducer. A single text input doesn't need a reducer. Match the tool to the complexity.

A Slightly Richer Example: Form State

To cement the idea, here's how the same reducer pattern scales gracefully to a login form — the kind of thing that would get messy fast with three separate useState calls.

const initialState = {
  username: '',
  password: '',
  isSubmitting: false,
};

function formReducer(state, action) {
  switch (action.type) {
    case 'SET_FIELD':
      // action.payload = { field: 'username', value: 'yashraj' }
      return { ...state, [action.payload.field]: action.payload.value };

    case 'SUBMIT_START':
      return { ...state, isSubmitting: true };

    case 'SUBMIT_DONE':
      return { ...state, isSubmitting: false };

    default:
      return state;
  }
}

function LoginForm() {
  const [state, dispatch] = useReducer(formReducer, initialState);

  const handleChange = (e) => {
    dispatch({
      type: 'SET_FIELD',
      payload: { field: e.target.name, value: e.target.value },
    });
  };

  const handleSubmit = async () => {
    dispatch({ type: 'SUBMIT_START' });
    await fakeApiCall(state);
    dispatch({ type: 'SUBMIT_DONE' });
  };

  return (
    <div>
      <input name="username" value={state.username} onChange={handleChange} />
      <input name="password" type="password" value={state.password} onChange={handleChange} />
      <button onClick={handleSubmit} disabled={state.isSubmitting}>
        {state.isSubmitting ? 'Logging in...' : 'Login'}
      </button>
    </div>
  );
}

Notice that SET_FIELD handles all fields with a single case — because the field name is part of the payload. All three fields stay in one state object, transitions are all visible in one reducer, and the component is left responsible only for rendering and dispatching.

The Bigger Picture: Where This Pattern Lives

useReducer is React's take on a much older idea. The reducer pattern is borrowed from functional programming — specifically from the Array.prototype.reduce idea that you fold a list of changes into a final value. Redux, which became enormously popular in the React ecosystem, is essentially this pattern at the application level.

Understanding useReducer well also makes the leap to Redux Context patterns, Zustand, and other state libraries much easier — because they all share this same vocabulary of actions, reducers, and dispatch.

Notes

The reducer pattern is fundamentally about separating what happened from what it means. Your UI dispatches events. Your reducer decides what those events mean for state. That separation keeps your components clean, your logic testable, and your state transitions auditable — you can read the reducer top to bottom and know every possible way your state can change.

Start with the counter. Internalize the (state, action) => newState contract. Then notice how naturally it scales when your state grows more complex. That's the pattern working as designed.

This article is about how experienced React engineers actually use useContext — the patterns that show up in real codebases, the mistakes that silently destroy performance, and the architectural decisions that make context scale without becoming a liability.

A Quick Reset: What You Already Know

const ThemeContext = createContext('light');

function App() {
  return (
    <ThemeContext.Provider value="dark">
      <Page />
    </ThemeContext.Provider>
  );
}

function Page() {
  const theme = useContext(ThemeContext);
  return <div className={theme}>Hello</div>;
}

This works. But in production, you'll almost never write context this raw. Let's build up from here.

Pattern 1: The Custom Hook Wrapper (The Standard)

Exposing the raw context object to consumers is a footgun. If someone calls useContext(ThemeContext) outside of a Provider, they get the default value silently — no error, no warning, just a bug that's hard to trace.

The fix is to wrap useContext in a custom hook that validates its environment:

// context/ThemeContext.js
import { createContext, useContext, useState } from 'react';

const ThemeContext = createContext(null);

export function ThemeProvider({ children }) {
  const [theme, setTheme] = useState('light');

  const toggle = () =>
    setTheme(prev => (prev === 'light' ? 'dark' : 'light'));

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

export function useTheme() {
  const context = useContext(ThemeContext);
  if (context === null) {
    throw new Error('useTheme must be used within a ThemeProvider');
  }
  return context;
}

Now consumers do this:

import { useTheme } from '@/context/ThemeContext';

function Navbar() {
  const { theme, toggle } = useTheme();
  return (
    <nav className={`navbar navbar--${theme}`}>
      <button onClick={toggle}>Switch to {theme === 'light' ? 'dark' : 'light'} mode</button>
    </nav>
  );
}

Why this matters:

• The error boundary is clear and immediate — you know exactly where the context is missing.

• Consumers never import the raw context object. They only import useTheme. This means you can completely refactor the internals later without touching a single consumer.

• It reads like domain language, not React plumbing.

Pattern 2: Auth Context — The Most Common Production Use Case

Authentication state is the canonical use case for context. It's global, it changes infrequently, and nearly every component in the app needs to read it (but rarely write it).

// context/AuthContext.js
import { createContext, useContext, useState, useEffect } from 'react';

const AuthContext = createContext(null);

export function AuthProvider({ children }) {
  const [user, setUser] = useState(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    // Simulate token check on mount
    const storedUser = localStorage.getItem('user');
    if (storedUser) {
      setUser(JSON.parse(storedUser));
    }
    setLoading(false);
  }, []);

  const login = async (credentials) => {
    const response = await fakeAuthAPI(credentials);
    setUser(response.user);
    localStorage.setItem('user', JSON.stringify(response.user));
  };

  const logout = () => {
    setUser(null);
    localStorage.removeItem('user');
  };

  return (
    <AuthContext.Provider value={{ user, loading, login, logout }}>
      {children}
    </AuthContext.Provider>
  );
}

export function useAuth() {
  const context = useContext(AuthContext);
  if (!context) throw new Error('useAuth must be used within AuthProvider');
  return context;
}

Now your protected routes become trivial to write:

function ProtectedRoute({ children }) {
  const { user, loading } = useAuth();

  if (loading) return <Spinner />;
  if (!user) return <Navigate to="/login" />;
  return children;
}

And your login button anywhere in the tree:

function Header() {
  const { user, logout } = useAuth();

  return (
    <header>
      {user ? (
        <>
          <span>Welcome, {user.name}</span>
          <button onClick={logout}>Sign out</button>
        </>
      ) : (
        <a href="/login">Sign in</a>
      )}
    </header>
  );
}

No props. No drilling through App → Layout → Header. Clean.

Pattern 3: Splitting Context to Avoid Unnecessary Re-renders

Here's a performance trap most React developers hit once and never forget.

Imagine you have a shopping cart context:

// ❌ The naive version
const CartContext = createContext(null);

export function CartProvider({ children }) {
  const [items, setItems] = useState([]);
  const [isOpen, setIsOpen] = useState(false);

  const addItem = (item) => setItems(prev => [...prev, item]);
  const removeItem = (id) => setItems(prev => prev.filter(i => i.id !== id));
  const toggle = () => setIsOpen(prev => !prev);

  return (
    <CartContext.Provider value={{ items, isOpen, addItem, removeItem, toggle }}>
      {children}
    </CartContext.Provider>
  );
}

Every time isOpen toggles (like when the cart drawer opens), every component consuming this context re-renders — including your product cards that only care about addItem. This is wasteful and gets expensive at scale.

The fix: split your context by update frequency and concern.

// ✅ Split context
const CartStateContext = createContext(null);
const CartActionsContext = createContext(null);
const CartUIContext = createContext(null);

export function CartProvider({ children }) {
  const [items, setItems] = useState([]);
  const [isOpen, setIsOpen] = useState(false);

  // Memoize actions so their references stay stable
  const actions = useMemo(() => ({
    addItem: (item) => setItems(prev => [...prev, item]),
    removeItem: (id) => setItems(prev => prev.filter(i => i.id !== id)),
  }), []);

  const ui = useMemo(() => ({
    isOpen,
    toggle: () => setIsOpen(prev => !prev),
  }), [isOpen]);

  return (
    <CartActionsContext.Provider value={actions}>
      <CartUIContext.Provider value={ui}>
        <CartStateContext.Provider value={items}>
          {children}
        </CartStateContext.Provider>
      </CartUIContext.Provider>
    </CartActionsContext.Provider>
  );
}

// Each hook only subscribes to what it needs
export const useCartItems = () => useContext(CartStateContext);
export const useCartActions = () => useContext(CartActionsContext);
export const useCartUI = () => useContext(CartUIContext);

Now a product card that just needs addItem consumes useCartActions — it will never re-render when the cart drawer opens or closes.

Pattern 4: Multi-Level Context (Scope-Aware Providers)

Context isn't just for global, app-wide state. You can scope it to a subtree — and this is an underused, powerful pattern.

Imagine a DataGrid component. Each row needs to know its own row data and whether it's selected. You don't want this to live in global state. Instead, create row-scoped context:

const RowContext = createContext(null);

function DataGrid({ rows }) {
  return (
    <table>
      <tbody>
        {rows.map(row => (
          <RowContext.Provider key={row.id} value={row}>
            <TableRow />
          </RowContext.Provider>
        ))}
      </tbody>
    </table>
  );
}

function TableRow() {
  const row = useContext(RowContext);
  return (
    <tr>
      <td>{row.name}</td>
      <td>{row.status}</td>
      <ActionCell />
    </tr>
  );
}

function ActionCell() {
  const row = useContext(RowContext); // Gets the nearest Provider's value
  return <button onClick={() => handleAction(row.id)}>Edit</button>;
}

Each <RowContext.Provider> wraps its own row. Any component inside that row can reach up and grab that row's data without knowing where it lives in the component tree. This is the same mechanism that makes compound component patterns like <Select> / <Option> work in UI libraries.

Pattern 5: Context + useReducer (The Flux-Lite Pattern)

When your context state has multiple related fields and complex transitions, useState gets messy. useReducer pairs naturally with context to give you Redux-like clarity without the Redux overhead.

const initialState = {
  theme: 'light',
  language: 'en',
  notifications: true,
};

function settingsReducer(state, action) {
  switch (action.type) {
    case 'SET_THEME':
      return { ...state, theme: action.payload };
    case 'SET_LANGUAGE':
      return { ...state, language: action.payload };
    case 'TOGGLE_NOTIFICATIONS':
      return { ...state, notifications: !state.notifications };
    case 'RESET':
      return initialState;
    default:
      throw new Error(`Unknown action: ${action.type}`);
  }
}

const SettingsContext = createContext(null);

export function SettingsProvider({ children }) {
  const [settings, dispatch] = useReducer(settingsReducer, initialState);

  return (
    <SettingsContext.Provider value={{ settings, dispatch }}>
      {children}
    </SettingsContext.Provider>
  );
}

export function useSettings() {
  const ctx = useContext(SettingsContext);
  if (!ctx) throw new Error('useSettings must be used within SettingsProvider');
  return ctx;
}

Consumer usage is clear and intention-revealing:

function SettingsPanel() {
  const { settings, dispatch } = useSettings();

  return (
    <div>
      <select
        value={settings.theme}
        onChange={e => dispatch({ type: 'SET_THEME', payload: e.target.value })}
      >
        <option value="light">Light</option>
        <option value="dark">Dark</option>
      </select>

      <button onClick={() => dispatch({ type: 'TOGGLE_NOTIFICATIONS' })}>
        Notifications: {settings.notifications ? 'On' : 'Off'}
      </button>

      <button onClick={() => dispatch({ type: 'RESET' })}>
        Reset to defaults
      </button>
    </div>
  );
}

The reducer acts as a single source of truth for all state transitions. Each dispatch call is an explicit, named event — easy to trace, easy to test.

The Performance Reality Check

useContext does not bail out of re-renders. Unlike useState which skips re-renders when the value doesn't change, every context consumer re-renders whenever the Provider's value prop changes — even if the part of the value they use is the same.

The most common mistake is creating a new object reference on every render:

// ❌ New object on every render = every consumer re-renders every time
<AuthContext.Provider value={{ user, login, logout }}>

Fix it with useMemo:

// ✅ Stable reference unless user, login, or logout change
const value = useMemo(() => ({ user, login, logout }), [user, login, logout]);
<AuthContext.Provider value={value}>

For functions specifically, use useCallback:

const login = useCallback(async (credentials) => {
  const res = await authAPI(credentials);
  setUser(res.user);
}, []); // No deps — this never needs to change

When to Reach for Zustand or Redux Instead

Context is not a state management library. It's a dependency injection mechanism. The distinction matters:

Context re-renders all consumers on value change. This is fine when the data changes rarely (theme, auth, settings). It becomes a problem when dat a updates multiple times per second or when thousands of components are subscribed.

Putting It Together: A Real Feature

Here's what a complete, production-ready notification system looks like using everything above:

// context/NotificationContext.js
import { createContext, useContext, useReducer, useCallback } from 'react';

const NotificationContext = createContext(null);

function notificationReducer(state, action) {
  switch (action.type) {
    case 'ADD':
      return [...state, { id: Date.now(), ...action.payload }];
    case 'REMOVE':
      return state.filter(n => n.id !== action.id);
    case 'CLEAR':
      return [];
    default:
      return state;
  }
}

export function NotificationProvider({ children }) {
  const [notifications, dispatch] = useReducer(notificationReducer, []);

  const notify = useCallback((message, type = 'info') => {
    const id = Date.now();
    dispatch({ type: 'ADD', payload: { message, type } });

    // Auto-dismiss after 4s
    setTimeout(() => dispatch({ type: 'REMOVE', id }), 4000);
  }, []);

  const dismiss = useCallback((id) => {
    dispatch({ type: 'REMOVE', id });
  }, []);

  return (
    <NotificationContext.Provider value={{ notifications, notify, dismiss }}>
      {children}
      <NotificationToast />
    </NotificationContext.Provider>
  );
}

export function useNotification() {
  const ctx = useContext(NotificationContext);
  if (!ctx) throw new Error('useNotification must be used within NotificationProvider');
  return ctx;
}

// The UI layer lives inside the Provider itself
function NotificationToast() {
  const { notifications, dismiss } = useContext(NotificationContext);

  return (
    <div className="toast-container">
      {notifications.map(n => (
        <div key={n.id} className={`toast toast--${n.type}`}>
          <span>{n.message}</span>
          <button onClick={() => dismiss(n.id)}>×</button>
        </div>
      ))}
    </div>
  );
}

Anywhere in your app:

function SaveButton() {
  const { notify } = useNotification();

  const handleSave = async () => {
    try {
      await saveData();
      notify('Changes saved successfully', 'success');
    } catch {
      notify('Failed to save. Please try again.', 'error');
    }
  };

  return <button onClick={handleSave}>Save</button>;
}

No prop threading. No event emitters. No external libraries. Just context doing exactly what it was built for.

Key Takeaways

• Always wrap useContext in a custom hook. It enforces provider boundaries, hides implementation details, and reads like your domain.

• Split contexts by concern. State, actions, and UI state often belong in separate contexts when they update at different frequencies.

• Memoize your context value. An inline object literal creates a new reference on every render. useMemo stops that.

• Pair useReducer with context when state has complex transitions or more than two or three related fields.

• Scope context to subtrees, not just the app root — it's a powerful pattern for compound components and reusable feature modules.

• Know when to stop. Context is a delivery mechanism, not a substitute for Zustand, Redux, or React Query when you're dealing with high-frequency or server-synchronized state.

Simply put, useContext is a built-in React hook that lets any component read shared data directly — without needing someone to pass it down through props.

useContext is a React Hook that lets you read and subscribe to context from your component.

Think of it like a group chat. Instead of one person forwarding a message to the next person, who forwards it to the next — you just broadcast it to the whole group and anyone who needs it can read it.

Here's the signature. It really is this simple:

const value = useContext(MyContext);

Internally, useContext is built on top of React’s Context API — a feature designed to share data across a component tree without manually passing props at every level. It is commonly used for values that are needed globally in the app, such as the current user, theme, or language.

2. Why Do We Need It? (The Prop Drilling Problem)

To understand the benefit, first imagine the problem.

Suppose your app needs to show the logged-in user’s name in multiple places like the Navbar, Sidebar, Profile page, and a deeply nested Settings panel. Without context, you would need to pass the user prop through every component in the hierarchy — even through components that don’t actually use it.

This situation is known as prop drilling.

Example structure:

App (contains user data)
  └── Layout (passes user prop)
        └── Sidebar (passes user prop)
              └── Panel (passes user prop)
                    └── UserCard ← finally uses the user data

Layout, Sidebar, and Panel don't need user at all. They're just acting as middlemen. This makes your code:

• Hard to read — component signatures get bloated with props they don't use

• Hard to refactor — rename a prop and you're updating five files

• Fragile — add a new layer and you need to thread the prop through again

useContext solves this cleanly. You broadcast the value from the top, and UserCard subscribes directly — all the middle components stay completely unaware.

3. How It Works: The 3-Step Pattern

Using useContext always follows the same three steps.

Step 1 — Create the context

// ThemeContext.js
import { createContext } from 'react';

// The argument is the default value (used when no Provider is found above)
export const ThemeContext = createContext('light');

Step 2 — Wrap your component tree with a Provider

// App.jsx
import { useState } from 'react';
import { ThemeContext } from './ThemeContext';

export default function App() {
  const [theme, setTheme] = useState('light');

  return (
    // Every child inside this Provider can read "theme"
    <ThemeContext.Provider value={theme}>
      <Navbar />
      <MainContent />
      <button onClick={() => setTheme(t => t === 'light' ? 'dark' : 'light')}>
        Toggle Theme
      </button>
    </ThemeContext.Provider>
  );
}

Step 3 — Consume it anywhere with useContext

// Navbar.jsx
import { useContext } from 'react';
import { ThemeContext } from './ThemeContext';

function Navbar() {
  // No props needed — just read directly
  const theme = useContext(ThemeContext);

  return <nav className={`navbar ${theme}`}>Current theme: {theme}</nav>;
}

That's the entire pattern. Create → Provide → Consume.

4. Basic Example: Theme Switcher

Here's the complete example in one place, copy-paste ready:

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

// 1. Create context
const ThemeContext = createContext('light');

// 2. Custom hook (optional but highly recommended)
function useTheme() {
  return useContext(ThemeContext);
}

// 3. A deeply nested component — zero props needed
function Card() {
  const theme = useTheme();
  const isDark = theme === 'dark';

  return (
    <div style={{
      background: isDark ? '#1e1e3a' : '#ffffff',
      color: isDark ? '#ffffff' : '#1a1a2e',
      padding: '16px',
      borderRadius: '8px'
    }}>
      <p>I'm a card in <strong>{theme}</strong> mode!</p>
    </div>
  );
}

// 4. Root component — provides the value
export default function App() {
  const [theme, setTheme] = useState('light');

  return (
    <ThemeContext.Provider value={theme}>
      <Card />
      <button onClick={() => setTheme(t => t === 'light' ? 'dark' : 'light')}>
        Toggle Theme
      </button>
    </ThemeContext.Provider>
  );
}

Pro tip: Notice the useTheme() custom hook. Instead of calling useContext(ThemeContext) in every file, you wrap it once and export a clean, meaningful hook name. This is considered best practice and makes your code easier to test and change later.

5. Real-World Example: Auth Context

Authentication is the most common real-world use for context. Here's a production-ready pattern:

// AuthContext.jsx
import { createContext, useContext, useState, useMemo } from 'react';

const AuthContext = createContext(null);

export function AuthProvider({ children }) {
  const [user, setUser] = useState(null);

  const value = useMemo(() => ({
    user,
    login: (userData) => setUser(userData),
    logout: () => setUser(null),
  }), [user]);

  return (
    <AuthContext.Provider value={value}>
      {children}
    </AuthContext.Provider>
  );
}

// Custom hook with a helpful error guard
export function useAuth() {
  const context = useContext(AuthContext);
  if (!context) {
    throw new Error('useAuth must be used inside <AuthProvider>');
  }
  return context;
}

Now in any component, anywhere in the app:

function Dashboard() {
  const { user, logout } = useAuth();

  return (
    <div>
      <h1>Welcome, {user.name}!</h1>
      <button onClick={logout}>Log out</button>
    </div>
  );
}

Clean, readable, and no prop chains in sight.

6. Performance Considerations

The core rule: Every component that calls useContext will re-render whenever the context value changes — even if the specific part it uses hasn't changed.

The Re-render Trap

// ❌ One giant context — a cart update re-renders EVERYONE
<AppContext.Provider value={{ user, theme, cart, settings }}>
  {children}
</AppContext.Provider>

If cart updates (say, someone adds an item), every single component consuming AppContext will re-render — including those that only care about theme or user. On a large app, this adds up fast.

The Fix: Split Contexts by Concern

// ✅ Separate contexts — cart updates only affect cart consumers
<ThemeContext.Provider value={theme}>
  <AuthContext.Provider value={user}>
    <CartContext.Provider value={cart}>
      {children}
    </CartContext.Provider>
  </AuthContext.Provider>
</ThemeContext.Provider>

Each context now updates independently. A cart change doesn't wake up your theme consumers.

Memoize Your Context Value

When your context value is an object, React creates a new object reference on every render — which triggers all consumers even if the data hasn't changed. Fix it with useMemo:

// Without useMemo, this object is new every render
const value = useMemo(() => ({
  user,
  login,
  logout,
}), [user]); // Only recreates when 'user' actually changes

Quick Performance Checklist

7. Use Cases — Where useContext Shines

Here are the situations where useContext is the right tool for the job:

Theme / Dark Mode — Store the active color scheme globally. Any component can read and respond to theme changes without a single prop.

Authentication — Share the logged-in user's profile, permissions, and auth actions (login/logout) across every page and component.

Internationalization (i18n) — Provide the active locale and translation function app-wide so every piece of text can render in the right language.

Shopping Cart — Track cart items and totals globally so the Navbar badge, product pages, and checkout all stay in sync.

Notifications / Toast Messages — Trigger alerts from deep inside a component tree without wiring up callbacks all the way to the root.

App-wide Preferences — Font size, currency, accessibility settings — any user preference that multiple unrelated components need to respect.

8. useContext vs Redux / Zustand

A very common question: "Now that we have useContext, do we still need Redux?"

Honest answer — sometimes yes, sometimes no. They solve slightly different problems.

The rule of thumb: Use useContext for things that change infrequently and are needed broadly — theme, auth, locale. Reach for Redux or Zustand when your state updates often, your logic is complex, or you need powerful debugging tools.

Many mature apps use both — context for global config, a dedicated store for business logic.

9. Summary — The useContext Cheat Sheet

Here's everything in one place:

1. Create — const MyContext = createContext(defaultValue)

2. Provide — Wrap your tree with <MyContext.Provider value={...}>

3. Consume — Read anywhere with const val = useContext(MyContext)

4. Abstract — Wrap in a custom hook (useAuth, useTheme) for a clean API

5. Split — Separate contexts by concern to avoid cascading re-renders

6. Memoize — Wrap object values in useMemo to stabilize references

One thing to avoid: Don't reach for context for everything. Local UI state — dropdown open/closed, form input values, hover states — still belongs in useState inside the component. Context is for data that truly needs to be global.

useContext is one of those hooks that quietly makes your entire codebase cleaner once you internalize the pattern. Start by picking one prop you've been drilling through three or more components and migrate it to context. The clarity you get back is immediate.

It is one of the most frequently asked topics in DSA interviews.

What is a Heap?

A heap is a Complete Binary Tree, which means:

• All levels are completely filled

• The last level is filled from left to right

Heaps are typically implemented using arrays, not pointer-based trees.

Heap Property

There are two types of heaps:

🔹 Min-Heap

• Parent node is smaller than its children

• The smallest element is always at the root

🔹 Max-Heap

• Parent node is greater than its children

• The largest element is always at the root

In Python, the heapq module implements a Min-Heap by default.

Array Representation of Heap

For a node at index i (0-based indexing):

• Left child → 2*i + 1

• Right child → 2*i + 2

• Parent → (i - 1) // 2

This is why heaps are implemented efficiently using arrays.

Common Heap Operations & Time Complexity

Using Heap in Python (heapq)

1️⃣ Build Min Heap (Heapify)

Time: O(n)
Space: O(1) (in-place)

import heapq

A = [-4, 3, 1, 0, 2, 5, 10, 8, 12, 9]
heapq.heapify(A) #O(n)

print(A)

heapify() converts a list into a valid heap in linear time.

⚡ Interview Insight:
Building a heap using repeated insertion takes O(n log n), but heapify() does it in O(n).

2️⃣ Insert into Heap

Time: O(log n)

heapq.heappush(A, 4)
print(A)

3️⃣ Extract Minimum

Time: O(log n)

min_val = heapq.heappop(A)
print(A, min_val)

4️⃣ Peek Minimum (Without Removing)

Time: O(1)

A[0]

The smallest element is always at index 0.

5️⃣ Heappush + Heappop Combined

Time: O(log n)

heapq.heappushpop(A, 99)
print(A)

More efficient than doing push then pop separately.

Heap Sort in Python

Time: O(n log n)
Space: O(n) (extra list used)

def heapsort(arr):
    heapq.heapify(arr)
    result = []

    while arr:
        result.append(heapq.heappop(arr))

    return result

print(heapsort([1, 3, 5, 7, 9, 2, 4, 6, 8, 0]))

⚠️ Note:
In-place heap sort with O(1) space is possible but more complex to implement manually.

Max Heap in Python

Python does not directly support max-heap.
We simulate it by inserting negative values.

B = [-4, 3, 1, 0, 2, 5, 10, 8, 12, 9]

# Convert to negative
B = [-x for x in B]

heapq.heapify(B)

largest = -heapq.heappop(B)
print(largest)

# Insert 7
heapq.heappush(B, -7)

⚡ Interview Tip:
This technique is very commonly used in competitive programming.

Build Heap from Scratch (Using Insert)

Time: O(n log n)

C = [-5, 4, 2, 1, 7, 0, 3]
heap = []

for x in C:
    heapq.heappush(heap, x)
    print(heap)

Repeated insertion is slower than heapify.

Using Tuples in Heap

Heaps can store tuples.

Python compares tuples element by element.

Example: Frequency-based sorting.

from collections import Counter
import heapq

D = [5, 4, 3, 5, 4, 3, 5, 5, 4]
counter = Counter(D)

heap = []

for key, value in counter.items():
    heapq.heappush(heap, (value, key))

print(heap)

This is used in:

• Top K Frequent Elements

• Frequency Sorting

• Scheduling Problems

Priority Queue vs Heap

A Priority Queue is an abstract data structure.

A Heap is one way to implement it efficiently.

Priority Queue ensures:

• Highest (or lowest) priority element is removed first.

Median of Data Stream (Two Heaps Technique)

One of the most popular heap-based interview problems is:

Design a data structure that supports adding numbers and finding the median at any time.

Problem Statement

You continuously receive numbers from a data stream.

You must support two operations:

1. addNum(num) → Add a number

2. findMedian() → Return the median of all inserted numbers

Why Sorting Every Time Is Not Good?

If you sort the array every time:

• Insertion → O(1)

• Sorting → O(n log n)

• Finding median → O(1)

This is inefficient for large streams.

We need something better.

Optimal Approach: Two Heaps

We use:

• 🔹 Max Heap → Stores the smaller half of numbers

• 🔹 Min Heap → Stores the larger half of numbers

Why Two Heaps?

We divide numbers into two balanced halves:

Max Heap (left side)  |  Min Heap (right side)
Smaller numbers       |  Larger numbers

This ensures:

• Median is either:

  • Top of one heap

  • Or average of tops of both heaps

Important Rules

1. Size difference between heaps should not exceed 1

2. All elements in max heap ≤ elements in min heap

Python Implementation

Since Python only provides a Min Heap,

we simulate a Max Heap using negative values.

import heapq

class MedianFinder:

    def __init__(self):
        self.small = []  # Max heap (invert values)
        self.large = []  # Min heap

    def addNum(self, num):

        # Step 1: Push to max heap (invert value)
        heapq.heappush(self.small, -num)

        # Step 2: Ensure ordering property
        if self.small and self.large and (-self.small[0] > self.large[0]):
            value = -heapq.heappop(self.small)
            heapq.heappush(self.large, value)

        # Step 3: Balance sizes
        if len(self.small) > len(self.large) + 1:
            value = -heapq.heappop(self.small)
            heapq.heappush(self.large, value)

        if len(self.large) > len(self.small):
            value = heapq.heappop(self.large)
            heapq.heappush(self.small, -value)

    def findMedian(self):

        if len(self.small) > len(self.large):
            return -self.small[0]

        return (-self.small[0] + self.large[0]) / 2

Time Complexity

This is optimal.

Example

Input Stream:

1 → median = 1
1, 2 → median = 1.5
1, 2, 3 → median = 2
1, 2, 3, 4 → median = 2.5

Heaps internally balance automatically.

In this blog, we will use LL as short form for Linked List.

What is a Linked List?

A Linked List is a collection of individual nodes connected using memory addresses (references).

Each node contains:

• A value

• A reference (pointer) to the next node

We do not store elements in continuous memory like arrays.

Head of Linked List

Every linked list has a starting point called the Head.

• The head points to the first node.

• In most problems, the head is already given to you.

• All operations (traversal, insertion, deletion) start from the head.

Structure of a Node (Singly Linked List)

Here is the correct Python structure:

class Node:
    def __init__(self, val, next=None):
        self.val = val
        self.next = next

Explanation:

• val → stores the data.

• next → stores the reference to the next node.

• None means there is no next node (end of the list).

Traversal of Linked List

To traverse a linked list:

• Start from head

• Move until it becomes None

In Python, we use None instead of null.

def traverse(head):
    while head:
        print(head.val)
        head = head.next   # Move to next node

Time Complexity → O(N)

Types of Linked Lists

1️⃣ Singly Linked List

• Each node points to the next node only.

• Traversal is possible in one direction only.

2️⃣ Doubly Linked List

In a doubly linked list:

• Each node stores reference to:

  • Next node

  • Previous node

• We usually maintain both Head and Tail.

Structure:

class DoublyNode:
    def __init__(self, val, next=None, prev=None):
        self.val = val
        self.next = next
        self.prev = prev

Advantages:

• Can traverse in both directions.

• Deletion becomes easier if node reference is given.

Reverse a Linked List

This is one of the most commonly asked DSA interview questions.

There are two ways to reverse a linked list:

1️⃣ Iterative Approach

def reverse_ll_iterative(head):
    prev = None
    current = head  # Always use a separate pointer for traversal

    while current:
        next_node = current.next
        current.next = prev
        prev = current
        current = next_node

    return prev

Time Complexity → O(N)

Space Complexity → O(1)

Why interviewers prefer this:

• Efficient

• No extra space

• Clear pointer manipulation understanding

2️⃣ Recursive Approach

Corrected version:

def reverse_ll_recursive(head):
    if not head or not head.next:
        return head

    new_head = reverse_ll_recursive(head.next)

    head.next.next = head
    head.next = None

    return new_head

Time Complexity → O(N)

Space Complexity → O(N) (because of recursion stack)

⚠️ Important:
In interviews, mention that recursion uses extra stack space.

Linked lists are used in:

• Stack and Queue implementation

• LRU Cache

• Hash collisions (chaining)

• Graph adjacency list

• Merge Two Sorted Lists

• Detect Cycle (Floyd’s Algorithm)

If you understand pointer manipulation clearly, many advanced problems become easier.

A Graph is a data structure used to represent relationships between different entities.

It consists of:

• Vertices (Nodes) → Represent entities

• Edges → Represent connections between nodes

Example:

• Social networks

• Maps and routes

• Web pages linking to each other

• Dependency graphs

Types of Graphs

1️⃣ Directed Graph → Edges have direction
2️⃣ Undirected Graph → Edges have no direction
3️⃣ Weighted Graph → Edges have weights (cost/distance)
4️⃣ Unweighted Graph → No weights

Graph Representation in Python

Most common representation in DSA interviews:

Adjacency List (Most Preferred)

graph = {
    1: [2, 3],
    2: [4],
    3: [],
    4: []
}

This means:

• 1 is connected to 2 and 3

• 2 is connected to 4

Time-efficient and memory-efficient.

BFS (Breadth First Search)

BFS explores level by level.

It uses a Queue.

When to Use BFS?

• Shortest path in unweighted graph

• Level order traversal

• Finding minimum steps

BFS Code (Python)

from collections import deque

def bfs(graph, start):
    visited = set()
    queue = deque([start])
    visited.add(start)

    while queue:
        node = queue.popleft()
        print(node)

        for neighbor in graph[node]:
            if neighbor not in visited:
                visited.add(neighbor)
                queue.append(neighbor)

Time Complexity → O(V + E)

Example Question (BFS)

Question: Find the shortest path from node 1 to all other nodes in an unweighted graph.

👉 Use BFS because it guarantees shortest path in unweighted graphs.

DFS (Depth First Search)

DFS explores as deep as possible before backtracking.

It uses:

• Recursion (stack)

• Or an explicit stack

DFS Code (Recursive)

def dfs(graph, node, visited):
    if node in visited:
        return

    visited.add(node)
    print(node)

    for neighbor in graph[node]:
        dfs(graph, neighbor, visited)

Call it like:

visited = set()
dfs(graph, 1, visited)

Time Complexity → O(V + E)

When to Use DFS?

• Detect cycles

• Backtracking problems

• Topological sort

• Checking connectivity

Example Question (DFS)

Question: Detect if a graph has a cycle.

👉 DFS is commonly used for cycle detection.

Dijkstra’s Algorithm

Used to find the shortest path in a weighted graph.

⚠️ Works only when weights are non-negative.

When to Use Dijkstra?

• Shortest path in weighted graph

• Network routing

• Map navigation systems

Example Graph (Weighted)

graph = {
    0: [(1, 4), (2, 1)],
    1: [(3, 1)],
    2: [(1, 2), (3, 5)],
    3: []
}

Each tuple: (neighbor, weight)

Dijkstra’s Algorithm Code (Python)

import heapq

def dijkstra(graph, start):
    min_heap = [(0, start)]  # (distance, node)
    distances = {node: float('inf') for node in graph}
    distances[start] = 0

    while min_heap:
        current_distance, current_node = heapq.heappop(min_heap)

        if current_distance > distances[current_node]:
            continue

        for neighbor, weight in graph[current_node]:
            distance = current_distance + weight

            if distance < distances[neighbor]:
                distances[neighbor] = distance
                heapq.heappush(min_heap, (distance, neighbor))

    return distances

Time Complexity of Dijkstra

Using Min-Heap (Priority Queue):

👉 O((V + E) log V)

Example Question (Dijkstra)

Question: Given a weighted graph and a source node, find the shortest path to all other nodes.

👉 Use Dijkstra if:

• Weights are non-negative

• You need shortest path

Graphs are one of the most powerful and frequently asked topics in DSA interviews.
If you master BFS, DFS, and Dijkstra, you can solve a large percentage of graph problems confidently.

Arrays allow easy and fast access to elements using an index, which makes them one of the most important data structures in DSA.

In Python, we don’t have traditional arrays like in C++ or Java.
Instead, we use something called a List.

Python Lists (Dynamic Arrays)

In Python, a list is a dynamic array.

Example:

arr = [1, 2, 3, 4, 5]

Key Characteristics:

• Lists are mutable → They can be changed after declaration.

• They are dynamic → Their size can grow or shrink.

• They allow index-based access → arr[0], arr[1], etc.

Static vs Dynamic Arrays

🔹 Static Array

• Size is fixed.

• Cannot grow after creation.

• Example: Arrays in C++

🔹 Dynamic Array (Python List)

• Size can increase or decrease.

• Memory is managed automatically.

• Used in almost all DSA problems in Python.

Important List Operations

1️⃣ Access by Index → O(1)

arr[2]

Accessing an element using an index is constant time.

2️⃣ Searching for an Element → O(N)

if 5 in arr:
    print(True)

This takes O(N) time because Python needs to traverse the list element by element.

3️⃣ Important Dynamic Array Methods

✅ append() → O(1) (Amortized)

arr.append(6)

• Adds an element to the end.

• Amortized O(1) means most of the time it is constant time.

• Occasionally, resizing happens internally, which takes O(N), but overall average remains O(1).

✅ pop() → O(1)

arr.pop()

• Removes the last element.

• Constant time operation.

⚠️ pop(index) is O(N) because shifting is required.

✅ insert(index, value) → O(N)

arr.insert(2, 10)

• Inserts element at a specific position.

• All elements after that index need to shift.

• Therefore, time complexity is O(N).

✅ len() → O(1)

len(arr)

• Returns the number of elements in the list.

• Constant time operation.

Why Arrays (Lists) Are Extremely Important in DSA

Most beginner DSA problems are based on arrays:

• Two Sum

• Sliding Window

• Prefix Sum

• Kadane’s Algorithm

• Sorting

• Binary Search

Tuples

A tuple in Python is an ordered collection of elements, just like a list.

However, the key difference is:

👉 Tuples are immutable.

Once a tuple is created, its values cannot be changed.

How to Create a Tuple

t = (1, 2, 3, 4)

You can also create a tuple without parentheses:

t = 1, 2, 3

Tuple vs List (Important Difference)

Why Tuples Matter in DSA

Although tuples are not used as frequently as lists in basic DSA problems, they are very useful in certain scenarios:

1️⃣ Returning Multiple Values from a Function

def min_max(arr):
    return (min(arr), max(arr))

2️⃣ Storing Fixed Data

For example:

• Coordinates → (x, y)

• Graph edges → (node1, node2)

• Key-value pairs

Important Interview Insight ⚡

🔹 Tuples are Hashable (if elements are immutable)

This means they can be used as keys in dictionaries or stored inside sets.

Example:

visited = set()
visited.add((1, 2))

This is very common in:

• Graph problems

• Grid-based problems

• Backtracking problems

Lists cannot be used as dictionary keys because they are mutable.

Time Complexity

• Index access → O(1)

• Searching → O(N)

• No append, insert, or remove (because immutable)

When Should You Use a Tuple?

Use a tuple when:

• Data should not change

• You want slightly better performance

• You need to use the value as a dictionary key

• You are returning multiple values from a function

Key Takeaway

Tuples are like "fixed lists."
They protect your data from accidental modification and are especially useful in hashing-related problems in DSA.

This means once a string is created, it cannot be changed.

Example:

s = "python"

s[0] = "P"   # ❌ This will give an error

You cannot modify a character directly inside a string.

What Does “Immutable” Mean?

If you try to change a string, Python does not modify the original string.
Instead, it creates a new string in memory.

Example:

s = "python"
s = "Python"

Here, a new string is created.

Some of the most common and useful string methods are:

Case Conversion: upper(), lower(), capitalize(), title(), and swapcase() allow for changing the casing of strings.

Searching: Methods like find(), index(), and count() locate or count substrings, while startswith() and endswith() check string boundaries.

Modification: strip() (and lstrip()/rstrip()) removes whitespace, replace() substitutes substrings, split() divides strings into lists, and join() concatenates iterables.

Formatting/Validation: format() or f-strings are used for string formatting, while isalpha(), isdigit(), and isalnum() validate string content.

Why Is This Important in DSA?

Many interview problems are based on strings:

• Palindrome problems

• Anagram checking

• Substring problems

• Pattern matching

• Sliding window on strings

Because strings are immutable:

• You cannot modify characters directly.

• You often convert strings into lists when modification is required.

Example:

s = "python"
s_list = list(s)
s_list[0] = "P"
s = "".join(s_list)

Searching in a String → O(N)

You can check whether a character exists in a string using:

if "a" in s:
    print(True)

This operation takes O(N) time because Python may need to traverse the entire string.

Time Complexity :

• Index access → O(1)

• Searching → O(N)

• Concatenation inside a loop → Can become O(N²) (be careful!)

For large string manipulation problems, consider:

• Using a list for modification

• Using join() instead of repeated concatenation

DSA (Data Structures and Algorithms) is one of the most important subjects to learn as a coder or software engineer. Most companies test DSA concepts during technical interviews.

In real-world jobs, you may not directly implement complex DSA algorithms every day (except for applying the core concepts and logic). Still, companies strongly focus on DSA during interviews.

The reason behind this is not just to check whether you know trees or graphs. The real purpose is to evaluate your problem-solving skills — how you approach complex and large problems, how you break them down, and how you handle a task without going blank.

This is what truly matters.

Nowadays, simply memorizing syntax is not enough. Many companies even allow candidates to use Google or AI tools to look up syntax or small code snippets. However, tools cannot replace logical thinking.

To solve problems efficiently, you still need to remember basic syntax — such as how to use queues, define variables, write loops, and apply built-in functions. Knowing these fundamentals reduces the time spent searching for syntax and allows you to focus completely on the logic of solving the problem.

And in DSA, logic is everything.

Why choose python ?

You can choose any programming language to learn DSA.

However, most people usually pick one of these three:

• C++

• Java

• Python

Among these, Python has the simplest and most readable syntax. It is easy to understand and easier to remember compared to the others.

If you are a working professional, you are likely already using a different language or framework in your job. Learning DSA in a language with heavy syntax can sometimes feel overwhelming.

That is why Python is a great choice. You spend less time worrying about syntax and more time focusing on logic and problem-solving. It helps you conserve mental energy and use your brainpower where it truly matters — solving problems.

In this blog, we will focus only on the essential concepts and syntax required for DSA. No unnecessary theory, no extra distractions — just what you actually need to remember.

Let’s get started. 🚀

Variables in Python :

In Python, defining a variable is very simple.
You only need to write the variable name and assign a value to it. There is no need to explicitly mention the data type like in C++ or Java.

This is one of the biggest reasons why Python is beginner-friendly and widely used for learning Data Structures and Algorithms (DSA).

Example :

string = "python for dsa"
number = 2
floating_number = 2.9869
character = "c"
bit = 0 
largest_number = float("inf") 
smallest_number = float("-inf")

Why This Matters in DSA

In languages like C++ or Java, you must define the data type explicitly:

int number = 2;

But in Python, the interpreter automatically detects the type. This feature is called dynamic typing.

Important for Interviews ⚡

When solving DSA problems:

• You often need variables to store counts, indexes, flags, or temporary values.

• You may need very large or very small values while comparing numbers.

• float("inf") and float("-inf") are extremely useful in problems like:

  • Finding minimum or maximum values

  • Binary search variations

  • Dynamic programming

  • Greedy algorithms

Example use case:

min_value = float("inf")

This ensures that any number compared with min_value will be smaller initially.

What Makes useRef Different?

At first glance, useRef might seem similar to useState. Both persist values across renders, both are React hooks, and both are tools for managing component state. But here's the crucial difference: when you update a ref, your component doesn't re-render. When you update state with useState, it does.

Think of useRef as a box that holds a value. You can put something in the box, take it out, or replace it with something else—all without React caring about what you're doing. The component won't re-render, no matter how many times you change what's inside.

const countRef = useRef(0);

// This will NOT cause a re-render
countRef.current = countRef.current + 1;

Compare this to useState:

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

// This WILL cause a re-render
setCount(count + 1);

When Should You Actually Use useRef?

The question isn't just "can I use useRef?" but "should I use useRef?" Here are the scenarios where it makes the most sense.

Accessing DOM Elements Directly

This is probably the most common use case, and it's the one that feels most natural coming from vanilla JavaScript. Sometimes you just need direct access to a DOM node—maybe to focus an input, measure an element's dimensions, or integrate with a third-party library that expects a DOM reference.

function TextInputWithFocus() {
  const inputRef = useRef(null);

  const handleFocus = () => {
    inputRef.current.focus();
  };

  return (
    <div>
      <input ref={inputRef} type="text" />
      <button onClick={handleFocus}>Focus the input</button>
    </div>
  );
}

This pattern is clean, straightforward, and doesn't introduce any unnecessary re-renders.

Storing Previous Values

One particularly useful pattern is storing the previous value of a prop or state. This lets you compare current and previous values without the complexity of additional state management.

function usePrevious(value) {
  const ref = useRef();

  useEffect(() => {
    ref.current = value;
  });

  return ref.current;
}

function Counter({ count }) {
  const previousCount = usePrevious(count);

  return (
    <div>
      <p>Current: {count}</p>
      <p>Previous: {previousCount}</p>
      <p>Changed by: {count - (previousCount || 0)}</p>
    </div>
  );
}

This works because useEffect runs after the render, so ref.current still holds the old value during the render phase.

Managing Timers and Intervals

If you've ever tried to clear a timer in a React component, you know the pain of losing the timer ID between renders. useRef solves this elegantly.

function Timer() {
  const [seconds, setSeconds] = useState(0);
  const intervalRef = useRef(null);

  const startTimer = () => {
    if (intervalRef.current !== null) return;

    intervalRef.current = setInterval(() => {
      setSeconds(s => s + 1);
    }, 1000);
  };

  const stopTimer = () => {
    if (intervalRef.current === null) return;

    clearInterval(intervalRef.current);
    intervalRef.current = null;
  };

  useEffect(() => {
    return () => {
      if (intervalRef.current !== null) {
        clearInterval(intervalRef.current);
      }
    };
  }, []);

  return (
    <div>
      <p>Seconds: {seconds}</p>
      <button onClick={startTimer}>Start</button>
      <button onClick={stopTimer}>Stop</button>
    </div>
  );
}

The ref keeps track of the interval ID across renders, and we can reliably clear it when needed.

Avoiding Stale Closures

Here's where things get interesting. Sometimes you need the latest value of a prop or state inside a callback that doesn't re-create on every render. This is where refs can save you from the dreaded stale closure problem.

function SearchComponent() {
  const [query, setQuery] = useState('');
  const latestQueryRef = useRef(query);

  useEffect(() => {
    latestQueryRef.current = query;
  }, [query]);

  const handleSearch = useCallback(() => {
    // This always has the latest query value
    // even though handleSearch doesn't change
    fetch(`/api/search?q=${latestQueryRef.current}`)
      .then(response => response.json())
      .then(data => console.log(data));
  }, []); // Empty deps - function never recreates

  return (
    <div>
      <input 
        value={query} 
        onChange={(e) => setQuery(e.target.value)} 
      />
      <button onClick={handleSearch}>Search</button>
    </div>
  );
}

Common Pitfalls and How to Avoid Them

Don't Read Refs During Render

This is the biggest mistake developers make with useRef. Reading ref.current during the render phase can lead to inconsistent behavior because refs don't trigger re-renders.

// ❌ Bad - reading ref during render
function BadExample() {
  const countRef = useRef(0);

  const increment = () => {
    countRef.current++;
  };

  // This will always show 0 because changing the ref doesn't re-render
  return <div>{countRef.current}</div>;
}

// ✅ Good - use state for values that affect the UI
function GoodExample() {
  const [count, setCount] = useState(0);

  const increment = () => {
    setCount(count + 1);
  };

  return <div>{count}</div>;
}

Remember: Refs are Synchronous

Unlike state updates, which React batches and processes asynchronously, ref updates happen immediately and synchronously.

function Example() {
  const ref = useRef(0);

  const handleClick = () => {
    ref.current = 1;
    console.log(ref.current); // Logs 1 immediately

    ref.current = 2;
    console.log(ref.current); // Logs 2 immediately
  };
}

This can be both a blessing and a curse. It's great when you need immediate access to a value, but it means you need to be careful about when and how you update refs.

useRef vs useState: Making the Right Choice

The decision between useRef and useState comes down to one key question: does this value need to trigger a re-render when it changes?

Use useState when:

• The value affects what's rendered on screen

• You need React to respond to changes in the value

• The value is part of your component's visual state

Use useRef when:

• The value doesn't affect the rendered output

• You need to store metadata about your component

• You're interacting with DOM elements directly

• You need to avoid triggering re-renders for performance

Advanced Pattern: Combining useRef with useEffect

One powerful pattern is using refs to track whether a component has mounted or to prevent certain effects from running on the initial render.

function ComponentWithMountCheck() {
  const [data, setData] = useState(null);
  const hasMounted = useRef(false);

  useEffect(() => {
    if (!hasMounted.current) {
      hasMounted.current = true;
      return;
    }

    // This only runs on updates, not on mount
    console.log('Data changed:', data);
    saveDataToLocalStorage(data);
  }, [data]);

  return <div>{/* Your component */}</div>;
}

This pattern is particularly useful when you want different behavior on mount versus subsequent updates.

Performance Considerations

Using useRef appropriately can significantly improve your component's performance. Since refs don't cause re-renders, they're perfect for storing values that change frequently but don't need to update the UI.

Consider a scroll position tracker:

function ScrollTracker() {
  const scrollPositionRef = useRef(0);
  const [visibleSection, setVisibleSection] = useState('top');

  useEffect(() => {
    const handleScroll = () => {
      scrollPositionRef.current = window.scrollY;

      // Only update state (and trigger re-render) when crossing thresholds
      if (scrollPositionRef.current > 500 && visibleSection !== 'bottom') {
        setVisibleSection('bottom');
      } else if (scrollPositionRef.current <= 500 && visibleSection !== 'top') {
        setVisibleSection('top');
      }
    };

    window.addEventListener('scroll', handleScroll);
    return () => window.removeEventListener('scroll', handleScroll);
  }, [visibleSection]);

  return <div>Current section: {visibleSection}</div>;
}

Here, we're tracking every scroll event with a ref (no re-renders), but only updating state when it actually matters for the UI.

Real-World Example: Debounced Search

Let's put it all together with a practical example that combines several concepts:

function DebouncedSearch() {
  const [searchTerm, setSearchTerm] = useState('');
  const [results, setResults] = useState([]);
  const timeoutRef = useRef(null);
  const requestRef = useRef(null);

  const performSearch = async (term) => {
    if (requestRef.current) {
      requestRef.current.abort();
    }

    const controller = new AbortController();
    requestRef.current = controller;

    try {
      const response = await fetch(`/api/search?q=${term}`, {
        signal: controller.signal
      });
      const data = await response.json();
      setResults(data);
    } catch (error) {
      if (error.name !== 'AbortError') {
        console.error('Search failed:', error);
      }
    }
  };

  const handleSearchChange = (e) => {
    const value = e.target.value;
    setSearchTerm(value);

    if (timeoutRef.current) {
      clearTimeout(timeoutRef.current);
    }

    timeoutRef.current = setTimeout(() => {
      if (value.trim()) {
        performSearch(value);
      } else {
        setResults([]);
      }
    }, 300);
  };

  useEffect(() => {
    return () => {
      if (timeoutRef.current) {
        clearTimeout(timeoutRef.current);
      }
      if (requestRef.current) {
        requestRef.current.abort();
      }
    };
  }, []);

  return (
    <div>
      <input 
        type="text"
        value={searchTerm}
        onChange={handleSearchChange}
        placeholder="Search..."
      />
      <ul>
        {results.map(result => (
          <li key={result.id}>{result.title}</li>
        ))}
      </ul>
    </div>
  );
}

This example demonstrates several key useRef patterns: managing timers, handling cleanup, and tracking mutable values that don't need to cause re-renders.

Wrapping Up

The useRef hook is one of those tools that seems simple on the surface but reveals its true power once you understand when and how to use it properly. It's not about replacing useState—it's about complementing it. Use refs for implementation details that don't affect the rendered output, and you'll write more efficient, cleaner React code.

The key takeaway? If changing a value should update what the user sees, use useState. If it's just something you need to remember between renders without affecting the UI, reach for useRef. Master this distinction, and you'll avoid a lot of common React performance issues while writing more maintainable code.

In React's declarative world, we typically let React handle DOM updates. However, there are times when you need to directly interact with DOM elements—focusing an input field, measuring an element's dimensions, or integrating with third-party libraries. This is where useRef becomes essential.

In this guide, we'll explore how to use useRef to access DOM nodes, starting from the basics and building up to production-ready patterns.

What is useRef?

useRef is a React Hook that creates a mutable reference object that persists across re-renders. Unlike state, updating a ref doesn't trigger a component re-render, making it perfect for storing values that shouldn't affect the visual output.

Basic Syntax

const myRef = useRef(initialValue);

The ref object has a single property called current that holds the actual value. When you attach a ref to a DOM element, React automatically sets ref.current to that DOM node.

Your First Ref: Focusing an Input

Let's start with the most common use case—focusing an input field when a component mounts.

Basic Example

import { useRef, useEffect } from 'react';

function SearchBox() {
  const inputRef = useRef(null);

  useEffect(() => {
    // Focus the input when component mounts
    inputRef.current.focus();
  }, []);

  return (
    <input 
      ref={inputRef}
      type="text" 
      placeholder="Start typing..." 
    />
  );
}

How it works:

1. We create a ref with useRef(null) (null is the initial value)

2. We attach the ref to the input using the ref attribute

3. React sets inputRef.current to the actual DOM element

4. In useEffect, we call inputRef.current.focus() to focus the input

Production-Grade Example: Advanced Search Component

Here's a real-world example that demonstrates multiple ref patterns you'll use in production applications.

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

function AdvancedSearchBar({ onSearch, autoFocus = false }) {
  const [query, setQuery] = useState('');
  const [isSearching, setIsSearching] = useState(false);
  const inputRef = useRef(null);
  const searchTimeoutRef = useRef(null);

  // Auto-focus on mount if specified
  useEffect(() => {
    if (autoFocus && inputRef.current) {
      inputRef.current.focus();
    }
  }, [autoFocus]);

  // Cleanup timeout on unmount
  useEffect(() => {
    return () => {
      if (searchTimeoutRef.current) {
        clearTimeout(searchTimeoutRef.current);
      }
    };
  }, []);

  const handleInputChange = (e) => {
    const value = e.target.value;
    setQuery(value);

    // Clear existing timeout
    if (searchTimeoutRef.current) {
      clearTimeout(searchTimeoutRef.current);
    }

    // Debounce search
    setIsSearching(true);
    searchTimeoutRef.current = setTimeout(() => {
      onSearch(value);
      setIsSearching(false);
    }, 500);
  };

  const handleClear = () => {
    setQuery('');
    onSearch('');
    // Focus input after clearing
    inputRef.current?.focus();
  };

  const handleKeyDown = (e) => {
    if (e.key === 'Escape') {
      handleClear();
    }
  };

  return (
    <div className="search-container">
      <input
        ref={inputRef}
        type="text"
        value={query}
        onChange={handleInputChange}
        onKeyDown={handleKeyDown}
        placeholder="Search..."
        aria-label="Search input"
        aria-busy={isSearching}
      />
      {query && (
        <button 
          onClick={handleClear}
          aria-label="Clear search"
          type="button"
        >
          Clear
        </button>
      )}
      {isSearching && <span>Searching...</span>}
    </div>
  );
}

Key Patterns Demonstrated

1. Conditional Focus

if (autoFocus && inputRef.current) {
  inputRef.current.focus();
}

Always check if ref.current exists before accessing it. This prevents errors during initial render or if the component unmounts.

2. Multiple Refs We use two refs: one for the DOM node (inputRef) and one for storing the timeout ID (searchTimeoutRef). Refs aren't just for DOM nodes—they're perfect for any mutable value that shouldn't cause re-renders.

3. Optional Chaining

inputRef.current?.focus();

Using ?. ensures we don't throw an error if the ref is null.

Common DOM Operations with useRef

Measuring Elements

function ImageGallery() {
  const containerRef = useRef(null);
  const [dimensions, setDimensions] = useState({ width: 0, height: 0 });

  useEffect(() => {
    if (containerRef.current) {
      const { width, height } = containerRef.current.getBoundingClientRect();
      setDimensions({ width, height });
    }
  }, []);

  return (
    <div ref={containerRef}>
      <p>Container size: {dimensions.width}x{dimensions.height}</p>
    </div>
  );
}

Scrolling to Elements

function ChatWindow({ messages }) {
  const bottomRef = useRef(null);

  useEffect(() => {
    // Scroll to bottom when new messages arrive
    bottomRef.current?.scrollIntoView({ behavior: 'smooth' });
  }, [messages]);

  return (
    <div className="chat-messages">
      {messages.map(msg => (
        <div key={msg.id}>{msg.text}</div>
      ))}
      <div ref={bottomRef} />
    </div>
  );
}

Playing/Pausing Media

function VideoPlayer({ src }) {
  const videoRef = useRef(null);
  const [isPlaying, setIsPlaying] = useState(false);

  const togglePlay = () => {
    if (videoRef.current) {
      if (isPlaying) {
        videoRef.current.pause();
      } else {
        videoRef.current.play();
      }
      setIsPlaying(!isPlaying);
    }
  };

  return (
    <div>
      <video ref={videoRef} src={src} />
      <button onClick={togglePlay}>
        {isPlaying ? 'Pause' : 'Play'}
      </button>
    </div>
  );
}

Best Practices

1. Always Check for Null

// Good
if (inputRef.current) {
  inputRef.current.focus();
}

// Better
inputRef.current?.focus();

// Bad - can throw error
inputRef.current.focus();

2. Don't Overuse Refs

Use refs only when you need to step outside React's declarative paradigm. For most UI updates, state and props are the right choice.

// Bad - using ref for something state should handle
const countRef = useRef(0);
countRef.current += 1; // Won't trigger re-render

// Good - use state for values that affect rendering
const [count, setCount] = useState(0);
setCount(c => c + 1); // Triggers re-render

3. Clean Up Side Effects

When using refs with timers, event listeners, or subscriptions, always clean them up.

useEffect(() => {
  const element = elementRef.current;

  const handleClick = () => console.log('clicked');
  element?.addEventListener('click', handleClick);

  return () => {
    element?.removeEventListener('click', handleClick);
  };
}, []);

4. Use TypeScript for Type Safety

const inputRef = useRef<HTMLInputElement>(null);
const videoRef = useRef<HTMLVideoElement>(null);
const divRef = useRef<HTMLDivElement>(null);

Common Pitfalls to Avoid

Pitfall 1: Accessing Refs During Render

// Bad - don't access ref.current during render
function MyComponent() {
  const ref = useRef(null);
  console.log(ref.current); // Will be null on first render
  return <div ref={ref}>Content</div>;
}

// Good - access in useEffect or event handlers
function MyComponent() {
  const ref = useRef(null);

  useEffect(() => {
    console.log(ref.current); // Now it's safe
  }, []);

  return <div ref={ref}>Content</div>;
}

Pitfall 2: Forgetting Dependencies

// Bad - missing dependency
useEffect(() => {
  inputRef.current?.focus();
}, []); // If inputRef comes from props, this is wrong

// Good - include all dependencies
useEffect(() => {
  inputRef.current?.focus();
}, [inputRef]);

Conclusion

The useRef hook is a powerful tool for accessing DOM nodes in React. Remember these key points:

• Use useRef when you need direct DOM access

• Always check if ref.current exists before using it

• Access refs in useEffect or event handlers, not during render

• Clean up any side effects that use refs

• Prefer state for values that should trigger re-renders

With these patterns, you're ready to handle DOM manipulation confidently in your React applications.

Further Reading:

• React useRef Documentation

• Manipulating the DOM with Refs

• Understanding React Refs

First,

What is key ?

A key is any identifier that:

1. Uniquely represents a piece of data or request

2. Needs to be consistently routed to the same node

3. Can be hashed to produce a number

Why consistent hashing exists?

The problem it solves:

Traditional hashing uses: server = hash(key) % number_of_servers

Example with 4 servers:

• hash("user:123") % 4 = 2 → Server 2

• hash("user:456") % 4 = 1 → Server 1

What breaks:

When you add/remove a server (say go from 4 to 5 servers):

• hash("user:123") % 5 = 3 → Now Server 3 (was Server 2!)

• hash("user:456") % 5 = 1 → Still Server 1 (lucky!)

Result: Almost every key gets remapped to a different server because the modulo divisor changed. If you have 1 million cached items, adding one server means ~800,000+ cache misses and data movement.

Consistent hashing fixes this:

When adding/removing servers, only ~K/N keys need remapping (where K = total keys, N = number of servers).

• Add a server: ~1/N keys move

• Remove a server: only that server's keys move

Real-world impact:

Without consistent hashing:

• Adding a cache server → entire cache invalidated → database meltdown

• Server failure → all keys remapped → cascading failures

With consistent hashing:

• Adding a cache server → smooth, minimal disruption

• Server failure → only affected keys redistributed

Bottom line: It enables elastic scaling in distributed systems without causing massive data shuffles that would overwhelm your infrastructure.

How it works

1. Hash Ring Creation: A large, circular hash space (the "ring") is defined, using a hash function (like MD5) for both servers and data keys.

2. Node Placement: Each server (or node) is hashed and placed at a specific point on the ring, often using multiple virtual points for better distribution.

3. Data Mapping: Data keys are also hashed, placing them on the ring.

4. Assignment: A data key is assigned to the first server encountered when moving clockwise from the key's position on the ring.

Common enhancement:

Systems often use "virtual nodes"—each physical server gets multiple positions on the ring. This distributes load more evenly and prevents hotspots when servers have different capacities.

Real-world uses:

Distributed caches (Memcached, Redis clusters), distributed databases (Cassandra, DynamoDB), and content delivery networks all use consistent hashing to efficiently distribute data across changing sets of servers.

The problem without virtual nodes:

Imagine you have 3 servers on the hash ring. With simple consistent hashing, each server appears once on the ring at a random position. You might end up with:

Server A: position 100
Server B: position 200  
Server C: position 500

This creates uneven ranges:

• Server A handles keys from 500→100 (a huge arc of ~600 units)

• Server B handles keys from 100→200 (only 100 units)

• Server C handles keys from 200→500 (300 units)

Server A gets 6x more load than Server B—very unbalanced!

The solution with virtual nodes:

Instead of placing each server once, you create multiple "virtual" copies. Say 150 virtual nodes per physical server:

Server A: positions 45, 123, 289, 467, 891, ... (150 positions total)
Server B: positions 12, 234, 356, 678, 923, ... (150 positions total)
Server C: positions 78, 145, 401, 567, 834, ... (150 positions total)

Now the ring has 450 points instead of 3, and they're scattered throughout. This means:

• Each server's ranges are distributed across the entire ring

• Load averages out statistically—each server handles roughly 33% of keys

• When a server fails, its load redistributes evenly across remaining servers

How this virtual nodes are placed in ring ?

The placement of virtual nodes uses hash functions to generate their positions on the ring.

For each physical server, you generate multiple virtual node identifiers and hash them:

Server A, Virtual Node 0: hash("ServerA-0") → position 12847
Server A, Virtual Node 1: hash("ServerA-1") → position 98234
Server A, Virtual Node 2: hash("ServerA-2") → position 45621
...
Server A, Virtual Node 149: hash("ServerA-149") → position 73012

Common patterns:

1. Append index: hash(serverID + index)

   • Example: hash("192.168.1.10-0"), hash("192.168.1.10-1")

2. Random seeds: Use different hash functions or seeds

   • Example: MD5(serverID + vnodeNumber)

3. Multiple hash functions: Apply different hashes to the same server ID

   • Example: SHA1(serverID), MD5(serverID), CRC32(serverID)

Key properties:

• The hash function produces pseudo-random but deterministic positions

• Positions are uniformly distributed across the ring (0 to 2^32 or similar)

• Same server always gets the same virtual node positions (deterministic)

• Different servers get different positions (good hash distribution)

Data structure:

In practice, you maintain a sorted list or tree of all virtual node positions:

[12847 → Server A, 23456 → Server C, 45621 → Server A, 67890 → Server B, ...]

When a key needs placement, you hash it and do a binary search to find the next position clockwise—that's the responsible server.

Real-world example of how a request flows through a consistent hashing system

Scenario: Distributed Cache (like Memcached cluster)

You have 3 cache servers with 3 virtual nodes each:

Hash Ring (0 to 999 for simplicity):
Position 045 → Server A (vnode 0)
Position 123 → Server B (vnode 0)
Position 234 → Server C (vnode 0)
Position 456 → Server A (vnode 1)
Position 567 → Server B (vnode 1)
Position 678 → Server C (vnode 1)
Position 789 → Server A (vnode 2)
Position 890 → Server B (vnode 2)
Position 912 → Server C (vnode 2)

Request comes in:

A user requests: GET user:12345:profile

Step-by-step:

1. Hash the key: hash("user:12345:profile") → 500

2. Find position on ring: Looking at position 500, search clockwise for the next server: ... 456 (Server A) < 500 < 567 (Server B) ...

The next position clockwise is 567 → Server B

3. Route to Server B: Request goes to Server B (192.168.1.20):

Client → Load Balancer → Server B

4. Server B handles it

   • If data exists: return from cache

   • If miss: fetch from database, cache it, return to client

Another request:

GET user:99999:profile

1. hash("user:99999:profile") → 800

2. Next position clockwise: 890 → Server B

3. Route to Server B again

Third request:

GET user:55555:profile

1. hash("user:55555:profile") → 100

2. Next position clockwise: 123 → Server B

3. Route to Server B

Fourth request:

GET product:88888:details

1. hash("product:88888:details") → 950

2. Next position clockwise: wrap around to 045 → Server A

3. Route to Server A

What happens when Server C fails?

Ring becomes:

Position 045 → Server A
Position 123 → Server B
Position 456 → Server A
Position 567 → Server B
Position 789 → Server A
Position 890 → Server B
(Server C's positions removed)

Keys that were on Server C (positions 234, 678, 912) now redistribute:

• Keys near 234 → go to Server A (position 456)

• Keys near 678 → go to Server A (position 789)

• Keys near 912 → go to Server A (position 045)

Only ~33% of keys are remapped (those that were on Server C), not the entire dataset!

The useEffect cleanup function is an optional function you can return from within the useEffect Hook that handles the cleanup of side effects to prevent memory leaks and unwanted behavior in your application.

useEffect(() => {
    // Setup the side effect
    const intervalId = setInterval(() => {
      setCount(c => c + 1);
    }, 1000);

    // Return the cleanup function
    return () => {
      clearInterval(intervalId); // Tidy up the interval
    };
  }, []); // Empty dependency array means it runs on mount and cleans up on unmount

The cleanup function should stop or undo whatever the setup function was doing.

Purpose and When It Runs

It runs in two main scenarios:

• Before the component unmounts (removed from the DOM).

• Before the effect runs again due to a change in its dependencies.

This ensures that the previous effect is tidied up before a new one is initiated, preventing issues like trying to update the state of an unmounted component or having multiple intervals running simultaneously. It is very important to clean up to prevent unwanted issues at production grade application.

The Problem: Resource Leaks in Component Lifecycles

Consider a real-time dashboard that displays user activity data. The component fetches updates every 5 seconds using a polling mechanism:

function UserActivityDashboard() {
  const [activities, setActivities] = useState([]);

  useEffect(() => {
    const interval = setInterval(() => {
      fetchUserActivities().then(data => {
        setActivities(data);
      });
    }, 5000);
  }, []);

  return (
    <div>
      {activities.map(activity => (
        <ActivityCard key={activity.id} {...activity} />
      ))}
    </div>
  );
}

The Critical Flaw: When this component unmounts (user navigates away), the interval continues executing in the background. Each time the user returns to the dashboard, a new interval is created without clearing the previous one. Since this browser APIs are outside of react control it will be keep running even though component is not present on page, react knows that but browser does not.

Consequences Without Cleanup:

• Multiple intervals run simultaneously, multiplying API requests

• Server load increases exponentially with each component mount/unmount cycle

• Memory consumption grows continuously as abandoned intervals accumulate

• State updates may be attempted on unmounted components, triggering React warnings

• API rate limits may be exceeded, causing service degradation

• Increased infrastructure costs from unnecessary network traffic

The Solution: Implementing Cleanup Functions

The cleanup function returned from useEffect executes when the component unmounts or before the effect runs again, ensuring proper resource disposal:

function UserActivityDashboard() {
  const [activities, setActivities] = useState([]);

  useEffect(() => {
    const interval = setInterval(() => {
      fetchUserActivities().then(data => {
        setActivities(data);
      });
    }, 5000);

    // Cleanup function - runs on unmount
    return () => {
      clearInterval(interval);
    };
  }, []);

  return (
    <div>
      {activities.map(activity => (
        <ActivityCard key={activity.id} {...activity} />
      ))}
    </div>
  );
}

The cleanup function ensures that when the component unmounts, the interval is properly cleared, preventing the accumulation of background processes.

Common Scenarios Requiring Cleanup

1. WebSocket Connections

WebSocket connections maintain persistent, bidirectional communication channels between client and server:

useEffect(() => {
  const ws = new WebSocket('wss://api.example.com/live');

  ws.onmessage = (event) => {
    setMessages(prev => [...prev, event.data]);
  };

  return () => {
    ws.close();
  };
}, []);

What This Does: The effect establishes a WebSocket connection and registers a message handler. When messages arrive from the server, they're added to the existing messages array using the functional form of setState (prev => [...prev, event.data]), which ensures we're working with the most current state.

Consequences Without Cleanup:

• Socket connections remain open indefinitely, consuming server resources

• The server continues sending messages to disconnected clients

• Multiple socket connections accumulate for the same user session

• Message handlers attempt to update state on unmounted components

• Server-side connection limits may be reached, affecting all users

• Memory leaks occur from retained message handlers and accumulated data

• Network bandwidth is wasted on messages sent to inactive connections

2. Event Listeners

DOM event listeners attach handlers to global objects like window or document:

useEffect(() => {
  const handleResize = () => {
    setWindowWidth(window.innerWidth);
  };

  window.addEventListener('resize', handleResize);

  return () => {
    window.removeEventListener('resize', handleResize);
  };
}, []);

What This Does: The effect registers a resize event listener on the window object. The handler captures the current window width and updates component state. The cleanup function removes the listener when the component unmounts.

Consequences Without Cleanup:

• Event listeners accumulate with each component mount, creating duplicates

• All registered handlers execute on every event, causing redundant processing

• Memory leaks occur as handlers maintain references to unmounted components

• Performance degrades as the number of active listeners grows

• setState calls on unmounted components trigger console warnings

• Browser DevTools show increasing numbers of event listeners over time

• Application responsiveness decreases due to excessive event handling

3. Asynchronous Operations with State Updates

Async operations may complete after a component has unmounted, attempting to update non-existent state:

useEffect(() => {
  let isCancelled = false;

  async function loadUser() {
    const user = await fetchUser(userId);
    if (!isCancelled) {
      setUser(user);
    }
  }

  loadUser();

  return () => {
    isCancelled = true;
  };
}, [userId]);

What This Does: The effect initiates an async data fetch and uses a cancellation flag to track whether the component is still mounted. The cleanup function sets this flag to true, preventing state updates if the fetch completes after unmounting. When userId changes, the cleanup runs before the new effect, canceling the previous request.

Consequences Without Cleanup:

• React warnings: "Can't perform a React state update on an unmounted component"

• Race conditions where older requests overwrite newer data

• Unnecessary network requests continue processing despite irrelevant results

• Memory isn't freed properly as callbacks hold references to unmounted components

• Application state becomes inconsistent when stale data overwrites current state

• Debugging becomes difficult due to non-deterministic state updates

• User experience suffers from UI flickering as outdated data briefly appears

4. Subscriptions (e.g., Firebase, Redux)

External data subscriptions require explicit unsubscription to prevent leaks:

useEffect(() => {
  const unsubscribe = firestore
    .collection('messages')
    .onSnapshot(snapshot => {
      const messages = snapshot.docs.map(doc => ({
        id: doc.id,
        ...doc.data()
      }));
      setMessages(messages);
    });

  return () => {
    unsubscribe();
  };
}, []);

What This Does: The effect creates a real-time subscription to a Firestore collection. The onSnapshot method returns an unsubscribe function, which we store and call during cleanup to terminate the subscription.

Consequences Without Cleanup:

• Active subscriptions continue consuming backend resources

• Real-time updates trigger state changes on unmounted components

• Database read operations continue, increasing billing costs

• Multiple subscriptions to the same data source accumulate

• Server maintains unnecessary open connections

• Memory leaks from retained snapshot listeners and callbacks

• Network bandwidth wasted on updates for inactive UI components

5. Animation Frames

RequestAnimationFrame creates render loops that must be canceled:

useEffect(() => {
  let animationId;

  const animate = () => {
    setPosition(prev => ({
      x: prev.x + velocity.x,
      y: prev.y + velocity.y
    }));
    animationId = requestAnimationFrame(animate);
  };

  animationId = requestAnimationFrame(animate);

  return () => {
    cancelAnimationFrame(animationId);
  };
}, [velocity.x, velocity.y]);

What This Does: The effect creates a recursive animation loop using requestAnimationFrame, updating position on every frame. The cleanup function cancels any pending animation frame when the component unmounts or when velocity dependencies change.

Consequences Without Cleanup:

• Animation loops continue running invisibly in the background

• CPU usage remains high even when animations aren't visible

• Battery drain on mobile devices due to constant rendering

• Multiple animation loops run simultaneously, compounding performance issues

• Frame rate decreases as orphaned animations accumulate

• Browser becomes unresponsive under the load of hundreds of animation frames

• Thermal throttling may occur on devices from sustained high CPU usage

Best Practices

Rule of Principle: If an effect creates a resource, establishes a connection, registers a listener, or initiates an ongoing process, it must include cleanup logic. The cleanup function should reverse or terminate whatever the effect established.

Testing Cleanup: In development, React's Strict Mode intentionally mounts components twice to expose missing cleanup logic. Effects without proper cleanup will exhibit doubled behavior, making issues immediately visible.

Pattern Recognition: Look for these patterns that always require cleanup:

• setInterval / setTimeout → clearInterval / clearTimeout

• addEventListener → removeEventListener

• new WebSocket() → ws.close()

• .subscribe() → .unsubscribe() or returned unsubscribe function

• requestAnimationFrame → cancelAnimationFrame

• Async operations → cancellation flags or AbortController

Proper cleanup ensures applications remain performant, predictable, and maintainable as they scale in complexity and user engagement.

The need for useEffect in React is to handle side effects in functional components, allowing you to synchronize your component with an external system after rendering, preventing interference with the rendering process. It manages tasks like data fetching, setting up subscriptions (timers, event listeners), and directly manipulating the DOM, replacing class component lifecycle methods (like componentDidMount, componentDidUpdate) with a unified API.

What are Side Effects?
Side effects are any actions that reach outside the component's scope to interact with something React doesn't directly control, such as:

• Data Fetching: Calling APIs to get data.

• DOM Manipulation: Changing the document title or adding/removing elements.

• Subscriptions: Setting up timers (setTimeout, setInterval) or event listeners (window resize, keypress).

• Logging: Logging to the console.

What problem occurs when we do not use useEffect for side effects ?

Problem 1: Infinite Loops 💥

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

  // ❌ This runs DURING render
  setCount(count + 1); // This triggers a re-render
                       // Which runs setCount again
                       // Which triggers another re-render
                       // INFINITE LOOP!

  return <div>{count}</div>;
}

What happens:

• Render starts → setCount called → triggers re-render →

• New render starts → setCount called again → triggers re-render →

• CRASH! React stops after ~50 iterations to prevent browser freeze

Problem 2: Unpredictable Behavior

function BadAPICall() {
  const [data, setData] = useState(null);

  // ❌ API call during render
  fetch('/api/data')
    .then(res => res.json())
    .then(setData); // When data arrives, triggers re-render

  return <div>{data || 'Loading...'}</div>;
}

What happens:

• Initial render → fetch called (Request #1 sent)

• Parent re-renders for some reason → BadAPICall renders again → fetch called (Request #2 sent)

• User clicks button → BadAPICall renders → fetch called (Request #3 sent)

• Result: Dozens of unnecessary API calls! Your server gets hammered! 📡💥

Problem 3: Race Conditions

function UserProfile({ userId }) {
  const [user, setUser] = useState(null);

  // ❌ Fetch during render
  fetch(`/api/users/${userId}`)
    .then(res => res.json())
    .then(setUser);

  return <div>{user?.name}</div>;
}

// User changes from ID 1 → ID 5 quickly
// Request for user 1 sent (takes 500ms)
// Request for user 5 sent (takes 100ms)
// User 5 displays ✓
// Then user 1 response arrives and overwrites it ❌
// Wrong user shown!

React's Rendering Process

Here's what React actually does during a render:

// React's internal process (simplified)
function reactRenderProcess() {
  // Phase 1: RENDER (Pure calculation)
  const virtualDOM = YourComponent(); // Just calls your function

  // Phase 2: Compare with previous render
  const changes = compareVirtualDOMs(oldVirtualDOM, virtualDOM);

  // Phase 3: COMMIT (Actually update the browser)
  applyChangesToRealDOM(changes);

  // Phase 4: Run effects
  runAllUseEffects(); // ← This is where side effects happen!
}

During Phase 1 (Render):

• React might call your component multiple times

• React might throw away the result without committing it

• React needs to be able to pause and resume

• This is why it must be pure!

Simple Analogy 🎨

Think of rendering like a painter planning a painting:

During Rendering (Planning Phase):

• "I'll paint a tree here, a house there..."

• Just thinking and sketching

• Might change mind and start over

• Don't order paint, don't call suppliers!

After Rendering (Execution Phase - useEffect):

• Plan is finalized

• Painting is on the wall

• Now you can order more paint, call the client, post on social media

• These are "side effects"

Summary: Why Not Update State During Rendering?

1. Renders can happen multiple times - React might render but not commit

2. Renders must be predictable - Same input = same output

3. Prevents infinite loops - State updates during render cause re-renders

4. Avoids duplicate side effects - API calls, subscriptions would run repeatedly

5. Enables React features - Concurrent rendering, Suspense, time-slicing

The rule: Rendering = pure calculation. Side effects = useEffect.

The useEffect hook in React lets you perform side effects in functional components, such as data fetching, subscriptions, or manually updating the DOM. It provides a way to synchronize your component with external systems after the rendering process is complete.

In simple terms, when your component first renders and shows to the user, you often need to fetch fresh data from an API or set up event listeners. But here's the problem: you can't just make an API call and update a regular variable - React won't know anything changed, so it won't update what the user sees.

This is where useEffect comes in. It lets you run code after your component renders. Inside useEffect, you can fetch data and update state using setState. When you update state, React detects the change and re-renders your component with the new data.

Think of it this way: useEffect is the designated place for 'side effects' - things like API calls, subscriptions, or timers that need to happen after rendering.

Syntax

• Setup Function: Contains the core logic of your effect. React runs this function after the component renders and the DOM is updated.

• Cleanup Function (optional): If your effect needs cleanup (e.g., stopping a timer, unsubscribing from an event), you return a function from the setup function. React runs this cleanup function before the component unmounts or before the effect runs again due to a dependency change.

• Dependencies Array (optional): An array of values (props, state, etc.) that the effect depends on. The effect will re-run only when any value in this array changes.

• Side effects are the ones which update the states.

• Dependencies are the one when you want to run this side effects again when this dependency value is changed. It will run once if empty array is passed.

useEffect(() => {
  // Side effect code (setup function)

  return () => {
    // Cleanup function (optional)
  };
}, [dependencies]); // Optional dependency array

Example

Basic but production level example used by many products and teams. Set window size when it is changed (resized). If you not able to understand it is fine just notice the syntax.

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

const WindowTracker = () => {
  // 1. Initialize state to hold the window width
  const [windowWidth, setWindowWidth] = useState(window.innerWidth);

  useEffect(() => {
    // 2. Define the function to update state
    const handleResize = () => {
      setWindowWidth(window.innerWidth);
    };

    // 3. Setup: Add the event listener on mount
    window.addEventListener('resize', handleResize);

    // 4. Cleanup: This function runs when the component is destroyed (unmounted)
    // In production, always clean up subscriptions, timers, and listeners!
    return () => {
      window.removeEventListener('resize', handleResize);
    };

    // 5. Dependency Array: Empty [] means this effect runs ONCE on mount
  }, []); 

  return (
    <div style={{ padding: '20px', textAlign: 'center' }}>
      <h2>Window Width Monitor</h2>
      <p>The current width of your browser is: <strong>{windowWidth}px</strong></p>
    </div>
  );
};

export default WindowTracker;

Common Use Cases

• Fetching Data: The most common use case is fetching data from an API when a component mounts or when a certain prop/state changes.

• DOM Manipulation: Manually updating the DOM (e.g., setting the document title) when this cannot be done declaratively in the render phase.

• Event Listeners/Subscriptions: Setting up and tearing down event listeners or subscriptions to external systems to prevent memory leaks.

Understanding this small things can help in optimizing the code and creating bug less features. Everything matters at scale.

The Stale State Problem

Consider this seemingly innocent counter:

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

  const incrementThreeTimes = () => {
    setCount(count + 1);
    setCount(count + 1);
    setCount(count + 1);
  };

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={incrementThreeTimes}>Add 3</button>
    </div>
  );
}

You expect the count to increase by 3. Instead, it increases by 1. Why? All three setCount calls capture the same count value from the render when the button was clicked. Each reads count as 0, resulting in three calls of setCount(0 + 1).

Functional Updates: The Solution

Pass a function to your state setter instead of a value. React calls this function with the current state, guaranteeing you always work with up-to-date data:

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

  const incrementThreeTimes = () => {
    setCount(prevCount => prevCount + 1);
    setCount(prevCount => prevCount + 1);
    setCount(prevCount => prevCount + 1);
  };

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={incrementThreeTimes}>Add 3</button>
    </div>
  );
}

Now each update receives the result of the previous update. The first call gets 0 and returns 1. The second call gets 1 and returns 2. The third call gets 2 and returns 3. Perfect.

Real-World Example: Shopping Cart

import { useState } from 'react';

function ShoppingCart() {
  const [items, setItems] = useState([]);

  const addItem = (product) => {
    setItems(prevItems => {
      const existingItem = prevItems.find(item => item.id === product.id);

      if (existingItem) {
        // Increase quantity if item exists
        return prevItems.map(item =>
          item.id === product.id
            ? { ...item, quantity: item.quantity + 1 }
            : item
        );
      }

      // Add new item
      return [...prevItems, { ...product, quantity: 1 }];
    });
  };

  const removeItem = (productId) => {
    setItems(prevItems => prevItems.filter(item => item.id !== productId));
  };

  const updateQuantity = (productId, newQuantity) => {
    if (newQuantity <= 0) {
      removeItem(productId);
      return;
    }

    setItems(prevItems =>
      prevItems.map(item =>
        item.id === productId
          ? { ...item, quantity: newQuantity }
          : item
      )
    );
  };

  const getTotalPrice = () => {
    return items.reduce((total, item) => total + (item.price * item.quantity), 0);
  };

  return (
    <div className="shopping-cart">
      <h2>Shopping Cart</h2>
      {items.length === 0 ? (
        <p>Your cart is empty</p>
      ) : (
        <>
          <ul>
            {items.map(item => (
              <li key={item.id}>
                <span>{item.name}</span>
                <span>${item.price}</span>
                <input
                  type="number"
                  value={item.quantity}
                  onChange={(e) => updateQuantity(item.id, parseInt(e.target.value))}
                  min="0"
                />
                <button onClick={() => removeItem(item.id)}>Remove</button>
              </li>
            ))}
          </ul>
          <div className="cart-total">
            <strong>Total: ${getTotalPrice().toFixed(2)}</strong>
          </div>
        </>
      )}
    </div>
  );
}

This cart uses functional updates throughout. The addItem function reads the previous items array to check if a product exists. Without functional updates, rapidly clicking "Add to Cart" could result in duplicate entries instead of increased quantities.

Asynchronous Operations and Functional Updates

function AsyncCounter() {
  const [count, setCount] = useState(0);
  const [loading, setLoading] = useState(false);

  const incrementAfterDelay = async () => {
    setLoading(true);

    // Simulate API call
    await new Promise(resolve => setTimeout(resolve, 1000));

    // Using functional update ensures we increment the current count
    // even if the user triggered multiple async operations
    setCount(prevCount => prevCount + 1);
    setLoading(false);
  };

  const incrementMultipleTimes = () => {
    // Start 3 async operations simultaneously
    incrementAfterDelay();
    incrementAfterDelay();
    incrementAfterDelay();
  };

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={incrementMultipleTimes} disabled={loading}>
        Increment 3 Times (Async)
      </button>
      {loading && <p>Loading...</p>}
    </div>
  );
}

Without functional updates, all three async operations would capture the initial count value, resulting in the counter only incrementing by 1 regardless of how many operations complete.

Production Pattern: Todo List with Optimistic Updates

function TodoList() {
  const [todos, setTodos] = useState([]);
  const [inputValue, setInputValue] = useState('');

  const addTodo = async () => {
    if (!inputValue.trim()) return;

    const tempId = Date.now();
    const newTodo = {
      id: tempId,
      text: inputValue,
      completed: false,
      syncing: true
    };

    // Optimistic update
    setTodos(prevTodos => [...prevTodos, newTodo]);
    setInputValue('');

    try {
      // Simulate API call
      const response = await fetch('/api/todos', {
        method: 'POST',
        body: JSON.stringify({ text: newTodo.text }),
        headers: { 'Content-Type': 'application/json' }
      });

      const savedTodo = await response.json();

      // Update with real ID from server
      setTodos(prevTodos =>
        prevTodos.map(todo =>
          todo.id === tempId
            ? { ...savedTodo, syncing: false }
            : todo
        )
      );
    } catch (error) {
      // Rollback on error
      setTodos(prevTodos => prevTodos.filter(todo => todo.id !== tempId));
      alert('Failed to add todo');
    }
  };

  const toggleTodo = async (id) => {
    // Optimistic update
    setTodos(prevTodos =>
      prevTodos.map(todo =>
        todo.id === id
          ? { ...todo, completed: !todo.completed, syncing: true }
          : todo
      )
    );

    try {
      await fetch(`/api/todos/${id}`, {
        method: 'PATCH',
        body: JSON.stringify({ completed: true }),
        headers: { 'Content-Type': 'application/json' }
      });

      // Remove syncing flag
      setTodos(prevTodos =>
        prevTodos.map(todo =>
          todo.id === id
            ? { ...todo, syncing: false }
            : todo
        )
      );
    } catch (error) {
      // Rollback on error
      setTodos(prevTodos =>
        prevTodos.map(todo =>
          todo.id === id
            ? { ...todo, completed: !todo.completed, syncing: false }
            : todo
        )
      );
    }
  };

  const deleteTodo = async (id) => {
    const todoToDelete = todos.find(todo => todo.id === id);

    // Optimistic delete
    setTodos(prevTodos => prevTodos.filter(todo => todo.id !== id));

    try {
      await fetch(`/api/todos/${id}`, { method: 'DELETE' });
    } catch (error) {
      // Rollback: add the todo back
      setTodos(prevTodos => [...prevTodos, todoToDelete]);
      alert('Failed to delete todo');
    }
  };

  return (
    <div>
      <input
        type="text"
        value={inputValue}
        onChange={(e) => setInputValue(e.target.value)}
        onKeyPress={(e) => e.key === 'Enter' && addTodo()}
        placeholder="Add a todo..."
      />
      <button onClick={addTodo}>Add</button>

      <ul>
        {todos.map(todo => (
          <li key={todo.id} style={{ opacity: todo.syncing ? 0.5 : 1 }}>
            <input
              type="checkbox"
              checked={todo.completed}
              onChange={() => toggleTodo(todo.id)}
              disabled={todo.syncing}
            />
            <span style={{ textDecoration: todo.completed ? 'line-through' : 'none' }}>
              {todo.text}
            </span>
            <button onClick={() => deleteTodo(todo.id)} disabled={todo.syncing}>
              Delete
            </button>
          </li>
        ))}
      </ul>
    </div>
  );
}

This code implements a React functional component for a To-Do List using a technique called Optimistic UI Updates. This pattern makes the app feel faster by updating the interface immediately before waiting for a server response.

Key Functionalities

• Optimistic UI Strategy: For every action (add, toggle, delete), the app updates the local state first so the user sees the change instantly. It then makes the API call in the background and corrects the state only if the server fails.

• Syncing State: While a network request is in progress, the code sets a syncing flag. This is used to:

  • Visually dim the item (setting opacity: 0.5).

  • Disable interactions (like clicking the checkbox or delete button) to prevent "race conditions" while the server is processing.

• ID Management:

  • When adding a task, it uses a temporary ID (Date.now()) to render the item immediately.

  • Once the server responds, it replaces the temporary ID with the permanent ID returned by the database.

• Error Handling & Rollbacks:

  • If an API call fails, the catch blocks contain logic to revert the UI.

  • For example, if deleting fails, the item is added back to the list; if toggling fails, the checkbox switches back to its previous state.

With functional update this code works with integrity and consistency.

When to use Functional Updates

When Functional Updates Are Critical

Multiple Updates in Single Event: Any time you update state multiple times in one function.

Async Operations: setTimeout, setInterval, fetch calls, or any promise-based code.

Event Handlers with Captured State: Callbacks that close over state values.

Computed Updates: When the new state depends on the old state mathematically or logically.

When Direct Updates Work Fine

Setting Absolute Values: When the new state doesn't depend on the old state:

const resetCount = () => setCount(0); // Direct update is fine
const setToValue = (value) => setCount(value); // Also fine

Single Update Per Event: If you only update state once per event and don't have async operations:

const handleClick = () => {
  setCount(count + 1); // Generally safe in isolation
};

Performance Characteristics

Functional updates don't add meaningful overhead. React must process the update regardless. The function call itself is negligible compared to the re-render cost.

React batches multiple state updates automatically in React 18+, whether using direct or functional updates. Batching optimizes renders, not individual state setter calls.

Common Patterns

Toggle Boolean State

const [isOpen, setIsOpen] = useState(false);

// Instead of: setIsOpen(!isOpen)
const toggle = () => setIsOpen(prev => !prev);

Increment/Decrement

const increment = () => setCount(prev => prev + 1);
const decrement = () => setCount(prev => prev - 1);
const incrementBy = (amount) => setCount(prev => prev + amount);

Array Operations

// Add item
setItems(prev => [...prev, newItem]);

// Remove item
setItems(prev => prev.filter(item => item.id !== idToRemove));

// Update item
setItems(prev => prev.map(item =>
  item.id === idToUpdate ? { ...item, ...updates } : item
));

// Sort
setItems(prev => [...prev].sort((a, b) => a.value - b.value));

Object Updates

// Merge properties
setUser(prev => ({ ...prev, name: 'John' }));

// Nested update
setSettings(prev => ({
  ...prev,
  preferences: {
    ...prev.preferences,
    theme: 'dark'
  }
}));

TypeScript Integration

interface Todo {
  id: number;
  text: string;
  completed: boolean;
}

function TypedTodoList() {
  const [todos, setTodos] = useState<Todo[]>([]);

  const addTodo = (text: string) => {
    setTodos((prevTodos: Todo[]) => [
      ...prevTodos,
      { id: Date.now(), text, completed: false }
    ]);
  };

  return <div>{/* UI */}</div>;
}

TypeScript infers the parameter type automatically in most cases, but explicit typing clarifies intent.

Key Notes

Use functional updates when new state depends on previous state. This pattern prevents bugs in async operations, multiple updates, and event handlers with captured state.

The pattern is simple: pass a function instead of a value. React guarantees your function receives the current state, eliminating race conditions and stale closures.

Direct updates work perfectly when setting absolute values or making single updates without dependencies on previous state.

The Problem with Direct Initialization

Consider a component that initializes state from localStorage:

function UserPreferences() {
  // This runs on EVERY render
  const savedTheme = JSON.parse(localStorage.getItem('theme') || '{}');
  const [preferences, setPreferences] = useState(savedTheme);

  return <div>Theme: {preferences.mode}</div>;
}

The localStorage read and JSON parsing execute on every render, even though useState only uses the initial value once. For a component that re-renders frequently, this wastes significant processing time.

Lazy Initialization: Function-Based Initial State

useState accepts a function as its initial value. React calls this function only during the initial render, skipping it on subsequent re-renders.

function UserPreferences() {
  // This runs ONLY on the initial render
  const [preferences, setPreferences] = useState(() => {
    const saved = localStorage.getItem('theme');
    return saved ? JSON.parse(saved) : { mode: 'light', fontSize: 16 };
  });

  return <div>Theme: {preferences.mode}</div>;
}

The arrow function wraps the initialization logic. React invokes it once, caches the result, and ignores the function on future renders.

Real-World Use Case: Complex Data Processing

import { useState } from 'react';

function DataAnalysisDashboard({ rawDataset }) {
  const [processedData, setProcessedData] = useState(() => {
    console.log('Processing dataset...');

    // Expensive operations
    const filtered = rawDataset.filter(item => item.isValid);
    const sorted = filtered.sort((a, b) => b.value - a.value);
    const aggregated = sorted.reduce((acc, item) => {
      const key = item.category;
      acc[key] = (acc[key] || 0) + item.value;
      return acc;
    }, {});

    return {
      items: sorted.slice(0, 100),
      summary: aggregated,
      total: filtered.length
    };
  });

  return (
    <div>
      <h2>Analysis Results</h2>
      <p>Total Items: {processedData.total}</p>
      <ul>
        {processedData.items.map(item => (
          <li key={item.id}>{item.name}: {item.value}</li>
        ))}
      </ul>
    </div>
  );
}

Without lazy initialization, this filtering, sorting, and aggregation would execute on every render, degrading performance dramatically as the dataset grows.

Production Pattern: Form with Persisted State

function AdvancedContactForm() {
  const [formData, setFormData] = useState(() => {
    try {
      const saved = sessionStorage.getItem('contactFormDraft');
      if (saved) {
        const parsed = JSON.parse(saved);
        // Validate the structure
        if (parsed.name && parsed.email && parsed.message) {
          return parsed;
        }
      }
    } catch (error) {
      console.error('Failed to load draft:', error);
    }

    // Return default structure
    return {
      name: '',
      email: '',
      message: '',
      subscribe: false,
      priority: 'normal'
    };
  });

  const updateField = (field, value) => {
    const updated = { ...formData, [field]: value };
    setFormData(updated);

    // Persist changes
    sessionStorage.setItem('contactFormDraft', JSON.stringify(updated));
  };

  const handleSubmit = (e) => {
    e.preventDefault();
    // Submit logic
    sessionStorage.removeItem('contactFormDraft');
  };

  return (
    <form onSubmit={handleSubmit}>
      <input
        type="text"
        value={formData.name}
        onChange={(e) => updateField('name', e.target.value)}
        placeholder="Your name"
      />
      <input
        type="email"
        value={formData.email}
        onChange={(e) => updateField('email', e.target.value)}
        placeholder="Email address"
      />
      <textarea
        value={formData.message}
        onChange={(e) => updateField('message', e.target.value)}
        placeholder="Your message"
      />
      <label>
        <input
          type="checkbox"
          checked={formData.subscribe}
          onChange={(e) => updateField('subscribe', e.target.checked)}
        />
        Subscribe to newsletter
      </label>
      <button type="submit">Send Message</button>
    </form>
  );
}

This form demonstrates multiple lazy initialization benefits: error handling, validation, and default fallback values. Users never lose their draft, even after accidental navigation.

When to Use Lazy Initialization

• Reading from Browser APIs: localStorage, sessionStorage, IndexedDB access involves I/O operations.

• Complex Calculations: Mathematical operations, data transformations, or filtering large datasets.

• Expensive Object Creation: Building complex nested structures or instantiating classes.

• Reading URL Parameters: Parsing window.location.search or constructing URLSearchParams objects.

When NOT to Use Lazy Initialization

Simple Values: Don't wrap primitives in functions:

// Unnecessary
const [count, setCount] = useState(() => 0);

// Better
const [count, setCount] = useState(0);

Props as Initial State: If the value comes from props and is already computed:

// Unnecessary
const [value, setValue] = useState(() => props.initialValue);

// Better
const [value, setValue] = useState(props.initialValue);

Performance Comparison

// Without lazy initialization
function SlowComponent() {
  const expensiveValue = computeExpensiveValue(); // Runs every render
  const [data, setData] = useState(expensiveValue);

  const [counter, setCounter] = useState(0);

  // Every click triggers expensive computation
  return <button onClick={() => setCounter(counter + 1)}>Clicks: {counter}</button>;
}

// With lazy initialization
function FastComponent() {
  const [data, setData] = useState(() => computeExpensiveValue()); // Runs once
  const [counter, setCounter] = useState(0);

  // Clicks no longer trigger expensive computation
  return <button onClick={() => setCounter(counter + 1)}>Clicks: {counter}</button>;
}

In the slow version, every button click re-renders the component and re-computes the expensive value, even though it's never used again. The fast version (functional way) computes it once and skips it on all future renders.

Common Mistakes

Returning Undefined

// Wrong: function doesn't return anything
const [data, setData] = useState(() => {
  localStorage.getItem('data');
});

// Correct: explicit return
const [data, setData] = useState(() => {
  return localStorage.getItem('data');
});

Using Function Results Instead of Functions

// Wrong: calls the function immediately
const [data, setData] = useState(computeValue());

// Correct: passes the function itself
const [data, setData] = useState(() => computeValue());

The difference is subtle but critical. The first example calls computeValue() on every render. The second passes a function that React calls only once.

Debugging Lazy Initialization

Add logging to verify initialization runs only once:

const [data, setData] = useState(() => {
  console.log('Initializing state - should see this once');
  return expensiveComputation();
});

In React StrictMode (development), you'll see the log twice due to double-rendering, but in production, it executes exactly once.

Integration with TypeScript

interface UserPreferences {
  theme: 'light' | 'dark';
  language: string;
  notifications: boolean;
}

function Settings() {
  const [prefs, setPrefs] = useState<UserPreferences>(() => {
    const saved = localStorage.getItem('preferences');
    if (saved) {
      return JSON.parse(saved) as UserPreferences;
    }
    return {
      theme: 'light',
      language: 'en',
      notifications: true
    };
  });

  return <div>Current theme: {prefs.theme}</div>;
}

TypeScript inference works seamlessly with lazy initialization, providing type safety for your initial state function.

Notes (Key points)

Lazy initialization optimizes performance by deferring expensive computations until absolutely necessary and ensuring they execute only once. Wrap initialization logic in a function when reading from browser APIs, processing data, or performing calculations.

Skip lazy initialization for simple values and computed props. The function wrapper adds unnecessary overhead for trivial initializations.

Master this pattern to build responsive React applications that feel instant, even when working with complex data structures and expensive operations.

Understanding useState Fundamentals

The useState hook enables functional components to maintain and update local state. It returns an array containing the current state value and a function to update it.

It must be defined and used inside functional component only.

useState is a fundamental React Hook that lets functional components manage state (data that changes over time) by declaring a state variable, its initial value, and a function to update it, returning them as an array [stateValue, setStateFunction]. It's used for simple state like numbers, strings, objects, or arrays.

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

Here count is a variable, it’s value can be updated only using setCount function.

This elegant API masks sophisticated behavior. React tracks state changes, triggers re-renders, and ensures your UI stays synchronized with application data.

How it works

• Import: import { useState } from 'react';.

• Declaration: const [count, setCount] = useState(0);.

  • count: The current state value (e.g., 0).

  • setCount: The function to update count.

  • useState(0): Sets the initial value (can be any data type).

• Updating: Call the setter function, e.g., setCount(count + 1) or setCount(prevCount => prevCount + 1). Difference b/w this is when you want to update previous value, when there is count getting updated more than one time. First one will only update once even though called multiple times.

• Re-render: Calling the setter function tells React to re-render the component with the new state value.

A regular variable is like a whiteboard that gets erased every time you leave the room (re-render). useState is like a notebook where React writes down the value so it is waiting for you when you come back.

IMP Internally, React holds state in an array or a similar structure associated with that specific component's position in the UI tree. When it is re-render react checks the stored value if it is updated then react ignores the initial state. The state remains stored as long as the component remains in its specific position in the UI tree (it is "mounted").

IMP One important point is that when a state requires complex computation for its initial value, it should be initialized using a function, for example: useState(() => getInitialValue()). If the state is initialized directly, the computation may run on every re-render. However, when using the functional initializer, the function is executed only on the first render, which improves performance.

// Correct: The function is only called once
const [data, setData] = useState(() => performExpensiveTask());

// Incorrect: performExpensiveTask() runs on every single render
const [data, setData] = useState(performExpensiveTask());

Building a Counter

Let's build a counter that demonstrates real-world patterns you'll use across React applications.

import { useState } from 'react';

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

  const increment = () => setCount(count + 1);
  const decrement = () => setCount(count - 1);
  const reset = () => setCount(0);

  return (
    <div className="counter-container">
      <h2>Current Count: {count}</h2>
      <div className="button-group">
        <button onClick={decrement} disabled={count === 0}>
          Decrease
        </button>
        <button onClick={reset}>Reset</button>
        <button onClick={increment}>Increase</button>
      </div>
      <p className="counter-status">
        {count === 0 && "Start counting!"}
        {count > 0 && `You've counted ${count} times`}
        {count < 0 && "Negative territory!"}
      </p>
    </div>
  );
}

Every call to setCount schedules a re-render. React compares the new state with the previous state. If they differ, React updates the component and its children.

Real-World Counter Applications

Counters appear everywhere in production applications:

• Inventory Management: Track product quantities with increment/decrement controls.

• Shopping Carts: Adjust item quantities before checkout.

• Form Inputs: Create numeric steppers for age, quantity, or rating inputs.

• Analytics Dashboards: Display real-time counters for metrics like page views or active users.

Advanced Counter: Multi-Step Incrementer

function SmartCounter() {
  const [count, setCount] = useState(0);
  const [step, setStep] = useState(1);

  const adjustCount = (direction) => {
    setCount(count + (step * direction));
  };

  return (
    <div>
      <h2>Count: {count}</h2>
      <div>
        <label>
          Step Size:
          <input
            type="number"
            value={step}
            onChange={(e) => setStep(Number(e.target.value))}
            min="1"
          />
        </label>
      </div>
      <button onClick={() => adjustCount(-1)}>-{step}</button>
      <button onClick={() => adjustCount(1)}>+{step}</button>
    </div>
  );
}

This example combines multiple state values and demonstrates controlled inputs, a critical pattern for form handling.

Common Pitfalls to Avoid

Direct State Mutation

Never modify state directly:

// Wrong
count = count + 1;

// Correct
setCount(count + 1);

Direct mutation bypasses React state management, preventing re-renders and breaking your UI.

Performance Considerations

useState updates are efficient for simple values like numbers and strings. For primitive values, this comparison is instantaneous (quick ~ O(1)).

Multiple state updates in the same event handler are batched automatically in React 18+, preventing unnecessary re-renders. In same function all useState update will count to one render only.

Testing State Updates

import { render, screen, fireEvent } from '@testing-library/react';

test('increments counter', () => {
  render(<InteractiveCounter />);
  const button = screen.getByText('Increase');

  fireEvent.click(button);
  expect(screen.getByText(/Current Count: 1/)).toBeInTheDocument();
});

Testing state changes validates your component's core functionality.