Hooks Interview Questions
With Answers & Code Examples

Two rules enforced by the eslint-plugin-react-hooks linter:

1. Only call hooks at the top level — never inside loops, conditions, or nested functions
2. Only call hooks in React function components or custom hooks — not in regular JS functions

Why? React tracks hook state by call order. It uses an internal linked list — hook #1, hook #2, etc. If you call hooks conditionally, the order changes between renders and React's state gets mismatched:

// ❌ WRONG — conditional hook breaks the call order
function Profile({ userId }) {
  if (!userId) return null; // return before hook!
  const [user, setUser] = useState(null); // hook #1 sometimes skipped
}

// ✅ CORRECT — always call hooks, handle condition inside
function Profile({ userId }) {
  const [user, setUser] = useState(null); // hook #1 always
  if (!userId) return null;               // condition after hooks
}

const [state, setState] = useState(initialValue);

Functional updates — use when next state depends on current state:

// ❌ Potentially stale closure
setCount(count + 1);
setCount(count + 1); // both read the same stale 'count'

// ✅ Always gets the latest value
setCount(c => c + 1);
setCount(c => c + 1); // correctly increments twice

Batching — React 18 batches all state updates (even in setTimeout, fetch callbacks) into a single re-render:

// React 18: both updates batched into ONE re-render
setTimeout(() => {
  setCount(c => c + 1);
  setName('Alice');
}, 0);

Lazy initialization — pass a function to avoid re-running expensive setup on every render:

// ❌ computeExpensive() runs every render (result discarded after mount)
const [state, setState] = useState(computeExpensive());

// ✅ Only runs on mount
const [state, setState] = useState(() => computeExpensive());

useEffect(() => {
  // effect logic
  return () => { /* cleanup */ };
}, [dependencies]);

Three dependency modes:

// 1. No array — runs after EVERY render
useEffect(() => { document.title = 'Re-ran'; });

// 2. Empty array — runs ONCE after mount
useEffect(() => {
  const ws = new WebSocket(url);
  return () => ws.close(); // cleanup on unmount
}, []);

// 3. With deps — runs when any dep changes
useEffect(() => {
  fetchUser(userId); // re-fetches whenever userId changes
}, [userId]);

Cleanup timing:

• Runs before the next effect fires (when deps change)
• Runs on component unmount

useEffect(() => {
  const id = setInterval(() => tick(), 1000);
  return () => clearInterval(id); // cleans up before next effect
}, [tick]);

Both run after render but at different times:

• useEffect — fires after the browser paints. Non-blocking. Use for most side effects (data fetching, subscriptions).
• useLayoutEffect — fires synchronously after DOM mutations but before paint. Blocking. Use for reading layout to prevent visual flicker.

// useEffect — paint happens first, then effect
// Causes flicker if you update DOM based on measurement
useEffect(() => {
  const height = ref.current.offsetHeight; // reads layout
  setHeight(height); // triggers second render → visible flicker!
}, []);

// useLayoutEffect — DOM updated, effect runs, THEN paint
// No flicker because browser hasn't painted yet
useLayoutEffect(() => {
  const height = ref.current.offsetHeight;
  setHeight(height); // only one paint with correct height
}, []);

Sequence:

render → DOM mutations → useLayoutEffect → browser paint → useEffect

useRef returns a mutable object { current: initialValue }. Changing .current does NOT trigger a re-render.

Use case 1: DOM access

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

  useEffect(() => {
    inputRef.current.focus(); // direct DOM access
  }, []);

  return ;
}

Use case 2: Storing mutable values (instance variables)

function Timer() {
  const intervalRef = useRef(null);
  const renderCount = useRef(0);

  renderCount.current++; // doesn't trigger re-render

  function start() {
    intervalRef.current = setInterval(tick, 1000);
  }
  function stop() {
    clearInterval(intervalRef.current); // access latest value, no stale closure
  }
}

useRef vs useState for mutable values:

• Need re-render when it changes? → useState
• Just need to store/read without re-rendering? → useRef

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

// 2. Provide value
function App() {
  const [theme, setTheme] = useState('light');
  return (
    
      
    
  );
}

// 3. Consume anywhere in the tree
function Button() {
  const { theme, setTheme } = useContext(ThemeContext);
  return Click;
}

When to avoid:

• High-frequency updates — every consumer re-renders on every context change. Putting frequently-changing state (mouse position, scroll) in context is expensive.
• Unrelated values in one context — split into separate contexts so consumers only re-render for changes they care about.

// ❌ One fat context — Button re-renders when user changes even if only needs theme
const AppContext = createContext({ theme, user, cart });

// ✅ Split contexts — each consumer only subscribes to what it needs
const ThemeContext = createContext(theme);
const UserContext  = createContext(user);

const [state, dispatch] = useReducer(reducer, initialState);

const initialState = { count: 0, loading: false, error: null };

function reducer(state, action) {
  switch (action.type) {
    case 'INCREMENT':   return { ...state, count: state.count + 1 };
    case 'SET_LOADING': return { ...state, loading: action.payload };
    case 'SET_ERROR':   return { ...state, error: action.payload };
    case 'RESET':       return initialState;
    default:            return state;
  }
}

function Counter() {
  const [state, dispatch] = useReducer(reducer, initialState);
  return (
     dispatch({ type: 'INCREMENT' })}>
      {state.count}
    
  );
}

Choose useReducer when:

• Multiple related state values that change together
• Next state depends on action type, not just a single value
• Complex state transition logic you want to test independently
• State transitions need to be auditable (dispatch history)

