DEV Community: reactuse.com

From Next.js to Pareto: What Changes and What Stays the Same

reactuse.com — Fri, 03 Apr 2026 01:51:49 +0000

You know Next.js. You know file-based routing, layouts, loaders, SSR. You probably also know the pain: server components vs client components, the "use client" dance, mysterious hydration errors, and a 233 KB client bundle before you write a single line of app code.

Pareto gives you the same SSR patterns — but without the complexity. Standard React components, Vite instead of Webpack/Turbopack, and a 62 KB client bundle. This post walks through exactly what changes when you move from Next.js to Pareto, and what stays familiar.

The mental model shift

Next.js (App Router): Every component is a server component by default. Want useState? Add "use client". Data fetching happens via async server components or route-level generateMetadata. You're constantly thinking about the server/client boundary.

Pareto: Every component is a regular React component that runs on both server and client. Data fetching happens in loader.ts files — a pattern borrowed from Remix. There's no "use client" directive because there's no server component / client component split.

Next.js mental model:  "Is this a server component or a client component?"
Pareto mental model:   "Is this data or UI?"

Routing: almost identical

If you know Next.js App Router conventions, Pareto's routing is immediately familiar:

Next.js	Pareto	Purpose
`page.tsx`	`page.tsx`	Route component
`layout.tsx`	`layout.tsx`	Wrapping layout
—	`loader.ts`	Server-side data
`loading.tsx`	Suspense + `<Await>`	Loading states
`error.tsx`	`ParetoErrorBoundary`	Error handling
`not-found.tsx`	`not-found.tsx`	404 page
`route.ts`	`route.ts`	API endpoint
`head.tsx` / `generateMetadata`	`head.tsx`	Meta tags

The biggest difference: Pareto uses a dedicated loader.ts file for data fetching instead of making the page component async.

Data fetching: loaders replace async components

Next.js (App Router):

// app/dashboard/page.tsx (server component)
export default async function Dashboard() {
  const stats = await db.getStats()
  return <h1>{stats.total} users</h1>
}

Pareto:

// app/dashboard/loader.ts
import type { LoaderContext } from '@paretojs/core'

export function loader(ctx: LoaderContext) {
  return { stats: db.getStats() }
}

// app/dashboard/page.tsx
import { useLoaderData } from '@paretojs/core'

export default function Dashboard() {
  const { stats } = useLoaderData<{ stats: { total: number } }>()
  return <h1>{stats.total} users</h1>
}

Two files instead of one, but the separation is intentional: data fetching is explicit, testable, and never mixed with rendering logic. The component is standard React — no async, no await, no server-only constraints.

Streaming: `defer()` instead of Suspense gymnastics

Next.js: Streaming requires splitting your page into server and client components, coordinating loading.tsx boundaries, and understanding which components block the initial render.

Pareto: Call defer() in your loader. Wrap slow data in <Await>. Done.

// app/dashboard/loader.ts
import { defer } from '@paretojs/core'

export async function loader() {
  const userCount = await getUserCount()  // resolve fast data first

  return defer({
    userCount,                             // resolved — sent immediately
    activityFeed: getActivityFeed(),       // slow — streamed later
    analytics: getAnalytics(),             // slower — streamed even later
  })
}

// app/dashboard/page.tsx
import { useLoaderData, Await } from '@paretojs/core'

export default function Dashboard() {
  const { userCount, activityFeed, analytics } = useLoaderData()

  return (
    <div>
      <h1>{userCount} users</h1>

      <Await resolve={activityFeed} fallback={<Skeleton />}>
        {(feed) => <ActivityList items={feed} />}
      </Await>

      <Await resolve={analytics} fallback={<ChartSkeleton />}>
        {(data) => <AnalyticsChart data={data} />}
      </Await>
    </div>
  )
}

Each <Await> creates its own Suspense boundary. Fast data renders immediately. Slow data streams in progressively. Same behavior on initial SSR load and client-side navigation (via NDJSON streaming in Pareto 4.0).

Head management: React components, not config objects

Next.js:

export async function generateMetadata({ params }) {
  const post = await getPost(params.id)
  return { title: post.title, description: post.excerpt }
}

Pareto:

// app/blog/[id]/head.tsx
export default function Head({ loaderData }: { loaderData: { post: Post } }) {
  return (
    <>
      <title>{loaderData.post.title}</title>
      <meta name="description" content={loaderData.post.excerpt} />
      <meta property="og:title" content={loaderData.post.title} />
    </>
  )
}

It's a React component. You can use conditional logic, compose from shared components, or render anything valid in <head>. Head components merge from root layout to page — the deepest route wins for duplicate tags.

State management: built-in, not bolted on

Next.js has no opinion on state management. You bring your own Redux, Zustand, Jotai, etc., and figure out SSR hydration yourself.

Pareto ships defineStore() with Immer:

import { defineStore } from '@paretojs/core/store'

const { useStore, getState, setState } = defineStore((set) => ({
  items: [] as CartItem[],
  total: 0,
  addItem: (item: CartItem) => set((d) => {
    d.items.push(item)
    d.total += item.price
  }),
}))

SSR hydration is automatic. State defined on the server is serialized and restored on the client without any manual dehydrate / rehydrate boilerplate.

Configuration: one file

Next.js: next.config.js for framework config + separate Webpack/Turbopack customization + potential middleware.ts + environment variable conventions.

Pareto: One pareto.config.ts:

import type { ParetoConfig } from '@paretojs/core'

const config: ParetoConfig = {
  configureVite(config) {
    // Standard Vite config — your plugins just work
    return config
  },
  configureServer(app) {
    // Standard Express app — add any middleware
    app.use(cors())
  },
}

export default config

No framework magic. It's Vite and Express under the hood, both fully accessible.

The performance difference

We run automated benchmarks in CI comparing Pareto against Next.js on identical hardware:

Data loading throughput: Pareto 2,733 req/s vs Next.js 293 req/s (9.3x)
Streaming SSR capacity: Pareto 2,022 req/s vs Next.js 310 req/s (6.5x)
Client JS bundle: 62 KB vs 233 KB (73% smaller)

In infrastructure terms: a page serving 2,000 req/s needs 1 Pareto server vs 6 Next.js instances. Full benchmark details: paretojs.tech/blog/benchmarks

What you give up

Transparency matters. Here's what Pareto doesn't have:

Server components — No RSC, no "use client". This is by design: the loader pattern is simpler and covers 95% of use cases.
Image optimization — No <Image> component with automatic resizing. Use standard <img> with a CDN.
ISR / Static generation — Pareto is SSR-only. No generateStaticParams(), no build-time rendering. If you need static pages, pair with a static site generator.
Middleware — No edge middleware concept. Use Express middleware in configureServer() instead.
Vercel integration — No one-click deploy. You deploy a standard Node.js server.
Ecosystem size — Smaller community, fewer examples. You're early.

If you're building a content-heavy marketing site with ISR, Next.js is still the right call. If you're building a data-driven app where performance and simplicity matter, Pareto is worth the switch.

Migration checklist

npx create-pareto@latest my-app — scaffold a new project
Move your routes from app/ — file structure is nearly identical
Extract async server components into loader.ts + standard component
Replace "use client" directives — they're not needed, just delete them
Move generateMetadata to head.tsx components
Replace loading.tsx with defer() + <Await> for streaming
Replace next/link with Link from @paretojs/core
Move Webpack config to configureVite() in pareto.config.ts
Deploy as a standard Node.js server

npx create-pareto@latest my-app
cd my-app && npm install && npm run dev

Pareto is a lightweight, streaming-first React SSR framework built on Vite. Documentation

Building Real-Time Features in React Without WebSocket Libraries

reactuse.com — Thu, 02 Apr 2026 02:57:15 +0000

Building Real-Time Features in React Without WebSocket Libraries

When developers hear "real-time," they reach for WebSocket libraries. Socket.IO, Pusher, Ably -- the ecosystem is full of them. But many real-time features do not need bidirectional communication. A stock ticker, a notification feed, a deployment log, a live sports score -- all of these are one-directional streams from server to client. For these use cases, the browser already has a built-in protocol that is simpler, lighter, and automatically reconnects: Server-Sent Events (SSE).

Combine SSE with the Network Information API for connection awareness, and the BroadcastChannel API for cross-tab coordination, and you have a complete real-time toolkit -- zero WebSocket libraries required. In this article, we will build each piece from scratch first, see where the manual approach breaks down, then replace it with hooks from ReactUse that handle all the edge cases in a few lines.

1. Server-Sent Events with useEventSource

What Are Server-Sent Events?

Server-Sent Events (SSE) is a standard that lets a server push updates to the browser over a plain HTTP connection. Unlike WebSockets, SSE is unidirectional -- the server sends, the client receives. The browser's native EventSource API handles connection management, automatic reconnection, and event parsing out of the box.

// A basic SSE endpoint (server side, for reference)
// GET /api/notifications
// Content-Type: text/event-stream
//
// data: {"message": "New deployment started"}
// id: 1
//
// data: {"message": "Deployment complete"}
// id: 2

The Manual Way

Let us connect to an SSE endpoint in React without any libraries.

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

function useManualEventSource(url: string) {
  const [data, setData] = useState<string | null>(null);
  const [status, setStatus] = useState<
    "CONNECTING" | "CONNECTED" | "DISCONNECTED"
  >("DISCONNECTED");
  const [error, setError] = useState<Event | null>(null);
  const esRef = useRef<EventSource | null>(null);
  const retriesRef = useRef(0);

  useEffect(() => {
    const connect = () => {
      setStatus("CONNECTING");
      const es = new EventSource(url);
      esRef.current = es;

      es.onopen = () => {
        setStatus("CONNECTED");
        setError(null);
        retriesRef.current = 0;
      };

      es.onmessage = (event) => {
        setData(event.data);
      };

      es.onerror = (err) => {
        setError(err);
        setStatus("DISCONNECTED");
        es.close();
        esRef.current = null;

        // Manual reconnection logic
        retriesRef.current += 1;
        if (retriesRef.current < 5) {
          setTimeout(connect, 1000 * retriesRef.current);
        }
      };
    };

    connect();

    return () => {
      esRef.current?.close();
      esRef.current = null;
    };
  }, [url]);

  return { data, status, error };
}

That is about 45 lines, and it already has problems:

Named events are not handled. SSE supports custom event types (e.g., event: deploy-status), but onmessage only catches unnamed messages. Supporting named events requires calling addEventListener for each event type and cleaning up each listener on unmount.
Reconnection is naive. The code retries up to 5 times with linear backoff, but there is no way to configure the limit, the delay, or a failure callback.
No explicit close/reopen. If the user navigates away and comes back, or if you want to pause the stream while the tab is hidden, you need more state tracking.
SSR will crash. EventSource does not exist on the server.

With useEventSource

The useEventSource hook from ReactUse handles all of this.

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

function DeploymentLog() {
  const { data, status, error, event, lastEventId, close, open } =
    useEventSource("/api/deployments/stream", ["deploy-start", "deploy-end"], {
      autoReconnect: {
        retries: 5,
        delay: 2000,
        onFailed: () => console.error("SSE connection permanently failed"),
      },
    });

  return (
    <div>
      <div>
        Status: {status}
        {status === "DISCONNECTED" && (
          <button onClick={open}>Reconnect</button>
        )}
        {status === "CONNECTED" && (
          <button onClick={close}>Disconnect</button>
        )}
      </div>

      {error && <div className="error">Connection error occurred</div>}

      <div className="log-entry">
        <span className="event-type">{event}</span>
        <span className="event-id">#{lastEventId}</span>
        <pre>{data}</pre>
      </div>
    </div>
  );
}

Look at what you get for free:

Named event support. Pass an array of event names as the second argument, and the hook listens to each one. The event return value tells you which event type fired.
Configurable auto-reconnect. Set the number of retries, the delay between attempts, and a callback when all retries are exhausted.
Explicit close and reopen. Call close() to disconnect, open() to reconnect -- useful for pausing streams in background tabs.
SSR safe. The hook guards against EventSource being undefined on the server.
Last event ID tracking. The lastEventId value lets you resume from where you left off if the server supports it.

A Practical Example: Live Notification Feed

import { useEventSource } from "@reactuses/core";
import { useState, useEffect } from "react";

interface Notification {
  id: string;
  title: string;
  body: string;
  severity: "info" | "warning" | "error";
}

function NotificationFeed() {
  const [notifications, setNotifications] = useState<Notification[]>([]);
  const { data, status, event } = useEventSource(
    "/api/notifications/stream",
    ["info", "warning", "error"],
    {
      autoReconnect: {
        retries: -1, // retry forever
        delay: 3000,
      },
    }
  );

  useEffect(() => {
    if (data) {
      try {
        const notification: Notification = {
          ...JSON.parse(data),
          severity: event as Notification["severity"],
        };
        setNotifications((prev) => [notification, ...prev].slice(0, 50));
      } catch {
        // malformed data, ignore
      }
    }
  }, [data, event]);

  return (
    <div>
      <h2>
        Live Notifications
        <span className={`status-dot status-${status.toLowerCase()}`} />
      </h2>
      {notifications.map((n) => (
        <div key={n.id} className={`notification notification-${n.severity}`}>
          <strong>{n.title}</strong>
          <p>{n.body}</p>
        </div>
      ))}
    </div>
  );
}

The hook handles the SSE lifecycle. Your component only deals with parsing data and rendering UI.

2. Authenticated SSE Streams with useFetchEventSource

The Problem with Native EventSource

The native EventSource API has a major limitation: you cannot set custom headers. That means no Authorization: Bearer <token>, no custom X-Request-ID, and no POST requests with a body. If your SSE endpoint requires authentication, EventSource is not enough.

The common workaround is to pass the token as a query parameter (/api/stream?token=abc), but that leaks credentials into server logs, browser history, and referrer headers. It is a security anti-pattern.

The Manual Way

To send headers with an SSE-like connection, you need to use fetch with a readable stream -- and handle chunked parsing, reconnection, and abort signals yourself.

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

function useManualFetchSSE(url: string, token: string) {
  const [data, setData] = useState<string | null>(null);
  const [status, setStatus] = useState<string>("DISCONNECTED");
  const abortRef = useRef<AbortController | null>(null);

  useEffect(() => {
    const controller = new AbortController();
    abortRef.current = controller;
    setStatus("CONNECTING");

    const connect = async () => {
      try {
        const response = await fetch(url, {
          headers: {
            Authorization: `Bearer ${token}`,
            Accept: "text/event-stream",
          },
          signal: controller.signal,
        });

        if (!response.ok) throw new Error(`HTTP ${response.status}`);
        if (!response.body) throw new Error("No response body");

        setStatus("CONNECTED");
        const reader = response.body.getReader();
        const decoder = new TextDecoder();
        let buffer = "";

        while (true) {
          const { done, value } = await reader.read();
          if (done) break;

          buffer += decoder.decode(value, { stream: true });
          const lines = buffer.split("\n\n");
          buffer = lines.pop() || "";

          for (const chunk of lines) {
            const dataLine = chunk
              .split("\n")
              .find((l) => l.startsWith("data: "));
            if (dataLine) {
              setData(dataLine.slice(6));
            }
          }
        }
      } catch (err) {
        if (!controller.signal.aborted) {
          setStatus("DISCONNECTED");
          // reconnection logic here...
        }
      }
    };

    connect();
    return () => controller.abort();
  }, [url, token]);

  return { data, status };
}

This is already 55+ lines, and it is incomplete. It does not handle named events, event IDs, reconnection with backoff, or POST requests. Parsing the SSE text protocol by hand is error-prone.

With useFetchEventSource

The useFetchEventSource hook wraps the @microsoft/fetch-event-source library in a React-friendly API. It supports custom headers, POST requests with bodies, and all the reconnection logic you need.

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

function AuthenticatedStream() {
  const { data, status, event, error, close, open } = useFetchEventSource(
    "/api/private/stream",
    {
      method: "POST",
      headers: {
        Authorization: `Bearer ${getAccessToken()}`,
        "X-Request-ID": crypto.randomUUID(),
      },
      body: JSON.stringify({
        channels: ["deployments", "alerts"],
      }),
      autoReconnect: {
        retries: 10,
        delay: 2000,
        onFailed: () => {
          // Token might be expired -- redirect to login
          window.location.href = "/login";
        },
      },
      onOpen: () => console.log("Stream connected"),
      onError: (err) => {
        console.error("Stream error:", err);
        return 5000; // retry after 5 seconds
      },
    }
  );

  return (
    <div>
      <div>Connection: {status}</div>
      {error && <div className="error">{error.message}</div>}
      <pre>{data}</pre>
    </div>
  );
}

Key differences from useEventSource:

Feature	useEventSource	useFetchEventSource
Custom headers	No	Yes
POST requests	No	Yes
Request body	No	Yes
Based on	Native `EventSource`	`fetch` API
Auto-reconnect	Yes	Yes
Named events	Yes (via array)	Yes (via `event` field)

Use useEventSource when your endpoint is public or uses cookie-based auth. Use useFetchEventSource when you need token-based auth, custom headers, or POST requests.

A Practical Example: AI Chat Streaming

