The DOM Bridge & Escape Hatches

React memory comprises of Fiber Nodes and Blueprints. But eventually, something has to touch the actual Browser DOM. This unit covers the boundary layer between React's memory and the Browser's reality.

1. The Conflict: Declarative vs. Imperative

• React is Declarative: We tell it what we want (<div className="hidden" />), and React figures out how to update the DOM.
• The Browser DOM is Imperative: We must give specific commands (element.focus(), video.play(), window.scrollTo()).

The Gap: We cannot pass a focus={true} prop to a standard HTML input. There is no declarative attribute for playing a video or measuring the width of a div. React's data flow hits a wall here. To cross this wall, we need an Escape Hatch.

2. The Solution: useRef (The Escape Hatch)

useRef returns a mutable object { current: initialValue }. This object persists for the entire lifetime of the component.

The Hook's Secret

Inside the Fiber Node:

• useState lives in memoizedState. When it changes, React flags the Fiber as dirty and triggers a re-render.
• useRef also lives in memoizedState inside the same Fiber Node.

The Difference: useRef is just a plain JavaScript object stored on the Fiber. When we change ref.current = 5:

1. We are mutating the object directly in the heap.
2. React's Reconciliation Engine is not notified.
3. No Dirty Fiber flag is set. No Render Phase is triggered.
4. The value is saved silently in memory.

The Two Practical Use Cases

Since useRef is just a persistent container, we use it for two very different things:

Use Case A: Accessing the DOM (Imperative Control)

This is the most common usage. We pass the ref object to a JSX element. React puts the actual DOM node into .current.

function SearchBar() {
  const inputRef = useRef(null);
 
  const handleFocus = () => {
    // Access the DOM directly to call imperative methods
    inputRef.current.focus();
  };
 
  return (
    <>
      <input ref={inputRef} type="text" />
      <button onClick={handleFocus}>Focus</button>
    </>
  );
}

Use Case B: Mutable Variables (Silent Memory)

We can use refs to store values that need to survive renders (like a Timer ID or previous props) but should not trigger a UI update when they change.

function Timer() {
  const intervalRef = useRef(null); // distinct from state!
 
  const startTimer = () => {
    // We store the ID here. Updating it won't re-render the component.
    intervalRef.current = setInterval(() => console.log("Tick"), 1000);
  };
 
  const stopTimer = () => {
    clearInterval(intervalRef.current);
  };
 
  return <button onClick={stopTimer}>Stop</button>;
}

The Lifecycle of a Ref

Knowing when to access a ref is critical to avoiding null errors.

1. Render Phase (The Blueprint): React calls our function. Never read or write ref.current here. The DOM node doesn't exist yet, or it refers to the old DOM node.

• Bad: return <div>{ref.current.clientWidth}</div> (Will crash or show old data).

2. Commit Phase (The Reality): React applies changes to the DOM.
3. Layout Phase: Immediately after DOM updates, React mutates the ref object, setting .current to the new DOM node. This is the safe time to read/write them (usually inside useEffect).

3. Synthetic Events

When we write <button onClick={handleClick}>, we are not adding a standard DOM Event Listener to that button.

• The Reality: React adds one giant event listener to the root (or document) of our app. This is called Event Delegation.
• The Process:

1. User clicks a button.
2. The Browser sends the event bubbling up to the root.
3. React catches it.
4. React looks at the Fiber Tree to figure out which component was clicked and calls our function.

Why does this matter? It proves again that React is an abstraction layer. It isolates us from the Real World (Native DOM Events) to optimize performance (fewer listeners) and ensure consistency.

📝 Summary Table

🛑 Stop and Think

1. The Single Source of Truth Problem

If we create a Scroll Progress Bar component, we might be tempted to store scrollPosition in useState.

• The Risk: The Browser handles scrolling on its own thread (the Compositor). If we try to force the scroll position via React State (window.scrollTo(state)), we fight the browser.
• The Result: Jittery scrolling and poor performance.
• The Fix: Let the Browser own the scroll (Reality). Use React useRef to simply read the value when needed, or sync strictly for UI display, not control.

2. Why ref is null on first render

const inputRef = useRef(null);
console.log(inputRef.current); // -> null
return <input ref={inputRef} />;

Why is it null? Because console.log runs during the Render Phase. React is still building the Blueprint. The input element hasn't been created in the browser yet. React can't give us the DOM node until the Commit Phase finishes.