useCallback(fn, deps) returns a memoized function that only changes if deps change.

const handleClick = useCallback(() => {
  doSomething(id);
}, [id]); // only creates a new function when id changes

It only helps in two scenarios:

1. Passed to a React.memo child (prevents unnecessary re-renders):

const MemoChild = React.memo(({ onClick }) => Click);

// Without useCallback — new function ref every render → MemoChild always re-renders
// With useCallback — same ref if deps unchanged → MemoChild skips re-render
const handleClick = useCallback(() => doWork(id), [id]);

2. Used as a useEffect dependency:

const fetchData = useCallback(() => {
  api.get(url).then(setData);
}, [url]);

useEffect(() => { fetchData(); }, [fetchData]); // won't re-run unless url changes

When it does NOT help:

• Functions passed to native DOM elements (div, button) — they don't check reference equality
• Without React.memo on the child — the child re-renders regardless

// useMemo — memoizes the RETURN VALUE of a function
const sortedList = useMemo(() => {
  return [...items].sort((a, b) => a.name.localeCompare(b.name));
}, [items]); // only re-sorts when items changes

// useCallback — memoizes the FUNCTION ITSELF
const handleSort = useCallback(() => {
  setSortedList([...items].sort(...));
}, [items]);

Use useMemo for:

• Expensive computations (filtering 10k items, building complex data structures)
• Stable object/array references passed as props to React.memo children
• Values used as useEffect dependencies that would otherwise change every render

// ❌ New object every render → useEffect re-runs every render
const options = { timeout: 5000, retries: 3 };
useEffect(() => fetchData(options), [options]);

// ✅ Stable reference
const options = useMemo(() => ({ timeout: 5000, retries: 3 }), []);
useEffect(() => fetchData(options), [options]);

Custom hooks extract stateful logic from components into reusable functions. They must start with use.

// Custom hook — useFetch
function useFetch(url) {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    let cancelled = false;
    setLoading(true);
    fetch(url)
      .then(r => r.json())
      .then(d => { if (!cancelled) setData(d); })
      .catch(e => { if (!cancelled) setError(e); })
      .finally(() => { if (!cancelled) setLoading(false); });
    return () => { cancelled = true; }; // cleanup race condition
  }, [url]);

  return { data, loading, error };
}

// Usage — clean component
function UserProfile({ id }) {
  const { data: user, loading } = useFetch(`/api/users/${id}`);
  if (loading) return ;
  return 
{user.name}
;
}

Common custom hook patterns:

• useLocalStorage(key, initial) — sync state with localStorage
• useDebounce(value, delay) — debounce a value
• useOnClickOutside(ref, handler) — close dropdowns
• usePrevious(value) — track previous render's value
• useIntersectionObserver(ref) — lazy loading / infinite scroll

useId generates a stable, unique ID that is consistent across server-side rendering and client-side hydration.

// ❌ Problem — random or Math.random IDs cause SSR hydration mismatch
function Field({ label }) {
  const id = Math.random(); // different value on server vs client → hydration error!
  return (
    <>
      {label}
      
    
  );
}

// ✅ useId — stable, unique, SSR-safe
function Field({ label }) {
  const id = useId(); // e.g. ":r0:", ":r1:" — consistent server + client
  return (
    <>
      {label}
      
    
  );
}

// Multiple IDs from one useId call — append suffixes
function ComboField() {
  const id = useId();
  return (
    <>
      Name
      
      
Your full name
    
  );
}

forwardRef — lets a parent component pass a ref to a DOM node or component instance inside a child.

useImperativeHandle — customizes what a parent receives via that ref, exposing only a controlled API instead of the raw DOM node.

// Without forwardRef — parent can't reach inner input
function Input(props) {
  return ;
}

// ✅ With forwardRef — parent can call .focus(), etc.
const Input = forwardRef(function Input(props, ref) {
  return ;
});

// Parent
function Form() {
  const inputRef = useRef(null);
  return (
    <>
      
       inputRef.current.focus()}>Focus
    
  );
}

// ─── useImperativeHandle — expose limited API ──────────────────────────────
const FancyInput = forwardRef(function FancyInput(props, ref) {
  const inputRef = useRef();

  useImperativeHandle(ref, () => ({
    focus: () => inputRef.current.focus(),
    clear: () => { inputRef.current.value = ''; },
    // Parent can NOT access inputRef.current directly — only these two methods
  }));

  return ;
});

const ref = useRef();
ref.current.focus(); // ✅
ref.current.value;   // ❌ undefined — not exposed

A stale closure occurs when a function captures a value from a previous render and never gets updated to see the new value.

// ❌ Classic example — setInterval with stale count
function Counter() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    const id = setInterval(() => {
      console.log(count); // always logs 0 — stale closure!
      setCount(count + 1); // always sets to 1 — bug!
    }, 1000);
    return () => clearInterval(id);
  }, []); // empty deps — closure captures count=0 forever
}

// ✅ Fix 1 — functional update (doesn't need to close over count)
setCount(c => c + 1); // always gets the latest count

// ✅ Fix 2 — add count to deps (effect re-runs on every count change)
useEffect(() => {
  const id = setInterval(() => {
    setCount(count + 1);
  }, 1000);
  return () => clearInterval(id); // cleans up old interval
}, [count]);

// ✅ Fix 3 — useRef stores mutable value, not affected by closures
const countRef = useRef(count);
useEffect(() => { countRef.current = count; }, [count]);

useEffect(() => {
  const id = setInterval(() => {
    setCount(countRef.current + 1); // always reads latest
  }, 1000);
  return () => clearInterval(id);
}, []);