SSE is the standard protocol for streaming AI responses (OpenAI, Anthropic, and others all use it). Here is how to build a streaming chat UI with authentication.

import { useFetchEventSource } from "@reactuses/core";
import { useState, useEffect, useCallback } from "react";

function AIChatStream() {
  const [messages, setMessages] = useState<
    Array<{ role: string; content: string }>
  >([]);
  const [input, setInput] = useState("");
  const [streamedResponse, setStreamedResponse] = useState("");

  const { data, status, open, close } = useFetchEventSource(
    "/api/chat/completions",
    {
      method: "POST",
      headers: {
        Authorization: `Bearer ${getApiKey()}`,
      },
      body: JSON.stringify({
        messages,
        stream: true,
      }),
      immediate: false, // don't connect on mount
      onOpen: () => setStreamedResponse(""),
    }
  );

  // Accumulate streamed tokens
  useEffect(() => {
    if (data) {
      try {
        const parsed = JSON.parse(data);
        const token = parsed.choices?.[0]?.delta?.content;
        if (token) {
          setStreamedResponse((prev) => prev + token);
        }
      } catch {
        // ignore [DONE] or malformed chunks
      }
    }
  }, [data]);

  const sendMessage = useCallback(() => {
    if (!input.trim()) return;
    setMessages((prev) => [...prev, { role: "user", content: input }]);
    setInput("");
    open(); // start the SSE stream
  }, [input, open]);

  return (
    <div className="chat">
      {messages.map((msg, i) => (
        <div key={i} className={`message message-${msg.role}`}>
          {msg.content}
        </div>
      ))}
      {streamedResponse && (
        <div className="message message-assistant">{streamedResponse}</div>
      )}
      <div className="input-row">
        <input
          value={input}
          onChange={(e) => setInput(e.target.value)}
          onKeyDown={(e) => e.key === "Enter" && sendMessage()}
          placeholder="Type a message..."
        />
        <button onClick={sendMessage} disabled={status === "CONNECTING"}>
          Send
        </button>
      </div>
    </div>
  );
}

The immediate: false option is critical here -- we do not want the connection to open on mount. We call open() explicitly when the user sends a message.

3. Network Status Detection with useNetwork and useOnline

Real-time features are useless if the user is offline. Worse, they fail silently -- the SSE connection drops, fetch requests hang, and the UI shows stale data without any indication that something is wrong. Good real-time UIs are network-aware.

The Manual Way

import { useState, useEffect } from "react";

function useManualNetworkStatus() {
  const [isOnline, setIsOnline] = useState(
    typeof navigator !== "undefined" ? navigator.onLine : true
  );
  const [connectionType, setConnectionType] = useState<string | undefined>();

  useEffect(() => {
    const handleOnline = () => setIsOnline(true);
    const handleOffline = () => setIsOnline(false);

    window.addEventListener("online", handleOnline);
    window.addEventListener("offline", handleOffline);

    // Network Information API (not available in all browsers)
    const conn = (navigator as any).connection;
    if (conn) {
      const handleChange = () => {
        setConnectionType(conn.effectiveType);
      };
      conn.addEventListener("change", handleChange);
      handleChange();

      return () => {
        window.removeEventListener("online", handleOnline);
        window.removeEventListener("offline", handleOffline);
        conn.removeEventListener("change", handleChange);
      };
    }

    return () => {
      window.removeEventListener("online", handleOnline);
      window.removeEventListener("offline", handleOffline);
    };
  }, []);

  return { isOnline, connectionType };
}

That is around 35 lines for just two pieces of information, and it does not track downlink speed, round-trip time, data saver mode, or the timestamp of the last status change. The Network Information API also uses vendor-prefixed properties (mozConnection, webkitConnection) that this code does not handle.

With useNetwork

The useNetwork hook returns the full picture.

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

function NetworkDebugPanel() {
  const {
    online,
    previous,
    since,
    downlink,
    effectiveType,
    rtt,
    saveData,
    type,
  } = useNetwork();

  return (
    <div className="network-panel">
      <div>
        Status: {online ? "Online" : "Offline"}
        {previous !== undefined && previous !== online && (
          <span>
            {" "}
            (was {previous ? "online" : "offline"}, changed{" "}
            {since?.toLocaleTimeString()})
          </span>
        )}
      </div>
      <div>Connection: {type ?? "unknown"}</div>
      <div>Effective type: {effectiveType ?? "unknown"}</div>
      <div>Downlink: {downlink ? `${downlink} Mbps` : "unknown"}</div>
      <div>RTT: {rtt ? `${rtt}ms` : "unknown"}</div>
      <div>Data saver: {saveData ? "enabled" : "disabled"}</div>
    </div>
  );
}

The hook handles all the vendor prefixes, event listeners, and SSR safety. The previous and since fields are especially useful -- they let you show "You went offline 30 seconds ago" instead of just "Offline."

With useOnline

If you only need the boolean, useOnline is even simpler. It is a thin wrapper around useNetwork that returns just the online value.

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

function OfflineBanner() {
  const isOnline = useOnline();

  if (isOnline) return null;

  return (
    <div className="offline-banner">
      You are offline. Real-time updates are paused.
    </div>
  );
}

A Practical Example: Adaptive Quality Streaming

The network information from useNetwork lets you adapt your application's behavior to the user's connection quality.

import { useNetwork } from "@reactuses/core";
import { useMemo } from "react";

function useAdaptivePolling(baseInterval: number) {
  const { online, effectiveType, saveData } = useNetwork();

  const interval = useMemo(() => {
    if (!online) return null; // stop polling when offline
    if (saveData) return baseInterval * 4; // respect data saver
    switch (effectiveType) {
      case "slow-2g":
      case "2g":
        return baseInterval * 3;
      case "3g":
        return baseInterval * 2;
      case "4g":
      default:
        return baseInterval;
    }
  }, [online, effectiveType, saveData, baseInterval]);

  return interval;
}

function LiveScoreboard() {
  const pollingInterval = useAdaptivePolling(5000);
  const { online, effectiveType } = useNetwork();

  return (
    <div>
      {!online && (
        <div className="banner">Offline -- showing cached scores</div>
      )}
      {effectiveType === "slow-2g" && (
        <div className="banner">Slow connection -- updates reduced</div>
      )}
      {/* Scoreboard content using pollingInterval */}
    </div>
  );
}

On a fast 4G connection, the scoreboard updates every 5 seconds. On a slow 2G connection, it updates every 15 seconds. Offline, it stops entirely and shows cached data. The user gets the best experience their connection can support.

4. Cross-Tab Communication with useBroadcastChannel

Real-time data often needs to be shared across browser tabs. If a user has your dashboard open in three tabs and a new notification arrives via SSE, all three tabs should show it -- but only one tab should maintain the SSE connection. The BroadcastChannel API makes this possible.

The Manual Way

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

function useManualBroadcastChannel<T>(channelName: string) {
  const [data, setData] = useState<T | undefined>();
  const channelRef = useRef<BroadcastChannel | null>(null);

  useEffect(() => {
    if (typeof BroadcastChannel === "undefined") return;

    const channel = new BroadcastChannel(channelName);
    channelRef.current = channel;

    const handleMessage = (event: MessageEvent<T>) => {
      setData(event.data);
    };

    const handleError = (event: MessageEvent) => {
      console.error("BroadcastChannel error:", event);
    };

    channel.addEventListener("message", handleMessage);
    channel.addEventListener("messageerror", handleError);

    return () => {
      channel.removeEventListener("message", handleMessage);
      channel.removeEventListener("messageerror", handleError);
      channel.close();
    };
  }, [channelName]);

  const post = useCallback((message: T) => {
    channelRef.current?.postMessage(message);
  }, []);

  return { data, post };
}

This works for simple cases, but it does not track whether BroadcastChannel is supported, whether the channel is closed, error state, or timestamps for deduplication.

With useBroadcastChannel

The useBroadcastChannel hook provides a complete, type-safe wrapper.

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

interface DashboardMessage {
  type: "NEW_DATA" | "USER_ACTION" | "TAB_CLOSING";
  payload?: unknown;
  sourceTab: string;
}

function DashboardSync() {
  const { data, post, isSupported, isClosed, error } = useBroadcastChannel<
    DashboardMessage,
    DashboardMessage
  >({ name: "dashboard-sync" });

  const broadcast = (type: DashboardMessage["type"], payload?: unknown) => {
    post({
      type,
      payload,
      sourceTab: sessionStorage.getItem("tab-id") || "unknown",
    });
  };

  useEffect(() => {
    if (data?.type === "NEW_DATA") {
      // Update local state with data from another tab
      console.log("Received data from tab:", data.sourceTab, data.payload);
    }
  }, [data]);

  if (!isSupported) {
    return <div>Cross-tab sync not available in this browser.</div>;
  }

  return (
    <div>
      <button onClick={() => broadcast("NEW_DATA", { count: 42 })}>
        Share data with other tabs
      </button>
      {error && <div className="error">Sync error</div>}
      {isClosed && <div className="warning">Channel closed</div>}
    </div>
  );
}

The hook gives you:

isSupported -- check if BroadcastChannel is available before rendering sync-dependent UI.
isClosed -- know when the channel has been closed (by you or by the browser).
error -- handle message serialization errors.
timeStamp -- deduplicate messages when the same data is received multiple times.
Type safety -- generic parameters <D, P> for received data type and posted data type.

5. Putting It All Together: A Real-Time Dashboard

Let us combine all five hooks into a production-style real-time dashboard. This dashboard:

Receives live metrics via SSE (with authentication)
Detects network status and adapts accordingly
Shares data across tabs so only one tab maintains the SSE connection
Shows connection health to the user

import {
  useFetchEventSource,
  useNetwork,
  useOnline,
  useBroadcastChannel,
  useEventSource,
} from "@reactuses/core";
import { useState, useEffect, useCallback, useRef } from "react";

// --- Types ---

interface MetricEvent {
  timestamp: number;
  cpu: number;
  memory: number;
  requests: number;
  errors: number;
}

interface TabMessage {
  type: "METRIC_UPDATE" | "CLAIM_LEADER" | "RELEASE_LEADER" | "HEARTBEAT";
  payload?: MetricEvent;
  tabId: string;
}

// --- Leader Election Hook ---

function useTabLeader(channelName: string) {
  const tabId = useRef(crypto.randomUUID()).current;
  const [isLeader, setIsLeader] = useState(false);
  const { data, post } = useBroadcastChannel<TabMessage, TabMessage>({
    name: channelName,
  });

  useEffect(() => {
    // On mount, claim leadership after a short delay
    const timer = setTimeout(() => {
      post({ type: "CLAIM_LEADER", tabId });
      setIsLeader(true);
    }, Math.random() * 200);

    return () => {
      clearTimeout(timer);
      post({ type: "RELEASE_LEADER", tabId });
    };
  }, [post, tabId]);

  useEffect(() => {
    if (data?.type === "CLAIM_LEADER" && data.tabId !== tabId) {
      if (data.tabId > tabId) {
        setIsLeader(false);
      }
    }
    if (data?.type === "RELEASE_LEADER") {
      // Another tab released -- try to claim
      setTimeout(() => {
        post({ type: "CLAIM_LEADER", tabId });
        setIsLeader(true);
      }, Math.random() * 100);
    }
  }, [data, tabId, post]);

  return { isLeader, tabId };
}

// --- Network-Aware SSE Hook ---

function useMetricsStream(enabled: boolean) {
  const { online, effectiveType } = useNetwork();

  const { data, status, error, close, open } = useFetchEventSource(
    "/api/metrics/stream",
    {
      headers: {
        Authorization: `Bearer ${getAccessToken()}`,
      },
      immediate: false,
      autoReconnect: {
        retries: -1,
        delay: effectiveType === "4g" ? 2000 : 5000,
        onFailed: () => console.error("Metrics stream failed permanently"),
      },
    }
  );

  // Connect/disconnect based on enabled flag and online status
  useEffect(() => {
    if (enabled && online) {
      open();
    } else {
      close();
    }
  }, [enabled, online, open, close]);

  return { data, status, error };
}

// --- Main Dashboard Component ---

function RealtimeDashboard() {
  const [metrics, setMetrics] = useState<MetricEvent[]>([]);
  const isOnline = useOnline();
  const { online, effectiveType, rtt } = useNetwork();

  // Leader election -- only the leader tab opens the SSE connection
  const { isLeader, tabId } = useTabLeader("metrics-leader");

  // SSE stream -- only active if this tab is the leader
  const { data: sseData, status: sseStatus } = useMetricsStream(isLeader);

  // Cross-tab data sharing
  const { data: tabData, post: broadcastToTabs } = useBroadcastChannel<
    TabMessage,
    TabMessage
  >({ name: "metrics-data" });

  // When the leader receives SSE data, broadcast it to other tabs
  useEffect(() => {
    if (isLeader && sseData) {
      try {
        const metric: MetricEvent = JSON.parse(sseData);
        setMetrics((prev) => [...prev, metric].slice(-100));
        broadcastToTabs({
          type: "METRIC_UPDATE",
          payload: metric,
          tabId,
        });
      } catch {
        // malformed data
      }
    }
  }, [isLeader, sseData, broadcastToTabs, tabId]);

  // When a non-leader tab receives broadcast data, update local state
  useEffect(() => {
    if (!isLeader && tabData?.type === "METRIC_UPDATE" && tabData.payload) {
      setMetrics((prev) => [...prev, tabData.payload!].slice(-100));
    }
  }, [isLeader, tabData]);

  const latestMetric = metrics[metrics.length - 1];

  return (
    <div className="dashboard">
      {/* Connection Status Bar */}
      <header className="status-bar">
        <div className="status-indicators">
          <span className={`dot ${isOnline ? "green" : "red"}`} />
          <span>
            {isOnline ? "Online" : "Offline"}
            {effectiveType && ` (${effectiveType})`}
            {rtt && ` -- ${rtt}ms RTT`}
          </span>
        </div>
        <div className="tab-info">
          {isLeader ? "Leader tab (SSE active)" : "Follower tab (via broadcast)"}
          <span className={`dot ${sseStatus === "CONNECTED" ? "green" : "yellow"}`} />
        </div>
      </header>

      {/* Offline Banner */}
      {!isOnline && (
        <div className="offline-banner">
          You are offline. Showing the last {metrics.length} cached metrics.
          Data will resume when your connection is restored.
        </div>
      )}

      {/* Metrics Grid */}
      {latestMetric && (
        <div className="metrics-grid">
          <MetricCard
            label="CPU Usage"
            value={`${latestMetric.cpu.toFixed(1)}%`}
            status={latestMetric.cpu > 80 ? "danger" : "normal"}
          />
          <MetricCard
            label="Memory"
            value={`${latestMetric.memory.toFixed(1)}%`}
            status={latestMetric.memory > 90 ? "danger" : "normal"}
          />
          <MetricCard
            label="Requests/sec"
            value={latestMetric.requests.toLocaleString()}
            status="normal"
          />
          <MetricCard
            label="Errors/sec"
            value={latestMetric.errors.toLocaleString()}
            status={latestMetric.errors > 10 ? "danger" : "normal"}
          />
        </div>
      )}

      {/* Sparkline Chart (last 100 data points) */}
      <div className="chart-section">
        <h3>CPU Over Time</h3>
        <div className="sparkline">
          {metrics.map((m, i) => (
            <div
              key={i}
              className="bar"
              style={{
                height: `${m.cpu}%`,
                backgroundColor: m.cpu > 80 ? "#ef4444" : "#22c55e",
              }}
            />
          ))}
        </div>
      </div>
    </div>
  );
}

function MetricCard({
  label,
  value,
  status,
}: {
  label: string;
  value: string;
  status: "normal" | "danger";
}) {
  return (
    <div className={`metric-card metric-${status}`}>
      <div className="metric-label">{label}</div>
      <div className="metric-value">{value}</div>
    </div>
  );
}

Here is what each hook contributes to this dashboard:

useFetchEventSource -- connects to the authenticated metrics SSE endpoint with automatic reconnection.
useEventSource -- could be used instead if the endpoint does not require auth headers (swap it in with zero API changes to the component).
useNetwork -- provides connection quality data (effectiveType, rtt) for the status bar and adaptive reconnection delays.
useOnline -- drives the offline banner and pauses the SSE connection when the network drops.
useBroadcastChannel -- enables leader election and cross-tab data sharing, so only one tab maintains the SSE connection while all tabs show live data.

The result is a dashboard that:

Uses a single SSE connection across all tabs (saving server resources)
Automatically reconnects with adaptive backoff based on connection quality
Shows real-time network status to the user
Degrades gracefully when offline
Shares data instantly across every open tab

When to Use Which Hook

Scenario	Hook	Why
Public SSE endpoint	`useEventSource`	Simple, native EventSource
SSE with auth headers	`useFetchEventSource`	Custom headers via fetch
SSE with POST body	`useFetchEventSource`	Supports request bodies
Simple online/offline check	`useOnline`	Returns a single boolean
Detailed connection info	`useNetwork`	Downlink, RTT, effective type
Cross-tab messaging	`useBroadcastChannel`	In-memory, no persistence
Cross-tab + persistence	`useBroadcastChannel` + `useLocalStorage`	Best of both

