Frontend Component and State Architecture Questions

Evaluation criteria

• Predictability of data flow (who reads/writes each piece of state)
• Frequency of cross-component sharing (local only vs app-wide)
• Performance cost (renders, serialization, middleware)
• Complexity & developer ergonomics (boilerplate, debugging)
• Team size/ownership boundaries (modules, vertical teams)
• Tooling/observability needs (time travel, logging, devtools)

Trade-offs

• Local state: minimal boilerplate, best for UI-specific ephemeral state; poor for widely-shared or cross-route state.
• Context + hooks: lightweight for app-level config, theme, auth; can cause unnecessary re-renders and implicit dependencies if overused.
• Centralized store (Redux): explicit, testable, good for complex sync, optimistic updates, and cross-team contracts; higher initial complexity and indirection.

Phased recommendation

1. Start with local state + small Contexts for global primitives (auth, theme). Prefer custom hooks to encapsulate logic.
2. Monitor signals: if you see many props drilling, duplicated fetching logic, complex caching, or multiple teams owning overlapping state, evaluate a store.
3. Adopt store incrementally: introduce Redux (or Zustand) in limited domains (e.g., cart, notifications), migrate gradually, add middleware/RTK Query for async needs.
4. Keep hybrid model—local for UI, global store for shared domain state—and document ownership and patterns.

This balances speed-to-market with a path to scale when justified.

Approach (summary)
I’d reduce DOM nodes with virtualization, isolate per-row work, avoid unnecessary reconciliation with stable keys + memoization, and store selection separately so checking doesn’t re-render the entire list.

Virtualization

• Use react-window or react-virtualized to render only visible rows (plus small overscan). This cuts DOM from 10k to ~30–100 nodes.
• Keep row height fixed or measured once (VariableSizeList if necessary).

Component split & memoization

• Split Row into: RowContainer (handles positioning from virtualizer) and RowContent (renders complex children).
• Memoize RowContent with React.memo and a custom props comparator that checks only props that matter (e.g., data reference, selection state slice).
• Move expensive logic out of render: useMemo for computed derived data, useCallback for event handlers.

Example:

// RowContent.js
const RowContent = React.memo(function RowContent({item, selected, onToggle}) {
  // heavy render of children
}, (prev, next) => prev.item === next.item && prev.selected === next.selected);

Keys & identity

• Use stable unique IDs (not index). Ensure items reused by virtualization keep same key to avoid full remounts.

Selection / checkbox state without full re-render

• Store selection as a Set or Map in parent but avoid passing the whole set down.
• For each row, pass a boolean selected prop (derived) or use a subscription model:
  • Option A: Derive selected = selectionSet.has(id) and memoize selector so only changed rows re-render.
  • Option B: Use a context with a selector hook (e.g., use-subscription or Zustand) so only components subscribed to a particular id update.
• Keep checkbox as a controlled component but handlers use stable callbacks (useCallback with id parameter closure via ref to avoid recreating functions).

Other optimizations

• Avoid inline objects/arrays in props.
• Use CSS for hide/show rather than conditional rendering when possible.
• Profile with React DevTools flamechart and browser FPS; tune overscan and batching.

Trade-offs

• Context/subscription adds complexity but yields minimal re-renders. Virtualization requires careful scroll UX (focus, keyboard navigation) handling.

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.

Answer (Frontend Developer)

Problem & cause
A useEffect that updates state listed in its dependency array can retrigger itself: effect runs → state changes → effect sees changed dep → runs again → infinite loop.

Bad example (infinite loop)

import { useState, useEffect } from 'react';

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

  useEffect(() => {
    // BAD: updates count unconditionally while depending on count
    setCount(count + 1);
  }, [count]);

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

Fix strategies

1. Conditional updates

useEffect(() => {
  if (count < 5) setCount(c => c + 1);
}, [count]);

Only updates when necessary, so eventually stops.

2. Functional setState (avoids stale closures; often combined with condition)

useEffect(() => {
  setCount(c => {
    if (c >= 5) return c;
    return c + 1;
  });
}, []); // run once

Using functional update lets you remove count from deps and run once.

3. Stabilize dependencies (useCallback / useMemo / refs)

const expensive = useMemo(() => computeHeavy(value), [value]);
useEffect(() => { doSomething(expensive); }, [expensive]);

Ensure functions/objects are stable so effect doesn't rerun unnecessarily.

4. Move logic out of effect
   If logic can run during an event or initialization, run it outside effect. For example, derive state lazily:

const [count, setCount] = useState(() => initialCount());

Why these work

• Conditional updates prevent unnecessary setState.
• Functional updates avoid needing the state in deps.
• Stabilizing deps prevents spurious identity changes.
• Moving logic avoids effect side-effects entirely.

Use lint rules (react-hooks/exhaustive-deps) as guidance and prefer minimal, explicit dependencies.