react rendering reconciliation interview questions

The 4 triggers for a re-render

// Trigger 1: setState / useState setter
function Counter() {
  const [count, setCount] = useState(0)
  // Clicking the button triggers a re-render of Counter
  return <button onClick={() => setCount(c => c + 1)}>{count}</button>
}
// Trigger 2: Context value change
const ThemeContext = createContext('light')
function App() {
  const [theme, setTheme] = useState('light')
  return (
    <ThemeContext.Provider value={theme}>  {/* change here... */}
      <ThemedButton />                      {/* ...re-renders this */}
    </ThemeContext.Provider>
  )
}
function ThemedButton() {
  const theme = useContext(ThemeContext)  // subscribed → re-renders on value change
  return <button className={theme}>Click</button>
}
// Trigger 3: Parent re-renders (the most common source of surprise re-renders)
function Parent() {
  const [x, setX] = useState(0)
  return <><Child /><button onClick={() => setX(x + 1)}>Update Parent</button></>
}
function Child() {
  // Child re-renders every time Parent re-renders — even though it uses no props
  console.log('Child rendered')
  return <div>Static child</div>
}
// What does NOT trigger a re-render:
const obj = { value: 1 }
obj.value = 2          // Direct mutation — React never knows. Don't do this.
props.name = 'new'     // Mutating props — also invisible to React, and breaks things.

What "Virtual DOM" actually means

// When you write JSX:
const element = <h1 className="title">Hello</h1>
// Babel compiles it to:
const element = React.createElement('h1', { className: 'title' }, 'Hello')
// Which produces a plain JavaScript object (the "virtual DOM node"):
const element = {
  type: 'h1',
  props: {
    className: 'title',
    children: 'Hello'
  },
  key: null,
  ref: null,
  // ...a few other internal fields
}
// The "virtual DOM" is just: a tree of these plain JS objects.
// React keeps TWO of these trees at all times:
// 1. The current tree (what's on screen now)
// 2. The work-in-progress tree (what should be on screen after this render)
//
// After reconciliation, work-in-progress becomes current.
// This is double buffering — more on this in the Fiber topic.

The diffing algorithm — O(n) with two heuristics

Naive tree diffing is O(n³). React achieves O(n) using two deliberate heuristics:

// Heuristic 1: Different element types → tear down, rebuild from scratch
// Before:
<div><Counter /></div>
// After:
<span><Counter /></span>
// React sees div → span. It destroys the div subtree entirely (unmounts Counter)
// and builds the span subtree fresh. Counter's state is LOST.
// This means: changing a wrapper element type loses all child state.
// Same type → update props, recurse into children
// Before: <div className="old">content</div>
// After:  <div className="new">content</div>
// React keeps the DOM node, just updates className. No unmount. State preserved.
 
// Heuristic 2: Children are reconciled using keys
// Without keys — React diffs by position:
// Before: [<A/>, <B/>, <C/>]
// After:  [<X/>, <A/>, <B/>, <C/>]
// React compares A→X (different), B→A (different), C→B (different), new→C
// Result: 3 updates + 1 insert. Expensive and wrong.
 
// With keys — React matches by identity:
// Before: [<A key="a"/>, <B key="b"/>, <C key="c"/>]
// After:  [<X key="x"/>, <A key="a"/>, <B key="b"/>, <C key="c"/>]
// React sees key "x" is new (insert), "a","b","c" moved (reorder).
// Result: 1 insert + reorder. State on A, B, C is preserved.

The index-as-key bug, shown concretely