Installation

npm install @reactuses/core

Or with your preferred package manager:

pnpm add @reactuses/core
yarn add @reactuses/core

Related Hooks

useEventSource -- reactive Server-Sent Events with named event support and auto-reconnect
useFetchEventSource -- SSE via fetch, supporting custom headers, POST requests, and authentication
useNetwork -- detailed network status including connection type, downlink speed, and RTT
useOnline -- simple boolean for online/offline detection
useBroadcastChannel -- type-safe cross-tab messaging via the BroadcastChannel API
useDocumentVisibility -- track whether the current tab is visible
useLocalStorage -- persistent state with automatic cross-tab synchronization

ReactUse provides 100+ hooks for React. Explore them all →

We Benchmarked Our SSR Framework Against Next.js — Here's What We Found

reactuse.com — Wed, 01 Apr 2026 04:15:53 +0000

We built Pareto, a lightweight streaming-first React SSR framework on Vite. Claims are cheap — so we built an automated benchmark suite that runs in CI on every PR, comparing Pareto against Next.js, React Router (Remix), and TanStack Start on identical hardware.

What We Tested

Four scenarios covering the most common SSR workloads:

Static SSR — Page with inline data, no async loader. Pure SSR throughput.
Data Loading — Loader with simulated 10ms DB query. SSR + data fetching overhead.
Streaming SSR — defer() + Suspense with 200ms delayed data. Streaming pipeline efficiency.
API / JSON — Pure JSON endpoint. Routing + serialization overhead.

All benchmarks on GitHub Actions (Ubuntu, Node 22, 4 CPUs), using autocannon with 100 connections for 30 seconds.

Throughput: Requests Per Second

Scenario	Pareto	Next.js	React Router	TanStack Start
Static SSR	2,224/s	3,328/s	997/s	2,009/s
Data Loading	2,733/s	293/s	955/s	1,386/s
Streaming SSR	247/s	236/s	247/s	247/s
API / JSON	3,675/s	2,212/s	1,950/s	—

Next.js wins on static SSR. But the moment a loader is involved, Pareto handles 9.3x more requests than Next.js and 2.9x more than React Router.

Load Capacity: Max Sustainable QPS

We ran a ramp-up test from 1 to 1,000 concurrent connections, measuring the max QPS each framework sustains while keeping p99 latency under 500ms.

Scenario	Pareto	Next.js	React Router	TanStack Start
Static SSR	2,281/s	2,203/s	1,098/s	1,515/s
Data Loading	2,735/s	331/s	1,044/s	1,458/s
Streaming SSR	2,022/s	310/s	807/s	960/s
API / JSON	3,556/s	1,419/s	1,912/s	—

Under streaming SSR load, Pareto sustains 2,022 req/s — that's 6.5x Next.js and 2.5x React Router.

What this looks like in practice: Say your product page needs to serve 2,000 req/s at peak. With Pareto, that's a single server. With Next.js at 331/s, you'd need 6 servers behind a load balancer. For streaming SSR dashboards, it's 1 Pareto instance vs 7 Next.js instances.

Latency

Scenario	Pareto p50/p99	Next.js p50/p99	React Router p50/p99
Static SSR	431ms / 1.35s	244ms / 326ms	704ms / 7.16s
Data Loading	350ms / 702ms	1.42s / 7.82s	760ms / 7.41s
API / JSON	266ms / 320ms	283ms / 321ms	486ms / 2.12s

Under 100 concurrent connections, Pareto's data loading p99 is 702ms while Next.js spikes to 7.82s. 99% of users get their page in under 700ms with Pareto. With Next.js, 1 in 100 users waits nearly 8 seconds.

Bundle Size

Framework	Client JS (gzip)	Total (gzip)
Pareto	62 KB	72 KB
Next.js	233 KB	409 KB
React Router	100 KB	102 KB
TanStack Start	101 KB	272 KB

62 KB of client JavaScript — roughly 1/4 of Next.js. On 4G mobile (~5 Mbps), that's 100ms to download vs 370ms. On 3G, it's 330ms vs 1.2 seconds before any rendering begins.

The Cost Difference

Here's a concrete scenario — a SaaS dashboard at 10,000 data-loading req/s peak:

Framework	Servers needed (4 CPU)	Monthly cost (est.)
Pareto	4	~$160
TanStack Start	7	~$280
React Router	10	~$400
Next.js	31	~$1,240

How We Keep Benchmarks Honest

CI automated — runs on every PR touching core code
System tuning — ASLR disabled, CPU governor performance
Median aggregation — eliminates outlier noise, CV% for stability
Sequential isolation — one framework at a time, cooldown between runs
Same hardware — all frameworks on the same GitHub Actions runner

The full suite is open source: github.com/childrentime/pareto/tree/main/benchmarks

npx create-pareto my-app
cd my-app && npm install && npm run dev

Pareto is a lightweight, streaming-first React SSR framework built on Vite. GitHub · Docs

React Scroll Effects Without External Libraries

reactuse.com — Tue, 31 Mar 2026 01:47:13 +0000

React Scroll Effects Without External Libraries

Scroll is the most fundamental user interaction on the web. Progress bars that fill as you read, headers that shrink and stick, modals that lock the page behind them, "scroll to section" buttons -- these effects appear on nearly every modern site. Yet implementing them correctly in React means juggling addEventListener, IntersectionObserver, overflow styles, and a surprising number of edge cases. Most developers either pull in a heavy animation library or spend hours writing brittle imperative code.

This post takes a different path. We will tackle six common scroll scenarios, starting each time with the manual implementation so you understand the mechanics, then replacing it with a purpose-built hook from ReactUse (@reactuses/core). ReactUse is an open-source collection of 100+ React hooks that wrap common browser and element interactions into simple, composable APIs. By the end you will have a toolkit of composable, SSR-safe hooks that handle scroll tracking, scroll locking, smooth scrolling, sticky detection, visibility detection, and intersection observing -- all without a single external animation or scroll library.

1. Tracking Scroll Position

The Manual Way

Tracking how far a user has scrolled seems straightforward until you account for throttling, direction detection, and knowing when the user has reached the edges.

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

function ManualScrollTracker() {
  const containerRef = useRef<HTMLDivElement>(null);
  const [scrollY, setScrollY] = useState(0);
  const [direction, setDirection] = useState<"up" | "down">("down");
  const lastY = useRef(0);

  useEffect(() => {
    const el = containerRef.current;
    if (!el) return;

    const onScroll = () => {
      const y = el.scrollTop;
      setDirection(y > lastY.current ? "down" : "up");
      lastY.current = y;
      setScrollY(y);
    };

    el.addEventListener("scroll", onScroll, { passive: true });
    return () => el.removeEventListener("scroll", onScroll);
  }, []);

  const progress = containerRef.current
    ? scrollY /
      (containerRef.current.scrollHeight - containerRef.current.clientHeight)
    : 0;

  return (
    <div>
      <div
        style={{
          position: "fixed",
          top: 0,
          left: 0,
          height: 4,
          width: `${progress * 100}%`,
          background: "#4f46e5",
          transition: "width 0.1s",
        }}
      />
      <div
        ref={containerRef}
        style={{ height: "100vh", overflow: "auto" }}
      >
        {/* long content */}
      </div>
    </div>
  );
}

This gets the job done for a simple progress bar. But it does not tell you whether the user has reached the bottom, it has no horizontal scroll tracking, and the direction detection is naive (a single-pixel bounce during momentum scroll will flip it). Adding "arriving at edge" thresholds means even more state and math.

With useScroll

useScroll returns the current x and y offsets, scroll direction on both axes, plus boolean isScrolling and arrivedState fields that tell you whether the user has reached the top, bottom, left, or right edge.

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

function ScrollTracker() {
  const containerRef = useRef<HTMLDivElement>(null);

  const [position, direction, arrivedState, isScrolling] = useScroll(
    containerRef,
    { throttle: 50 }
  );

  const el = containerRef.current;
  const progress = el
    ? position.y / (el.scrollHeight - el.clientHeight)
    : 0;

  return (
    <div>
      {/* Progress bar */}
      <div
        style={{
          position: "fixed",
          top: 0,
          left: 0,
          height: 4,
          width: `${Math.min(progress * 100, 100)}%`,
          background: "#4f46e5",
          zIndex: 50,
        }}
      />

      {/* Scroll info overlay */}
      <div
        style={{
          position: "fixed",
          bottom: 16,
          right: 16,
          padding: "8px 16px",
          background: "#1e293b",
          color: "#fff",
          borderRadius: 8,
          fontSize: 14,
          zIndex: 50,
        }}
      >
        <div>Y: {Math.round(position.y)}px</div>
        <div>Direction: {direction.y ?? "none"}</div>
        <div>
          {arrivedState.bottom
            ? "You reached the bottom!"
            : isScrolling
              ? "Scrolling..."
              : "Idle"}
        </div>
      </div>

      <div
        ref={containerRef}
        style={{ height: "100vh", overflow: "auto" }}
      >
        {Array.from({ length: 100 }, (_, i) => (
          <p key={i} style={{ padding: "8px 16px" }}>
            Paragraph {i + 1}
          </p>
        ))}
      </div>
    </div>
  );
}

One hook call replaces all the manual event wiring, direction tracking, and edge detection. The built-in throttle option keeps performance smooth even on rapid-fire scroll events.

2. Locking Scroll for Modals

The Manual Way

When you open a modal, you need to prevent the page behind it from scrolling. The classic approach is to toggle overflow: hidden on the body:

import { useEffect, useState } from "react";

function ManualModal() {
  const [isOpen, setIsOpen] = useState(false);

  useEffect(() => {
    if (isOpen) {
      const scrollY = window.scrollY;
      document.body.style.position = "fixed";
      document.body.style.top = `-${scrollY}px`;
      document.body.style.width = "100%";
      document.body.style.overflow = "hidden";

      return () => {
        document.body.style.position = "";
        document.body.style.top = "";
        document.body.style.width = "";
        document.body.style.overflow = "";
        window.scrollTo(0, scrollY);
      };
    }
  }, [isOpen]);

  return (
    <>
      <button onClick={() => setIsOpen(true)}>Open Modal</button>
      {isOpen && (
        <div
          style={{
            position: "fixed",
            inset: 0,
            background: "rgba(0,0,0,0.5)",
            display: "flex",
            alignItems: "center",
            justifyContent: "center",
            zIndex: 100,
          }}
        >
          <div
            style={{
              background: "#fff",
              padding: 24,
              borderRadius: 12,
              maxWidth: 400,
            }}
          >
            <h2>Modal Title</h2>
            <p>The page behind this modal cannot scroll.</p>
            <button onClick={() => setIsOpen(false)}>Close</button>
          </div>
        </div>
      )}
    </>
  );
}

This works on desktop browsers, but the position: fixed trick causes the page to jump on iOS Safari if you don't carefully save and restore the scroll position. It also does not handle multiple overlapping modals or scrollable containers other than the body.

With useScrollLock

useScrollLock handles all these edge cases. Pass it a ref to the element you want to lock -- typically document.body -- and a boolean to control the lock state.

import { useScrollLock } from "@reactuses/core";
import { useState } from "react";

function Modal() {
  const [isOpen, setIsOpen] = useState(false);

  useScrollLock(
    typeof document !== "undefined" ? document.body : null,
    isOpen
  );

  return (
    <>
      <button onClick={() => setIsOpen(true)}>Open Modal</button>
      {isOpen && (
        <div
          style={{
            position: "fixed",
            inset: 0,
            background: "rgba(0,0,0,0.5)",
            display: "flex",
            alignItems: "center",
            justifyContent: "center",
            zIndex: 100,
          }}
        >
          <div
            style={{
              background: "#fff",
              padding: 24,
              borderRadius: 12,
              maxWidth: 400,
            }}
          >
            <h2>Modal Title</h2>
            <p>Scroll is locked. Try scrolling the page behind.</p>
            <button onClick={() => setIsOpen(false)}>Close</button>
          </div>
        </div>
      )}
    </>
  );
}

One line to lock, automatic unlock on unmount, SSR-safe with the document guard. The scroll position is preserved correctly across all browsers.

3. Smooth Scroll to a Section

The Manual Way

"Scroll to" buttons that jump to a section on the page are common in landing pages. The imperative approach:

import { useRef } from "react";

function ManualScrollTo() {
  const sectionRef = useRef<HTMLDivElement>(null);

  const scrollToSection = () => {
    sectionRef.current?.scrollIntoView({
      behavior: "smooth",
      block: "start",
    });
  };

  return (
    <div>
      <nav style={{ position: "fixed", top: 0, padding: 16, zIndex: 10 }}>
        <button onClick={scrollToSection}>Go to Features</button>
      </nav>

      <div style={{ height: "100vh", background: "#f1f5f9" }}>
        <h1 style={{ paddingTop: 80 }}>Hero Section</h1>
      </div>

      <div ref={sectionRef} style={{ padding: 40 }}>
        <h2>Features</h2>
        <p>Feature content here...</p>
      </div>
    </div>
  );
}

scrollIntoView is fine for basic cases, but it does not let you control the easing curve, the scroll axis, or the offset (important when you have a fixed header that would overlap the target). There is also no way to know when the scrolling animation has completed.

With useScrollIntoView

useScrollIntoView gives you fine-grained control over the scroll animation, including custom duration, easing, axis, offset, and an onComplete callback.

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

function SmoothScrollPage() {
  const targetRef = useRef<HTMLDivElement>(null);

  const { scrollIntoView } = useScrollIntoView(targetRef, {
    duration: 800,
    offset: 80, // account for a fixed header
  });

  return (
    <div>
      <nav
        style={{
          position: "fixed",
          top: 0,
          left: 0,
          right: 0,
          height: 64,
          background: "#1e293b",
          display: "flex",
          alignItems: "center",
          padding: "0 24px",
          zIndex: 50,
        }}
      >
        <button
          onClick={() => scrollIntoView({ alignment: "start" })}
          style={{
            background: "#4f46e5",
            color: "#fff",
            border: "none",
            padding: "8px 16px",
            borderRadius: 6,
            cursor: "pointer",
          }}
        >
          Jump to Pricing
        </button>
      </nav>

      <div style={{ height: "150vh", paddingTop: 80 }}>
        <h1>Hero</h1>
        <p>Scroll down or click the button above.</p>
      </div>

      <div ref={targetRef} style={{ padding: 40, background: "#eef2ff" }}>
        <h2>Pricing</h2>
        <p>Plans and pricing details...</p>
      </div>

      <div style={{ height: "100vh" }} />
    </div>
  );
}

The offset option ensures the section appears below your fixed header rather than being hidden behind it. The smooth animation uses a configurable easing function, and the hook cleans up properly if the component unmounts mid-scroll.

4. Detecting Sticky Headers

The Manual Way

A common pattern is to change a header's appearance once it becomes sticky (adding a shadow, shrinking its height, etc.). Detecting this manually requires an IntersectionObserver with a sentinel element:

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

function ManualStickyHeader() {
  const sentinelRef = useRef<HTMLDivElement>(null);
  const [isStuck, setIsStuck] = useState(false);

  useEffect(() => {
    const sentinel = sentinelRef.current;
    if (!sentinel) return;

    const observer = new IntersectionObserver(
      ([entry]) => {
        setIsStuck(!entry.isIntersecting);
      },
      { threshold: 0 }
    );

    observer.observe(sentinel);
    return () => observer.disconnect();
  }, []);

  return (
    <div>
      {/* Sentinel: when this scrolls out of view, the header is stuck */}
      <div ref={sentinelRef} style={{ height: 1 }} />
      <header
        style={{
          position: "sticky",
          top: 0,
          padding: isStuck ? "8px 24px" : "16px 24px",
          background: isStuck ? "rgba(255,255,255,0.95)" : "#fff",
          boxShadow: isStuck ? "0 2px 8px rgba(0,0,0,0.1)" : "none",
          transition: "all 0.2s",
          zIndex: 40,
        }}
      >
        <h1 style={{ margin: 0, fontSize: isStuck ? 18 : 24 }}>
          My App
        </h1>
      </header>
      <main style={{ padding: 24 }}>
        {Array.from({ length: 80 }, (_, i) => (
          <p key={i}>Content paragraph {i + 1}</p>
        ))}
      </main>
    </div>
  );
}

This sentinel-based approach works but is fragile. You need to position the sentinel correctly, manage the observer lifecycle, and keep the sentinel in sync if the DOM structure changes.

With useSticky

useSticky handles sticky detection cleanly. It returns a boolean that flips to true when the element enters its stuck state.

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

function StickyHeader() {
  const headerRef = useRef<HTMLElement>(null);
  const [isStuck] = useSticky(headerRef);

  return (
    <div>
      <header
        ref={headerRef}
        style={{
          position: "sticky",
          top: 0,
          padding: isStuck ? "8px 24px" : "16px 24px",
          background: isStuck
            ? "rgba(255,255,255,0.95)"
            : "#fff",
          boxShadow: isStuck
            ? "0 2px 8px rgba(0,0,0,0.1)"
            : "none",
          transition: "all 0.2s",
          zIndex: 40,
        }}
      >
        <h1 style={{ margin: 0, fontSize: isStuck ? 18 : 24 }}>
          My App
        </h1>
      </header>
      <main style={{ padding: 24 }}>
        {Array.from({ length: 80 }, (_, i) => (
          <p key={i}>Content paragraph {i + 1}</p>
        ))}
      </main>
    </div>
  );
}

