Inside React: from JSX to DOM updates

jsx(type, props, key) does almost nothing: it returns a small, plain object called a React element, a description of what you want on screen. Nothing is rendered, and no component runs, until React is given that object.

• An element is { $$typeof, type, key, ref, props }. $$typeof is the symbol react.transitional.element, which React checks so that JSON from a server can't pass itself off as an element (a defence against injection).
• type is a string for DOM elements ("ul") and the function itself for components. Writing <Badge /> doesn't call Badge; React calls it later, when it renders.
• Children live in props.children. The key is kept outside props (stringified), which is why a component can't read its own key.
• Elements are immutable snapshots: every render creates new ones, and React compares them with the previous ones to decide what to change.

Elements are thrown away after every render, so they can't hold state. For that React keeps a fiber for each component and DOM node: a long-lived object that records its type and key, its props, its state, and links to its parent, first child and next sibling.

• A function component's hooks are a linked list on its fiber, in call order. That is why hooks must run in the same order every render: React finds each hook's state by its position in that list.
• React keeps two copies of the tree. The current one matches the screen; a render builds the next version in the other copy (the work-in-progress), and committing swaps them. Copies are reused, so renders don't allocate a whole new tree.
• Because a render only builds the hidden copy, React can pause it, throw it away or restart it without the screen ever showing a half-finished state.
• Each DOM element points back to its fiber, which is how React DevTools shows component names for what you hover.

Comparing two trees in general is expensive, so React uses two cheap rules instead. Elements of a different type produce different trees, and among siblings, the key says which element is which.

• Same type in the same position: React keeps the DOM node and the component's state, and only updates changed attributes and text.
• Different type (even <div> to <section> with identical children): the old subtree is unmounted, DOM and state included, and a new one is mounted.
• Without real keys, list items are matched by position. Insert at the top and React updates every row instead of inserting one, and each row's state stays at its old position, now under the wrong item.
• A key is also a reset button: changing a component's key makes React treat it as a new component with fresh state.

An update happens in two phases. In the render phase React calls your components to get new elements and works out the changes; nothing touches the screen and the work can be interrupted. In the commit phase it applies the changes to the DOM in one go, then runs effects.

• Render runs parent first (a parent's output decides its children). Effects run child first, because a child is complete before its parent is.
• useLayoutEffect runs during the commit, after the DOM has changed but before the browser paints: the place to measure layout or adjust it without a visible flicker. It blocks painting, so keep it short.
• useEffect runs later. For updates caused by a discrete event such as a click, React runs the effects before the browser paints the next frame, so the effect's result shows up with the click; for other updates they normally run after the paint.
• A transition shows the scheduler at work: React first re-renders urgently (so isPending can turn true), lets the browser draw a frame, and only then renders the transition itself.
• Render must be pure: React may call a component more than once for one commit (Strict Mode does it on purpose in development), or start a render and throw it away.

Not all updates are equally urgent. Typing must show at once; a list filtered by that typing can wait a moment. React gives updates priorities (lanes): urgent ones render synchronously, while transitions and deferred values render in small slices that yield to the browser and can be abandoned when newer input arrives.

• A synchronous render can't be interrupted: if the list takes 125 ms, the browser can't paint the next keystroke for 125 ms.
• useDeferredValue(query) renders the input with the new text first, then re-renders the list with the deferred value at low priority. If another key arrives meanwhile, React drops that render and starts again with the latest value.
• The slow component must be memoized (memo) so the urgent render can skip it, and React can only pause between components: one component that does 100 ms of work in its body can't be interrupted. The demo's list is 250 small row components for that reason.
• startTransition does the same for state updates you trigger yourself, such as switching tabs. Neither makes the slow work faster; they keep it from blocking more important work, which is what Interaction to Next Paint measures (see large dataset performance for making the work itself cheaper).