Frontend Component and State Architecture Questions

Step-by-step approach

1) Reproduce the scenario

• Identify the slow interaction (typing, list scroll, toggle).
• Run app in development build (or production build with source maps) so profiler behavior matches.

2) Record a profile

• Open React DevTools → Profiler.
• Click “Start profiling”, perform the action, then “Stop profiling”.
• Note overall CPU time and largest commits.

3) Inspect Flamegraph / Ranked chart

• Use Flamegraph to find tall/wide bars (components with expensive renders or frequent renders).
• Ranked shows total render time per component; focus on hotspots.

4) Use “Why did this render?”

• Select a component and open “Why did this render?” panel.
• Look for:
  • Props changed (value differences indicated)
  • Hook/state changed
  • Context changed
  • Parent rendered (causing child to render even if props unchanged)

5) Check props / contexts / hooks

• Compare previous vs next props shown in DevTools.
• Look for:
  • New object/array/inline function props each render
  • Context value identity changes (e.g., passing a fresh object)
  • State updates in parent that aren't needed by child

6) Apply fixes

• Memoize pure children: React.memo(Component) — prevents renders when shallow-equal props.
• Stabilize callbacks/values: useCallback, useMemo for functions/objects passed as props.
• Move state down or split components: colocate state near consumers so fewer parents update.
• Split heavy components: lazy load or virtualize long lists (react-window).
• Use useRef for mutable values that shouldn't trigger renders.

Typical profiler examples to look for

• Child renders even though props appear identical — likely parent re-render or new prop identities (inline function/object).
• Context provider re-renders everything after unrelated state change — provider recreating value object.
• Frequent small commits during typing — input value state held too high, causing many siblings to render.
• Large single commit with big render time — a heavy component doing synchronous work (render-costly calculations) — move to useMemo or web worker.

Reasoning

• DevTools tells you both the symptom (who rendered) and the cause (what changed). Targeting identity/stability of props, reducing parent updates, and breaking up responsibilities yields the biggest wins.

Brief definition

• Local component state: state owned and managed inside a single component (useState/useReducer). Good for UI-only concerns.
• Derived state: values computed from existing state/props (avoid storing if can be calculated).
• Lifted state: moved to a common parent (or context/store) when multiple children need the same source of truth.

Criteria to decide

• Ownership: who reads/writes the value? If only one component, keep local.
• Single source of truth: if several components must agree, lift.
• Cost of computation: if derived from cheap inputs, compute; if expensive, memoize rather than store.
• Re-render scope: lift increases the number of components subscribing; keep local to limit re-renders.

Example — keep local

• A dropdown’s open/closed boolean used only by the Dropdown component.
• Trade-offs: minimal re-renders (only dropdown updates), easy unit testing, single source simple. If another component later needs it, you’d lift.

Example — lift state

• Selected item in a multi-pane layout where Sidebar selects an item and Details shows it: lift selectedId to parent (or context).
• Trade-offs: single-source-of-truth prevents inconsistencies; easier integration and cross-component tests; however more re-renders unless you memoize children or split state updates.

Derived state guidance

• Prefer computing: e.g., filteredList = items.filter(...) from items + filterTerm. Use useMemo if expensive.
• Avoid duplicating derived values to reduce bugs.

Summary of trade-offs

• Re-renders: local limits scope; lifted can increase renders but can be optimized.
• Testability: local state is simple to unit test; lifted state enables easier integration tests.
• Single-source-of-truth: lift when multiple consumers need consistent state; compute when value is purely derivable.

Controlled vs Uncontrolled — short definition

• Controlled: React state is the single source of truth. Input value is driven by state and updated via onChange.
• Uncontrolled: DOM holds the value. You read it via refs when needed (imperative).

Controlled example (useState)

import React, { useState } from "react";

function ControlledInput() {
  const [value, setValue] = useState("");
  return (
    <input
      value={value}
      onChange={e => setValue(e.target.value)}
      aria-label="name"
    />
  );
}

Uncontrolled example (ref)

import React, { useRef } from "react";

function UncontrolledInput() {
  const ref = useRef(null);
  const handleSubmit = () => {
    alert(ref.current.value);
  };
  return (
    <>
      <input ref={ref} defaultValue="initial" aria-label="name" />
      <button onClick={handleSubmit}>Submit</button>
    </>
  );
}

Pros / Cons

• Controlled pros: easy validation, instant UI feedback, predictable state, easier to serialize/form-solve, fits React patterns.
• Controlled cons: more boilerplate, can re-render often with many inputs.
• Uncontrolled pros: less code for simple/default inputs, fewer re-renders, good for integrating non-React libs.
• Uncontrolled cons: harder to validate live, imperative reads, state less obvious.

When to choose

• Many inputs / complex validation / dynamic forms → Controlled (use form libraries like React Hook Form to mitigate performance).
• Simple one-off inputs, file inputs, or third‑party widgets → Uncontrolled (or integrate via refs).

Testing, perf, accessibility

• Testing: Controlled components are easier to unit-test via state assertions; uncontrolled require DOM queries (still testable).
• Performance: Uncontrolled can avoid frequent React renders; controlled can be optimized with debouncing or form libs that minimize re-renders.
• Accessibility: Both can be accessible if you provide labels/aria attributes. Controlled makes it simpler to announce validation messages because you manage state; uncontrolled requires extra wiring.

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)

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.

Approach

• Use useEffect to subscribe to window resize.
• Keep width/height in state.
• Debounce the handler with a timeout ref to avoid expensive re-renders.
• Clean up event listener and timeout on unmount.

Code (React, functional component)

import React, { useState, useEffect, useRef } from "react";

function WindowSize({ delay = 150 }) {
  const [size, setSize] = useState({
    width: window.innerWidth,
    height: window.innerHeight,
  });
  const timeoutRef = useRef(null);

  useEffect(() => {
    const onResize = () => {
      // clear any pending update
      if (timeoutRef.current) clearTimeout(timeoutRef.current);
      // schedule a debounced update
      timeoutRef.current = setTimeout(() => {
        setSize({ width: window.innerWidth, height: window.innerHeight });
        timeoutRef.current = null;
      }, delay);
    };

    window.addEventListener("resize", onResize);

    // cleanup: remove listener and clear timeout
    return () => {
      window.removeEventListener("resize", onResize);
      if (timeoutRef.current) {
        clearTimeout(timeoutRef.current);
        timeoutRef.current = null;
      }
    };
  }, [delay]);

  return (
    <div>
      Width: {size.width}px, Height: {size.height}px
    </div>
  );
}

export default WindowSize;

Why this works

• Debounce reduces rerenders during rapid resize while keeping UI responsive (delay controls responsiveness).
• useRef stores timeout id without causing renders; cleanup prevents memory leaks and stale timers.
• Using the effect dependency on delay lets the hook adapt if delay changes.

Edge cases / alternatives

• For immediate first update on mount, call setSize once in effect before adding listener.
• For more features, use lodash.debounce with useCallback and cancel on cleanup.
• Tune delay (100–200ms) based on UX needs.