No sentinel elements. No manual observer setup. The hook does the detection internally and gives you a single reactive boolean to drive your styles.

5. Revealing Elements on Scroll

The Manual Way

Fade-in-on-scroll effects are everywhere. The standard approach is to set up an IntersectionObserver for each animated element:

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

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

  useEffect(() => {
    const el = ref.current;
    if (!el) return;

    const observer = new IntersectionObserver(
      ([entry]) => {
        if (entry.isIntersecting) {
          setIsVisible(true);
          observer.unobserve(el); // only animate once
        }
      },
      { threshold: 0.1 }
    );

    observer.observe(el);
    return () => observer.disconnect();
  }, []);

  return (
    <div
      ref={ref}
      style={{
        opacity: isVisible ? 1 : 0,
        transform: isVisible ? "translateY(0)" : "translateY(30px)",
        transition: "opacity 0.6s ease, transform 0.6s ease",
      }}
    >
      {children}
    </div>
  );
}

Copy-pasting this observer logic into every component that needs a reveal animation quickly becomes tedious.

With useElementVisibility

useElementVisibility wraps IntersectionObserver into a single boolean return value. Pair it with a useState flag to create one-time reveal effects:

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

function RevealOnScroll({ children }: { children: React.ReactNode }) {
  const ref = useRef<HTMLDivElement>(null);
  const [visible] = useElementVisibility(ref);
  const [hasRevealed, setHasRevealed] = useState(false);

  useEffect(() => {
    if (visible && !hasRevealed) {
      setHasRevealed(true);
    }
  }, [visible, hasRevealed]);

  return (
    <div
      ref={ref}
      style={{
        opacity: hasRevealed ? 1 : 0,
        transform: hasRevealed ? "translateY(0)" : "translateY(30px)",
        transition: "opacity 0.6s ease, transform 0.6s ease",
      }}
    >
      {children}
    </div>
  );
}

function FeaturePage() {
  return (
    <div style={{ padding: "100vh 24px 24px" }}>
      <RevealOnScroll>
        <h2>Feature One</h2>
        <p>This fades in when scrolled into view.</p>
      </RevealOnScroll>
      <div style={{ height: 200 }} />
      <RevealOnScroll>
        <h2>Feature Two</h2>
        <p>Each section animates independently.</p>
      </RevealOnScroll>
      <div style={{ height: 200 }} />
      <RevealOnScroll>
        <h2>Feature Three</h2>
        <p>And they only animate once -- no flickering on scroll back.</p>
      </RevealOnScroll>
    </div>
  );
}

useElementVisibility gives you the live visibility state. The hasRevealed flag ensures the animation only fires once. For repeating animations, simply drop the flag and drive the style directly from visible.

6. Advanced Intersection: Scroll-Linked Progress

The Manual Way

For more advanced scroll effects -- like a progress indicator that fills as you scroll through a specific section -- you need fine-grained intersection ratios:

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

function ManualSectionProgress() {
  const sectionRef = useRef<HTMLDivElement>(null);
  const [ratio, setRatio] = useState(0);

  useEffect(() => {
    const el = sectionRef.current;
    if (!el) return;

    const thresholds = Array.from({ length: 101 }, (_, i) => i / 100);
    const observer = new IntersectionObserver(
      ([entry]) => setRatio(entry.intersectionRatio),
      { threshold: thresholds }
    );

    observer.observe(el);
    return () => observer.disconnect();
  }, []);

  return (
    <div>
      <div style={{ height: "100vh" }} />
      <div ref={sectionRef} style={{ minHeight: "100vh", padding: 40 }}>
        <div
          style={{
            position: "sticky",
            top: 20,
            width: 200,
            height: 8,
            background: "#e2e8f0",
            borderRadius: 4,
          }}
        >
          <div
            style={{
              height: "100%",
              width: `${ratio * 100}%`,
              background: "#4f46e5",
              borderRadius: 4,
              transition: "width 0.1s",
            }}
          />
        </div>
        <h2>Long Section</h2>
        {Array.from({ length: 20 }, (_, i) => (
          <p key={i}>Paragraph {i + 1} of the section.</p>
        ))}
      </div>
      <div style={{ height: "100vh" }} />
    </div>
  );
}

Building 101 threshold steps and managing the observer manually is verbose. And if you want multiple observers with different root margins or targets, the boilerplate multiplies.

With useIntersectionObserver

useIntersectionObserver exposes the full IntersectionObserver API in a declarative way. You get the IntersectionObserverEntry directly, including intersectionRatio, isIntersecting, and boundingClientRect.

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

function SectionProgress() {
  const sectionRef = useRef<HTMLDivElement>(null);
  const [ratio, setRatio] = useState(0);

  useIntersectionObserver(
    sectionRef,
    ([entry]) => {
      setRatio(entry.intersectionRatio);
    },
    {
      threshold: Array.from({ length: 101 }, (_, i) => i / 100),
    }
  );

  return (
    <div>
      <div style={{ height: "100vh" }} />
      <div ref={sectionRef} style={{ minHeight: "100vh", padding: 40 }}>
        <div
          style={{
            position: "sticky",
            top: 20,
            width: 200,
            height: 8,
            background: "#e2e8f0",
            borderRadius: 4,
          }}
        >
          <div
            style={{
              height: "100%",
              width: `${ratio * 100}%`,
              background: "#4f46e5",
              borderRadius: 4,
              transition: "width 0.1s",
            }}
          />
        </div>
        <h2>Long Section</h2>
        {Array.from({ length: 20 }, (_, i) => (
          <p key={i}>Paragraph {i + 1} of the section.</p>
        ))}
      </div>
      <div style={{ height: "100vh" }} />
    </div>
  );
}

The hook manages the observer lifecycle, reconnects when options change, and cleans up on unmount. You focus on what to do with the intersection data, not how to wire the observer.

Putting It All Together

These hooks compose naturally. Here is a landing page skeleton that combines all six:

import {
  useScroll,
  useScrollLock,
  useScrollIntoView,
} from "@reactuses/core";
import { useSticky, useElementVisibility } from "@reactuses/core";
import { useRef, useState } from "react";

function LandingPage() {
  const scrollContainerRef = useRef<HTMLDivElement>(null);
  const pricingRef = useRef<HTMLDivElement>(null);
  const headerRef = useRef<HTMLElement>(null);

  // Track scroll for progress bar
  const [position] = useScroll(scrollContainerRef);

  // Sticky header detection
  const [isStuck] = useSticky(headerRef);

  // Smooth scroll to pricing
  const { scrollIntoView } = useScrollIntoView(pricingRef, {
    offset: 64,
  });

  // Modal with scroll lock
  const [modalOpen, setModalOpen] = useState(false);
  useScrollLock(
    typeof document !== "undefined" ? document.body : null,
    modalOpen
  );

  // Reveal pricing section
  const [pricingVisible] = useElementVisibility(pricingRef);

  const el = scrollContainerRef.current;
  const progress = el
    ? position.y / (el.scrollHeight - el.clientHeight)
    : 0;

  return (
    <div ref={scrollContainerRef} style={{ height: "100vh", overflow: "auto" }}>
      {/* Progress bar */}
      <div
        style={{
          position: "fixed",
          top: 0,
          left: 0,
          height: 3,
          width: `${Math.min(progress * 100, 100)}%`,
          background: "#4f46e5",
          zIndex: 60,
        }}
      />

      {/* Sticky header */}
      <header
        ref={headerRef}
        style={{
          position: "sticky",
          top: 0,
          padding: isStuck ? "8px 24px" : "16px 24px",
          background: "#fff",
          boxShadow: isStuck ? "0 2px 8px rgba(0,0,0,0.1)" : "none",
          transition: "all 0.2s",
          zIndex: 50,
          display: "flex",
          justifyContent: "space-between",
          alignItems: "center",
        }}
      >
        <span style={{ fontWeight: 700 }}>MyApp</span>
        <div style={{ display: "flex", gap: 12 }}>
          <button onClick={() => scrollIntoView()}>Pricing</button>
          <button onClick={() => setModalOpen(true)}>Contact</button>
        </div>
      </header>

      {/* Hero */}
      <section style={{ height: "100vh", padding: 40 }}>
        <h1>Build amazing products</h1>
      </section>

      {/* Pricing with reveal */}
      <section
        ref={pricingRef}
        style={{
          padding: 40,
          opacity: pricingVisible ? 1 : 0,
          transform: pricingVisible ? "none" : "translateY(30px)",
          transition: "all 0.6s ease",
        }}
      >
        <h2>Pricing</h2>
        <p>Plans and details here.</p>
      </section>

      <div style={{ height: "100vh" }} />

      {/* Modal */}
      {modalOpen && (
        <div
          style={{
            position: "fixed",
            inset: 0,
            background: "rgba(0,0,0,0.5)",
            display: "flex",
            alignItems: "center",
            justifyContent: "center",
            zIndex: 100,
          }}
        >
          <div
            style={{
              background: "#fff",
              padding: 24,
              borderRadius: 12,
              maxWidth: 400,
            }}
          >
            <h2>Contact Us</h2>
            <p>Page scroll is locked while this modal is open.</p>
            <button onClick={() => setModalOpen(false)}>Close</button>
          </div>
        </div>
      )}
    </div>
  );
}

Each hook handles one responsibility. They share refs naturally, do not conflict with each other, and all clean up automatically on unmount.

Installation

npm i @reactuses/core

Related Hooks

useScroll -- Track scroll position, direction, and edge arrival
useScrollLock -- Lock scroll on any element
useScrollIntoView -- Smooth scroll to a target element with offset and easing
useSticky -- Detect when an element enters its sticky state
useElementVisibility -- Check if an element is visible in the viewport
useIntersectionObserver -- Full-featured intersection observation
useEventListener -- Attach event listeners declaratively
useElementSize -- Track element dimensions reactively
useElementBounding -- Get live bounding rectangle of an element

ReactUse provides 100+ hooks for React. Explore them all →

Real-time React: Syncing State Across Browser Tabs

reactuse.com — Fri, 27 Mar 2026 00:49:00 +0000

Real-time React: Syncing State Across Browser Tabs

Your user logs out in one tab. In another tab, they are still browsing authenticated content. They change the theme to dark mode, but the other three tabs stay light. They add an item to their cart, switch tabs, and the cart count shows zero. These are not edge cases — they are everyday realities of multi-tab browsing, and most React applications handle them poorly or not at all.

Browsers do not share React state between tabs by default. Each tab runs its own JavaScript context with its own component tree, its own state, and its own memory. Yet users expect a seamless experience. When something changes in one tab, they expect every tab to reflect that change immediately.

In this article, we will explore the browser APIs that make cross-tab communication possible, look at the manual approach and its pitfalls, and then see how hooks from ReactUse reduce all of that complexity to a few lines of code.

Two Browser APIs for Cross-Tab Communication

Before reaching for any library, it helps to understand what the browser gives us natively.

BroadcastChannel API

The BroadcastChannel API lets you send messages between browsing contexts — tabs, windows, iframes — that share the same origin. You create a channel by name, and any context that opens a channel with the same name can send and receive messages.

// Tab A
const channel = new BroadcastChannel("my-app");
channel.postMessage({ type: "LOGOUT" });

// Tab B
const channel = new BroadcastChannel("my-app");
channel.onmessage = (event) => {
  if (event.data.type === "LOGOUT") {
    // redirect to login
  }
};

BroadcastChannel is fast, supports structured cloning (so you can send objects, arrays, and even ArrayBuffer), and does not touch persistent storage. It is purely in-memory messaging between contexts. The downside is that messages are fire-and-forget — if a tab is not open when the message is sent, it never receives it.

Storage Events

When one tab writes to localStorage, every other tab on the same origin receives a storage event. This gives you cross-tab reactivity for free — but only for string-serializable data, and only through localStorage (not sessionStorage, which is scoped to a single tab).

// Tab A writes
localStorage.setItem("theme", "dark");

// Tab B listens
window.addEventListener("storage", (event) => {
  if (event.key === "theme") {
    console.log("Theme changed to:", event.newValue); // "dark"
  }
});

Storage events have a major advantage: the data persists. If a user opens a new tab after the change was made, the new tab reads the current value from localStorage on mount. You get both reactivity and persistence.

The Manual Approach — And Why It Gets Messy

Let us try to build cross-tab theme syncing from scratch. We need to:

Read the initial value from localStorage.
Parse it (everything in localStorage is a string).
Set up a storage event listener to detect changes from other tabs.
Serialize and write back when the local tab changes the value.
Clean up the listener on unmount.

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

function useCrossTabTheme() {
  const [theme, setThemeState] = useState<"light" | "dark">(() => {
    try {
      const stored = localStorage.getItem("app-theme");
      return stored === "dark" ? "dark" : "light";
    } catch {
      return "light";
    }
  });

  // Listen for changes from other tabs
  useEffect(() => {
    const handler = (event: StorageEvent) => {
      if (event.key === "app-theme" && event.newValue) {
        setThemeState(event.newValue as "light" | "dark");
      }
    };
    window.addEventListener("storage", handler);
    return () => window.removeEventListener("storage", handler);
  }, []);

  // Write to localStorage when local state changes
  const setTheme = useCallback((value: "light" | "dark") => {
    setThemeState(value);
    try {
      localStorage.setItem("app-theme", value);
    } catch {
      // storage full or unavailable
    }
  }, []);

  return [theme, setTheme] as const;
}

That is about 30 lines for a single string value. Now imagine doing this for auth tokens, user preferences, cart state, and notification counts. Each one needs its own serialization logic, error handling, and cleanup. And we have not even touched BroadcastChannel yet — if we want to send structured messages (not just key-value strings), we need a second communication layer with its own setup and teardown.

This is where well-designed hooks eliminate boilerplate without hiding the underlying concepts.

useBroadcastChannel: Type-Safe Messaging Between Tabs

The useBroadcastChannel hook from ReactUse wraps the BroadcastChannel API in a clean, declarative interface. It handles channel creation, message listening, cleanup on unmount, and even SSR safety — all in a single call.

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

function NotificationSync() {
  const { data, post, error } = useBroadcastChannel<{
    type: string;
    payload?: unknown;
  }>("my-app-notifications");

  // Send a message to all other tabs
  const broadcastLogout = () => {
    post({ type: "LOGOUT" });
  };

  // React to messages from other tabs
  useEffect(() => {
    if (data?.type === "LOGOUT") {
      // Clear local auth state and redirect
      authStore.clear();
      window.location.href = "/login";
    }
  }, [data]);

  return <button onClick={broadcastLogout}>Log out everywhere</button>;
}

The generic type parameter gives you full TypeScript safety for the message shape. No manual serialization — BroadcastChannel uses structured cloning natively. No cleanup code — the hook closes the channel when the component unmounts. And the error value lets you handle the rare case where BroadcastChannel is not supported.

useLocalStorage: Automatic Cross-Tab Sync

For state that should persist and sync across tabs, useLocalStorage is the right tool. It works like useState, but the value is backed by localStorage and automatically stays in sync across all tabs via storage events.

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

function ThemeToggle() {
  const [theme, setTheme] = useLocalStorage<"light" | "dark">(
    "app-theme",
    "light"
  );

  return (
    <button onClick={() => setTheme(theme === "light" ? "dark" : "light")}>
      Current: {theme}
    </button>
  );
}

When setTheme is called in one tab, every other tab running this hook with the same key ("app-theme") updates automatically. The hook handles JSON serialization, initial value fallback, SSR guards, and storage event subscription internally. You write one line of hook usage; the hook writes thirty lines of browser API code for you.

Contrast this with useSessionStorage, which provides the same API but scopes the value to the current tab. Session storage does not fire cross-tab events and does not persist after the tab closes. Choose useLocalStorage when you want cross-tab sync; choose useSessionStorage when you want tab-isolated persistence.

Practical Patterns

Pattern 1: Syncing Auth State (Logout Everywhere)

One of the most critical cross-tab scenarios is authentication. When a user logs out in one tab, every other tab must react immediately — otherwise they might continue making authenticated requests that fail silently or expose stale data.

import { useBroadcastChannel, useLocalStorage } from "@reactuses/core";

function useAuth() {
  const [token, setToken] = useLocalStorage<string | null>("auth-token", null);
  const { data, post } = useBroadcastChannel<{ type: "LOGOUT" | "LOGIN" }>(
    "auth-channel"
  );

  // Handle messages from other tabs
  useEffect(() => {
    if (data?.type === "LOGOUT") {
      setToken(null);
      window.location.href = "/login";
    }
  }, [data, setToken]);

  const login = (newToken: string) => {
    setToken(newToken);
    post({ type: "LOGIN" });
  };

  const logout = () => {
    setToken(null);
    post({ type: "LOGOUT" });
    window.location.href = "/login";
  };

  return { token, login, logout, isAuthenticated: token !== null };
}

