The Complete Picture: From a Keystroke to a Pixel
Series: How React Works Under the Hood
This is the final article. If you haven't read Parts 1–8, this article won't land the way it should. Go back and start there.Part 1: Motivation Behind React Fiber: Time Slicing & Suspense
Part 2: Why React Had to Build Its Own Execution Engine
Part 3: How React Finds What Actually Changed
Part 4: The Idea That Makes Suspense Possible
Part 5: The React Lifecycle From the Inside
Part 6: How State Actually Works
Part 7: The Trap of Vibe Coding useCallback
Part 8: Server Components & Hydration: The Real Story
Eight Articles. One Question.
In Part 1, Dan Abramov stood in front of a room in Iceland and asked:
"With vast differences in computing power and network speed, how do we deliver the best user experience for everyone?"
We've spent eight articles building the answer. But we've never seen all the pieces working together at once. We've seen Fiber explained. The Scheduler explained. The Reconciler. Algebraic effects. Lifecycle. State. Performance. Server Components. Each one in isolation.
This article puts them together. Not as a summary — as a story. One user. One interaction. Every layer of React underneath it.
By the end, you'll see that everything we built across eight articles was always one system.
The User
She opens a product search page on a mid-range Android phone — the kind of device hundreds of millions of people actually use. Her connection is decent but not fast. She's looking for headphones.
She types. She clicks. She adds something to her cart.
From her perspective: the page loads, she types, results appear, she clicks a button, the cart updates. Four seconds of her life.
Underneath those four seconds, every system in this series ran. Let's trace it.
The Page Loads
The request hits the server. This is Part 8's world.
Server Components run — async, directly querying the database. The product catalog, the navigation, the page layout. None of this code ships to her phone. It renders on the server and becomes the RSC payload — a JSON description of the UI that streams to the client in chunks. Her phone gets real HTML almost immediately, not a white screen waiting for JavaScript.
While the HTML is visible, React starts hydration in the background. It walks the server-rendered DOM and matches each node to its Fiber counterpart — attaching event listeners, storing references, making the page interactive. Because React 18 uses the same Lane priority system from Part 3, if she taps something before hydration finishes, React jumps to that boundary first. The rest of the tree waits. Her tap doesn't go ignored.
The page is ready. She types.
She Types "h"
This is where Parts 2, 3, and 6 all meet.
A change event fires. React calls setQuery('h'). Calling setQuery doesn't immediately update anything — it creates an update object, drops it into a global buffer, and marks a trail called childLanes on every ancestor of the search input fiber, all the way to the root. This is how React knows where work is waiting without walking the entire tree.
The Scheduler sees the update. Because this is a user interaction, it's SyncLane — the highest priority. It runs synchronously. The call stack equivalent of "drop everything and handle this."
React walks the Fiber tree following the trail of childLanes. Every branch with childLanes === 0 is skipped instantly — the footer, the recommendations panel, the filters sidebar. React touches only what needs to change. The input updates. The character appears on screen.
That took a few milliseconds. She doesn't notice. She keeps typing.
The Results Need to Update
Here's the problem that Part 1 opened with — still alive, still relevant.
Filtering 10,000 products on every keystroke is expensive. If React treated the results update with the same urgency as the input update, every character she types would block until the filtering finished. The input would lag. The experience would feel broken.
This is exactly Dan's typing + chart demo from 2018. The chart is the results list. It has to update. But it shouldn't block the input.
The fix is startTransition — wrapping the expensive update so React knows it can wait. The input still updates immediately at SyncLane. The results update in the background at TransitionLane, interruptibly:
setQuery(e.target.value); // urgent — runs now
startTransition(() => setResults(filter(query))); // deferrable — runs when free
That's the entire mechanism. startTransition tells React: this update is real but not urgent. Internally, React assigns it a TransitionLane instead of SyncLane. The Scheduler now has two tasks — the keystroke at the top, the results render below it.
The results render begins using the concurrent work loop — the one that checks shouldYield() after every fiber. She types another character. A new SyncLane keystroke arrives. React abandons the results render mid-tree, handles the keystroke — she sees it immediately — then starts the results render again with the new query.
isPending tells you the transition is in progress, so you can show a spinner or dim the old results while new ones load. The old results stay visible until the render completes. She never sees a blank list.
This is the Git metaphor from Part 1 made real: the keystroke is always the hotfix on main. The results render is always the feature branch. React rebases automatically.
What if you can't wrap the setter?
Sometimes the state lives in a child component or a library you don't control. useDeferredValue solves this — it gives you a deferred copy of a value that React renders at lower priority, interruptibly, without you needing to touch the setter:
const deferredQuery = useDeferredValue(query);
// ResultList receives deferredQuery — renders at TransitionLane, same mechanism
The practical rule: use useTransition when you own the setter, useDeferredValue when you own the value but not where it comes from.
React Finds What Changed
She paused typing. The results render runs to completion. This is Part 3.
React walks the ResultList fiber, runs the component function, gets new JSX. The Reconciler compares old to new. Each product has a key prop — its ID. React builds a map of old fibers keyed by product ID. For each new product, it looks up the existing fiber. Found: reuse it, update only what changed. Not found: create it. Products no longer in results: mark for deletion.
React doesn't touch the DOM during any of this. It marks fibers with flags — insert this, update that, delete this — and bubbles those flags up the tree. By the time it reaches the root, every decision about what needs to change is recorded. Nothing has changed in the DOM yet.
The DOM Updates
The Commit phase runs — synchronous, uninterruptible. The two Fiber trees swap. The workInProgress tree becomes current. What was being built in the background is now the source of truth.
DOM operations execute in order: deletions first, then insertions, then updates. Products that disappeared are removed. New products are inserted. Changed cards get their props updated directly on the existing DOM node — no recreation.
The browser paints. She sees the filtered results.
She Clicks "Add to Cart"
The click fires. setCartCount(c => c + 1) is called. Same machinery as the keystroke — SyncLane, update queued, trail marked up to the root, Scheduler fires synchronously.
React walks the trail. Everything outside the Header subtree has childLanes === 0 — the results list, the filters, the footer — all skipped in one check each. React touches only the Header and its CartIcon child.
The render runs. The commit runs. Now Part 5 takes over.
useLayoutEffect fires synchronously — the DOM is updated, the browser hasn't painted yet. If CartIcon needs to measure its width for an animation, this is the only safe moment. Then the browser paints. She sees the cart count increment.
In the next macro task — after paint, via MessageChannel — useEffect runs. The analytics event fires. localStorage syncs. None of this blocked the paint. None of it delayed what she saw.
What Didn't Run
Of the entire component tree — dozens of components, hundreds of fibers — exactly three ran their render functions for the cart click:
- The root — has
childLanes > 0 -
Header— haschildLanes > 0 -
CartIcon— the state changed here
Everything else: ResultList, SearchInput, Filters, Footer, Recommendations, every ProductCard — skipped. Not because of React.memo. Not because of useCallback. Because childLanes was zero on every other subtree, and React's built-in bailout skipped each one in a single check.
This is the answer to Part 7. The tools exist for the rare cases where the built-in bailout isn't enough. For everything else — the default behavior handles it.
The Complete Map
Eight parts. One answer.
Fiber is the foundation. React replaced the opaque JavaScript call stack with its own — plain objects it controls completely. This made pausing, resuming, and prioritizing possible. Without Fiber, nothing else in this series exists.
The Scheduler sits on top of Fiber and decides what runs and when. Keystrokes get SyncLane — they always run first, synchronously. Results renders get TransitionLane — they run in the background, interruptibly. shouldYield() checks the clock after every fiber to keep the browser breathing between frames.
The Reconciler uses the Fiber tree to find the minimum set of DOM changes. It follows the childLanes trail to find what changed, skips everything with clean subtrees, diffs lists by key, and marks flags on fibers — never touching the DOM until the entire decision is made. Then the Commit phase applies everything atomically so the user never sees a half-updated UI.
Algebraic Effects is the mental model that connects Suspense, ErrorBoundary, and hooks. Components signal what they need by throwing. React — acting as the effect handler — catches it, decides what to do, and resumes when the data arrives. useState feels local because of this model, even though state lives on a Fiber node React controls.
Lifecycle is when effects run relative to the Commit phase. useLayoutEffect fires synchronously before the browser paints — for DOM measurements that must happen before the user sees anything. useEffect fires after paint in the next macro task — for everything else. The separation isn't arbitrary. It maps directly to the Commit phase structure.
State is a hook object on a Fiber's linked list. Calling setState doesn't update immediately — it drops a note in a queue. React reads that queue during the next render, on its own schedule, in its own order. This is why you see the old value after calling setState. The snapshot hasn't changed yet. The note is pending.
Performance is mostly free. The childLanes bailout skips entire subtrees in one check when nothing changed. Structural patterns like children-as-props prevent unnecessary re-renders without any memoization overhead. React.memo, useCallback, and useMemo exist for the small set of cases where the built-in bailout genuinely isn't enough — and they should only be added after measuring.
Server Components moved the question from "how do we render faster on the client" to "how do we send less to the client in the first place." Server code that never ships. RSC payloads that stream progressively. Selective hydration that prioritizes what the user is interacting with. Every Server Action a public endpoint — treat it like one.
What's Still Being Built
The series ends here but React doesn't.
The React Compiler is stable and shipping. It automatically applies the memoization from Part 7 at build time — React.memo, useMemo, useCallback — applied intelligently, without you writing any of it. Understanding this series is exactly what makes your code Compiler-friendly.
use() is the ergonomic layer on top of the algebraic effects model from Part 4. Where Suspense required a data library to implement the throw-Promise pattern, use() exposes it directly from React.
Server Actions security is still maturing. React2Shell revealed a persistent gap between the mental model (local function) and the reality (public HTTP endpoint). The ecosystem is figuring out better defaults. Until then: validate everything.
The One-Sentence Answer
React delivers the best user experience for everyone by giving developers a declarative component model while handling — invisibly — the complexity of prioritizing work, interrupting expensive renders, deferring non-urgent updates, minimizing DOM changes, and progressively delivering content from server to client, through the Fiber and Scheduler machinery built for exactly this purpose.
Eight articles to earn one sentence.
What You Actually Have Now
Before this series, React was a tool you used. After it, React is a system you understand.
The next time an input lags, you know it's a SyncLane update blocked by a lower-priority render — and you know startTransition is the right fix, not useCallback. The next time a component re-renders unexpectedly, you know to check the reference equality of its props and the childLanes trail — not to wrap everything in React.memo. The next time a page loads slowly, you know the difference between a bundle size problem (Server Components), a data waterfall problem (streaming and Suspense), and a render performance problem (Fiber and Reconciler).
The tools haven't changed. But the questions you ask before reaching for them have.
That's what understanding internals actually gives you: not the ability to contribute to React's source code, but the ability to debug faster, make better decisions earlier, and stop adding complexity to fix problems you only half-understood.
Write something. Ship it. Now you'll know why it works.
🙏 Thank You
This series exists because of the people who built these systems and took the time to explain them.
Dan Abramov — for Beyond React 16, the Git metaphor that makes Time Slicing click, RSC from Scratch, Algebraic Effects for the Rest of Us, and overreacted.io. More teaching in one career than most people manage in ten.
Andrew Clark — for the react-fiber-architecture document that set the design goals every article in this series built toward.
Sebastian Markbåge — for the algebraic effects mental model that connects Suspense, ErrorBoundary, Hooks, and Context into one coherent story.
Matheus Albuquerque — for the clearest explanation of FiberNode internals at React Summit 2022.
Sam Galson — for connecting React to the wider computer science of fibers, coroutines, and continuations.
JSer (jser.dev) — for the deepest source-level analysis of React internals anywhere on the internet. Every code-level claim in this series was verified against JSer's work. An extraordinary resource.
Sophie Alpert, Joe Savona, Luna Wei — for the React team's continued work on documentation, RFCs, and honest discussion of tradeoffs.
Lydia Hallie — for JavaScript visualizations that shaped this series' style from the beginning.
Lachlan Davidson — for responsibly disclosing CVE-2025-55182 and working with the React team to fix it.
That's the series. Thank you for reading. 🔧
Tags: #react #javascript #webdev #tutorial
Top comments (0)