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 पुराने और नए Fiber ट्री की तुलना करके अपडेट, इंसर्ट या डिलीट का निर्णय कैसे करता है।
Reconciliation, React का वह algorithm है जो state या props बदलने पर UI को efficiently update करता है। पूरे DOM tree को फिर से render करने के बजाय, React पिछले virtual DOM tree की नई rendered tree से तुलना करता है और ज़रूरी operations की minimum संख्या compute करता है। यह O(n³) के बजाय O(n) समय में करने के लिए दो key heuristics का उपयोग करता है।
React मान लेता है: (1) अलग-अलग types के elements पूरी तरह अलग trees बनाते हैं — इसलिए React पुराने subtree को unmount करता है और एक fresh one mount करता है। (2) Developer, key prop का उपयोग करके renders के पार stable identity hint कर सकता है।
जब दो elements का same type हो (जैसे दोनों <div>), React existing DOM node को रखता है और केवल changed attributes/props को update करता है। इससे DOM nodes को unnecessarily destroy और recreate करने से बचा जाता है।
यदि type बदलता है (जैसे <div> → <span>), React पुरे old component tree को unmount करता है (सभी cleanups चलाते हुए) और new tree को fresh mount करता है। State खो जाती है।
Children की lists के लिए, React key के द्वारा old और new items को match करता है। Keys के बिना, React position का उपयोग करता है — जो items reorder होने पर unnecessary unmounts कर सकता है। Keys React को existing DOM nodes को move करने देती हैं।
जैसे-जैसे React दोनों trees walk करता है, यह एक 'effect list' बनाता है — काम करने वाले fibers की linked list (updates, insertions, deletions)। commit phase इस list को walk करके real DOM पर changes apply करता है।
React के reconciliation engine में काम की एक इकाई। प्रत्येक component का एक fiber नोड होता है जो type, props, state, और parent/child/sibling fibers के pointers store करता है।
Current fiber tree का एक clone जहाँ React reconciliation के दौरान changes apply करता है। commit phase पूरा होने के बाद ही 'current' बनता है।
Pending DOM mutations वाले fibers की एक flat linked list, reconciliation के दौरान बनाई जाती है और commit phase के दौरान walk की जाती है।
जब React detect करता है कि fiber के props और context नहीं बदले हैं, तो वह उस subtree को render करना पूरी तरह skip कर सकता है — एक 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 React के declarative model को practical बनाता है। आप describe करते हैं कि UI कैसा दिखना चाहिए, और React ज़रूरी DOM changes का minimum set figure out करता है। Fiber architecture इसे interruptible बनाती है — React reconciliation को mid-tree pause कर सकता है और बाद में resume कर सकता है, जो Suspense और transitions जैसी concurrent features को enable करता है।
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.