This uses both hooks together: useLocalStorage persists the token and syncs it across tabs, while useBroadcastChannel sends an immediate imperative signal that triggers the redirect. The token sync via localStorage ensures any tab opened after the logout reads null. The broadcast ensures tabs open during the logout react instantly.

Pattern 2: Syncing Theme Across Tabs

import { useLocalStorage } from "@reactuses/core";
import { useEffect } from "react";

function useThemeSync() {
  const [theme, setTheme] = useLocalStorage<"light" | "dark">(
    "app-theme",
    "light"
  );

  useEffect(() => {
    document.documentElement.setAttribute("data-theme", theme ?? "light");
  }, [theme]);

  return { theme: theme ?? "light", setTheme };
}

Because useLocalStorage already handles cross-tab sync, the useEffect fires in every tab whenever the theme changes — keeping the DOM attribute in sync everywhere.

Pattern 3: Cart State in E-Commerce

Shopping cart data is a classic candidate for cross-tab sync. Users often browse products in multiple tabs and expect the cart to be consistent.

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

interface CartItem {
  id: string;
  name: string;
  quantity: number;
  price: number;
}

function useCart() {
  const [items, setItems] = useLocalStorage<CartItem[]>("cart-items", []);

  const addItem = (item: Omit<CartItem, "quantity">) => {
    setItems((prev) => {
      const current = prev ?? [];
      const existing = current.find((i) => i.id === item.id);
      if (existing) {
        return current.map((i) =>
          i.id === item.id ? { ...i, quantity: i.quantity + 1 } : i
        );
      }
      return [...current, { ...item, quantity: 1 }];
    });
  };

  const removeItem = (id: string) => {
    setItems((prev) => (prev ?? []).filter((i) => i.id !== id));
  };

  const totalItems = (items ?? []).reduce((sum, i) => sum + i.quantity, 0);

  return { items: items ?? [], addItem, removeItem, totalItems };
}

Add an item in Tab A, and the cart badge updates in Tab B instantly. No WebSocket, no polling, no server round-trip.

Pattern 4: Leader Election

Sometimes you want only one tab to perform a task — polling an API, maintaining a WebSocket connection, or running a background sync. The useBroadcastChannel hook provides the messaging layer for a simple leader election protocol.

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

function useLeaderElection(channelName: string) {
  const [isLeader, setIsLeader] = useState(false);
  const idRef = useRef(Math.random().toString(36).slice(2));
  const { data, post } = useBroadcastChannel<{
    type: "CLAIM" | "HEARTBEAT" | "RELEASE";
    id: string;
  }>(channelName);

  useEffect(() => {
    // On mount, try to claim leadership
    post({ type: "CLAIM", id: idRef.current });
    const timer = setTimeout(() => setIsLeader(true), 200);

    return () => {
      clearTimeout(timer);
      post({ type: "RELEASE", id: idRef.current });
    };
  }, [post]);

  useEffect(() => {
    if (data?.type === "CLAIM" && data.id !== idRef.current) {
      // Another tab is claiming — compare IDs to break ties
      if (data.id > idRef.current) {
        setIsLeader(false);
      }
    }
  }, [data]);

  return isLeader;
}

Only the leader tab runs expensive operations. When it closes, it broadcasts a RELEASE message and another tab claims leadership.

Optimizing Background Tabs

Cross-tab sync is only part of the picture. When a tab is in the background, you often want to pause expensive work — polling APIs, running animations, or processing data. Two hooks from ReactUse make this straightforward.

useDocumentVisibility

useDocumentVisibility returns the current visibility state of the document — "visible" or "hidden". Use it to pause work when the tab is not visible.

import { useDocumentVisibility } from "@reactuses/core";
import { useEffect, useState } from "react";

function usePolling(url: string, intervalMs: number) {
  const visibility = useDocumentVisibility();
  const [data, setData] = useState(null);

  useEffect(() => {
    if (visibility === "hidden") return; // stop polling in background

    const fetchData = async () => {
      const res = await fetch(url);
      setData(await res.json());
    };

    fetchData();
    const id = setInterval(fetchData, intervalMs);
    return () => clearInterval(id);
  }, [url, intervalMs, visibility]);

  return data;
}

When the user switches away from the tab, the interval is cleared. When they switch back, a fresh interval starts. No wasted network requests while the tab is hidden.

useWindowFocus

useWindowFocus tracks whether the browser window itself has focus. This is subtler than visibility — a tab can be visible but unfocused (for example, when the user is interacting with DevTools or another window overlapping the browser).

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

function FocusIndicator() {
  const focused = useWindowFocus();

  return (
    <div>
      {focused
        ? "You are viewing this tab"
        : "Welcome back when you return!"}
    </div>
  );
}

Combine useDocumentVisibility and useWindowFocus for fine-grained control: pause non-critical work when the tab is hidden, and throttle less-critical work when the tab is visible but unfocused.

Combining Hooks: A Cross-Tab Notification System

Let us put it all together. Here is a notification system that broadcasts alerts across tabs, persists unread counts in localStorage, and pauses updates when the tab is hidden.

import {
  useBroadcastChannel,
  useLocalStorage,
  useDocumentVisibility,
  useOnline,
} from "@reactuses/core";
import { useEffect, useCallback } from "react";

interface Notification {
  id: string;
  title: string;
  body: string;
  timestamp: number;
}

function useNotificationSync() {
  const [notifications, setNotifications] = useLocalStorage<Notification[]>(
    "app-notifications",
    []
  );
  const [unreadCount, setUnreadCount] = useLocalStorage<number>(
    "unread-count",
    0
  );
  const { data, post } = useBroadcastChannel<{
    type: "NEW_NOTIFICATION" | "MARK_READ" | "CLEAR_ALL";
    notification?: Notification;
  }>("notification-channel");
  const visibility = useDocumentVisibility();
  const isOnline = useOnline();

  // Handle messages from other tabs
  useEffect(() => {
    if (!data) return;

    switch (data.type) {
      case "NEW_NOTIFICATION":
        if (data.notification) {
          setNotifications((prev) => [data.notification!, ...(prev ?? [])]);
          setUnreadCount((prev) => (prev ?? 0) + 1);
        }
        break;
      case "MARK_READ":
        setUnreadCount(0);
        break;
      case "CLEAR_ALL":
        setNotifications([]);
        setUnreadCount(0);
        break;
    }
  }, [data, setNotifications, setUnreadCount]);

  const addNotification = useCallback(
    (title: string, body: string) => {
      const notification: Notification = {
        id: crypto.randomUUID(),
        title,
        body,
        timestamp: Date.now(),
      };
      setNotifications((prev) => [notification, ...(prev ?? [])]);
      setUnreadCount((prev) => (prev ?? 0) + 1);
      post({ type: "NEW_NOTIFICATION", notification });
    },
    [post, setNotifications, setUnreadCount]
  );

  const markAllRead = useCallback(() => {
    setUnreadCount(0);
    post({ type: "MARK_READ" });
  }, [post, setUnreadCount]);

  // Auto-mark as read when tab becomes visible
  useEffect(() => {
    if (visibility === "visible" && (unreadCount ?? 0) > 0) {
      markAllRead();
    }
  }, [visibility, unreadCount, markAllRead]);

  return {
    notifications: notifications ?? [],
    unreadCount: unreadCount ?? 0,
    addNotification,
    markAllRead,
    isOnline,
  };
}

This hook uses four ReactUse hooks working together:

useBroadcastChannel sends real-time signals between tabs when notifications arrive or are read.
useLocalStorage persists the notification list and unread count so new tabs pick up the current state.
useDocumentVisibility automatically marks notifications as read when the user returns to a background tab.
useOnline (via useOnline) exposes the network status so the UI can indicate when the app is offline and notifications may be delayed.

Each hook handles one concern. Composed together, they form a complete system with persistence, real-time sync, visibility awareness, and network status — in under 70 lines.

When to Use Which Approach

Scenario	Recommended Hook	Why
Persisted state that syncs across tabs	`useLocalStorage`	Data survives refresh; storage events provide sync
Tab-scoped state that does not sync	`useSessionStorage`	Isolated per tab; no cross-tab events
Real-time imperative messages	`useBroadcastChannel`	Fast, supports structured data, no persistence overhead
Both persistence and instant messaging	`useLocalStorage` + `useBroadcastChannel`	Best of both: persist for new tabs, broadcast for open tabs
Pausing background work	`useDocumentVisibility` / `useWindowFocus`	Reduce unnecessary computation and network requests

Installation

npm install @reactuses/core

Or with your preferred package manager:

pnpm add @reactuses/core
yarn add @reactuses/core

Related Hooks

useBroadcastChannel — type-safe cross-tab messaging via the BroadcastChannel API
useLocalStorage — persistent state with automatic cross-tab synchronization
useSessionStorage — tab-scoped persistent state
useDocumentVisibility — track whether the current tab is visible
useWindowFocus — track whether the browser window has focus
useEventListener — declarative event listener management with automatic cleanup
useOnline — reactive network connectivity status

ReactUse provides 100+ hooks for React. Explore them all →

Originally published on ReactUse Blog

Pareto 3.0: A Lightweight React SSR Framework, Rebuilt on Vite 7

reactuse.com — Thu, 26 Mar 2026 15:13:06 +0000

TL;DR: Pareto 3.0 is a ground-up rewrite — Rspack replaced by Vite 7, React 19 required, simplified routing conventions, Immer-powered state management, and a new ParetoErrorBoundary component. Try it: npx create-pareto@latest my-app

If you've used Next.js or Remix, you know the React SSR patterns: file-based routing, layouts, loaders, streaming. Pareto gives you the same patterns without the complexity. No server components, no framework lock-in, no config maze.

Pareto 3.0 is the release where the framework caught up with the vision: everything you need to build fast React apps, nothing you don't.

What changed in 3.0

Vite 7 replaces Rspack

Pareto 2.x used Rspack with separate client/server configs, Babel, and a lazy compiler. All gone.

Pareto 3.0 uses Vite 7:

Instant dev server — ready in milliseconds, not seconds
Native ESM — no bundling during dev
React Fast Refresh — HMR that preserves component state
Your Vite plugins work — PostCSS, Tailwind, MDX, etc. No framework wrappers
One config — configureVite() in pareto.config.ts

// pareto.config.ts
import type { ParetoConfig } from '@paretojs/core'

const config: ParetoConfig = {
  configureVite(config) {
    config.plugins.push(myVitePlugin())
    return config
  },
}

export default config

React 19

Pareto 3.0 requires React 19. You get use(), Actions, useOptimistic(), and improved Suspense — but no server components. Pareto uses the loader pattern: your components are standard React that works on both server and client.

Simplified routing

Convention files in 3.0:

File	Purpose
`page.tsx`	Route component
`layout.tsx`	Wrapping layout
`loader.ts`	Server-side data fetching (new!)
`head.tsx`	Per-route title and meta tags
`not-found.tsx`	404 page
`route.ts`	JSON API endpoint

New: loader.ts — Define loaders in a separate file. Keeps data fetching separate from components:

// app/dashboard/loader.ts
import type { LoaderContext } from '@paretojs/core'

export function loader(ctx: LoaderContext) {
  return { stats: getDashboardStats() }
}

Changed: Error handling — error.tsx convention is gone. Use ParetoErrorBoundary instead — place it anywhere in the component tree:

import { ParetoErrorBoundary } from '@paretojs/core'

<ParetoErrorBoundary fallback={({ error }) => <p>{error.message}</p>}>
  <RiskyComponent />
</ParetoErrorBoundary>

State management with Immer

defineStore() now uses Immer. Mutate directly, get immutable results:

import { defineStore } from '@paretojs/core/store'

const counterStore = defineStore((set) => ({
  count: 0,
  increment: () => set((draft) => { draft.count++ }),
}))

// Use anywhere — supports direct destructuring
const { count, increment } = counterStore.useStore()

SSR serialization is automatic — no hydration code needed.

Security headers

OWASP-recommended headers out of the box:

import { securityHeaders } from '@paretojs/core/node'

app.use(securityHeaders())

Streaming SSR — the killer feature

The reason Pareto exists. Send the page shell immediately, stream slow data as it resolves:

import { defer, useLoaderData, Await } from '@paretojs/core'
import { Suspense } from 'react'

export function loader() {
  return defer({
    quickData: { total: 42 },           // sent immediately
    slowData: fetchFromDatabase(),       // streamed later
  })
}

export default function Page() {
  const { quickData, slowData } = useLoaderData()

  return (
    <div>
      <h1>{quickData.total} items</h1>
      <Suspense fallback={<Skeleton />}>
        <Await resolve={slowData}>
          {(data) => <DataTable rows={data} />}
        </Await>
      </Suspense>
    </div>
  )
}

Users see content fast. Slow data loads progressively. No full-page spinners.

Migration from 2.x

Install @paretojs/core@3, update to React 19
Remove Rspack config, use configureVite() instead
Replace error.tsx files with ParetoErrorBoundary
Test loaders with Vite's dev server

Try it

npx create-pareto@latest my-app
cd my-app
npm install
npm run dev

Open http://localhost:3000. Edit app/page.tsx. Done.

Links:

GitHub: childrentime/pareto
Docs: paretojs.dev
Full release notes: paretojs.dev/blog/pareto-3/

Pareto is MIT licensed and open source. If you find it useful, give it a star on GitHub.

Building Accessible React Components with Hooks

reactuse.com — Thu, 26 Mar 2026 06:36:58 +0000

Building Accessible React Components with Hooks

Accessibility is not a checklist you run through before launch. It is a design constraint that shapes how your application behaves from the first line of code. When we talk about accessibility in React, most developers think of ARIA attributes, semantic HTML, and screen reader support. Those matter. But there is an entire category of accessibility that gets far less attention: respecting the preferences your users have already set at the operating system level.

Every major operating system lets users configure preferences like reduced motion, high contrast, dark mode, and text direction. These are not cosmetic choices. A user who enables "reduce motion" may experience vestibular disorders that make animated transitions physically uncomfortable. A user who enables high contrast may have low vision. When your React application ignores these signals, it is not just a missed feature — it is a barrier.

This article shows you how to detect and respond to these OS-level preferences in React using hooks from ReactUse. We will cover reduced motion, contrast preferences, color scheme detection, focus management, and text direction — then bring everything together in a practical component.

The Problem with Manual Media Query Listeners

The browser exposes OS-level preferences through CSS media queries like prefers-reduced-motion, prefers-contrast, and prefers-color-scheme. You can read these in JavaScript using window.matchMedia. Here is what the manual approach looks like:

import { useState, useEffect } from "react";

function useManualReducedMotion(): boolean {
  const [prefersReducedMotion, setPrefersReducedMotion] = useState(false);

  useEffect(() => {
    const mediaQuery = window.matchMedia("(prefers-reduced-motion: reduce)");
    setPrefersReducedMotion(mediaQuery.matches);

    const handler = (event: MediaQueryListEvent) => {
      setPrefersReducedMotion(event.matches);
    };

    mediaQuery.addEventListener("change", handler);
    return () => mediaQuery.removeEventListener("change", handler);
  }, []);

  return prefersReducedMotion;
}

This works, but it has problems. You need to handle SSR (where window does not exist), manage event listener cleanup, and repeat this pattern for every media query you want to track. Multiply that across reduced motion, contrast, color scheme, and other queries, and you end up with a lot of boilerplate that is easy to get wrong.

ReactUse provides hooks that encapsulate this pattern with correct SSR handling, proper cleanup, and real-time updates when the user changes their system preferences.

useReducedMotion: Respecting Motion Preferences

The useReducedMotion hook detects whether the user has enabled the "reduce motion" setting on their device. This is one of the most impactful accessibility hooks you can use, because motion can cause real physical discomfort for users with vestibular disorders.

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

function AnimatedCard({ children }: { children: React.ReactNode }) {
  const prefersReducedMotion = useReducedMotion();

  return (
    <div
      style={{
        transition: prefersReducedMotion
          ? "none"
          : "transform 0.3s ease, opacity 0.3s ease",
        animation: prefersReducedMotion ? "none" : "fadeIn 0.5s ease-in",
      }}
    >
      {children}
    </div>
  );
}

The key insight here is not just to disable animations — it is to provide an equivalent experience without motion. A card that fades in over 500ms for most users should simply appear instantly for users who prefer reduced motion. The content is the same; only the delivery changes.

You can also use this hook to swap between animation strategies:

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

function PageTransition({ children }: { children: React.ReactNode }) {
  const prefersReducedMotion = useReducedMotion();

  if (prefersReducedMotion) {
    // Instant transition — no motion, but still a visual change
    return <div style={{ opacity: 1 }}>{children}</div>;
  }

  // Full slide-in animation for users who haven't opted out
  return (
    <div
      style={{
        animation: "slideInFromRight 0.4s ease-out",
      }}
    >
      {children}
    </div>
  );
}

usePreferredContrast: Adapting to Contrast Needs

The usePreferredContrast hook reads the prefers-contrast media query, which tells you whether the user wants more contrast, less contrast, or has no preference. This is critical for users with low vision.

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

