Component State Management Questions

Covers approaches and patterns for managing user interface state within component-based front end frameworks such as React and Angular. Topics include local component state, lifting state up, one way data flow, controlled versus uncontrolled components, prop passing and change handling, avoiding stale closures and missing dependency arrays, component composition patterns, performance considerations to prevent unnecessary re renders, and when to choose built in mechanisms versus external state libraries. For React this includes hooks such as useState, useContext, useReducer, useCallback, and useMemo and the trade offs of Context versus external stores. For Angular this includes using components and services, dependency injection, reactive programming patterns with observable streams, and change detection strategies. Candidates may be asked to compare state architectures, justify trade offs between simplicity and scalability, refactor components to improve state locality and performance, and design data flow for a feature from user interaction to persistent update.

EasyTechnical

67 practiced

What is a stale closure in the context of React hooks? Provide a concise example (in JavaScript using useEffect or an event handler) showing how a closure can capture outdated state and list two practical ways to avoid this problem in component code.

Sample Answer

**What a stale closure is (concise)**

A stale closure happens when a function captures variables from an earlier render and keeps referencing that old value later—common with useEffect, event handlers, or timers—so updates to state aren't seen by the closure.

**Example (stale closure with setInterval)**

javascript

import { useState, useEffect } from "react";

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

  useEffect(() => {
    const id = setInterval(() => {
      // This closure closes over the initial `count` value -> stale
      console.log("count:", count);
      setCount(count + 1);
    }, 1000);
    return () => clearInterval(id);
  }, []); // empty deps -> closure never sees later `count`
  return <div>{count}</div>;
}

**Two practical fixes**- Add dependencies / use fresh props: include `count` in the effect deps or recreate the callback so it captures latest state: - useEffect(() => { ... }, [count])- Use functional updates or refs to avoid relying on closed-over value: - setCount(c => c + 1) or store mutable latest value in useRef and read ref.current inside the closure

Both approaches ensure the closure uses up-to-date state.

HardTechnical

66 practiced

You are a frontend lead. The codebase started with localized component state but is becoming hard to maintain as features grow. Draft a plan to evaluate, propose, and lead a migration to an external state library. Include evaluation criteria (developer velocity, performance, debugging), a pilot/proof-of-concept approach, incremental migration strategies, rollback plans, and success metrics for stakeholders.

Sample Answer

**Situation & goal** I’d lead a pragmatic migration from localized component state to an external state library (e.g., Redux Toolkit, Zustand, or Recoil) to improve maintainability, predictability, and team velocity while minimizing risk.

**Evaluation criteria** - Developer velocity: onboarding time, number of lines changed per feature, local dev feedback. - Debuggability: time to reproduce bugs, quality of dev tools (time-travel, inspection). - Performance: render counts, bundle size impact, memory. Measure with Lighthouse, React Profiler. - Complexity fit: async handling, derived/compute state needs, testability. - Ecosystem & maintenance: community support, TypeScript friendliness, learning curve.

**Pilot / PoC** - Select a mid-complexity feature (one page or flow) that touches shared data (auth, preferences). - Implement state with chosen library, integrate devtools, add unit and integration tests. - Run performance comparisons (render counts, bundle delta) and gather developer feedback in 1–2 sprints.

**Incremental migration strategy** 1. Adopt hybrid model: keep local state where purely local (UI toggles), migrate shared state. 2. Define clear API surface: selectors, actions/thunks, and typed contracts. 3. Build adapter utilities to read/write both systems during transition. 4. Migrate feature-by-feature: start with cross-cutting concerns (session, user, feature flags) then domain areas. 5. Enforce patterns via linters, code reviews, and a migration checklist.

**Rollback & risk mitigation** - Keep changes feature-flagged; deploy behind flags and toggle off on regressions. - Maintain branch with prior behavior; CI must run both old and new integration tests. - Small incremental PRs, automated smoke tests, and a monitoring runbook for quick rollback.

**Success metrics for stakeholders** - 25% reduction in bug-reproduction time and in cross-component bugs within 3 months. - <10% bundle size regression or compensated by code-splitting. - Positive developer survey (NPS) increase and 20% faster onboarding for new devs on stateful features. - Observable reduction in unnecessary renders and improved Lighthouse/TTI where applicable.

I’d present the PoC results, recommended library, cost/benefit, and a 3–6 month phased migration roadmap to stakeholders and iterate from feedback.

MediumTechnical

74 practiced

Design keyboard navigation state for a custom tabs component. Requirements: arrow-key navigation, Home/End shortcuts, roving tabindex for accessibility, focus management, and ARIA attributes. Describe the state you would keep (e.g., focusedIndex, activeIndex), the event handlers, and how to minimize re-renders when tabs change.

Sample Answer

**Overview**

I’d keep minimal UI state and push transient focus into refs to avoid re-renders. Key pieces: focusedIndex (transient, for roving tabindex), activeIndex (controlled selection), tabsCount, and optionally orientation.

**State**- activeIndex: number — currently selected tab (controls panel visibility)- focusedIndex: number | null — which tab has tabindex=0; stored in ref to avoid re-renders- tabsRef: MutableRefArray<HTMLButtonElement> — direct DOM refs for focus calls- idPrefix / generated IDs for aria-controls/aria-labelledby

