How React Knows What to Re-render: The Reconciliation & Diffing Algorithm

          State/props change
                  │
                  ▼
┌─────────────────────────────────┐
│        RENDER PHASE             │
│  • Call component functions     │
│  • Build new virtual DOM tree   │
│  • Diff old tree vs new tree    │
│  • Produce list of changes      │
│  (pure, can be interrupted)     │
└─────────────────┬───────────────┘
                  │
                  ▼
┌─────────────────────────────────┐
│        COMMIT PHASE             │
│  • Apply DOM mutations          │
│  • Run useLayoutEffect          │
│  • Paint screen                 │
│  • Run useEffect (async)        │
│ (synchronous, never interrupted)│
└─────────────────────────────────┘

// JSX compiles to React.createElement calls
const element = <div className="card"><h1>Hello</h1></div>;

// Which compiles to:
const element = React.createElement(
  'div',
  { className: 'card' },
  React.createElement('h1', null, 'Hello')
);

// Which produces a plain JavaScript object:
{
  type: 'div',
  props: {
    className: 'card',
    children: {
      type: 'h1',
      props: { children: 'Hello' }
    }
  }
}

// React holds two fiber trees:
// current       - what is on screen right now
// workInProgress - what is being calculated
//
// After commit: workInProgress becomes current.
// The diff between them becomes the DOM mutation list.

O(n³) naive approach for 1,000 nodes:
  1,000 × 1,000 × 1,000 = 1,000,000,000 comparisons/render
  At 60 renders/sec = 60,000,000,000 operations/sec
  // Completely unusable

O(n) with React's two heuristics:
  Walk both trees once, compare node-by-node at same position
  For 1,000 nodes = 1,000 comparisons/render
  At 60 renders/sec = 60,000 operations/sec
  // Fast enough for real-time interaction

The two assumptions that make this possible:
  1. Different element type at same position → full remount (skip subtree comparison)
  2. key prop on list items → stable identity (skip position-based matching)

// PROBLEM: switching component types destroys state
function App({ isLoggedIn }) {
  return (
    <div>
      {isLoggedIn
        ? <UserDashboard />  // switching from GuestView:
        : <GuestView />     // entire subtree unmounts and remounts
      }
    </div>
  );
  // UserDashboard loses ALL state every time isLoggedIn changes
}

// SOLUTION: same component type, different props - state is preserved
function App({ isLoggedIn }) {
  return <Dashboard type={isLoggedIn ? 'user' : 'guest'} />;
}

// ─────────────────────────────────────────────────────────────

// THE MOST COMMON TRIGGER OF THIS BUG:
// Defining components inside a render function

function Parent() {
  // BAD: new function object every render = new type every render
  const Child = () => <div>content</div>; // Different reference each render!

  return <Child />;
  // React sees: "ComponentA" → "ComponentB" (new type!) → full remount
  // Every Parent render = Child unmounts and remounts
  // Any state in Child is destroyed
}

// GOOD: define outside the rendering parent
const Child = () => <div>content</div>; // Stable reference forever

function Parent() {
  return <Child />; // Same type every render - fast path
}

// ─────────────────────────────────────────────────────────────

// WHAT ACTUALLY HAPPENS IN THE DOM:
// div → span at same position:
// Before: <div className="box">Hello</div>
// After:  <span className="box">Hello</span>
//
// React does NOT reuse the div node.
// It calls div.remove() then creates a fresh span.
// Any DOM state (focus, scroll, input value) is lost.

// Before render:
<button className="btn" disabled={false} onClick={handleA}>Save</button>

// After render:
<button className="btn active" disabled={true} onClick={handleB}>Saving...</button>

// React's minimal DOM operations (no node creation!):
// element.setAttribute('class', 'btn active')
// element.setAttribute('disabled', '')
// element.removeEventListener('click', handleA)
// element.addEventListener('click', handleB)
// element.textContent = 'Saving...'

// ─────────────────────────────────────────────────────────────

// Component update - same type, new props
// Before:
<UserCard name="Alice" role="admin" />

// After:
<UserCard name="Alice" role="editor" />

// React calls UserCard({ name: 'Alice', role: 'editor' })
// UserCard re-renders, React diffs its output recursively
// Only the changed DOM nodes inside UserCard get patched