function ThemedButton({ children, onClick }: {
  children: React.ReactNode;
  onClick: () => void;
}) {
  const contrast = usePreferredContrast();

  const getButtonStyles = () => {
    switch (contrast) {
      case "more":
        return {
          backgroundColor: "#000000",
          color: "#FFFFFF",
          border: "3px solid #FFFFFF",
          fontWeight: 700 as const,
        };
      case "less":
        return {
          backgroundColor: "#E8E8E8",
          color: "#333333",
          border: "1px solid #CCCCCC",
          fontWeight: 400 as const,
        };
      default:
        return {
          backgroundColor: "#3B82F6",
          color: "#FFFFFF",
          border: "2px solid transparent",
          fontWeight: 500 as const,
        };
    }
  };

  return (
    <button onClick={onClick} style={getButtonStyles()}>
      {children}
    </button>
  );
}

When the user has requested higher contrast, you should increase the difference between foreground and background colors, use heavier font weights, and make borders more visible. When they request less contrast, soften the visual intensity. The default branch handles users who have not set a preference.

usePreferredColorScheme: System Theme Detection

The usePreferredColorScheme hook tells you whether the user's operating system is set to light mode, dark mode, or has no preference. This is the foundation for building theme-aware components.

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

function AdaptiveCard({ title, body }: { title: string; body: string }) {
  const colorScheme = usePreferredColorScheme();

  const isDark = colorScheme === "dark";

  return (
    <div
      style={{
        backgroundColor: isDark ? "#1E293B" : "#FFFFFF",
        color: isDark ? "#E2E8F0" : "#1E293B",
        border: `1px solid ${isDark ? "#334155" : "#E2E8F0"}`,
        borderRadius: "8px",
        padding: "24px",
      }}
    >
      <h3 style={{ marginTop: 0 }}>{title}</h3>
      <p>{body}</p>
    </div>
  );
}

For a simpler boolean check, ReactUse also provides usePreferredDark, which returns true when the user prefers a dark color scheme. And if you need a full dark mode toggle that persists the user's choice, useDarkMode provides that out of the box.

For even more granular control over media queries, useMediaQuery lets you subscribe to any CSS media query string and get live updates.

useFocus: Keyboard Navigation and Focus Management

Keyboard navigation is a core accessibility requirement. Users who cannot use a mouse rely on the Tab key to move between interactive elements. The useFocus hook gives you programmatic control over focus, which is essential for modal dialogs, dropdown menus, and dynamic content.

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

function SearchBar() {
  const inputRef = useRef<HTMLInputElement>(null);
  const [focused, setFocused] = useFocus(inputRef);

  return (
    <div>
      <input
        ref={inputRef}
        type="search"
        placeholder="Search..."
        style={{
          outline: focused ? "2px solid #3B82F6" : "1px solid #D1D5DB",
          padding: "8px 12px",
          borderRadius: "6px",
          width: "100%",
        }}
      />
      <button onClick={() => setFocused(true)}>
        Focus Search (Ctrl+K)
      </button>
    </div>
  );
}

The hook returns both the current focus state and a setter function. You can use the focus state to apply visual indicators (beyond the browser default) and use the setter to programmatically move focus — for example, when a modal opens or when a keyboard shortcut is triggered.

Pairing this with useActiveElement lets you track which element currently has focus across your entire application, which is useful for building focus traps and skip-navigation links.

useTextDirection: RTL and LTR Support

Internationalization and accessibility overlap heavily. The useTextDirection hook detects and manages the text direction of your document, supporting both left-to-right (LTR) and right-to-left (RTL) layouts.

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

function NavigationMenu() {
  const [dir, setDir] = useTextDirection();

  return (
    <nav
      style={{
        display: "flex",
        flexDirection: dir === "rtl" ? "row-reverse" : "row",
        gap: "16px",
        padding: "12px 24px",
      }}
    >
      <a href="/">Home</a>
      <a href="/about">About</a>
      <a href="/contact">Contact</a>
      <button onClick={() => setDir(dir === "rtl" ? "ltr" : "rtl")}>
        Toggle Direction
      </button>
    </nav>
  );
}

RTL support affects more than text alignment. Navigation order, icon placement, and margin/padding directions all need to flip. By using useTextDirection as the source of truth, you can build layout logic that adapts automatically.

Putting It All Together: An Accessible Notification Component

Here is a practical example that combines multiple accessibility hooks into a single component — a notification toast that respects motion preferences, adapts to contrast settings, follows the system color scheme, and manages focus correctly:

import { useRef, useEffect } from "react";
import {
  useReducedMotion,
  usePreferredContrast,
  usePreferredColorScheme,
  useFocus,
} from "@reactuses/core";

interface NotificationProps {
  message: string;
  type: "success" | "error" | "info";
  visible: boolean;
  onDismiss: () => void;
}

function AccessibleNotification({
  message,
  type,
  visible,
  onDismiss,
}: NotificationProps) {
  const prefersReducedMotion = useReducedMotion();
  const contrast = usePreferredContrast();
  const colorScheme = usePreferredColorScheme();
  const dismissRef = useRef<HTMLButtonElement>(null);
  const [, setFocused] = useFocus(dismissRef);

  const isDark = colorScheme === "dark";
  const isHighContrast = contrast === "more";

  // Move focus to the dismiss button when notification appears
  useEffect(() => {
    if (visible) {
      setFocused(true);
    }
  }, [visible, setFocused]);

  if (!visible) return null;

  const colors = {
    success: {
      bg: isDark ? "#064E3B" : "#ECFDF5",
      border: isHighContrast ? "#FFFFFF" : isDark ? "#10B981" : "#6EE7B7",
      text: isDark ? "#A7F3D0" : "#065F46",
    },
    error: {
      bg: isDark ? "#7F1D1D" : "#FEF2F2",
      border: isHighContrast ? "#FFFFFF" : isDark ? "#EF4444" : "#FCA5A5",
      text: isDark ? "#FECACA" : "#991B1B",
    },
    info: {
      bg: isDark ? "#1E3A5F" : "#EFF6FF",
      border: isHighContrast ? "#FFFFFF" : isDark ? "#3B82F6" : "#93C5FD",
      text: isDark ? "#BFDBFE" : "#1E40AF",
    },
  };

  const scheme = colors[type];

  return (
    <div
      role="alert"
      aria-live="assertive"
      style={{
        position: "fixed",
        top: "16px",
        right: "16px",
        backgroundColor: scheme.bg,
        color: scheme.text,
        border: `${isHighContrast ? "3px" : "1px"} solid ${scheme.border}`,
        borderRadius: "8px",
        padding: "16px 20px",
        maxWidth: "400px",
        display: "flex",
        alignItems: "center",
        gap: "12px",
        fontWeight: isHighContrast ? 700 : 400,
        // Respect motion preferences
        animation: prefersReducedMotion ? "none" : "slideIn 0.3s ease-out",
        transition: prefersReducedMotion ? "none" : "opacity 0.2s ease",
      }}
    >
      <span style={{ flex: 1 }}>{message}</span>
      <button
        ref={dismissRef}
        onClick={onDismiss}
        aria-label="Dismiss notification"
        style={{
          background: "none",
          border: `1px solid ${scheme.text}`,
          color: scheme.text,
          cursor: "pointer",
          borderRadius: "4px",
          padding: "4px 8px",
          fontWeight: isHighContrast ? 700 : 500,
        }}
      >
        Dismiss
      </button>
    </div>
  );
}

This component demonstrates several accessibility principles working together:

role="alert" and aria-live="assertive" ensure screen readers announce the notification immediately.
useReducedMotion disables the slide-in animation for users who prefer reduced motion.
usePreferredContrast increases border width and font weight for users who need more contrast.
usePreferredColorScheme adapts all colors to the user's light or dark theme.
useFocus moves keyboard focus to the dismiss button so the user can act on the notification without reaching for the mouse.

Why Hooks Are the Right Abstraction for Accessibility

Hooks are composable. Each accessibility concern is encapsulated in its own hook, and you combine them as needed. A simple button might only use usePreferredContrast. A complex modal might use all five hooks we covered. The hooks do not know about each other, which means you can adopt them incrementally without refactoring existing code.

Hooks also respond to changes in real time. If a user switches from light to dark mode while your application is open, the hooks update and your components re-render with the new preference. This is difficult to achieve with CSS-only solutions that rely on static class names.

Installation

Install ReactUse via your package manager:

npm install @reactuses/core

Then import the hooks you need:

import {
  useReducedMotion,
  usePreferredContrast,
  usePreferredColorScheme,
  useFocus,
  useTextDirection,
} from "@reactuses/core";

Related Hooks

useReducedMotion — detect the prefers-reduced-motion preference
usePreferredContrast — detect the prefers-contrast preference
usePreferredColorScheme — detect prefers-color-scheme (light, dark, or no preference)
usePreferredDark — boolean shorthand for dark mode detection
useDarkMode — full dark mode toggle with persistence
useMediaQuery — subscribe to any CSS media query
useFocus — programmatic focus management
useActiveElement — track the currently focused element
useTextDirection — detect and control LTR/RTL text direction

ReactUse provides 100+ hooks for React. Explore them all →

Originally published on ReactUse Blog

React Drag and Drop Without External Libraries

reactuse.com — Wed, 25 Mar 2026 01:50:31 +0000

React Drag and Drop Without External Libraries

Drag-and-drop is one of those interactions users expect to "just work." Whether it is reordering a task board, uploading files by dragging them onto a page, or letting users rearrange widgets on a dashboard, the ability to grab something and move it feels natural. Yet most React tutorials immediately reach for heavyweight libraries like react-dnd or dnd-kit -- packages that are powerful but add significant bundle size and conceptual overhead for many common use cases.

What if you could get smooth, production-ready drag-and-drop behavior with a single hook call? In this post we will start from raw browser APIs, see why they are painful, and then solve the same problems with two lightweight hooks from ReactUse (@reactuses/core): useDraggable and useDropZone. ReactUse is an open-source collection of 100+ React hooks that wrap common browser and element interactions into simple, composable APIs.

The Manual Approach: Pointer Events by Hand

The most basic way to make an element draggable is to listen for pointerdown, pointermove, and pointerup yourself. Here is what that typically looks like:

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

function ManualDraggable() {
  const ref = useRef<HTMLDivElement>(null);
  const [position, setPosition] = useState({ x: 0, y: 0 });
  const [isDragging, setIsDragging] = useState(false);
  const delta = useRef({ x: 0, y: 0 });

  useEffect(() => {
    const el = ref.current;
    if (!el) return;

    const onPointerDown = (e: PointerEvent) => {
      const rect = el.getBoundingClientRect();
      delta.current = { x: e.clientX - rect.left, y: e.clientY - rect.top };
      setIsDragging(true);
    };

    const onPointerMove = (e: PointerEvent) => {
      if (!isDragging) return;
      setPosition({
        x: e.clientX - delta.current.x,
        y: e.clientY - delta.current.y,
      });
    };

    const onPointerUp = () => setIsDragging(false);

    el.addEventListener("pointerdown", onPointerDown);
    window.addEventListener("pointermove", onPointerMove);
    window.addEventListener("pointerup", onPointerUp);

    return () => {
      el.removeEventListener("pointerdown", onPointerDown);
      window.removeEventListener("pointermove", onPointerMove);
      window.removeEventListener("pointerup", onPointerUp);
    };
  }, [isDragging]);

  return (
    <div
      ref={ref}
      style={{
        position: "fixed",
        left: position.x,
        top: position.y,
        cursor: isDragging ? "grabbing" : "grab",
        padding: 16,
        background: "#4f46e5",
        color: "#fff",
        borderRadius: 8,
      }}
    >
      Drag me
    </div>
  );
}

It works -- but look at the amount of state you have to manage. And this is the simple version. Real-world requirements quickly pile on more complexity.

Why Manual Drag-and-Drop is Hard

The snippet above has several shortcomings that surface the moment you move beyond a demo:

Container bounds. If you want the element to stay inside a parent container, you need to read the container dimensions on every move and clamp the position. That means calling getBoundingClientRect on two elements each frame.
Pointer types. The code above handles mouse events, but what about touch or pen? The PointerEvent API unifies them, yet filtering by pointer type (e.g., disabling drag for pen) requires extra conditionals.
Drag handles. Sometimes the draggable surface is only a small title bar inside a card. You need to split the "trigger" element from the "moving" element and wire the events accordingly.
Event cleanup. Forgetting to remove listeners -- or adding them with the wrong dependencies in useEffect -- causes subtle bugs like elements that keep moving after you release the mouse.
Drop zones. The HTML5 Drag and Drop API introduces dragenter, dragover, dragleave, and drop. Coordinating these events -- especially the notorious dragenter/dragleave flickering on child elements -- is error-prone.

These are exactly the problems that useDraggable and useDropZone solve out of the box.

useDraggable: One Hook, Full Control

useDraggable takes a ref to your target element and an optional configuration object. It returns the current x and y position, a boolean indicating whether the element is being dragged, and a setter in case you need to move the element programmatically.

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

function DraggableCard() {
  const el = useRef<HTMLDivElement>(null);

  const [x, y, isDragging] = useDraggable(el, {
    initialValue: { x: 100, y: 100 },
  });

  return (
    <div
      ref={el}
      style={{
        position: "fixed",
        left: x,
        top: y,
        cursor: isDragging ? "grabbing" : "grab",
        padding: 16,
        background: isDragging ? "#4338ca" : "#4f46e5",
        color: "#fff",
        borderRadius: 8,
        transition: isDragging ? "none" : "box-shadow 0.2s",
        boxShadow: isDragging ? "0 8px 24px rgba(0,0,0,0.2)" : "none",
        userSelect: "none",
        touchAction: "none",
      }}
    >
      Drag me anywhere
    </div>
  );
}

That is the entire component. No manual event listeners. No cleanup logic. Touch, mouse, and pen input work by default.

Constraining to a Container

Pass a containerElement ref and the hook automatically clamps the position so the element cannot leave the container:

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

function BoundedDrag() {
  const container = useRef<HTMLDivElement>(null);
  const el = useRef<HTMLDivElement>(null);

  const [x, y, isDragging] = useDraggable(el, {
    containerElement: container,
    initialValue: { x: 0, y: 0 },
  });

  return (
    <div
      ref={container}
      style={{
        position: "relative",
        width: 400,
        height: 300,
        border: "2px dashed #cbd5e1",
        borderRadius: 8,
      }}
    >
      <div
        ref={el}
        style={{
          position: "absolute",
          left: x,
          top: y,
          width: 80,
          height: 80,
          background: "#4f46e5",
          borderRadius: 8,
          cursor: isDragging ? "grabbing" : "grab",
          touchAction: "none",
        }}
      />
    </div>
  );
}

No manual clamping math. The hook reads the container's scroll and client dimensions and restricts the element automatically.

Using a Drag Handle

Often you want only a specific part of an element -- like a header bar -- to trigger dragging. Pass a handle ref:

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

function DraggablePanel() {
  const panel = useRef<HTMLDivElement>(null);
  const handle = useRef<HTMLDivElement>(null);

  const [x, y, isDragging] = useDraggable(panel, {
    handle,
    initialValue: { x: 200, y: 150 },
  });

  return (
    <div
      ref={panel}
      style={{
        position: "fixed",
        left: x,
        top: y,
        width: 280,
        background: "#fff",
        borderRadius: 8,
        boxShadow: "0 4px 12px rgba(0,0,0,0.15)",
        overflow: "hidden",
        touchAction: "none",
      }}
    >
      <div
        ref={handle}
        style={{
          padding: "8px 12px",
          background: "#4f46e5",
          color: "#fff",
          cursor: isDragging ? "grabbing" : "grab",
          userSelect: "none",
        }}
      >
        Drag from here
      </div>
      <div style={{ padding: 12 }}>
        <p>This content area does not trigger a drag.</p>
      </div>
    </div>
  );
}

The body of the panel remains interactive -- you can select text, click buttons, or scroll -- while the header is the only drag trigger.

useDropZone: File Drops Made Easy

useDropZone tackles the other half of the drag-and-drop story: receiving drops. It handles all four drag events (dragenter, dragover, dragleave, drop), suppresses the browser's default file-opening behavior, and solves the flickering dragleave problem using an internal counter.

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

function FileUploader() {
  const dropRef = useRef<HTMLDivElement>(null);
  const [files, setFiles] = useState<File[]>([]);

  const isOver = useDropZone(dropRef, (droppedFiles) => {
    if (droppedFiles) {
      setFiles((prev) => [...prev, ...droppedFiles]);
    }
  });

  return (
    <div
      ref={dropRef}
      style={{
        padding: 40,
        border: `2px dashed ${isOver ? "#4f46e5" : "#cbd5e1"}`,
        borderRadius: 8,
        background: isOver ? "#eef2ff" : "#f8fafc",
        textAlign: "center",
        transition: "all 0.15s",
      }}
    >
      {isOver ? (
        <p>Release to upload</p>
      ) : (
        <p>Drag files here to upload</p>
      )}
      {files.length > 0 && (
        <ul style={{ textAlign: "left", marginTop: 16 }}>
          {files.map((f, i) => (
            <li key={i}>
              {f.name} ({(f.size / 1024).toFixed(1)} KB)
            </li>
          ))}
        </ul>
      )}
    </div>
  );
}

