May 13, 2026

By ReactUse Team

React Observer Hooks: 7 Ways to Watch the DOM Without the Boilerplate

The DOM does not tell React when it changes. React owns one direction of the data flow — state goes in, markup comes out — and is mostly blind on the way back. If a third-party script injects a banner, if a font finishes loading and shoves the layout down 8 pixels, if a user resizes the window or scrolls a card into view, React has no idea unless you tell it. The browser ships four *Observer APIs to plug that gap, plus the getBoundingClientRect family for one-shot reads, and together they cover almost every “react to the DOM” requirement a real app has.

The trouble is that wiring observers into a React component is a small swamp of useEffect, useRef, cleanup functions, SSR guards, and the dreaded “observer fires before mount” race. Five lines of API turn into thirty lines of glue, and the glue is identical between components — so it gets copy-pasted, slightly mutated each time, and quietly accrues bugs. ReactUse ships seven focused hooks that hide the glue and give you back the API surface you actually wanted.

This post walks through all seven: what each observes, when to pick which, and what you would have written by hand if you had not picked them up.

1. useIntersectionObserver — “Is this element on screen?”

IntersectionObserver is the workhorse of modern lazy-loading. It reports when a target element crosses a threshold relative to the viewport (or a scroll container), without any of the scroll listener thrashing that the same job used to require. Lazy images, infinite scroll triggers, “viewed” tracking for analytics, fade-in on enter — all built on top of it.

The Manual Way

import { useEffect, useRef, useState } from "react";

function ManualOnScreen({ children }: { children: React.ReactNode }) {
  const ref = useRef<HTMLDivElement>(null);
  const [seen, setSeen] = useState(false);

  useEffect(() => {
    const el = ref.current;
    if (!el) return;
    const io = new IntersectionObserver(
      ([entry]) => {
        if (entry.isIntersecting) setSeen(true);
      },
      { rootMargin: "0px", threshold: 0.1 },
    );
    io.observe(el);
    return () => io.disconnect();
  }, []);

  return <div ref={ref}>{seen ? children : null}</div>;
}

This works, and the moment you need a second lazy section you copy it. By component number five you have five subtly different observers, three of them with the wrong threshold, one of them leaking because somebody refactored the cleanup. The shape is right; the repetition is not.

The ReactUse Way

useIntersectionObserver takes the ref and the options, and returns whether the element is currently intersecting:

import { useRef } from "react";
import { useIntersectionObserver } from "@reactuses/core";

function OnScreen({ children }: { children: React.ReactNode }) {
  const ref = useRef<HTMLDivElement>(null);
  const isVisible = useIntersectionObserver(ref, {
    threshold: 0.1,
  });

  return <div ref={ref}>{isVisible ? children : null}</div>;
}

The hook owns the observer’s lifecycle: it disconnects on unmount, recreates the observer when the options change, and is SSR-safe. Lazy-load an image, fire an analytics event the first time a card enters the viewport, or defer mounting a heavy chart until it scrolls in — same hook, different boolean.

A common pattern is the “load more” trigger for infinite scroll: place a sentinel <div> at the bottom of a list and fire the fetch when it becomes visible. That is essentially the implementation of useInfiniteScroll, which builds on this primitive.

2. useElementVisibility — The Boolean You Usually Want

A surprising amount of the time you do not care about IntersectionObserverEntry at all — you just want a boolean, and you want it for the whole viewport, not a scroll container. useElementVisibility is exactly that.

import { useRef } from "react";
import { useElementVisibility } from "@reactuses/core";

function FadeInOnView({ children }: { children: React.ReactNode }) {
  const ref = useRef<HTMLDivElement>(null);
  const visible = useElementVisibility(ref);

  return (
    <div
      ref={ref}
      className={`fade ${visible ? "fade-in" : ""}`}
    >
      {children}
    </div>
  );
}

Use it for fade-in-on-scroll, “viewed” telemetry, and “pause this video when it scrolls off-screen” patterns. When you need finer control — a custom root, a threshold below 1, multiple thresholds — drop down to useIntersectionObserver.

3. useResizeObserver — The Right Way to Track Size

For about a decade, “track an element’s size in React” meant attaching a window.resize listener and re-reading clientWidth on every event. That misses the most common case — the element resizing because its parent did, or because a sibling collapsed, or because a flex item below it grew. ResizeObserver fires on any size change to the observed element, regardless of cause.

The Manual Way

import { useEffect, useRef, useState } from "react";

