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 18 time slicing और priority lanes से UI को responsive कैसे रखता है।
Concurrent rendering, React 18 की वह क्षमता है जो एक साथ UI के कई versions तैयार कर सकती है और urgent updates को handle करने के लिए लंबे time-consuming renders को interrupt कर सकती है। Rendering एक single synchronous operation की बजाय जो main thread को block करे, React अब render work को mid-tree pause कर सकता है, browser को yield कर सकता है, urgent updates handle कर सकता है, फिर paused work को resume या discard कर सकता है।
React का Fiber reconciler प्रत्येक component को काम की एक छोटी unit (fiber) के रूप में represent करता है। Render phase एक समय में एक fiber process करता है, प्रत्येक unit के बाद check करता है कि क्या higher-priority काम आया है। यदि हाँ, तो यह pause कर सकता है और बाद में वापस आ सकता है।
React का scheduler render work को छोटे chunks में तोड़ता है। प्रत्येक chunk के बाद, यह browser को control वापस देता है — input events, animations और paints को होने देता है। इससे लंबे renders के दौरान UI freeze होने से बचता है।
React 18, updates को priority द्वारा classify करने के लिए 'lanes' model उपयोग करता है: SyncLane (user input, तुरंत होना चाहिए), InputContinuousLane (ongoing gestures), DefaultLane (normal state updates), TransitionLane (non-urgent UI transitions)।
यदि React एक low-priority render पर काम करते समय एक high-priority update आता है, तो React low-priority काम pause करता है, high-priority update को पूरी तरह process करता है (commit सहित), फिर low-priority काम को resume या restart करता है।
क्योंकि render phase pure है (कोई side effects नहीं), React आंशिक रूप से complete renders को safely discard कर सकता है और application state को corrupt किए बिना restart कर सकता है। Side effects केवल commit phase में होते हैं, जिसे कभी interrupt नहीं किया जाता।
Render work को ~5ms chunks में तोड़ना और chunks के बीच browser को yield करना। महंगे renders के दौरान UI को responsive रखता है।
एक bitmask system जो updates को SyncLane (सबसे urgent) से OffscreenLane (सबसे कम urgent) तक classify करता है। Scheduling order निर्धारित करता है।
React का internal task scheduler। Render tasks की एक priority queue manage करता है और priority और deadlines के आधार पर तय करता है कि आगे क्या करना है।
State update को non-urgent transition के रूप में mark करने का API। React को बताता है कि यह काम अधिक urgent updates के लिए interrupt किया जा सकता है।
Hook जो startTransition के साथ-साथ एक isPending boolean provide करता है जो दर्शाता है कि transition in progress है या नहीं।
1import { useState, useTransition } from 'react';23function SearchPage() {4 const [query, setQuery] = useState('');5 const [results, setResults] = useState([]);6 const [isPending, startTransition] = useTransition();78 function handleInput(e) {9 // Urgent: update the input immediately10 setQuery(e.target.value);1112 // Non-urgent: filtering 10,000 results can wait13 startTransition(() => {14 setResults(filterItems(e.target.value));15 });16 }1718 return (19 <>20 <input value={query} onChange={handleInput} />21 {isPending && <Spinner />}22 <ResultsList results={results} />23 </>24 );25}26// Typing feels instant (urgent update)27// Results update when React has time (transition)
React 18 से पहले, कोई भी state update जो slow render trigger करती थी, rendering पूरी होने तक पूरे UI को freeze कर देती थी। Concurrent rendering का अर्थ है कि input में typing, scrolling और buttons click करना responsive रहता है, भले ही React background में एक complex update compute कर रहा हो। यह Suspense, streaming SSR और React Server Components की नींव है।
A product catalog with 50,000 items needs instant search. Using debounce (300ms delay) feels sluggish. Without debounce, every keystroke triggers a heavy filter that blocks the main thread and makes typing lag.
Traditional approach: debounce → wait 300ms → filter → re-render. The user types 'laptop' and sees nothing for 300ms after each keystroke. Or without debounce: type 'l' → 50ms filter blocks thread → 'a' keystroke is delayed → laggy typing experience.
Use `startTransition` to mark the filter as non-urgent. React processes the input update immediately (typing stays responsive), then renders the filtered results when the main thread is free. If the user types another character before the filter completes, React ABANDONS the in-progress render and starts the new filter — no wasted work.
Takeaway: Concurrent rendering replaces debouncing for CPU-heavy UI updates. It provides a better UX (no artificial delay) with better performance (abandoned renders waste no DOM work). Use useTransition for filtering, sorting, and computing derived state.
Clicking a navigation link to a data-heavy dashboard page freezes the UI for 500ms while the new page renders 200+ chart components. The old page disappears, a blank screen shows, then the new page appears — jarring.
Without concurrent rendering, React must complete the entire render synchronously. Clicking 'Dashboard' unmounts the current page and starts rendering 200 charts. The main thread is blocked for 500ms — no animations, no response to user input, just a white flash.
Wrap the navigation in `startTransition(() => navigate('/dashboard'))`. React keeps the old page visible and interactive while rendering the dashboard in the background. If the user clicks 'Back' during this time, React abandons the dashboard render. The transition completes smoothly with no blank screen.
Takeaway: Concurrent rendering enables 'optimistic UI' for navigation — the old page stays visible until the new one is fully ready. This eliminates white-flash navigation transitions and lets users cancel slow navigations by clicking elsewhere. Next.js App Router uses this pattern by default.