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.
React purane aur naye Fiber trees compare karke update, insert ya delete ka decision kaise leta hai.
Reconciliation React ka algorithm hai jo state ya props change hone par UI ko efficiently update karta hai. Poore DOM tree ko re-render karne ki jagah, React previous virtual DOM tree ko nayi rendered tree se compare karta hai aur minimum number of operations compute karta hai. Yeh ise O(n) time mein karne ke liye do key heuristics use karta hai O(n³) ki jagah.
React assume karta hai: (1) Different types ke elements completely different trees produce karte hain — toh React purana subtree unmount karta hai aur ek fresh mount karta hai. (2) Developer key prop use karke renders ke across stable identity hint kar sakta hai.
Jab do elements ka same type ho (jaise dono <div>), React existing DOM node rakhta hai aur sirf changed attributes/props update karta hai. Isse unnecessarily DOM nodes destroy aur recreate karne se bachta hai.
Agar type change ho jaata hai (jaise <div> <span> ban jaata hai), React poora purana component tree unmount karta hai (saari cleanups run karke) aur nayi tree fresh mount karta hai. State lost ho jaati hai.
Children ki lists ke liye, React old aur new items ko key se match karta hai. Keys ke bina, React position use karta hai — jo items reorder hone par unnecessary unmounts cause kar sakta hai. Keys React ko existing DOM nodes efficiently move karne deti hain.
Jaise React dono trees walk karta hai, woh ek 'effect list' build karta hai — fibers ki ek linked list jinhe kaam karna hai (updates, insertions, deletions). Commit phase yeh list walk karta hai aur real DOM mein changes apply karta hai.
React ke reconciliation engine mein kaam ki ek unit. Har component ka ek fiber node hota hai jo type, props, state, aur parent/child/sibling fibers ke pointers store karta hai.
Current fiber tree ka ek clone jahan React reconciliation ke dauran changes apply karta hai. Sirf commit phase complete hone ke baad 'current' promote hota hai.
Pending DOM mutations wale fibers ki ek flat linked list, reconciliation ke dauran build hoti hai aur commit phase ke dauran walk ki jaati hai.
Jab React detect karta hai ki ek fiber ke props aur context nahi bade hain, toh woh us subtree ka rendering poori tarah skip kar sakta hai — ek key performance optimization.
1// Without keys — position-based matching (bad for reordering)2// Old: [<A/>, <B/>, <C/>]3// New: [<B/>, <A/>, <C/>]4// React sees: position 0 changed (updates A→B), position 1 changed (updates B→A)5// Result: 2 updates + possible state loss67// With keys — identity-based matching (correct)8// Old: [<A key="a"/>, <B key="b"/>, <C key="c"/>]9// New: [<B key="b"/>, <A key="a"/>, <C key="c"/>]10// React sees: same keys, just reordered11// Result: 0 updates, 2 DOM moves — much more efficient
Reconciliation hi React ke declarative model ko practical banata hai. Aap describe karte hain UI kaisi dikhni chahiye, aur React minimum set of DOM changes figure out karta hai. Fiber architecture ise interruptible banata hai — React reconciliation ko mid-tree pause kar sakta hai aur baad mein resume kar sakta hai, concurrent features jaise Suspense aur transitions enable karta hai.
You have a todo list where users can delete items from the middle. Each item has an input field showing its text. After deleting the 2nd item, the 3rd item's input shows the 2nd item's text.
Using `index` as the key means when item 2 is deleted, React thinks item 3 IS item 2 (same key=2). It reuses the old component instance (with stale state) instead of destroying item 2 and moving item 3.
Use a stable unique ID (e.g., `todo.id`) as the key. Now React correctly identifies which component was removed and which should be kept. The reconciliation algorithm can match by identity instead of position.
Takeaway: The reconciliation algorithm's O(n) shortcut relies entirely on keys for list matching. Using array index as key defeats this optimization and introduces state bugs whenever order changes.
You have a conditional render: `isAdmin ? <AdminPanel /> : <UserPanel />`. Switching between admin and user views causes a full re-mount, destroying all form state.
React's reconciliation sees a different component TYPE at the same position. Its heuristic: 'different type = completely different tree'. It destroys the old subtree and builds a new one from scratch — losing all internal state.
If both panels share a similar structure, use the same component with conditional rendering inside. Or use `key` to explicitly control when a component should re-mount vs update. Understanding that React compares types first, then props, helps you design state-preserving UIs.
Takeaway: React's reconciliation compares elements top-down: type first, then key, then props. A type change always triggers a full unmount/remount of the entire subtree — this is by design, not a bug.