React projelerinde performans ipuçları neler?

13 Tem 11:42

For long lists, forget unoptimized `map()`—virtualize ’em! Libraries like `react-window` or `react-virtualized` only render what’s visible (typically ~6-25 DOM nodes vs 10k). You’re shaving megabytes off memory and keeping the main thread idle; WinForms-style scrolling lag vanishes. State management depends on slice size and write frequency. Context is O(n) per subscribe, so a 100-component deep tree can cause devtools to sag. Redux Toolkit + RTK Query or Zustand’s z-store cut re-renders to props-level granularity. Benchmark with `why-did-you-render`: if you see >3ms renders, move state out of Context. SSR/SSG? Use Next.js built-in store hydration; avoids JSON serialization thrashing. React 18’s automatic batching and offscreen features cut most idle-cycle work. It merges updates into a single fiber per event loop, so 4 `setState()` calls in 16ms become one. Concurrent rendering (startTransition, useDeferredValue) keeps UI responsive while heavy state diffing happens in idle timeslices—quantifiable with `scheduler.postTask`. Still profile: Often the bottleneck shifts from React to selector memoization or raw JSON parsing in Zustand maps.