function ManualSize() {
  const ref = useRef<HTMLDivElement>(null);
  const [size, setSize] = useState({ width: 0, height: 0 });

  useEffect(() => {
    const el = ref.current;
    if (!el) return;
    const ro = new ResizeObserver((entries) => {
      const cr = entries[0].contentRect;
      setSize({ width: cr.width, height: cr.height });
    });
    ro.observe(el);
    return () => ro.disconnect();
  }, []);

  return (
    <div ref={ref}>
      {size.width.toFixed(0)} × {size.height.toFixed(0)}
    </div>
  );
}

The hidden cost: every entry update calls setState, which schedules a render. Resize a parent quickly and the observed component re-renders 60 times a second. Most of the time you can live with this, but if the state is consumed by an expensive subtree you need to either throttle the updates or push them into a ref instead.

The ReactUse Way

useResizeObserver accepts the ref and a callback that fires on each entry:

import { useRef, useState } from "react";
import { useResizeObserver } from "@reactuses/core";

function ResponsiveCard() {
  const ref = useRef<HTMLDivElement>(null);
  const [variant, setVariant] = useState<"narrow" | "wide">("narrow");

  useResizeObserver(ref, ([entry]) => {
    setVariant(entry.contentRect.width > 600 ? "wide" : "narrow");
  });

  return <div ref={ref} data-variant={variant}>…</div>;
}

This is the container-query pattern in fifteen lines: the card swaps between a narrow and a wide layout based on its own width, not the viewport’s. Place two of them in a flex row and they each pick their own layout independently.

4. useElementSize and useMeasure — Size in Two Flavors

If you only need width and height, the callback form is overkill. ReactUse ships two convenience hooks that wrap ResizeObserver and return state directly.

useElementSize returns { width, height } for the observed element:

import { useRef } from "react";
import { useElementSize } from "@reactuses/core";

function AutoFitGrid({ items }: { items: Item[] }) {
  const ref = useRef<HTMLDivElement>(null);
  const { width } = useElementSize(ref);
  const columns = Math.max(1, Math.floor(width / 240));

  return (
    <div
      ref={ref}
      style={{
        display: "grid",
        gridTemplateColumns: `repeat(${columns}, 1fr)`,
        gap: 16,
      }}
    >
      {items.map((it) => <Card key={it.id} item={it} />)}
    </div>
  );
}

The grid recomputes its column count whenever the container resizes — no media queries, no viewport guess, no JavaScript-controlled CSS variables.

useMeasure returns the full ResizeObserverEntry.contentRect (width, height, top, left, etc.) plus a ref to attach. Use it when you want size and the local coordinates in one call:

import { useMeasure } from "@reactuses/core";

function TooltipAnchor() {
  const [ref, rect] = useMeasure<HTMLButtonElement>();
  return (
    <>
      <button ref={ref}>Hover me</button>
      <Tooltip x={rect.left + rect.width / 2} y={rect.top} />
    </>
  );
}

The split between useElementSize and useMeasure is mostly ergonomic — pick whichever returns the shape your component already wants to consume.

5. useElementBounding — Position Plus Size, Synced

useElementBounding is the reactive equivalent of calling el.getBoundingClientRect() on every scroll and resize. It returns top, right, bottom, left, width, height, x, y — the full rect — and re-fires when the element moves or resizes for any reason.

import { useRef } from "react";
import { useElementBounding } from "@reactuses/core";

function StickyShadow() {
  const ref = useRef<HTMLDivElement>(null);
  const { top } = useElementBounding(ref);
  const stuck = top <= 0;

  return (
    <header
      ref={ref}
      className={stuck ? "header header--stuck" : "header"}
    >
      …
    </header>
  );
}

When a position: sticky header reaches the top of the viewport, its top becomes 0; the hook picks that up and the header gets a shadow. The same pattern works for floating action buttons that should change appearance once they leave their initial position, or popovers that need to track an anchor through layout changes.

The difference between useElementBounding and useMeasure: bounding is the viewport-relative rect (it changes on scroll), measure is the element’s intrinsic content rect (it does not). Pick bounding when you care about position, measure when you care about size.

6. useMutationObserver — When the DOM Changes Around You

MutationObserver is the heaviest of the four observer APIs, and the one with the narrowest legitimate use case. It fires when attributes, child nodes, or text content change on a target. In a React-first app you almost never need it — React owns the mutations, so React knows them. You reach for useMutationObserver when something outside React is mutating the DOM:

  • A third-party widget (Stripe Elements, an embedded video player, a chat bubble) injects content into a slot.
  • A contentEditable element is being edited by the user, and you want to react to text changes without polling.
  • A scripts toggles aria-expanded or data-state on an element you do not control, and you want to mirror it into React state.
