Virtual DOM and Reconciliation

#Context

const el = <li className="todo">Buy milk</li>

// compiles (React 17+ JSX transform) to roughly:
const el2 = jsx('li', {className: 'todo', children: 'Buy milk'})

// and that call just returns a description:
// { type: 'li', key: null,
//   props: { className: 'todo', children: 'Buy milk' } }

Element

The plain object a JSX expression produces: type, props, key. Cheap to create, never mutated, thrown away after the next render.

Render

Calling your components to get a new element tree. In React this produces no DOM changes by itself.

Reconciliation

Comparing the new tree with the previous one to work out which components keep their state and which DOM nodes must change.

Commit

Applying the computed changes to the real DOM, then running layout effects and, later, effects.

Fiber

React’s internal record for one component instance (since React 16): its type, state, props and links to parent, child and sibling.

Key

A string you give list items (or any element) so React can match old and new children by identity instead of by position.

#Why it matters

#How the diff works

1. 1
   Different type at the same position means a different thing. If a div becomes a section, or <Profile> becomes <Settings>, React destroys the old subtree, including all component state and DOM nodes, and mounts the new one from scratch. It never tries to morph one into the other.
2. 2
   Same type at the same position means the same thing, updated. React keeps the DOM node (or component instance and its state) and only patches the props that changed, then recurses into the children.
3. 3
   Children are matched by key, falling back to position. Without keys, the first old child is compared with the first new child, the second with the second, and so on. With keys, children are matched by identity wherever they moved.

#Keys decide which state survives

1. 1
   The list renders two rows, "Buy milk" (key 0) and "Walk dog" (key 1). The user edits the first input to "Buy milk and eggs". That text lives in the DOM input, not in React state.
2. 2
   A new todo, "Call mom", is prepended. The new list is "Call mom" (key 0), "Buy milk" (key 1), "Walk dog" (key 2).
3. 3
   React matches key 0 with key 0: same type, so it keeps the existing input node and only updates defaultValue, which has no effect after mount. The row now labelled "Call mom" still shows "Buy milk and eggs".
4. 4
   Key 1 is reused for "Buy milk" with the original text, and key 2 is new, so React mounts a fresh row for "Walk dog". Every row past the insertion point is wrong or rebuilt.
5. 5
   With key={todo.id}, React sees one new key at the top, mounts one row and inserts it; the edited input moves with its todo.

{todos.map((todo, i) => (
  // BUG: state follows the position, not the todo
  <li key={i}>
    <input defaultValue={todo.text} />
  </li>
))}

{todos.map(todo => (
  // stable identity from the data
  <li key={todo.id}>
    <input defaultValue={todo.text} />
  </li>
))}

Keys as a reset button

// a new userId = a new form; old draft state is discarded
<ProfileForm key={userId} userId={userId} />

// never: a fresh key each render remounts on every keystroke
<Row key={Math.random()} item={item} />

#Render, commit and Fiber

function Search({all}: {all: Item[]}) {
  const [query, setQuery] = useState('')
  const [results, setResults] = useState(all)
  const [isPending, startTransition] = useTransition()

  function onChange(e: React.ChangeEvent<HTMLInputElement>) {
    setQuery(e.target.value)          // urgent: the input stays responsive
    startTransition(() => {
      // low priority: React may abandon this render if you keep typing
      setResults(filterItems(all, e.target.value))
    })
  }

  return (
    <>
      <input value={query} onChange={onChange} />
      <ResultList items={results} dimmed={isPending} />
    </>
  )
}

#Frameworks without a diff

#Pitfalls

• Index as key in a list that changes order

  Inserting, deleting, sorting or filtering shifts every index, so state, DOM input values and animations stay with the position and end up on the wrong item. Index keys are only safe for static lists that never reorder; anything else needs an ID from the data.

• Unstable keys

  Math.random(), crypto.randomUUID() or a key built from mutable fields changes between renders, so React treats each row as brand new: it unmounts and remounts it, inputs lose focus and typed text, and effects run again. Generate IDs once, when the data is created.

• Declaring a component inside another component

  A function defined in the parent's body is a new function on every render, and a new function is a different component type. React therefore remounts that child each time the parent renders, resetting its state and focus. Define components at module level and pass data through props.

• Expecting state to reset when only props change

  Two <Form> elements in the same spot of a ternary are the same type at the same position, so they share state even if they represent different records. Give them different keys when they should be independent, instead of syncing props into state with an effect.

• Assuming the virtual DOM makes every update cheap

  The diff limits DOM writes, not JavaScript work: re-rendering a 5,000-row table on each keystroke still calls 5,000 components. Measure with the React Profiler, then virtualise long lists, move state down, use transitions or memoize.

#Interview questions