Describe useLayoutEffect and compare it with useEffect.

Question

Accepted Answer

The core difference between `useLayoutEffect` and `useEffect` is the timing of their execution. `useEffect` runs asynchronously after the browser has finished painting the screen, meaning **the user might see a brief flash of the initial state before the effect applies changes.** `useLayoutEffect`, however, runs synchronously immediately after React has calculated all DOM mutations but **before the browser paints, allowing you to make changes that are visible in the very first frame.** 1. React calculates DOM changes (virtual DOM diff) 2. DOM mutations are applied to the real DOM 3. ┌─────────────────────────────────────┐ │ 🔵 useLayoutEffect runs (synchronously) │ ← Blocks paint └─────────────────────────────────────┘ 4. Browser paints the screen (user sees UI) 5. ┌─────────────────────────────────┐ │ 🟢 useEffect runs (asynchronously) │ ← After paint └─────────────────────────────────┘ To visualize the order: when a component renders, React first updates the DOM, then `useLayoutEffect` fires, then the browser paints, and finally `useEffect` fires. **This means `useLayoutEffect` blocks the browser's paint until it completes, which is why heavy computations in it can hurt performance, while `useEffect` lets the browser render immediately and does its work afterward.** function TimingDemo() { const [count, setCount] = useState(0); // ✅ Runs asynchronously after paint useEffect(() => { console.log('useEffect runs after paint'); }, [count]); // 🟡 Runs synchronously before paint (blocking) useLayoutEffect(() => { console.log('useLayoutEffect runs before paint'); }, [count]); return

Count: {count}

; } // Console output order on click: // 1. 'useLayoutEffect runs before paint' // 2. (browser paints the screen) // 3. 'useEffect runs after paint' **Measuring DOM elements**: When you need to get an element's dimensions (`getBoundingClientRect()`, `offsetWidth`) for calculations that affect the initial layout. **Preventing visual flicker**: When making DOM changes that would be visible if they occurred after paint (e.g., adjusting scroll position, setting focus). **Synchronizing animations**: When you need to read or write layout properties in the same frame to prevent layout thrashing. **Auto-resizing textareas**: Calculating and applying new heights based on content before the user sees any height jump. function AutoResizingTextarea() { const textareaRef = useRef(null); const [value, setValue] = useState(''); // ✅ Good use of useLayoutEffect - prevents visible height jumps useLayoutEffect(() => { const textarea = textareaRef.current; if (!textarea) return; // Reset height to measure natural height textarea.style.height = '0px'; const scrollHeight = textarea.scrollHeight; // Apply the measured height textarea.style.height = `${scrollHeight}px`; }, [value]); return (

setValue(e.target.value)}
      style={{ resize: 'none', overflow: 'hidden' }}
    />
  );
} **Data fetching**: API calls, loading data from servers **Setting up subscriptions**: Event listeners, WebSocket connections **Updating non-visual state**: Document title, localStorage, analytics **Logging and analytics**: Tracking page views or user interactions **Any side effect that doesn't need to block the user's view** Because `useLayoutEffect` is synchronous and blocks the browser's paint, it can degrade performance if used unnecessarily or if it contains expensive computations. The rule of thumb is: **default to `useEffect` and only use `useLayoutEffect` when you need to read or write DOM layout before the user sees the screen**. Overusing `useLayoutEffect` can lead to **layout thrashing,** where the browser is forced to repeatedly recalculate styles and layout, causing **jank and poor frame rates**. function ExpensiveLayoutEffect() {
  const [data, setData] = useState<number[]>([]);

// ❌ Bad - blocks paint for expensive computation
  useLayoutEffect(() => {
    // Simulating expensive DOM measurements
    const measurements = [];
    for (let i = 0; i < 1000; i++) {
      const element = document.querySelector(`[data-item="${i}"]`);
      if (element) {
        measurements.push(element.getBoundingClientRect());
      }
    }
    console.log('Blocking paint for', measurements.length, 'measurements');
  }, [data]);

// ✅ Better - use useEffect unless sync timing is critical
  useEffect(() => {
    // Same expensive work, but doesn't block paint
    // User sees the update immediately, measurements happen after
  }, [data]);
} `useLayoutEffect` does not run on the server during SSR because it requires the DOM to be present. If you're using Next.js or any SSR setup, React will log a warning when `useLayoutEffect` is used on the server. For code that runs in both environments, you can either use `useEffect` (which is safe for SSR) or conditionally import

Describe useLayoutEffect and compare it with useEffect.

Describe useLayoutEffect and compare it with useEffect.

Scenario Questions

Follow-up Questions