import { useRef, useState } from "react";
import { useMutationObserver } from "@reactuses/core";

function ThirdPartyMount({ slot }: { slot: string }) {
  const ref = useRef<HTMLDivElement>(null);
  const [ready, setReady] = useState(false);

  useMutationObserver(
    ref,
    (mutations) => {
      const injected = mutations.some(
        (m) => m.type === "childList" && m.addedNodes.length > 0,
      );
      if (injected) setReady(true);
    },
    { childList: true, subtree: true },
  );

  return (
    <div ref={ref} data-third-party={slot}>
      {!ready && <Skeleton />}
    </div>
  );
}

The skeleton renders until the third-party script drops its content into the slot, then disappears. Without MutationObserver, your options were setInterval polling or MutationObserver plus a hand-rolled lifecycle — the former is wasteful, the latter is exactly what this hook saves you from.

A common pitfall: MutationObserver is fast but not free, and an unscoped subtree watcher on a busy element can fire dozens of times per second. Always pass the narrowest options object you can — if you only care about childList, do not pass attributes: true.

7. Choosing Between Them

The seven hooks overlap, and the overlap is intentional — different shapes work for different consumers. The cheat sheet:

You want…Hook
A boolean for “is this on screen?”useElementVisibility
Visibility with a custom root or thresholduseIntersectionObserver
Width and height as stateuseElementSize
The full content rect as stateuseMeasure
The viewport-relative rect (changes on scroll)useElementBounding
A callback on every resize entryuseResizeObserver
To react to DOM changes from outside ReactuseMutationObserver

A useful mental model: visibility hooks tell you where an element is relative to the user; size and bounding hooks tell you how big it is and where in the layout; mutation tells you what changed inside it.

A Worked Example: A Self-Sizing Lazy Card

Putting four of them together — a card that lazy-mounts its expensive chart only after it scrolls in, picks a layout based on its own width, and positions a tooltip relative to itself:

import { useRef, useState } from "react";
import {
  useElementVisibility,
  useElementSize,
  useElementBounding,
} from "@reactuses/core";

function LazyChartCard({ data }: { data: ChartData }) {
  const cardRef = useRef<HTMLDivElement>(null);
  const visible = useElementVisibility(cardRef);
  const { width } = useElementSize(cardRef);
  const { top, left } = useElementBounding(cardRef);

  const [hovered, setHovered] = useState(false);
  const layout = width > 600 ? "horizontal" : "vertical";

  return (
    <>
      <div
        ref={cardRef}
        data-layout={layout}
        className="card"
        onMouseEnter={() => setHovered(true)}
        onMouseLeave={() => setHovered(false)}
      >
        {visible ? <Chart data={data} /> : <Skeleton />}
      </div>
      {hovered && (
        <Tooltip
          x={left + width / 2}
          y={top - 8}
          text={`${data.label}: ${data.value}`}
        />
      )}
    </>
  );
}

The chart only constructs once it enters the viewport. The card flips its layout based on its own width, not the page’s. The tooltip floats above the card by tracking its bounding rect, so it stays anchored through scrolls and layout shifts. Three hooks, twenty lines of glue, zero useEffect blocks, zero addEventListener/removeEventListener pairs.

Performance Notes

Observers are not free, but the cost is concentrated and well-understood:

  • One observer per element is fine; one per row of a thousand-row list is not. For list virtualization, observe the scroll container once and resolve which row is visible inside the callback. The browser will sometimes coalesce many IntersectionObserver targets, but a long list with per-row observers still hurts.
  • useResizeObserver callbacks run on a separate task. Reading layout (getBoundingClientRect, offsetWidth) inside the callback is cheap; writing layout is also fine, with the catch that the write can trigger another resize entry. Guard against feedback loops by debouncing or by writing into a requestAnimationFrame.
  • MutationObserver is the most expensive of the four, especially with subtree: true. Scope it as narrowly as possible. If you find yourself watching a large subtree, consider whether a single explicit “third-party-ready” event from the embedded code would be cheaper.

Summary

The observer APIs are the bridge between “what React knows” and “what the DOM actually does.” Wired with raw useEffect they accumulate a lot of glue and a long tail of subtle bugs. Wired with these seven hooks they become one-liners that compose freely.

Browse the rest at reactuse.com — and if you replace a chunky useEffect-plus-observer dance with one of these, that is a good day at the keyboard.