// A todo list where items can be deleted
function TodoList() {
  const [todos, setTodos] = useState(['Buy milk', 'Read book', 'Exercise'])
  // ✗ WRONG: index as key
  return (
    <ul>
      {todos.map((todo, index) => (
        // When "Buy milk" (index 0) is deleted:
        // "Read book" becomes index 0, "Exercise" becomes index 1
        // React sees key 0 still exists — it REUSES the component instance
        // Result: wrong state, wrong focus, wrong animations
        <TodoItem key={index} text={todo} />
      ))}
    </ul>
  )
}
// ✓ CORRECT: stable unique ID as key
function TodoList() {
  const [todos, setTodos] = useState([
    { id: 'a1', text: 'Buy milk' },
    { id: 'b2', text: 'Read book' },
    { id: 'c3', text: 'Exercise' }
  ])
  return (
    <ul>
      {todos.map(todo => (
        // When "Buy milk" (id: a1) is deleted:
        // React sees key "a1" is gone → unmounts that instance
        // "b2" and "c3" still exist → reuses those instances with correct state
        <TodoItem key={todo.id} text={todo.text} />
      ))}
    </ul>
  )
}
// When IS index-as-key acceptable?
// Only when ALL three conditions are true:
// 1. The list is static — never reordered or filtered
// 2. Items are never inserted or deleted from the middle
// 3. Items have no internal state (they're purely display components)

Render phase vs Commit phase

// RENDER PHASE — pure, no side effects, may be interrupted (in Concurrent Mode)
// React calls your component functions
// Reconciles old tree vs new tree
// Builds a list of "effects" (DOM mutations needed)
// This phase can be paused, restarted, or thrown away entirely.
function MyComponent() {
  // This runs in the RENDER phase:
  const value = expensiveCalculation()  // runs on every render
  const [state] = useState(0)           // reads fiber state
  // No DOM access here. No network calls. Just return elements.
  return <div>{value}</div>
}
// COMMIT PHASE — synchronous, cannot be interrupted
// Phase 1 (Before Mutation): getSnapshotBeforeUpdate
// Phase 2 (Mutation): React applies DOM mutations
// Phase 3 (Layout): useLayoutEffect fires synchronously
// Then browser paints the screen
// Phase 4 (Passive Effects): useEffect fires asynchronously after paint
// useEffect vs useLayoutEffect — the key distinction:
function Modal() {
  const ref = useRef()
  // useLayoutEffect: fires BEFORE browser paint
  // Use when you need to read/mutate DOM before user sees it
  useLayoutEffect(() => {
    // Safe: DOM mutations here are invisible to the user
    const height = ref.current.getBoundingClientRect().height
    ref.current.style.marginTop = `-${height / 2}px`  // center vertically
  })
  // useEffect: fires AFTER browser paint
  // Use for data fetching, subscriptions, logging — most things
  useEffect(() => {
    // DOM mutations here cause a visible flicker (layout → paint → update)
    const height = ref.current.getBoundingClientRect().height
    ref.current.style.marginTop = `-${height / 2}px`  // user sees shift!
  })
  return <div ref={ref}>Modal content</div>
}
// Rule of thumb:
// Need to read/write DOM that affects layout → useLayoutEffect
// Everything else → useEffect

The "re-renders everything, updates few DOM nodes" model

// Imagine a parent with 5 children:
function Dashboard() {
  const [activeTab, setActiveTab] = useState('home')
  // When setActiveTab is called:
  // ALL 5 children re-render (their functions run)
  // React compares old output vs new output for each
  // DOM updates: maybe 1-2 className changes, nothing else
  return (
    <div>
      <Nav activeTab={activeTab} />         {/* function called — output changes */}
      <TabContent tab={activeTab} />        {/* function called — output changes */}
      <Sidebar />                           {/* function called — same output */}
      <Footer />                            {/* function called — same output */}
      <NotificationBell />                  {/* function called — same output */}
    </div>
  )
}
// Re-renders: 5 (all children ran)
// DOM mutations: 2 (Nav className, TabContent innerHTML)
// This is the trade-off React makes:
// Cheap JS function calls (re-renders) → minimal expensive DOM operations
// To prevent unnecessary re-renders on Sidebar, Footer, NotificationBell:
const Sidebar = React.memo(function Sidebar() { ... })
const Footer = React.memo(function Footer() { ... })
const NotificationBell = React.memo(function NotificationBell() { ... })
// Now only Nav and TabContent re-render when activeTab changes