Join the discussion
Comments
Loading comments...
Cookie preferences
We use essential cookies for sign-in and preferences. With your permission, we also use basic analytics to improve lessons.
Join the discussion
Loading comments...
We use essential cookies for sign-in and preferences. With your permission, we also use basic analytics to improve lessons.
Dekho kaise React reconciliation mein depth-first search se Fiber tree traverse karta hai.
Fiber React ka internal reconciliation engine hai, jo React 16 mein introduce kiya gaya tha. Aapki app mein har component ka ek corresponding Fiber node hota hai — ek JavaScript object jo component type, uske props, state, associated DOM node, aur parent, child, aur sibling fibers ke pointers store karta hai. Yeh linked structure React ko multiple frames mein kaam pause, resume, aur prioritize karne deta hai.
Jab React aapka component tree render karta hai, toh har element ke liye ek Fiber node banata hai. Node store karta hai: type (function/class/string), props, state, effect hooks, aur previous render ka work-in-progress state.
Ek recursive call stack ke unlike (jo pause nahi ho sakta), Fibers ek linked list ki tarah connected hote hain: har node mein ek child pointer (first child), sibling pointer (next sibling), aur return pointer (parent) hota hai. Isse React tree ko iteratively traverse kar sakta hai.
React fiber tree ko depth-first walk karta hai. Neeche jaate waqt (parent → child) 'beginWork' call karta hai aur upar aate waqt (child → parent) 'completeWork'. Yeh two-pass approach React ko bottom-up effect list build karne deta hai.
React ek saath do fiber trees maintain karta hai: 'current' tree (jo screen par hai) aur 'work-in-progress' tree (jo build ho raha hai). Har fiber node ka ek 'alternate' pointer hota hai jo doosre tree mein uske counterpart se link karta hai.
Jab commit phase complete hota hai, React atomically dono trees swap karta hai root ke 'current' pointer ko work-in-progress tree ki taraf point karke. Purana current tree next render ke liye naya work-in-progress ban jaata hai.
Ek JS object jo ek component ke liye ek unit of work represent karta hai. Isme type, key, ref, props, state, hooks list, effect tags, aur tree pointers hote hain.
Reconciliation ke dauran build hone wala fiber tree. User ko tab tak visible nahi hota jab tak commit phase complete nahi ho jaata aur yeh current tree se swap nahi ho jaata.
Woh do functions jo React fiber tree traverse karte waqt call karta hai. beginWork ek node ko neeche jaate waqt process karta hai; completeWork usse upar aate waqt finalize karta hai.
Ek fiber node par ek bitmask flag jo batata hai ki kya DOM work hona chahiye: Placement (insert), Update (patch props), Deletion (remove).
Har fiber mein ek 'alternate' field hota hai jo doosre tree mein uske counterpart ki taraf point karta hai (current ↔ work-in-progress). Double buffering enable karta hai.
1// Simplified Fiber node structure (React internals)2{3 tag: FunctionComponent, // type of fiber4 type: MyComponent, // component function/class/string5 key: null,6 ref: null,7 pendingProps: { id: 1 },8 memoizedProps: { id: 1 }, // props from last render9 memoizedState: hooksList, // linked list of hooks1011 // Tree pointers12 return: parentFiber, // parent13 child: firstChildFiber, // first child14 sibling: nextSiblingFiber, // next sibling1516 // Double buffering17 alternate: workInProgressFiber,1819 // Work tracking20 flags: Update | Passive, // effect tags21 lanes: DefaultLane, // priority22}
Fiber architecture hi React ke concurrent features ko possible banata hai. Kyunki kaam ek data structure ke roop mein represent hota hai (call stack nahi), React reconciliation ko kisi bhi fiber node par pause kar sakta hai, browser ko high-priority tasks jaise user input ke liye control wapas de sakta hai, aur wahan se resume kar sakta hai jahan chhoda tha. Yahi Suspense, transitions, aur automatic batching ka foundation hai.
Your dashboard app freezes for 200ms when a user opens a settings panel. React DevTools Profiler shows a long 'Render' phase but you can't identify which component is slow.
Without understanding Fiber, the profiler's flame graph (which shows fiber-by-fiber render times) looks like random colored bars. You don't know why some components are 're-rendered' when their props haven't changed.
Understanding that each bar in the Profiler IS a fiber node helps you trace the work loop: parent → child → sibling. You can identify which fiber's `beginWork` is slow, check its `memoizedProps` vs `pendingProps`, and apply React.memo or useMemo precisely.
Takeaway: The React DevTools Profiler is literally a fiber tree visualizer. Understanding fiber architecture transforms it from a confusing chart into a powerful debugging tool.
You have a drag-and-drop interface where moving an item should animate at 60fps, but data fetching from a heavy table re-render causes janky movement.
A single synchronous render blocks the main thread for 50ms+, causing the browser to skip animation frames during the data fetch re-render.
React Fiber's priority lanes system lets you wrap the heavy re-render in `startTransition()`, marking it as low-priority. The fiber work loop can now pause the heavy render, yield to the browser for animation frames, and resume later — all because fibers are interruptible units of work.
Takeaway: Fiber architecture is the reason `useTransition` and `useDeferredValue` exist. These APIs wouldn't be possible without interruptible, priority-based rendering.