{"id":4174,"date":"2024-10-17T17:24:30","date_gmt":"2024-10-17T17:24:30","guid":{"rendered":"https:\/\/algocademy.com\/blog\/understanding-reacts-virtual-dom-a-deep-dive-into-efficient-ui-updates\/"},"modified":"2026-10-15T12:51:16","modified_gmt":"2026-10-15T12:51:16","slug":"understanding-reacts-virtual-dom-a-deep-dive-into-efficient-ui-updates","status":"publish","type":"post","link":"https:\/\/algocademy.com\/blog\/understanding-reacts-virtual-dom-a-deep-dive-into-efficient-ui-updates\/","title":{"rendered":"React Virtual DOM Explained: Diffing, Reconciliation, Keys"},"content":{"rendered":"

React does not use a separate virtual DOM library.<\/strong> The virtual DOM is a pattern built into React itself. When you write JSX, you create plain JavaScript objects called React elements. React’s own reconciler (called Fiber since React 16) compares the elements from the last render with the new ones, and a renderer such as react-dom<\/code> applies the difference to the real DOM. There is nothing to install and nothing to configure.<\/p>\n

Some other libraries do ship their own virtual DOM: Vue and Preact are examples. Svelte and Solid take a different route and compile templates to direct DOM updates without one.<\/p>\n

What the “virtual DOM” actually is<\/h2>\n

React’s old documentation defined it as “a programming concept where an ideal, or virtual, representation of a UI is kept in memory and synced with the real DOM”. That same page (the legacy “Virtual DOM and Internals” FAQ) adds that it is more a pattern than a specific technology. In React the term usually refers to the React elements your components return, and React also keeps internal objects called fibers that hold extra information about the component tree.<\/p>\n

The current docs at react.dev describe the same thing without the term, as three steps: trigger, render, commit<\/strong>.<\/p>\n

    \n
  1. Trigger.<\/strong> A render starts on the initial render, or when a component’s state (or an ancestor’s) changes.<\/li>\n
  2. Render.<\/strong> React calls your components. “Rendering” here means calling your function, not touching the screen. On a re-render, React works out what changed compared with the previous render.<\/li>\n
  3. Commit.<\/strong> React updates the DOM. According to react.dev, it only changes DOM nodes if there is a difference between renders; if the output is the same as last time, the DOM is not touched.<\/li>\n<\/ol>\n

    The whole point is that you describe what the UI should look like for the current state, and React figures out the DOM operations. You never write “change this text node” yourself.<\/p>\n

    A toy version you can run<\/h2>\n

    This is not how React is implemented (React’s real reconciler is far more involved), but it shows the idea: elements are plain objects, and a diff produces a short list of DOM operations.<\/p>\n

    \/\/ A toy virtual DOM: elements are plain objects, diff() lists the DOM operations needed.\nconst h = (type, props, ...children) => ({ type, props: props || {}, children });\n\nfunction diff(oldNode, newNode, path = \"root\", ops = []) {\n  if (oldNode === undefined) { ops.push(`create ${JSON.stringify(newNode)} at ${path}`); return ops; }\n  if (newNode === undefined) { ops.push(`remove ${path}`); return ops; }\n  if (typeof oldNode === \"string\" || typeof newNode === \"string\") {\n    if (oldNode !== newNode) ops.push(`set text at ${path}: \"${oldNode}\" -> \"${newNode}\"`);\n    return ops;\n  }\n  if (oldNode.type !== newNode.type) {\n    ops.push(`replace <${oldNode.type}> with <${newNode.type}> at ${path} (whole subtree rebuilt)`);\n    return ops;\n  }\n  for (const k of new Set([...Object.keys(oldNode.props), ...Object.keys(newNode.props)])) {\n    if (oldNode.props[k] !== newNode.props[k]) ops.push(`set prop ${k} at ${path}: ${oldNode.props[k]} -> ${newNode.props[k]}`);\n  }\n  const n = Math.max(oldNode.children.length, newNode.children.length);\n  for (let i = 0; i < n; i++) diff(oldNode.children[i], newNode.children[i], `${path}\/${newNode.type}[${i}]`, ops);\n  return ops;\n}\n\nconst view = count => h(\"div\", { class: \"counter\" }, h(\"p\", {}, `Count: ${count}`), h(\"button\", {}, \"Increment\"));\nconsole.log(diff(view(0), view(1)));\nconsole.log(diff(view(0), { ...view(0), type: \"section\" }));<\/code><\/pre>\n
    Output:<\/p>\n
    [ 'set text at root\/div[0]\/p[0]: \"Count: 0\" -> \"Count: 1\"' ]\n[ 'replace <div> with <section> at root (whole subtree rebuilt)' ]<\/code><\/pre>\n
    Changing the count produces one text update. Changing the root element’s type replaces the whole subtree. Both match what React does.<\/p>\n
    The same thing in a React component<\/h2>\n
    import { useState } from \"react\";\n\nfunction Counter() {\n  const [count, setCount] = useState(0);\n\n  return (\n    <div>\n      <p>Count: {count}<\/p>\n      <button onClick={() => setCount(count + 1)}>Increment<\/button>\n    <\/div>\n  );\n}<\/code><\/pre>\n
    On a click, setCount<\/code> queues a render. React calls Counter<\/code> again, gets a new tree, sees that only the text inside the <p><\/code> differs, and updates that text node. The <div><\/code> and the <button><\/code> are left alone.<\/p>\n
    How the diffing works<\/h2>\n
    Comparing two arbitrary trees exactly is expensive, so React uses a heuristic. The legacy reconciliation docs describe it as an O(n) algorithm based on two assumptions:<\/p>\n
      \n
    1. Two elements of different types will produce different trees.<\/li>\n
    2. The developer can hint which children are stable across renders with a key<\/code> prop.<\/li>\n<\/ol>\n
      In practice this means:<\/p>\n