**ARIA & attributes**- role="tablist" on container, aria-orientation if vertical- Each tab: role="tab", aria-selected=(index===activeIndex), aria-controls=panelId, id=tabId, tabIndex = (index===focusedIndex ? 0 : -1)- Panels: role="tabpanel", aria-labelledby=tabId, hidden when not active

**Event handlers**- onKeyDown on each tab: - ArrowRight/ArrowDown: focusNext() - ArrowLeft/ArrowUp: focusPrev() - Home: focusFirst() - End: focusLast() - Enter/Space: setActive(focusedIndex) Implement wrapping and orientation-aware logic.- onClick: setActive(index); set focusedIndex ref to index- onFocus: set focusedIndex ref to index (so tabindex updates if needed)

**Focus management & re-render minimization**- Store focusedIndex in a ref; only update component state when activeIndex changes. This prevents rerender for every keyboard move.- Use a small effect to sync DOM tabindex when focusedIndex ref changes: directly set tabEl.tabIndex = 0/-1 instead of rerendering whole list.- Keep tabs as memoized child components; pass only stable props (isSelected boolean, id). Use refs for DOM focus to call .focus().- If using React context for deeply nested tabs, keep value stable (useMemo) and avoid passing focusedIndex ref as state.

**Edge cases**- Dynamic add/remove tabs: maintain stable IDs; clamp active/focused indices; if active removed, pick nearest sibling.- Disabled tabs: skip in focus navigation.

This approach satisfies roving tabindex, keyboard shortcuts, minimal re-renders, explicit focus control, and correct ARIA patterns.

MediumTechnical

63 practiced

Examine this React component:

javascript

function Counter() {
  const [count, setCount] = useState(0);
  useEffect(() => {
    const id = setInterval(() => {
      console.log('count:', count);
      setCount(count + 1);
    }, 1000);
    return () => clearInterval(id);
  }, []);
  return <div>{count}</div>;
}

Identify the bug that prevents the counter from incrementing as expected, explain why it happens (stale closure), and refactor the component to fix the issue using a functional update or a ref.

Sample Answer

**Answer (STAR-like, concise explanation + fix)**

**Bug & Why it happens**- The interval callback closes over the initial `count` (0). Because the effect has an empty deps array, the callback never sees updated state — classic stale closure. setCount(count + 1) keeps using the old `count`, so state stops incrementing properly.

**Fix 1 — Functional state update (recommended)** - Use updater form of setState so React provides latest value to the callback:

javascript

function Counter() {
  const [count, setCount] = useState(0);
  useEffect(() => {
    const id = setInterval(() => {
      setCount(c => c + 1); // c is always latest
    }, 1000);
    return () => clearInterval(id);
  }, []);
  return <div>{count}</div>;
}

**Fix 2 — Using a ref to read latest value**- Keep a ref in sync and read it inside the interval (useful if you need current value elsewhere):

javascript

function Counter() {
  const [count, setCount] = useState(0);
  const countRef = useRef(count);
  useEffect(() => { countRef.current = count; }, [count]);

  useEffect(() => {
    const id = setInterval(() => {
      const next = countRef.current + 1;
      setCount(next);
    }, 1000);
    return () => clearInterval(id);
  }, []);
  return <div>{count}</div>;
}

**Notes**- Prefer the functional update for simplicity and correctness.- Avoid adding `count` to effect deps here (would recreate interval each render).

MediumTechnical

55 practiced

Explain how React.memo, useMemo, and useCallback help prevent unnecessary re-renders. Provide concrete examples of common pitfalls—such as recreating objects/arrays inline, missing dependency arrays, and stale closures—and show how to fix them.

Sample Answer

**Overview — how they help**- React.memo wraps a component and shallowly compares props; it skips re-render when props are unchanged.- useMemo memoizes computed values (objects/arrays) so their identity stays stable across renders.- useCallback memoizes function identities so child components receiving callbacks don’t see new props each render.

**Common pitfall: recreating objects/arrays inline**Problem: Passing a new object/array literal forces memoized child to re-render.

jsx

// Bad: items recreated every render -> child re-renders
<Child items={[...data]} />

Fix: memoize the value

jsx

const items = useMemo(() => [...data], [data]);
<Child items={items} />

**Pitfall: recreating callbacks**Problem: Inline arrow functions change identity -> prop change

jsx

// Bad
<Child onClick={() => doSomething(id)} />

Fix:

jsx

const handleClick = useCallback(() => doSomething(id), [doSomething, id]);
<Child onClick={handleClick} />

**Pitfall: missing dependency arrays**Problem: useCallback/useMemo without correct deps leads to stale values or unnecessary recalcs.- Always list dependencies; for functions, include values used inside.- When including objects/functions from props, prefer stable references or lift state.

**Pitfall: stale closures**Problem: Callback captures old state

jsx

const countRef = useRef(count);
const fn = useCallback(() => console.log(countRef.current), []); // stale if ref not updated

Fix: include latest state in deps or use refs updated on every render:

jsx

useEffect(() => { countRef.current = count; }, [count]);
const fn = useCallback(() => console.log(countRef.current), []);

**When not to use them**- Don’t overuse: memoization has CPU/memory cost. Use when children are heavy or prop identities change frequently.

**Pattern**- Wrap pure child with React.memo.- Stabilize props (useMemo/useCallback).- Keep dependency arrays correct to avoid stale closures or extra work.

Unlock Full Question Bank

Get access to hundreds of Component State Management interview questions and detailed answers.

Join thousands of developers preparing for their dream job.