// ─────────────────────────────────────────────────────────────

// Style object diffing - React only sets changed style properties
// Before: style={{ color: 'red', fontSize: '14px' }}
// After:  style={{ color: 'blue', fontSize: '14px' }}
// React: element.style.color = 'blue'  (only color, not fontSize)

// WITHOUT keys - React matches by index (position)
// Before: ['Alice', 'Bob', 'Carol']
// After:  ['Zara', 'Alice', 'Bob', 'Carol']  (inserted Zara at start)
//
// React compares by position:
//   position 0: 'Alice' → 'Zara'  (update text)
//   position 1: 'Bob'   → 'Alice' (update text)
//   position 2: 'Carol' → 'Bob'   (update text)
//   position 3: -       → 'Carol' (create new node)
// Result: 3 unnecessary updates + 1 create

// WITH keys - React matches by identity
// Before: [Alice(key=1), Bob(key=2), Carol(key=3)]
// After:  [Zara(key=4), Alice(key=1), Bob(key=2), Carol(key=3)]
//
// React sees: key=4 is new → create; key=1,2,3 moved → reorder
// Result: 1 create + 3 DOM moves (much cheaper)

// ─────────────────────────────────────────────────────────────

// CORRECT key usage
function TodoList({ todos }) {
  return (
    <ul>
      {todos.map(todo => (
        <TodoItem
          key={todo.id}   // stable unique ID from your data source
          todo={todo}
        />
      ))}
    </ul>
  );
}

// ─────────────────────────────────────────────────────────────

// WRONG: index as key - breaks when list order changes
function BadList({ items }) {
  return items.map((item, index) => (
    <Item key={index} item={item} />
    // When items reorder, indexes stay in place
    // React reuses the wrong DOM nodes
  ));
}

// ─────────────────────────────────────────────────────────────

// THE STATE BUG: why index keys cause real problems
function InputList({ items }) {
  return items.map((item, i) => (
    // Input's DOM value (what user typed) stays at position i
    // But item.label (React prop) changes to new item at position i
    // Result: wrong label shown with wrong user input
    <input key={i} defaultValue={item.label} />
  ));
}

// FIX: stable ID ensures DOM node travels with its data
function InputList({ items }) {
  return items.map(item => (
    <input key={item.id} defaultValue={item.label} />
  ));
}

// PROBLEM: form keeps stale state when user changes
function UserProfile({ userId }) {
  // This form initializes from userId but manages its own state
  const [name, setName] = useState('');
  const [bio, setBio] = useState('');

  // BAD: useEffect approach - need to reset every piece of state
  useEffect(() => {
    setName('');  // easy to forget one of these
    setBio('');   // and bugs are subtle
  }, [userId]);

  // ...
}

// ─────────────────────────────────────────────────────────────

// SOLUTION: key prop as reset button
function App({ userId }) {
  return (
    // When userId changes → key changes → React unmounts old form
    // → mounts fresh UserProfile with clean state
    <UserProfile key={userId} userId={userId} />
  );
}

function UserProfile({ userId }) {
  const [name, setName] = useState('');
  const [bio, setBio] = useState('');
  // No useEffect needed - component always starts fresh for each userId
}

// ─────────────────────────────────────────────────────────────

// OTHER USE CASES for intentional key-based reset

// Reset a wizard/multi-step form
<MultiStepForm key={formVersion} />

// Reset an animation when data changes
<AnimatedCounter key={metricId} value={count} />

// Force a component to re-fetch on demand
const [refreshKey, setRefreshKey] = useState(0);
<DataFetcher key={refreshKey} url={url} />
<button onClick={() => setRefreshKey(k => k + 1)}>Refresh</button>

// Understanding render vs commit timing

