React Internals: How React Works Under the Hood

// Simplified fiber structure
interface Fiber {
  // Identity
  type: Function | string | Class;
  key: string | null;
  stateNode: any;
  
  // Tree structure
  child: Fiber | null;
  sibling: Fiber | null;
  return: Fiber | null;
  
  // Work
  alternate: Fiber | null;
  effectTag: number;
  expirationTime: number;
  updateQueue: any;
  
  // Hook state (for function components)
  memoizedState: any;
  memoizedProps: any;
}

// Example: When you have this component tree:
function App() {
  return (
    <div>
      <Header />
      <Main />
    </div>
  );
}

// React creates a fiber tree like:
// App (fiber)
//   - child: div (fiber)
//     - child: Header (fiber)
//     - sibling: Main (fiber)
//       - return: div (fiber)
//         - return: App (fiber)

Each component and DOM element becomes a fiber. The tree structure allows React to traverse and update efficiently. The alternate property links to the previous version for comparison during reconciliation.

// Example: Reconciliation scenario

// Before (previous render)
<div>
  <Header />
  <Main />
</div>

// After (current render)
<div>
  <Header />
  <Sidebar />
  <Main />
</div>

// Reconciliation process:

// 1. Compare root <div>: Same type, continue
// 2. Compare children:
//    - Header: Same type, same key (if any), update props if changed
//    - Sidebar: NEW (no matching child), mark for PLACEMENT
//    - Main: Same type, but position changed, mark for UPDATE/MOVE

// Effect list generated:
// [PLACEMENT: Sidebar, UPDATE: Main (position changed)]

// React then commits these changes efficiently

React uses keys to efficiently match old and new children. Without keys, React might unnecessarily recreate components. With keys, React can track moves and reuses components when possible.

// ❌ BAD: Using index as key when items can reorder
function TodoList({ todos }) {
  return (
    <ul>
      {todos.map((todo, index) => (
        <TodoItem key={index} todo={todo} />
      ))}
    </ul>
  );
}

// Problem: If todos reorder, React thinks items changed
// React will recreate components instead of moving them

// ✅ GOOD: Using stable, unique IDs
function TodoList({ todos }) {
  return (
    <ul>
      {todos.map((todo) => (
        <TodoItem key={todo.id} todo={todo} />
      ))}
    </ul>
  );
}

// React can now:
// 1. Match old and new items by key
// 2. Reuse component instances when items move
// 3. Only update props if data changed
// 4. Efficiently handle additions/removals

// When items reorder:
// Before: [A(id:1), B(id:2), C(id:3)]
// After:  [C(id:3), A(id:1), B(id:2)]

// With keys, React knows:
// - C moved from position 2 to 0 (move, don't recreate)
// - A moved from 0 to 1 (move, don't recreate)
// - B moved from 1 to 2 (move, don't recreate)

// Without keys (using index), React would think:
// - Item at 0 changed from A to C (recreate)
// - Item at 1 changed from B to A (recreate)
// - Item at 2 changed from C to B (recreate)
// All components get destroyed and recreated!

Keys enable React to efficiently track which items moved, were added, or removed. Without proper keys, React will unnecessarily recreate components, losing state and causing performance issues.

// Understanding the phases with code:

function Component() {
  const [count, setCount] = useState(0);
  
  // This runs during RENDER PHASE
  console.log('Render phase - can be interrupted');
  
  useEffect(() => {
    // This runs during COMMIT PHASE
    console.log('Commit phase - runs after DOM updates');
  });
  
  return <div>{count}</div>;
}

// React's internal process:

// RENDER PHASE (interruptible)
// 1. React calls Component()
// 2. Component returns JSX
// 3. React creates/updates fiber tree
// 4. React identifies changes needed
//    - If urgent update arrives, can pause here
// 5. React completes render phase