The isOver boolean lets you restyle the zone the instant a file enters, giving users clear visual feedback. No e.preventDefault() boilerplate, no fighting with flickering dragleave events.

Building a Kanban-Style Card Mover

Let's combine both hooks in a more realistic example -- a draggable card that snaps back when released and a drop zone that accepts it. We will also use useElementBounding to read zone positions for visual feedback.

import { useDraggable, useDropZone, useElementBounding } from "@reactuses/core";
import { useRef, useState } from "react";

interface Task {
  id: string;
  title: string;
}

function KanbanBoard() {
  const [todo, setTodo] = useState<Task[]>([
    { id: "1", title: "Design mockups" },
    { id: "2", title: "Write API spec" },
  ]);
  const [done, setDone] = useState<Task[]>([
    { id: "3", title: "Set up CI pipeline" },
  ]);

  const doneZoneRef = useRef<HTMLDivElement>(null);
  const todoZoneRef = useRef<HTMLDivElement>(null);

  const isOverDone = useDropZone(doneZoneRef, (files) => {
    // File drops are ignored in this example
  });

  const isOverTodo = useDropZone(todoZoneRef, (files) => {
    // File drops are ignored in this example
  });

  const doneBounds = useElementBounding(doneZoneRef);

  return (
    <div style={{ display: "flex", gap: 24, padding: 24 }}>
      <div>
        <h3>To Do</h3>
        <div
          ref={todoZoneRef}
          style={{
            minHeight: 200,
            padding: 12,
            background: isOverTodo ? "#fef3c7" : "#f1f5f9",
            borderRadius: 8,
          }}
        >
          {todo.map((task) => (
            <TaskCard
              key={task.id}
              task={task}
              onDrop={() => {
                setTodo((prev) => prev.filter((t) => t.id !== task.id));
                setDone((prev) => [...prev, task]);
              }}
              targetBounds={doneBounds}
            />
          ))}
        </div>
      </div>
      <div>
        <h3>Done</h3>
        <div
          ref={doneZoneRef}
          style={{
            minHeight: 200,
            padding: 12,
            background: isOverDone ? "#d1fae5" : "#f1f5f9",
            borderRadius: 8,
          }}
        >
          {done.map((task) => (
            <div
              key={task.id}
              style={{
                padding: 12,
                marginBottom: 8,
                background: "#fff",
                borderRadius: 6,
                boxShadow: "0 1px 3px rgba(0,0,0,0.1)",
              }}
            >
              {task.title}
            </div>
          ))}
        </div>
      </div>
    </div>
  );
}

function TaskCard({
  task,
  onDrop,
  targetBounds,
}: {
  task: Task;
  onDrop: () => void;
  targetBounds: ReturnType<typeof useElementBounding>;
}) {
  const el = useRef<HTMLDivElement>(null);

  const [x, y, isDragging, setPosition] = useDraggable(el, {
    initialValue: { x: 0, y: 0 },
    onEnd: (pos) => {
      // Check if the card was released over the "Done" column
      if (
        targetBounds &&
        pos.x >= targetBounds.left &&
        pos.x <= targetBounds.right &&
        pos.y >= targetBounds.top &&
        pos.y <= targetBounds.bottom
      ) {
        onDrop();
      }
      // Snap back to original position
      setPosition({ x: 0, y: 0 });
    },
  });

  return (
    <div
      ref={el}
      style={{
        position: "relative",
        left: x,
        top: y,
        padding: 12,
        marginBottom: 8,
        background: isDragging ? "#e0e7ff" : "#fff",
        borderRadius: 6,
        boxShadow: isDragging
          ? "0 8px 24px rgba(0,0,0,0.15)"
          : "0 1px 3px rgba(0,0,0,0.1)",
        cursor: isDragging ? "grabbing" : "grab",
        zIndex: isDragging ? 50 : 1,
        touchAction: "none",
        userSelect: "none",
        transition: isDragging ? "none" : "all 0.2s ease",
      }}
    >
      {task.title}
    </div>
  );
}

Key details worth noting:

useElementBounding gives us live left, right, top, and bottom values for the "Done" column so we can hit-test when the drag ends.
The onEnd callback snaps the card back to { x: 0, y: 0 } if it was not dropped on the target. This creates a satisfying rubber-band effect with the CSS transition.
No external state library is needed. React's useState is sufficient for this level of complexity.

Enhancing the Experience with Companion Hooks

ReactUse's hooks compose naturally. Here are a few ways to extend the examples above:

useMouse -- Track the cursor globally to show a custom drag cursor or a floating tooltip that follows the pointer during a drag operation.
useEventListener -- Attach a one-off keydown listener to cancel a drag when the user presses Escape.
useElementSize -- Dynamically read the width and height of a container to calculate snap-to-grid positions (e.g., round x to the nearest multiple of the cell width).

For example, adding Escape-to-cancel is just a few lines with useEventListener:

import { useDraggable, useEventListener } from "@reactuses/core";
import { useRef } from "react";

function CancelableDrag() {
  const el = useRef<HTMLDivElement>(null);
  const [x, y, isDragging, setPosition] = useDraggable(el);

  useEventListener("keydown", (e: KeyboardEvent) => {
    if (e.key === "Escape" && isDragging) {
      setPosition({ x: 0, y: 0 });
    }
  });

  return (
    <div
      ref={el}
      style={{
        position: "fixed",
        left: x,
        top: y,
        padding: 16,
        background: "#4f46e5",
        color: "#fff",
        borderRadius: 8,
        cursor: isDragging ? "grabbing" : "grab",
        touchAction: "none",
      }}
    >
      Drag me (press Esc to reset)
    </div>
  );
}

When to Still Use a Full Library

useDraggable and useDropZone cover the vast majority of drag-and-drop use cases with minimal code. However, if your requirements include complex reorderable lists with animated transitions, multi-container sorting with keyboard accessibility, or virtualized lists with thousands of items, a dedicated library like dnd-kit remains the better choice. The key insight is that you don't need one for every situation -- and for many projects, a pair of hooks is all it takes.

Installation

npm i @reactuses/core

Related Hooks

useDraggable -- Make any element draggable with pointer events
useDropZone -- Create drop zones for file uploads and drag operations
useElementBounding -- Get live bounding rectangle of an element
useMouse -- Track mouse position globally
useEventListener -- Attach event listeners declaratively
useElementSize -- Track element dimensions reactively

ReactUse provides 100+ hooks for React. Explore them all →

Originally published on ReactUse Blog

useMediaQuery: Complete Guide to Responsive Design in React

reactuse.com — Tue, 24 Mar 2026 06:40:51 +0000

CSS media queries handle most responsive styling, but sometimes your React components need to know about the viewport, user preferences, or device capabilities at the JavaScript level. Maybe you need to conditionally render a mobile navigation, detect dark mode, or respect reduced motion preferences. The useMediaQuery hook from ReactUse gives you a reactive boolean that stays in sync with any CSS media query string.

What is useMediaQuery?

useMediaQuery wraps the browser's window.matchMedia API in a React hook. Pass it a media query string and it returns a boolean. It subscribes to the change event internally, so the value updates automatically when conditions change.

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

function Example() {
  const isMobile = useMediaQuery("(max-width: 768px)");
  return <p>{isMobile ? "Mobile view" : "Desktop view"}</p>;
}

The API is minimal:

useMediaQuery(query: string, defaultState?: boolean) => boolean

Basic Usage: Mobile Detection

The most common use case is detecting screen width for conditional rendering:

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

function Navigation() {
  const isMobile = useMediaQuery("(max-width: 767px)");

  if (isMobile) {
    return (
      <button aria-label="Open menu">
        <HamburgerIcon />
      </button>
    );
  }

  return (
    <nav>
      <a href="/">Home</a>
      <a href="/about">About</a>
      <a href="/contact">Contact</a>
    </nav>
  );
}

The component only re-renders when the boolean flips, not on every resize pixel.

Reusable Breakpoints Pattern

Define your breakpoints once and reuse them across your app:

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

function useBreakpoint() {
  const isMobile = useMediaQuery("(max-width: 639px)");
  const isTablet = useMediaQuery("(min-width: 640px) and (max-width: 1023px)");
  const isDesktop = useMediaQuery("(min-width: 1024px)");
  return { isMobile, isTablet, isDesktop };
}

function Dashboard() {
  const { isMobile, isTablet } = useBreakpoint();
  const columns = isMobile ? 1 : isTablet ? 2 : 4;

  return (
    <div style={{ display: "grid", gridTemplateColumns: `repeat(${columns}, 1fr)`, gap: 16 }}>
      <Card title="Revenue" />
      <Card title="Users" />
      <Card title="Orders" />
      <Card title="Growth" />
    </div>
  );
}

Detecting User Preferences

Media queries go far beyond screen size. You can detect system-level preferences:

Dark Mode Detection

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

function ThemeProvider({ children }: { children: React.ReactNode }) {
  const prefersDark = useMediaQuery("(prefers-color-scheme: dark)");

  return (
    <div style={{
      background: prefersDark ? "#1a1a2e" : "#ffffff",
      color: prefersDark ? "#e0e0e0" : "#1a1a1a",
      minHeight: "100vh",
    }}>
      {children}
    </div>
  );
}

Reduced Motion

This is critical for accessibility. Users with vestibular disorders set this preference at the OS level:

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

function AnimatedCard({ children }: { children: React.ReactNode }) {
  const prefersReducedMotion = useMediaQuery("(prefers-reduced-motion: reduce)");

  return (
    <div style={{
      transition: prefersReducedMotion ? "none" : "transform 0.3s ease",
    }}>
      {children}
    </div>
  );
}

Other Useful Queries

const prefersHighContrast = useMediaQuery("(prefers-contrast: high)");
const isPortrait = useMediaQuery("(orientation: portrait)");
const hasHover = useMediaQuery("(hover: hover)");

SSR and Hydration Safety

When rendering on the server, window.matchMedia does not exist. Without a defaultState, the hook returns false on the server and the real value on the client, causing a React hydration mismatch.

Pass a defaultState to prevent this:

const isMobile = useMediaQuery("(max-width: 768px)", false);

In development mode, the hook logs a console warning if you forget defaultState during SSR.

Combining with Other Hooks

useMediaQuery pairs naturally with other ReactUse hooks. Here is a theme switcher that respects system preference but lets the user override:

import { useMediaQuery, useLocalStorage } from "@reactuses/core";

function ThemeSwitcher() {
  const systemPrefersDark = useMediaQuery("(prefers-color-scheme: dark)");
  const [userTheme, setUserTheme] = useLocalStorage<"light" | "dark" | "system">("theme", "system");

  const isDark = userTheme === "system" ? systemPrefersDark : userTheme === "dark";

  return (
    <div>
      <p>Current theme: {isDark ? "dark" : "light"}</p>
      <select value={userTheme} onChange={(e) => setUserTheme(e.target.value as "light" | "dark" | "system")}>
        <option value="system">System</option>
        <option value="light">Light</option>
        <option value="dark">Dark</option>
      </select>
    </div>
  );
}

Common Mistakes to Avoid

Using window.matchMedia directly in render -- you get a stale snapshot without subscribing to changes.
Forgetting defaultState with SSR -- always provide one in Next.js, Remix, or Astro projects.
Too many individual queries -- group related breakpoints into a custom hook like useBreakpoint.

Installation

npm i @reactuses/core
# or
pnpm add @reactuses/core
# or
yarn add @reactuses/core

FAQ

How is useMediaQuery different from CSS media queries?

CSS media queries apply styles declaratively. useMediaQuery gives you a JavaScript boolean so you can conditionally render components, run logic, or pass dynamic props. Use CSS for styling, use the hook when you need JavaScript-level awareness.

Does useMediaQuery cause performance issues?

No. Each call creates a single matchMedia listener, which is very lightweight. The component only re-renders when the boolean value actually changes, not on every resize event.

Can I use useMediaQuery with Next.js or other SSR frameworks?

Yes. Pass a defaultState parameter to avoid hydration mismatches. For example: useMediaQuery("(max-width: 768px)", false). The hook will use the default on the server and update to the real value on the client.

What media queries can I use besides screen width?

You can use any valid CSS media query: prefers-color-scheme, prefers-reduced-motion, prefers-contrast, orientation, hover, pointer, and more.

ReactUse provides 100+ production-ready hooks for React. Explore them all at reactuse.com →

React Hooks Performance: How to Avoid Unnecessary Re-renders

reactuse.com — Fri, 20 Mar 2026 06:19:55 +0000

Performance is the concern that separates production-quality React code from tutorial-grade code. Most React applications do not have a rendering problem — but the ones that do can feel sluggish and frustrating. The key is knowing when optimization matters and what tools actually help.

When Does React Re-render?

A component re-renders when:

Its state changes — calling setState re-renders the component and all children.
Its parent re-renders — even if props haven't changed, children re-render by default.
A consumed context changes — any useContext consumer re-renders when the context value updates.

Every optimization technique targets one or more of these triggers.

Rule 1: Don't Optimize Prematurely

Wrapping every value in useMemo and every function in useCallback is not optimization — it is overhead. Memoization has a cost: storing previous values, comparing dependencies, managing cached references. If the computation is trivial, memoization costs more than recomputing.

// Don't do this — memoization costs more than the addition
const total = useMemo(() => price + tax, [price, tax]);

// Just compute it
const total = price + tax;

Measure first with React DevTools Profiler. Optimize the slow parts, not everything.

useMemo — When It Actually Helps

useMemo caches a computed value and recalculates only when dependencies change. It helps in two scenarios:

Expensive computations:

function ProductList({ products, filter }: Props) {
  const filtered = useMemo(
    () => products.filter((p) => p.category === filter),
    [products, filter]
  );

  return (
    <ul>
      {filtered.map((p) => <li key={p.id}>{p.name}</li>)}
    </ul>
  );
}

Preserving referential equality for memoized children:

function Dashboard({ data }: Props) {
  const chartConfig = useMemo(
    () => ({ labels: data.map((d) => d.label), values: data.map((d) => d.value) }),
    [data]
  );
  return <MemoizedChart config={chartConfig} />;
}

useCallback — The Misunderstood Hook

useCallback only matters when the function is passed to a React.memo child or used as a hook dependency. Without React.memo on the child, useCallback does nothing useful.

// Before: new reference every render, MemoizedList always re-renders
function SearchPage() {
  const [query, setQuery] = useState("");
  const handleSelect = (id: string) => console.log("Selected:", id);
  return <MemoizedList onSelect={handleSelect} />;
}

// After: stable reference, MemoizedList skips re-renders
function SearchPage() {
  const [query, setQuery] = useState("");
  const handleSelect = useCallback((id: string) => {
    console.log("Selected:", id);
  }, []);
  return <MemoizedList onSelect={handleSelect} />;
}

State Structure Matters

Split unrelated state:

// Bad: updating name re-renders components that only read age
const [form, setForm] = useState({ name: "", age: 0 });

// Good: independent updates
const [name, setName] = useState("");
const [age, setAge] = useState(0);

Derive what you can:

// Bad: extra state that must stay in sync
const [items, setItems] = useState<Item[]>([]);
const [count, setCount] = useState(0);

// Good: derived value
const [items, setItems] = useState<Item[]>([]);
const count = items.length;

The useRef Pattern for Stable Callbacks

Store the latest callback in a ref to get a stable function reference that always calls the newest version — without adding the callback to dependency arrays:

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

function useInterval(callback: () => void, delay: number) {
  const callbackRef = useLatest(callback);
  useEffect(() => {
    const id = setInterval(() => callbackRef.current(), delay);
    return () => clearInterval(id);
  }, [delay]); // callback is NOT a dependency
}

How ReactUse Hooks Handle Performance Internally

ReactUse hooks use three key patterns:

Refs for callbacks. Hooks like useThrottleFn store your callback via useLatest. The wrapper calls the latest version through the ref — no stale closures, no need for useCallback.
Memoized setup. Expensive initialization (creating throttled functions) is wrapped in useMemo, running only when configuration changes.
Automatic cleanup. Pending timers are cancelled on unmount via useUnmount.

// Simplified internal pattern of useThrottleFn
function useThrottleFn(fn, wait, options) {
  const fnRef = useLatest(fn);
  const throttled = useMemo(
    () => throttle((...args) => fnRef.current(...args), wait, options),
    [wait]
  );
  useUnmount(() => throttled.cancel());
  return { run: throttled, cancel: throttled.cancel, flush: throttled.flush };
}

You don't need to wrap callbacks in useCallback before passing them to ReactUse hooks — the ref pattern handles it.

Practical Example: Optimized Search

Before — API call on every keystroke:

function Search() {
  const [query, setQuery] = useState("");
  const [results, setResults] = useState<Item[]>([]);

  useEffect(() => {
    if (query) {
      fetch(`/api/search?q=${query}`).then((r) => r.json()).then(setResults);
    }
  }, [query]);

  return (
    <div>
      <input value={query} onChange={(e) => setQuery(e.target.value)} />
      <ResultList items={results} />
    </div>
  );
}

