React Fiber's 20 Fields Are the Entire Runtime
Understanding the Fiber data structure turns opaque React behavior—bail-outs, priority inversions, memory leaks from orphaned subtrees—into legible field-level mechanics. When a production app leaks FiberNodes, the developer who knows that `return`, `child`, and `alternate` form a reference graph can trace the root cause instead of guessing at the garbage collector.
A memory-leak investigation into a long-running React app traced thousands of unreclaimed FiberNodes back to a third-party router that forgot to sever a root reference. The fix was three lines, but the real payoff was a line-by-line reading of the `FiberNode` constructor in `ReactFiber.js`. Each of its twenty-some fields maps to a runtime capability: `tag` routes the reconciler to the correct `beginWork` branch, the `child`/`sibling`/`return` pointers turn a recursive tree into an interruptible linked list, `lanes` and `childLanes` propagate scheduling priority upward so the work loop can skip entire subtrees, and `flags`/`subtreeFlags` collect side effects as bitmasks so the commit phase knows exactly what DOM work is needed.
The double-buffering bridge `alternate` lets React compare old and new state without keeping two full copies of global bookkeeping—that job belongs to the separate `FiberRootNode`, which holds `pendingLanes`, the scheduler callback, and error handlers outside the Fiber tree itself. The design separates four identities (component description, tree structure, work state, side-effect tracking) into distinct field groups, which means the component model, scheduler, renderer, and DevTools teams can all work against the same data structure without stepping on each other.
Fiber's design is a case study in how a single flat data structure, with no inheritance and no hidden state, can replace a whole family of specialized objects—the simplicity is what makes cloning, discarding, and reusing nodes cheap.
The four-identity split (component, tree, work, side effects) isn't just documentation; it's an organizational boundary that lets separate React teams evolve the scheduler, renderer, and component model against the same contract.
Bitmask-based lanes and flags are an underappreciated performance choice: they turn what would be array traversals and object lookups into single-cycle bitwise operations, and they compose cleanly with the upward-propagation pattern used by `childLanes` and `subtreeFlags`.
Calling the parent pointer `return` instead of `parent` is a deliberate semantic choice that reflects the traversal algorithm—it's a reminder that the Fiber tree is a work-list, not a static hierarchy.
The `deletions` array pattern (storing doomed children on the parent) is a generalizable trick for any tree transform where removed nodes won't be visited again but still need post-order cleanup.
The discussion splits between appreciation for deep technical writing in an AI-saturated era and a sharp critique that the article is a hollow listing of properties without the promised core logic. A side thread touches on memory management, with the author offering a follow-up on removing root node references. The tension is whether the article delivers on its title or merely catalogs fields.
In 2026, with Vibe Coding all the rage, it's genuinely rare to see such a carefully crafted technical article.
Many people think that since AI can write code, why bother learning anything. But if you can't even understand what the AI writes, you'll end up swallowing the bitter consequences yourself.
A total fluff piece. The stuff in the intro is never touched on again. Not a single word about the core logic of how it's done, just listing the property definitions of the Fiber object. Where exactly are the promised 3 lines of code and the core mechanism? Read it from start to finish and saw no core implementation at all, completely lacking focus. Just a bunch of conceptual nonsense.
If you didn't read it carefully, you could just not read, bookmark, or comment. 1. The 'three lines of code' refers to using three lines of code to fix a problem in my code; even someone who doesn't understand Fiber would know three lines of code can't possibly implement Fiber. 2. The title is 'How a Data Structure Carries the Entire Runtime'; if I don't talk about how the data structure is designed and implemented, what should I write about? 3. If you read an article and can't even identify the focus, I don't know what to say.