// COMMIT PHASE (synchronous)
// 1. React applies all DOM updates
// 2. React calls componentDidMount/Update (class components)
// 3. React runs useEffect callbacks
// 4. User sees updates

// Why this matters:
// - Render phase can be time-sliced across frames
// - High priority updates can interrupt low priority work
// - Commit phase ensures UI consistency

The separation of phases enables React's concurrent features. The render phase can be interrupted for urgent updates, while the commit phase ensures all DOM updates happen atomically.

// Example: Priority interruption

// Low priority work starts
React starts rendering a large list (1000 items)

// After rendering 100 items, user clicks a button

// React:
// 1. Pauses the list rendering
// 2. Processes the button click (high priority)
// 3. Updates the button immediately
// 4. Resumes list rendering when possible

// Without time slicing:
// - Button click waits for list to finish
// - UI feels unresponsive
// - Poor user experience

// With time slicing:
// - Button responds immediately
// - List continues in background
// - Smooth, responsive UI

// Using useTransition for non-urgent updates
import { useTransition } from 'react';

function SearchResults({ query }) {
  const [isPending, startTransition] = useTransition();
  
  const handleInput = (e) => {
    // Urgent: Update input immediately
    setInputValue(e.target.value);
    
    // Non-urgent: Search results can be interrupted
    startTransition(() => {
      setSearchResults(search(e.target.value));
    });
  };
  
  return (
    <div>
      <input 
        value={inputValue} 
        onChange={handleInput}
      />
      {isPending && <Spinner />}
      <ResultsList results={searchResults} />
    </div>
  );
}

Time slicing allows React to keep the UI responsive by breaking work into chunks and prioritizing user interactions. useTransition lets you mark updates as non-urgent so they don't block urgent updates.

// Commit phase execution order

function Component() {
  const ref = useRef(null);
  
  useEffect(() => {
    // Phase 4: Effect
    console.log('useEffect runs here - after DOM updates');
  });
  
  useLayoutEffect(() => {
    // Phase 3: Layout
    console.log('useLayoutEffect runs here - synchronous, before paint');
    // Can read layout and synchronously update
    if (ref.current) {
      ref.current.style.width = '100px';
    }
  });
  
  return <div ref={ref}>Content</div>;
}

// Execution order:
// 1. Mutation: DOM updates applied
// 2. Layout: useLayoutEffect runs (synchronous)
// 3. Browser paints
// 4. Effect: useEffect runs (after paint)

// Why this matters:
// - useLayoutEffect: Need to read/write layout synchronously
// - useEffect: Side effects that don't need to block paint

Understanding the commit phase order helps you choose between useEffect and useLayoutEffect. Layout effects run synchronously before paint, while regular effects run asynchronously after paint.

// Example: Debugging with React DevTools

// 1. Open React DevTools
// 2. Go to Profiler tab
// 3. Record a render
// 4. Analyze:

// You'll see:
// - Which components rendered
// - Render time
// - Commit time
// - Phase breakdown

// Common findings:

// Issue: Component re-rendering unnecessarily
// Solution: Use React.memo, useMemo, useCallback

function ExpensiveComponent({ data }) {
  // Re-renders even when data hasn't changed
  const expensiveValue = expensiveCalculation(data);
  return <div>{expensiveValue}</div>;
}

// Fix:
const ExpensiveComponent = React.memo(function ExpensiveComponent({ data }) {
  const expensiveValue = useMemo(
    () => expensiveCalculation(data),
    [data]
  );
  return <div>{expensiveValue}</div>;
});

// Issue: Reconciliation inefficient
// Solution: Use proper keys

// Issue: Effects running too often
// Solution: Fix dependency arrays

useEffect(() => {
  fetchData();
}, [userId]); // Only runs when userId changes

// Use React DevTools to verify:
// - Component renders
// - Effect runs
// - Dependencies match

React DevTools Profiler shows you exactly what React is doing. Use it to identify performance bottlenecks, unnecessary re-renders, and reconciliation inefficiencies.