After — debounced + memoized, ~90% fewer API calls:

import { useDebounce } from "@reactuses/core";
import { memo, useState, useEffect } from "react";

const MemoizedResultList = memo(ResultList);

function Search() {
  const [query, setQuery] = useState("");
  const debouncedQuery = useDebounce(query, 300);
  const [results, setResults] = useState<Item[]>([]);

  useEffect(() => {
    if (debouncedQuery) {
      fetch(`/api/search?q=${debouncedQuery}`).then((r) => r.json()).then(setResults);
    }
  }, [debouncedQuery]);

  return (
    <div>
      <input value={query} onChange={(e) => setQuery(e.target.value)} />
      <MemoizedResultList items={results} />
    </div>
  );
}

React 19 Compiler

The React Compiler aims to automatically insert useMemo and useCallback at build time. When it ships broadly, many manual memoization patterns become unnecessary. However, it does not replace good state design, debouncing, throttling, or ref-based patterns. It automates the mechanical part — the architectural decisions remain yours.

Common Mistakes

Memoizing everything. Adds overhead without measurable benefit for trivial computations.
useCallback without React.memo. Stable reference is useless if the child re-renders anyway.
All state in one object. Every field update triggers re-renders for all consumers.
Wrong dependency arrays. Missing deps cause stale closures; extra deps cause unnecessary recomputation.
Inline objects in JSX. style={{ color: "red" }} creates new references every render, defeating memoization.

Frequently Asked Questions

When should I use useMemo?

Use useMemo when you have measured a slow computation (filtering large arrays, complex transformations) or when you need referential equality for a value passed to a React.memo child. Do not use it for trivial calculations like arithmetic or string concatenation.

Does useCallback improve performance on its own?

No. useCallback only helps when the returned function is passed to a component wrapped in React.memo or used as a dependency in another hook like useEffect. Without those consumers, the stable reference has no effect.

How do I know if re-renders are a problem?

Use the React DevTools Profiler. It shows which components rendered, how long each render took, and what triggered it. Focus on components with render times above 1-2ms or those that re-render frequently with no visible change.

Will the React Compiler make all this unnecessary?

Partially. The compiler automates useMemo and useCallback insertion. It does not automate state structure decisions, debouncing, throttling, or architectural choices about component boundaries.

ReactUse provides 100+ production-ready hooks for React — TypeScript-first, tree-shakable, SSR-compatible.

Get started with ReactUse →

React Hooks vs Vue Composables: Complete Comparison for 2026

reactuse.com — Sun, 15 Mar 2026 06:04:52 +0000

React Hooks are functions prefixed with use that let React components manage state, side effects, and lifecycle behavior without classes. Vue Composables are functions that leverage Vue's Composition API to encapsulate and reuse reactive logic across components. Both solve the same fundamental problem -- sharing stateful logic -- but they do so with different reactivity models, execution semantics, and ecosystem conventions.

Why This Comparison Matters

Developers moving between React and Vue frequently search for equivalent patterns. Vue's ecosystem has VueUse, a collection of 200+ composables that has become the gold standard for reusable logic. React developers looking for the same breadth of utility hooks now have ReactUse, a library of 100+ hooks directly inspired by VueUse's design philosophy.

Side-by-Side Comparison

Aspect	React Hooks	Vue Composables
Reactivity model	Re-renders the entire component on state change	Fine-grained reactivity via proxied refs
Execution	Runs on every render	Runs once during `setup()`
State primitive	`useState` returns value + setter	`ref()` / `reactive()` returns a proxy
Side effects	`useEffect` with dependency array	`watchEffect` with automatic tracking
Lifecycle	`useEffect` cleanup pattern	`onMounted`, `onUnmounted`, etc.
Rules	Must follow Rules of Hooks (no conditionals)	No ordering constraints
SSR	Requires manual `typeof window` guards	Built-in `onServerPrefetch`
Memoization	Explicit (`useMemo`, `useCallback`)	Automatic via `computed()`
Leading utility library	ReactUse (100+ hooks)	VueUse (200+ composables)

How Reactivity Differs Under the Hood

React hooks re-execute on every render. When you call useState, React stores the value in an internal fiber and returns it fresh each time your component function runs. Derived values require useMemo with an explicit dependency array, and skipping a dependency is a common source of bugs.

Vue composables run once inside setup(). Refs and reactive objects are JavaScript proxies that track which effects depend on them. When a ref changes, only the specific effects that read it are re-triggered -- not the entire component. computed() automatically tracks its dependencies with no manual array required.

Code Comparison: useLocalStorage

React with ReactUse:

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

function Settings() {
  const [theme, setTheme] = useLocalStorage("theme", "light");
  return (
    <button onClick={() => setTheme(theme === "light" ? "dark" : "light")}>
      Current: {theme}
    </button>
  );
}

Vue with VueUse:

<script setup>
import { useLocalStorage } from "@vueuse/core";

const theme = useLocalStorage("theme", "light");

function toggle() {
  theme.value = theme.value === "light" ? "dark" : "light";
}
</script>

<template>
  <button @click="toggle">Current: {{ theme }}</button>
</template>

The API surface is nearly identical. ReactUse returns a [value, setter] tuple that mirrors useState. VueUse returns a reactive ref that you mutate directly.

Code Comparison: useWindowSize

React with ReactUse:

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

function Layout() {
  const { width, height } = useWindowSize();
  return <p>Window: {width} x {height}</p>;
}

Vue with VueUse:

<script setup>
import { useWindowSize } from "@vueuse/core";
const { width, height } = useWindowSize();
</script>

<template>
  <p>Window: {{ width }} x {{ height }}</p>
</template>

Code Comparison: useDark

React with ReactUse:

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

function ThemeToggle() {
  const [isDark, toggle] = useDarkMode({ classNameDark: "dark", classNameLight: "light" });
  return <button onClick={toggle}>{isDark ? "Light" : "Dark"}</button>;
}

Vue with VueUse:

<script setup>
import { useDark, useToggle } from "@vueuse/core";

const isDark = useDark();
const toggle = useToggle(isDark);
</script>

<template>
  <button @click="toggle">{{ isDark ? 'Light' : 'Dark' }}</button>
</template>

Key Differences

Execution model. React hooks run on every render, which means every variable inside a hook is recreated each time the component updates. Vue composables run once, and reactivity is handled through proxies. This is the single largest architectural difference.

Dependency tracking. React requires you to declare dependencies explicitly in arrays (useEffect, useMemo, useCallback). Vue tracks dependencies automatically at runtime. Manual dependency arrays are a frequent source of bugs in React.

SSR approach. Both frameworks support server-side rendering, but the guard patterns differ. React hooks typically check typeof window !== "undefined" before accessing browser APIs. Vue provides lifecycle hooks like onServerPrefetch.

Ecosystem maturity. VueUse has been the dominant utility library in the Vue ecosystem since 2020 and provides over 200 composables. ReactUse is newer but growing quickly, with 100+ hooks that cover the same categories.

ReactUse vs VueUse: The React Equivalent

ReactUse was built explicitly as the React equivalent of VueUse. The two libraries share naming conventions, category organization, and API design principles.

Capability	ReactUse	VueUse
Hook/composable count	100+	200+
TypeScript	First-class	First-class
Tree-shakable	Yes	Yes
SSR-safe	Yes	Yes
Interactive docs	Yes	Yes

For React developers who admire VueUse's breadth and ergonomics, ReactUse is the closest equivalent available today.

FAQ

Are React Hooks the same as Vue Composables?

They serve the same purpose -- encapsulating reusable stateful logic -- but they work differently. React hooks re-execute on every render and require explicit dependency arrays. Vue composables execute once and rely on fine-grained proxy-based reactivity.

Can I use VueUse in React?

No. VueUse depends on Vue's reactivity system. However, ReactUse provides equivalent hooks for React that follow the same naming conventions.

What is the React equivalent of VueUse?

ReactUse (@reactuses/core) is the most direct equivalent. It provides 100+ hooks inspired by VueUse, with TypeScript-first APIs and SSR compatibility. Install it with npm i @reactuses/core.

React Hooks and Vue Composables are two answers to the same question: how do you share stateful logic between components? Both approaches work well in production, and both have mature utility libraries -- VueUse for Vue and ReactUse for React.

If you are a React developer looking for the breadth and polish that VueUse brings to Vue, ReactUse is built for you.

npm i @reactuses/core

Explore ReactUse →

10 Browser API Hooks Every React Developer Needs

reactuse.com — Sat, 14 Mar 2026 04:35:54 +0000

Modern browsers ship with powerful APIs for geolocation, clipboard access, fullscreen mode, network status, and more. Using them directly in React is harder than it should be. You need to guard against server-side rendering, add and remove event listeners, handle permissions, and clean up on unmount. Multiply that by every browser API your app touches and you have a lot of repetitive, error-prone code.

ReactUse solves this with a library of 100+ hooks that wrap browser APIs into clean, SSR-safe, TypeScript-friendly interfaces. Every hook listed below checks for browser availability before accessing any API, so it works out of the box with Next.js, Remix, and any other SSR framework. Install once and import what you need:

npm i @reactuses/core

1. useMediaQuery -- Responsive Design

Respond to CSS media queries in JavaScript. The hook returns a boolean that updates in real time when the viewport changes.

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

function App() {
  const isMobile = useMediaQuery("(max-width: 768px)");
  return <div>{isMobile ? <MobileNav /> : <DesktopNav />}</div>;
}

Use it to conditionally render layouts, load different assets, or toggle features based on screen size without relying on CSS alone.

2. useClipboard -- Copy to Clipboard

Read from and write to the system clipboard using the modern Clipboard API. The hook handles permissions, HTTPS requirements, and focus-state edge cases.

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

function CopyButton({ text }: { text: string }) {
  const [clipboardText, copy] = useClipboard();
  return (
    <button onClick={() => copy(text)}>
      {clipboardText === text ? "Copied!" : "Copy"}
    </button>
  );
}

3. useGeolocation -- User Location

Track the user's geographic coordinates with automatic cleanup of the watchPosition listener on unmount.

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

function LocationDisplay() {
  const { coordinates, error, isSupported } = useGeolocation();
  if (!isSupported) return <p>Geolocation is not supported.</p>;
  if (error) return <p>Error: {error.message}</p>;
  return (
    <p>Lat: {coordinates.latitude}, Lng: {coordinates.longitude}</p>
  );
}

4. useFullscreen -- Fullscreen Mode

Toggle fullscreen on any element. The hook wraps the Fullscreen API and returns the current state along with control functions.

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

function VideoPlayer() {
  const ref = useRef<HTMLDivElement>(null);
  const [isFullscreen, { enterFullscreen, exitFullscreen, toggleFullscreen }] =
    useFullscreen(ref);
  return (
    <div ref={ref}>
      <video src="/demo.mp4" />
      <button onClick={toggleFullscreen}>
        {isFullscreen ? "Exit" : "Fullscreen"}
      </button>
    </div>
  );
}

5. useNetwork -- Online/Offline Status

Monitor the user's network connection. The hook tracks online/offline state and, where available, connection details like effectiveType and downlink.

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

function NetworkBanner() {
  const { online, effectiveType } = useNetwork();
  if (!online) return <div className="banner">You are offline</div>;
  return <div>Connection: {effectiveType}</div>;
}

6. useIdle -- Idle Detection

Detect when the user has stopped interacting with the page. The hook listens for mouse, keyboard, touch, and visibility events and returns true after the specified timeout.

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

function IdleWarning() {
  const isIdle = useIdle(300_000); // 5 minutes
  return isIdle ? <div>Are you still there?</div> : null;
}

7. useDarkMode -- Dark Mode Toggle

Manage dark mode with system preference detection, localStorage persistence, and automatic class toggling on the root element.

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

function ThemeToggle() {
  const [isDark, toggle] = useDarkMode({
    classNameDark: "dark",
    classNameLight: "light",
  });
  return (
    <button onClick={toggle}>
      {isDark ? "Switch to Light" : "Switch to Dark"}
    </button>
  );
}

8. usePermission -- Permission Status

Query the status of a browser permission (geolocation, camera, microphone, notifications, and others) and react to changes in real time.

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

function CameraAccess() {
  const status = usePermission("camera");
  if (status === "denied") return <p>Camera access was denied.</p>;
  if (status === "prompt") return <p>We need camera permission.</p>;
  return <p>Camera access granted.</p>;
}

9. useLocalStorage -- Persistent State

A drop-in replacement for useState that persists to localStorage. It handles serialization, SSR safety, cross-tab sync via the storage event, and error recovery.

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

function Settings() {
  const [lang, setLang] = useLocalStorage("language", "en");
  return (
    <select value={lang ?? "en"} onChange={(e) => setLang(e.target.value)}>
      <option value="en">English</option>
      <option value="es">Spanish</option>
      <option value="fr">French</option>
    </select>
  );
}

10. useEventListener -- Event Handling

Attach event listeners to any target (window, document, or a specific element) with automatic cleanup and TypeScript-safe event types.

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

function KeyLogger() {
  useEventListener("keydown", (event) => {
    console.log("Key pressed:", event.key);
  });
  return <p>Press any key...</p>;
}

This is the foundational hook that many other hooks in ReactUse are built on. It avoids stale closures by always referencing the latest handler.

Manual Implementation vs. ReactUse

Every hook above replaces a significant amount of boilerplate:

Concern	Manual Implementation	ReactUse Hook
SSR safety checks	`typeof window !== "undefined"` guards everywhere	Built in
Event listener cleanup	`useEffect` return with `removeEventListener`	Automatic
TypeScript event types	Manual generic constraints per event	Fully typed
Permission handling	`navigator.permissions.query` + state management	Single call
localStorage serialization	`JSON.parse` / `JSON.stringify` + error handling	Automatic
Cross-tab sync	Manual `storage` event listener	Built in

For a single hook the savings are modest. Across an entire application using five or more browser APIs, ReactUse eliminates hundreds of lines of defensive code.

FAQ

Are these hooks SSR-safe?

Yes. Every hook in ReactUse checks for browser availability before accessing any API. During server-side rendering, hooks return safe default values and skip browser-only logic.

Can I tree-shake unused hooks?

Yes. Importing from @reactuses/core supports tree-shaking. Your bundler will only include the hooks you actually import.

Do these hooks work with React 18 and 19?

ReactUse supports React 16.8 and above. All hooks are compatible with React 18 concurrent features and React 19.

ReactUse provides 100+ hooks for React. Explore them all →

DEV Community: reactuse.com

From Next.js to Pareto: What Changes and What Stays the Same

The mental model shift

Routing: almost identical

Data fetching: loaders replace async components

Streaming: defer() instead of Suspense gymnastics

Head management: React components, not config objects

State management: built-in, not bolted on

Configuration: one file

The performance difference

What you give up

Migration checklist

Building Real-Time Features in React Without WebSocket Libraries

Building Real-Time Features in React Without WebSocket Libraries

1. Server-Sent Events with useEventSource

What Are Server-Sent Events?

The Manual Way

With useEventSource

A Practical Example: Live Notification Feed

2. Authenticated SSE Streams with useFetchEventSource

The Problem with Native EventSource

The Manual Way

With useFetchEventSource

A Practical Example: AI Chat Streaming

3. Network Status Detection with useNetwork and useOnline

The Manual Way

With useNetwork

With useOnline

A Practical Example: Adaptive Quality Streaming

4. Cross-Tab Communication with useBroadcastChannel

The Manual Way

With useBroadcastChannel

5. Putting It All Together: A Real-Time Dashboard

When to Use Which Hook

Installation

Related Hooks

We Benchmarked Our SSR Framework Against Next.js — Here's What We Found

What We Tested

Throughput: Requests Per Second

Load Capacity: Max Sustainable QPS

Latency

Bundle Size

The Cost Difference

How We Keep Benchmarks Honest

React Scroll Effects Without External Libraries

React Scroll Effects Without External Libraries

1. Tracking Scroll Position

The Manual Way

With useScroll

2. Locking Scroll for Modals

The Manual Way

With useScrollLock

3. Smooth Scroll to a Section

The Manual Way

With useScrollIntoView

4. Detecting Sticky Headers

The Manual Way

With useSticky

5. Revealing Elements on Scroll

The Manual Way

With useElementVisibility

6. Advanced Intersection: Scroll-Linked Progress

The Manual Way

With useIntersectionObserver

Putting It All Together

Installation

Related Hooks

Real-time React: Syncing State Across Browser Tabs

Real-time React: Syncing State Across Browser Tabs

Two Browser APIs for Cross-Tab Communication

BroadcastChannel API

Storage Events

The Manual Approach — And Why It Gets Messy

useBroadcastChannel: Type-Safe Messaging Between Tabs

useLocalStorage: Automatic Cross-Tab Sync

Practical Patterns

Pattern 1: Syncing Auth State (Logout Everywhere)

Pattern 2: Syncing Theme Across Tabs

Pattern 3: Cart State in E-Commerce

Pattern 4: Leader Election

Streaming: `defer()` instead of Suspense gymnastics