What is the virtual DOM, and how does reconciliation work in React?

Imagine the class notice board. Every morning the class representative gets a fresh printed list of notices. Instead of tearing down the whole board and pinning everything again, they compare the new list with what is already on the board. One notice changed, one is new, one was removed. They swap just those three sheets.

React works the same way. Your components return JSX, which becomes a tree of plain JavaScript objects describing the UI. People call this the virtual DOM. The real DOM in the browser is the notice board. When state changes, React builds a new tree, compares it with the old one, and makes only the needed changes to the real DOM.

Updating the real DOM is not terribly slow by itself, but touching it more than necessary causes extra layout and paint work and loses things like focus and scroll position. The comparison step lets you write code as if you re-render everything, while React keeps the real changes small.

function Counter() {
  const [count, setCount] = useState(0);
  return (
    <div className="card">
      <h2>Placement Tracker</h2>
      <p>Applications sent: {count}</p>
      <button onClick={() => setCount(count + 1)}>Add</button>
    </div>
  );
}

When you click the button, Counter runs again and returns a new tree. React compares it with the old tree. The div, h2 and button are the same. Only the text inside p changed from 0 to 1, so React updates just that text node.

Comparing two arbitrary trees perfectly is expensive, so React uses simple rules that work well in practice:

1. Different element type means replace. If a <div> becomes a <section>, or <ProfileCard> becomes <LoginForm>, React removes the old subtree, including its state, and builds a new one.
2. Same type means update. React keeps the same DOM node or component instance and updates only the changed attributes and props, then continues into the children.
3. Keys identify list items. Among siblings, React matches children by key, so reordered items keep their state.

This happens in two phases. In the render phase React calls your components and works out what changed. In the commit phase it applies those changes to the real DOM and then runs effects. The render phase can be paused or interrupted for more urgent updates; the commit phase is applied in one go so users never see a half-updated screen.

• Re-rendering a long list of products when a filter changes, while only touching the rows that changed.
• Typing in a search box where the input keeps its focus while the results below update.
• Understanding why a component's state resets: if its type or key changes, React treats it as a new component.

• Saying "the virtual DOM makes React faster than plain JavaScript". Carefully written direct DOM updates can be faster; the benefit is that you get reasonable performance while writing simpler, declarative code.
• Defining a component inside another component. A new function is created on every render, so React sees a different type each time and resets its state.
• Thinking a re-render always means the DOM changed. Many re-renders end with no DOM changes at all.

• What is the difference between re-rendering and updating the DOM?
• Why does changing a component's key reset its state?
• What is React Fiber, and why can rendering be interrupted?