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.
Comment React 18 utilise le découpage temporel et les lanes de priorité pour garder l'interface réactive.
Le rendu concurrent est la capacité de React 18 à préparer simultanément plusieurs versions de l'interface et à interrompre les rendus de longue durée pour traiter des mises à jour plus urgentes. Au lieu que le rendu soit une opération synchrone unique qui bloque le thread principal, React peut maintenant suspendre le travail de rendu au milieu de l'arbre, céder au navigateur, traiter des mises à jour urgentes, puis reprendre ou abandonner le travail suspendu.
Le réconciliateur Fiber de React représente chaque composant comme une petite unité de travail (un fiber). La phase de rendu traite un fiber à la fois, vérifiant après chaque unité si un travail de priorité plus élevée est arrivé. Si c'est le cas, il peut se mettre en pause et revenir plus tard.
Le planificateur de React divise le travail de rendu en petits morceaux. Après chaque morceau, il rend le contrôle au navigateur — permettant aux événements d'entrée, animations et dessins de se produire. Cela évite le gel de l'interface pendant les rendus longs.
React 18 utilise un modèle de 'lanes' pour classer les mises à jour par priorité : SyncLane (entrée utilisateur, doit être immédiate), InputContinuousLane (gestes continus), DefaultLane (mises à jour de state normales), TransitionLane (transitions UI non urgentes).
Si une mise à jour haute priorité arrive pendant que React travaille sur un rendu basse priorité, React met en pause le travail basse priorité, traite complètement la mise à jour haute priorité (y compris le commit), puis reprend ou redémarre le travail basse priorité.
Parce que la phase de rendu est pure (pas d'effets de bord), React peut abandonner en toute sécurité des rendus partiellement complétés et les redémarrer sans corrompre l'état de l'application. Les effets de bord ne se produisent que dans la phase de commit, qui n'est jamais interrompue.
Diviser le travail de rendu en morceaux de ~5ms et céder au navigateur entre les morceaux. Maintient l'interface réactive pendant les rendus coûteux.
Un système de masques de bits classifiant les mises à jour de SyncLane (plus urgent) à OffscreenLane (moins urgent). Détermine l'ordre de planification.
Le planificateur de tâches interne de React. Gère une file de priorité de tâches de rendu et décide sur quoi travailler ensuite selon la priorité et les délais.
API pour marquer une mise à jour de state comme transition non urgente. Dit à React qu'il peut interrompre ce travail pour des mises à jour plus urgentes.
Hook qui fournit startTransition plus un booléen isPending indiquant si une transition est en cours.
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)
Avant React 18, toute mise à jour de state déclenchant un rendu lent gelait toute l'interface jusqu'à la fin du rendu. Le rendu concurrent signifie que taper dans un champ, faire défiler et cliquer sur des boutons restent réactifs même pendant que React calcule une mise à jour complexe en arrière-plan. C'est le fondement de Suspense, du SSR en streaming et des Composants Serveur React.
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.