Browser & Frontend Runtime
React fiber: tame a re-render storm
Reading about bailouts and lanes is not the same as pulling a real UI out of a re-render storm. Build a live, interactive data grid, drive it into jank, then apply the unit’s fix ladder — memoise, collocate, time-slice, virtualise, de-tear — until the numbers come back, with Profiler evidence at every step.
Turn the unit’s mental model into a reproducible engineering loop: instrument with the React Profiler, read the re-render reason for each fiber, fix at the right level (referential stability, then state collocation, then priority, then virtualisation), defend against tearing, and verify the fix with before/after INP and commit-time numbers.
Take a deliberately janky live data grid (your own or the spec below) and bring its keystroke INP under 200 ms and its commit time under one frame — without rewriting it in another framework — proving each step with React Profiler and Performance-panel measurements.
- A before/after table: keystroke INP (p75), longest commit time, and re-render count per keystroke — all measured under the same live-tick load, not estimated.
- Profiler traces before and after: the baseline shows a wide 'parent rendered, props unchanged' storm; the fixed trace shows only the genuinely-changed visible rows rendering, with commit under ~8 ms.
- Keystroke INP holds under 200 ms p75 during sustained typing while the store ticks ~10/second, and no Long Animation Frame is attributed to the grid during a 30-second session.
- A one-paragraph write-up naming which lever fixed each symptom (referential stability vs state collocation vs priority vs virtualisation vs tearing) and why that lever ranked where it did.
- Turn on the React Compiler and re-profile: confirm it inserts the memoisation you wrote by hand, note any component where it bails out conservatively, and explain why understanding the bailout mechanism let you read its output.
- Add a deliberate render-phase side effect (an analytics call in a component body), run it under StrictMode, and show the double-count; then move it to useEffect and show the count corrected — documenting why render must be pure.
- Add a useLayoutEffect that measures a row with getBoundingClientRect and adjusts a style, then show in the Profiler how it lengthens the commit (forced reflow); compare against doing the same work in useEffect after paint.
- Write a one-page on-call runbook: the Profiler triage steps, the 'parent rendered + unchanged props' signature, the fix ladder in order, and a verification checklist tying each fix to a measurable Profiler/INP delta.
This is the loop you will run in every real React performance incident: instrument with the Profiler first, read the re-render reason per fiber, then fix at the right level — referential stability before state collocation before priority before virtualisation — defend against tearing with useSyncExternalStore, and verify with before/after INP and commit numbers under identical load. Doing it once on a toy grid makes the production version muscle memory, and makes the React Compiler’s output something you can read rather than trust blindly.