function Component() {
  // RENDER PHASE - called during diffing, can run multiple times in dev
  const value = expensiveCalculation(); // pure, no side effects

  // BAD: Side effect in render - will run twice in StrictMode
  fetch('/api/data').then(setData); // Don't do this in render!
  localStorage.setItem('key', value); // Or this

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

// ─────────────────────────────────────────────────────────────

// COMMIT PHASE TIMING ORDER:
// 1. useLayoutEffect cleanup (from previous render)
// 2. DOM mutations applied
// 3. useLayoutEffect fires (synchronous, DOM is ready, before paint)
// 4. Browser paints
// 5. useEffect cleanup (from previous render)
// 6. useEffect fires (asynchronous, after paint)

function Example() {
  useLayoutEffect(() => {
    // Runs synchronously after DOM update, before paint
    // Use for: reading DOM measurements, syncing with third-party DOM libs
    const height = ref.current.getBoundingClientRect().height;
    // Set something that would cause visual flicker if done in useEffect
  });

  useEffect(() => {
    // Runs asynchronously after paint
    // Use for: data fetching, subscriptions, analytics, timers
    const id = setInterval(tick, 1000);
    return () => clearInterval(id); // cleanup on unmount or re-run
  });
}

// ─────────────────────────────────────────────────────────────

// WHY STRICTMODE DOUBLE-INVOKES
// In development, React renders each component twice to detect impure renders.
// If your component has the same output both times = pure = safe.
// If output differs = impure = bug waiting to happen in concurrent mode.

// This component is pure (double-invoke safe):
function PureCounter({ count }) {
  return <div>{count * 2}</div>; // Same output every time for same input
}

// This component is impure (double-invoke reveals bug):
let callCount = 0;
function ImpureComponent() {
  callCount++; // mutates external variable during render!
  return <div>Called {callCount} times</div>; // Output differs between calls
}

// TRIGGER 1: Own state change
function Counter() {
  const [count, setCount] = useState(0);
  // Clicking button triggers re-render of Counter and all its children
  return <button onClick={() => setCount(c => c + 1)}>{count}</button>;
}

// ─────────────────────────────────────────────────────────────

// TRIGGER 2: Parent re-render (even with same props)
function Parent() {
  const [tick, setTick] = useState(0);
  return (
    <div>
      <button onClick={() => setTick(t => t + 1)}>tick</button>
      <Child message="hello" /> {/* Re-renders on every tick - props didn't change! */}
    </div>
  );
}

// ─────────────────────────────────────────────────────────────

// TRIGGER 3: Context change
const ThemeContext = createContext('light');

function ThemedButton() {
  const theme = useContext(ThemeContext); // re-renders when ThemeContext value changes
  return <button className={theme}>Click</button>;
}

// PROBLEM: Large context = many unnecessary re-renders
const AppContext = createContext({ user: null, theme: 'light', locale: 'en' });

function LanguagePicker() {
  const { locale } = useContext(AppContext); // re-renders on user OR theme change too!
}

// SOLUTION: Split context by update frequency
const UserContext = createContext(null);
const ThemeContext2 = createContext('light');
const LocaleContext = createContext('en');

function LanguagePicker2() {
  const locale = useContext(LocaleContext); // only re-renders when locale changes
}

// ─────────────────────────────────────────────────────────────

// TRIGGER 4: useReducer dispatch
function Form() {
  const [state, dispatch] = useReducer(formReducer, initialState);
  // dispatch({ type: 'SET_NAME', payload: 'Alice' }) triggers re-render
}

// ─── REACT 17 BEHAVIOR ───────────────────────────────────────

// Inside React event handler - batched (1 re-render)
function handleClick() {
  setCount(c => c + 1); // batched
  setFlag(f => !f);     // batched
  // → 1 re-render total
}

// Inside setTimeout - NOT batched in React 17
setTimeout(() => {
  setCount(c => c + 1); // re-render 1
  setFlag(f => !f);     // re-render 2
  // → 2 re-renders (bad)
}, 1000);

// Inside Promise - NOT batched in React 17
fetch('/api').then(() => {
  setData(result); // re-render 1
  setLoading(false); // re-render 2
  // → 2 re-renders (bad)
});

// ─── REACT 18 BEHAVIOR ───────────────────────────────────────

// All of the above now batch automatically - 1 re-render each
setTimeout(() => {
  setCount(c => c + 1); // batched
  setFlag(f => !f);     // batched
  // → 1 re-render total
}, 1000);

fetch('/api').then(() => {
  setData(result);   // batched
  setLoading(false); // batched
  // → 1 re-render total
});

// ─── OPT OUT with flushSync ───────────────────────────────────
import { flushSync } from 'react-dom';

function handleChange() {
  flushSync(() => {
    setCount(c => c + 1); // flush immediately - forces synchronous re-render
  });
  // DOM is updated here before the next line runs
  const height = listRef.current.scrollHeight; // read fresh DOM value
  flushSync(() => {
    setScrollTarget(height); // another synchronous re-render
  });
}

// useCallback - stable function reference for memoized children
function Parent({ userId }) {
  const [filter, setFilter] = useState('');

  // Without useCallback: new function reference every render
  // → MemoizedList always re-renders (React.memo is useless)
  const handleSelect = useCallback((itemId) => {
    console.log('Selected:', userId, itemId);
  }, [userId]); // recreate only when userId changes

  const filteredItems = useMemo(
    () => items.filter(i => i.name.includes(filter)),
    [filter] // recompute only when filter changes
  );

  return (
    <div>
      <input value={filter} onChange={e => setFilter(e.target.value)} />
      <MemoizedList items={filteredItems} onSelect={handleSelect} />
    </div>
  );
}

// ─────────────────────────────────────────────────────────────

// React.memo - skip re-render if props are referentially equal
const MemoizedList = React.memo(function MemoizedList({ items, onSelect }) {
  return <ul>{items.map(item => (
    <li key={item.id} onClick={() => onSelect(item.id)}>{item.name}</li>
  ))}</ul>;
});

// ─────────────────────────────────────────────────────────────

// BROKEN: new object prop defeats React.memo
function Parent2() {
  const [count, setCount] = useState(0);
  // This object is a new reference every render
  const config = { theme: 'dark', size: 'lg' }; // new ref every render

  return <MemoizedChild config={config} />; // memo never skips
}

// FIXED: stabilize the reference
function Parent3() {
  const [count, setCount] = useState(0);
  const config = useMemo(() => ({ theme: 'dark', size: 'lg' }), []); // stable ref

  return <MemoizedChild config={config} />; // memo works
}

// ─────────────────────────────────────────────────────────────

// React.memo with custom comparison function (use sparingly)
const DataGrid = React.memo(
  function DataGrid({ rows, columns }) {
    return <table>{/* expensive table render */}</table>;
  },
  (prevProps, nextProps) => {
    // Return true = skip re-render (props "equal")
    // Return false = re-render (props "different")
    return (
      prevProps.rows.length === nextProps.rows.length &&
      prevProps.columns.join() === nextProps.columns.join()
    );
  }
);

import { useState, useTransition, useDeferredValue } from 'react';

// ─── useTransition ────────────────────────────────────────────

function SearchPage() {
  const [query, setQuery] = useState('');
  const [results, setResults] = useState([]);
  const [isPending, startTransition] = useTransition();

  function handleSearch(e) {
    // URGENT: update input immediately (user sees their typing)
    setQuery(e.target.value);

    // NON-URGENT: computing results can be interrupted
    startTransition(() => {
      setResults(expensiveFilter(e.target.value));
      // If user types again before this finishes,
      // React discards this render and starts fresh
    });
  }

  return (
    <div>
      <input value={query} onChange={handleSearch} />
      {isPending
        ? <Spinner />        // show while transition is in progress
        : <ResultsList results={results} />
      }
    </div>
  );
}

// ─── useDeferredValue ─────────────────────────────────────────

function SearchPage2() {
  const [query, setQuery] = useState('');
  // deferredQuery lags behind query during fast typing
  // React shows stale results while computing fresh ones
  const deferredQuery = useDeferredValue(query);

  return (
    <div>
      <input value={query} onChange={e => setQuery(e.target.value)} />
      {/* This renders with deferredQuery - won't block typing */}
      <ExpensiveResultsList query={deferredQuery} />
    </div>
  );
}

// ─── When to use which ───────────────────────────────────────

// useTransition: you own the state setter
//   → wrap the setter call in startTransition

// useDeferredValue: you don't own the setter (prop from parent, context)
//   → wrap the value itself with useDeferredValue

// Neither speeds up rendering.
// Both keep urgent interactions (typing, clicking) responsive
// by delaying non-urgent renders until the browser is idle.