Data Fetching & Server State

The most basic way to load data in React is to start a request in useEffect after the component renders, keep the result in state, and render one of three things: a loading message, an error, or the data. Every React developer has written this, and interviewers like it because the naive version has three bugs hiding in it.

The mental model: an effect is a subscription to "the props this render used". When userId changes, the old subscription (the old request) must be torn down and a new one started. If you forget the teardown, the old request is still out there, and whichever response arrives last wins, even if it's for the user you navigated away from. That's the race condition.

import { useEffect, useState } from "react";

export function UserProfile({ userId }) {
  const [user, setUser] = useState(null);
  const [error, setError] = useState(null);
  const [isLoading, setIsLoading] = useState(true);

  useEffect(() => {
    const controller = new AbortController();
    setIsLoading(true);
    setError(null);

    fetch(`/api/users/${userId}`, { signal: controller.signal })
      .then((res) => {
        if (!res.ok) throw new Error(`HTTP ${res.status}`);
        return res.json();
      })
      .then((data) => {
        setUser(data);
        setIsLoading(false);
      })
      .catch((err) => {
        if (err.name === "AbortError") return; // we cancelled it ourselves
        setError(err);
        setIsLoading(false);
      });

    return () => controller.abort();
  }, [userId]);

  if (isLoading) return <p>Loading…</p>;
  if (error) return <p role="alert">Error: {error.message}</p>;
  return <h2>{user.name}</h2>;
}

In development with <StrictMode>, React mounts, unmounts and re-mounts every component once to flush out missing cleanups. With this component, the test records two requests: the first is aborted by the cleanup (aborted: true) and the second one does the work (aborted: false). That's expected and harmless; see Strict Mode runs effects twice. If you see two completed requests in Strict Mode, your cleanup is missing.

useEffect(() => {
  let ignore = false;
  fetchUserFromSdk(userId).then((data) => {
    if (!ignore) setUser(data);
  });
  return () => {
    ignore = true;
  };
}, [userId]);

Where you'll see this: small apps, one-off widgets, and older code (often wrapped in a useFetch hook; see useFetch: a data-fetching hook). In my notes, the Redux version of the same idea was useEffect(() => { dispatch(fetchUsers()); }, [dispatch]) with loading/error/users read through useSelector: same shape, with the state moved into the store.

What the hand-written version still doesn't do: caching (go back to user 1 and it refetches), deduplication (two components = two requests), retries, refetching when data goes stale or the tab regains focus, pagination, and optimistic updates. Each is a few dozen lines, and they interact. That's the gap libraries like TanStack Query fill, and the reason the React docs recommend a framework or a data library over raw effects for anything non-trivial.

This is the idea that makes data libraries click, and it's a favourite "why would you use React Query?" interview answer.

Client state is owned by the browser: is the modal open, what's typed in the search box, which tab is selected. It's synchronous, always up to date, and only your code changes it. useState, useReducer, Context and Redux are built for it.

Server state is a cached copy of data that lives somewhere else. You don't own it: other users and other tabs change it behind your back. It's asynchronous to get, it can be out of date the moment you receive it, and several components usually want the same piece. The questions you have to answer are cache questions: when is my copy too old? Who else is already fetching it? When do I throw it away? After I change it, which copies are now wrong?

A mental model: client state is your notebook; server state is a photocopy of a page from a shared library book. Photocopies go out of date, several people want the same page, and you don't want to walk to the library every time someone asks.

import { useEffect, useState } from "react";
import { useQuery } from "@tanstack/react-query";

// Version 1: every component that needs the user fetches it itself.
function useCurrentUserEffect() {
  const [user, setUser] = useState(null);
  useEffect(() => {
    let ignore = false;
    fetch("/api/me")
      .then((res) => res.json())
      .then((data) => {
        if (!ignore) setUser(data);
      });
    return () => {
      ignore = true;
    };
  }, []);
  return user;
}

// Version 2: the user lives in a shared cache, keyed by ["me"].
function useCurrentUserQuery() {
  const { data } = useQuery({
    queryKey: ["me"],
    queryFn: () => fetch("/api/me").then((res) => res.json()),
  });
  return data ?? null;
}

function Header() {
  const user = useCurrentUser(); // one of the two hooks above
  return <header>{user ? `Hi, ${user.name}` : "…"}</header>;
}
function Sidebar() {
  const user = useCurrentUser();
  return <aside>{user ? `${user.unread} unread` : "…"}</aside>;
}

In practice: keep server data in a query library and client state in React state (or a small store). Once server data moves out, most apps find their Redux store shrinks to a handful of UI flags. Redux Toolkit's answer to the same problem is RTK Query.

TanStack Query (called React Query before v4) is a server-state cache. You give it a query key (the cache entry's name) and a query function (how to fetch it); it gives back the data plus a set of status flags, and handles caching, deduplication, background refetching and retries.

You set it up once: create a QueryClient (the cache) and provide it at the top of the tree. Then any component can call useQuery. This is my notes' example, moved from Axios to fetch (Axios isn't installed in the sandbox) with v5's status names.

import { QueryClient, QueryClientProvider } from "@tanstack/react-query";
import { TodoList } from "./TodoList";

const queryClient = new QueryClient(); // one per app, created outside components

export function App() {
  return (
    <QueryClientProvider client={queryClient}>
      <TodoList />
    </QueryClientProvider>
  );
}

import { useQuery } from "@tanstack/react-query";

async function fetchTodos() {
  const res = await fetch("/api/todos");
  if (!res.ok) throw new Error(`Failed to load todos (HTTP ${res.status})`);
  return res.json();
}

export function TodoList() {
  const { data, isPending, isError, error, isFetching } = useQuery({
    queryKey: ["todos"], // the cache entry's name
    queryFn: fetchTodos, // must return a promise; throw to signal an error
  });

  if (isPending) return <span>Loading...</span>;
  if (isError) return <span role="alert">Error: {error.message}</span>;

  return (
    <>
      {isFetching && <small>Refreshing…</small>}
      <ul>
        {data.map((todo) => (
          <li key={todo.id}>{todo.title}</li>
        ))}
      </ul>
    </>
  );
}

The flags, as of v5:

status answers "do I have data?" and fetchStatus answers "is the query function running?". They're independent: a query can be pending + paused (offline, waiting for the network) or success + fetching (refreshing).

When to reach for it: any app with more than a couple of server reads, especially lists, details and dashboards that several components share. Not needed for: one-off fetches in tiny apps, or apps whose framework already loads data per route (Next.js Server Components, React Router loaders), though many of those still use TanStack Query for client-side caching.

My notes flagged this as "Query KEYS: Really important" (the example under it was a screenshot that couldn't be read). It is the most important concept in TanStack Query, because the key is the cache. Every cache entry is identified by its key; same key means same data, shared by every component that asks; different key means a separate entry with its own loading state, fetch and lifetime.

The mental model: a query key is like a file path for the cache. ["todos"] is a folder, ["todos", "list", { status: "open" }] is a file inside it. Two rules follow: every variable the query function uses must be in the key (or two different requests share one file), and invalidation works by folder, so a good hierarchy lets you refresh "everything about todos" in one call.

import { useState } from "react";
import { useQuery, useQueryClient } from "@tanstack/react-query";

export const todoKeys = {
  all: ["todos"],
  lists: () => [...todoKeys.all, "list"],
  list: (filters) => [...todoKeys.lists(), filters],
  detail: (id) => [...todoKeys.all, "detail", id],
};

async function fetchTodos({ status }) {
  const res = await fetch(`/api/todos?status=${status}`);
  if (!res.ok) throw new Error(`HTTP ${res.status}`);
  return res.json();
}

export function FilteredTodos() {
  const [status, setStatus] = useState("open");
  const queryClient = useQueryClient();
  const { data, isPending } = useQuery({
    queryKey: todoKeys.list({ status }), // ["todos", "list", { status: "open" }]
    queryFn: () => fetchTodos({ status }),
  });

  return (
    <>
      <button onClick={() => setStatus("open")}>Open</button>
      <button onClick={() => setStatus("done")}>Done</button>
      <button onClick={() => queryClient.invalidateQueries({ queryKey: todoKeys.all })}>
        Refresh all
      </button>
      {isPending ? <p>Loading…</p> : <ul>{data.map((t) => <li key={t.id}>{t.title}</li>)}</ul>}
    </>
  );
}

How keys are compared: TanStack Query turns the key into a string with a deterministic hash that sorts object keys. The test shows ["todos", { status: "done", page: 1 }] and ["todos", { page: 1, status: "done" }] both hash to ["todos",{"page":1,"status":"done"}], so object key order doesn't matter. Array order does: ["todos", 1] and [1, "todos"] are different queries. Keys must be serialisable (strings, numbers, plain objects, arrays), not class instances or functions.

import { queryOptions, useQuery } from "@tanstack/react-query";

export const todoQuery = (id) =>
  queryOptions({
    queryKey: todoKeys.detail(id),
    queryFn: () => fetch(`/api/todos/${id}`).then((res) => res.json()),
    staleTime: 30_000,
  });

function Todo({ id }) {
  const { data } = useQuery(todoQuery(id));
  // …
}
// elsewhere, e.g. on hover: queryClient.prefetchQuery(todoQuery(id))

function Products({ page }) {
  const { data } = useQuery({
    queryKey: ["products"],
    queryFn: () => fetch(`/api/products?page=${page}`).then((r) => r.json()),
  });
  // …
}

TanStack Query has two timers per cache entry, and mixing them up is the most common interview stumble.

• staleTime: how long data counts as fresh after it was fetched. Fresh data is served from cache with no request. Once stale, it's still shown, but the next trigger (a component mounting, the window regaining focus, the network reconnecting, or an invalidation) refetches it in the background. Default: 0, so data is stale immediately.
• gcTime (v4: cacheTime): how long an unused entry (no mounted component is using it) is kept in memory before it's deleted. Default: 5 minutes (on the server, Infinity). While it's kept, a remount shows the cached data instantly.

Mental model: staleTime is the "best before" date: until then, don't even check for a newer copy. gcTime is how long the fridge keeps leftovers nobody's eating before throwing them out.

My notes' example set staleTime: 60000 ("until then data is fresh"), which is right, but used the v3/v4 call signature. Here it is in v5 form, with gcTime added:

import { useQuery } from "@tanstack/react-query";

async function fetchUsers() {
  const res = await fetch("/api/users");
  if (!res.ok) throw new Error(`HTTP ${res.status}`);
  return res.json();
}

export function Users({ staleTime = 60_000, gcTime }) {
  const { data, isPending, isFetching } = useQuery({
    queryKey: ["users"],
    queryFn: fetchUsers,
    staleTime, // fresh for 60 s: no refetch on mount, focus or reconnect
    gcTime, // how long the data stays cached after the last user unmounts (default 5 min)
  });

  if (isPending) return <div>Loading...</div>;
  return (
    <ul aria-busy={isFetching}>
      {data.map((user) => (
        <li key={user.id}>{user.name}</li>
      ))}
    </ul>
  );
}

What triggers a refetch of stale data (each can be turned off per query):

Each option can also be "always" (refetch even if fresh) or false.

Choosing values: there's no universal answer, it's a product decision about how out of date the data may be. Reference data (countries, feature flags) → staleTime: Infinity. A dashboard → 30–60 seconds. Data the user is actively editing elsewhere → keep 0 and rely on invalidation after mutations. Many teams set a default like staleTime: 60_000 on the QueryClient to stop the "refetch on every mount and every focus" behaviour that surprises people (you switch tabs and see a burst of requests in the Network panel).

Queries read; mutations write. useMutation wraps a function that changes data on the server (POST, PUT, PATCH, DELETE) and tracks its status (isPending, isError, isSuccess, data, error). Unlike useQuery it doesn't run on its own: you call mutate(variables). And it doesn't touch the cache unless you tell it to.

The mental model is write, then mark the photocopies out of date. After a successful write, the server's data has changed, so any cached query that might include it is wrong. The standard move is invalidateQueries with a key prefix: those entries become stale and the active ones refetch, so the UI catches up with the server. That's what my notes' example did; here it is in v5 form, with error handling added.

import { useMutation, useQueryClient } from "@tanstack/react-query";

async function addTodo(newTodo) {
  const res = await fetch("/api/todos", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(newTodo),
  });
  if (!res.ok) throw new Error(`Could not save (HTTP ${res.status})`);
  return res.json();
}

export function TodoInput() {
  const queryClient = useQueryClient();
  const mutation = useMutation({
    mutationFn: addTodo,
    onSuccess: () => {
      // Returning the promise keeps the mutation pending until the refetch finishes.
      return queryClient.invalidateQueries({ queryKey: ["todos"] });
    },
  });

  return (
    <div>
      <button onClick={() => mutation.mutate({ title: "New Todo" })} disabled={mutation.isPending}>
        {mutation.isPending ? "Adding…" : "Add Todo"}
      </button>
      {mutation.isError && <p role="alert">{mutation.error.message}</p>}
    </div>
  );
}

Other ways to sync the cache after a mutation:

• Invalidate (above): simplest and always correct; costs a refetch.
• Write the response into the cache: onSuccess: (saved) => queryClient.setQueryData(["todos", saved.id], saved). Saves a request when the server returns the full updated object; you must update every list that contains it, which is why many teams still invalidate the lists.
• Optimistic update: change the cache before the server answers (next topic).

mutate vs mutateAsync: mutate returns nothing and handles errors through the mutation state. mutateAsync returns a promise you can await, but it rejects on error, so you must catch it or you get an unhandled rejection. Prefer mutate plus the callbacks unless you need to chain.

An optimistic update shows the result of a write before the server confirms it, because most writes succeed and waiting 300 ms for a "like" to register feels broken. The deal you make: if the server says no, you roll back and tell the user.

Mental model: it's writing in pencil. You pencil the new todo into the list straight away, keep a photo of how the list looked before, and when the server answers you either ink it in (refetch the real data) or rub it out (restore the photo).

TanStack Query's recipe has three hooks into the mutation's life: onMutate (before the request: snapshot and write the guess), onError (restore the snapshot), onSettled (success or failure: refetch to get the real thing). This is the flow from my notes, corrected for v5 and for three bugs (below):

import { useMutation, useQueryClient } from "@tanstack/react-query";

async function addTodo(newTodo) {
  const res = await fetch("/api/todos", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(newTodo),
  });
  if (!res.ok) throw new Error(`Could not save (HTTP ${res.status})`);
  return res.json();
}

export function TodoForm() {
  const queryClient = useQueryClient();

  const mutation = useMutation({
    mutationFn: addTodo,
    // 1. Runs before mutationFn: update the cache as if the server already said yes.
    onMutate: async (newTodo) => {
      await queryClient.cancelQueries({ queryKey: ["todos"] }); // stop an in-flight GET overwriting us
      const previousTodos = queryClient.getQueryData(["todos"]);
      queryClient.setQueryData(["todos"], (old = []) => [
        ...old,
        { ...newTodo, id: `temp-${Date.now()}`, pending: true },
      ]);
      return { previousTodos }; // handed to onError / onSettled as `onMutateResult`
    },
    // 2. On failure: put the snapshot back.
    onError: (error, newTodo, onMutateResult) => {
      queryClient.setQueryData(["todos"], onMutateResult?.previousTodos);
    },
    // 3. Either way: refetch so the cache matches the server (real id, server fields).
    onSettled: () => queryClient.invalidateQueries({ queryKey: ["todos"] }),
  });

  const handleSubmit = (event) => {
    event.preventDefault();
    mutation.mutate({ title: "Optimistic Update" });
  };

  return (
    <form onSubmit={handleSubmit}>
      <button type="submit">Add Todo</button>
      {mutation.isError && <p role="alert">{mutation.error.message}</p>}
    </form>
  );
}

import { useMutation, useQuery, useQueryClient } from "@tanstack/react-query";

export function TodosWithPending() {
  const queryClient = useQueryClient();
  const { data = [] } = useQuery({
    queryKey: ["todos"],
    queryFn: () => fetch("/api/todos").then((res) => res.json()),
  });
  const { mutate, isPending, isError, variables } = useMutation({
    mutationFn: async (newTodo) => {
      const res = await fetch("/api/todos", {
        method: "POST",
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify(newTodo),
      });
      if (!res.ok) throw new Error(`HTTP ${res.status}`);
      return res.json();
    },
    onSettled: () => queryClient.invalidateQueries({ queryKey: ["todos"] }),
  });

  return (
    <>
      <button onClick={() => mutate({ title: "Buy milk" })}>Add</button>
      <ul>
        {data.map((t) => <li key={t.id}>{t.title}</li>)}
        {isPending && <li style={{ opacity: 0.5 }}>{variables.title}</li>}
        {isError && (
          <li>
            {variables.title} failed <button onClick={() => mutate(variables)}>Retry</button>
          </li>
        )}
      </ul>
    </>
  );
}

When to be optimistic: actions that almost always succeed and where speed matters (likes, toggles, reordering, adding to a list, chat messages). When not to: payments, anything irreversible, or anything where the server decides the result (a generated id the next screen needs, a price). For React 19's built-in version of the same idea, see useOptimistic.

Infinite scrolling loads a list page by page as the user scrolls: a feed, search results, a chat history. My notes paired "React-Window & TANSTACK for infinite scrolling" (a heading with nothing under it that could be read). They solve different halves: useInfiniteQuery fetches and caches the pages; a trigger (a "Load more" button, an IntersectionObserver sentinel, or a virtualised list's visible range) decides when to ask for the next one. react-window only matters once the list is long enough that rendering every row is slow.

Mental model: useInfiniteQuery is a query whose data is an array of pages, plus a cursor. Each page tells you where the next one starts (nextCursor). The cache entry looks like { pages: [page0, page1, …], pageParams: [0, 1, …] }, and fetchNextPage() appends one more page.

import { useEffect, useRef } from "react";
import { useInfiniteQuery } from "@tanstack/react-query";

async function fetchPosts({ pageParam }) {
  const res = await fetch(`/api/posts?cursor=${pageParam}`);
  if (!res.ok) throw new Error(`HTTP ${res.status}`);
  return res.json(); // { items: [...], nextCursor: number | null }
}

export function Feed() {
  const { data, fetchNextPage, hasNextPage, isFetchingNextPage, isPending } = useInfiniteQuery({
    queryKey: ["posts"],
    queryFn: fetchPosts,
    initialPageParam: 0,
    getNextPageParam: (lastPage) => lastPage.nextCursor ?? undefined, // undefined = no more pages
  });

  const sentinelRef = useRef(null);
  useEffect(() => {
    const el = sentinelRef.current;
    if (!el || !hasNextPage) return;
    const observer = new IntersectionObserver(([entry]) => {
      if (entry.isIntersecting && !isFetchingNextPage) fetchNextPage();
    });
    observer.observe(el);
    return () => observer.disconnect();
  }, [hasNextPage, isFetchingNextPage, fetchNextPage]);

  if (isPending) return <p>Loading…</p>;
  const posts = data.pages.flatMap((page) => page.items);

  return (
    <>
      <ul>
        {posts.map((post) => (
          <li key={post.id}>{post.title}</li>
        ))}
      </ul>
      <div ref={sentinelRef} />
      {isFetchingNextPage && <p>Loading more…</p>}
      {!hasNextPage && <p>You're all caught up.</p>}
    </>
  );
}

import { List } from "react-window";
import { useInfiniteQuery } from "@tanstack/react-query";

function Row({ index, style, ariaAttributes, posts, hasNextPage }) {
  if (index === posts.length) {
    return <div style={style} {...ariaAttributes}>{hasNextPage ? "Loading more…" : "End of feed"}</div>;
  }
  return <div style={style} {...ariaAttributes}>{posts[index].title}</div>;
}

export function VirtualFeed() {
  const { data, fetchNextPage, hasNextPage, isFetchingNextPage, isPending } = useInfiniteQuery({
    queryKey: ["posts"],
    queryFn: ({ pageParam }) => fetch(`/api/posts?cursor=${pageParam}`).then((res) => res.json()),
    initialPageParam: 0,
    getNextPageParam: (lastPage) => lastPage.nextCursor ?? undefined,
  });

  if (isPending) return <p>Loading…</p>;
  const posts = data.pages.flatMap((page) => page.items);

  return (
    <List
      rowComponent={Row}
      rowCount={posts.length + 1} // one extra row for the loader / end marker
      rowHeight={40}
      rowProps={{ posts, hasNextPage }}
      style={{ height: 400 }}
      onRowsRendered={({ stopIndex }) => {
        // Within 5 rows of the end: ask for the next page.
        if (stopIndex >= posts.length - 5 && hasNextPage && !isFetchingNextPage) fetchNextPage();
      }}
    />
  );
}

Practical notes:

• Use cursor-based pagination for feeds (the server returns "start after this id"). Offset pagination (?page=3) duplicates or skips items when rows are added while the user scrolls.
• Infinite scroll hurts footer access, "jump back to where I was", and accessibility. A "Load more" button (onClick={() => fetchNextPage()}) is often the better UX, and it's the same hook.
• For numbered pages (1, 2, 3 with prev/next), use a normal useQuery with the page in the key and placeholderData: keepPreviousData, not an infinite query.

Everything so far handles loading inside the component: if (isPending) return <Spinner />. Suspense flips that around. A component just reads the data as if it were already there; if it isn't, the component suspends, and the nearest <Suspense> boundary above it shows a fallback until it's ready. Errors work the same way with an error boundary.

React 19's use(promise) is the built-in way to read a promise like this. Mental model: use is "await for render". If the promise is fulfilled, use returns the value; if it's pending, React pauses this part of the tree and shows the fallback; if it rejected, use throws the error to the nearest error boundary.

The catch, and the reason libraries exist: the promise must be created outside render and be the same object on every render. If you call fetch during render, each render makes a new promise, which never settles in time, so the component never gets out of the fallback.

import { Suspense, use } from "react";
import { ErrorBoundary } from "react-error-boundary";

// A tiny cache so the SAME promise is returned on every render for the same id.
const cache = new Map();
function fetchUser(id) {
  if (!cache.has(id)) {
    cache.set(
      id,
      fetch(`/api/users/${id}`).then((res) => {
        if (!res.ok) throw new Error(`HTTP ${res.status}`);
        return res.json();
      }),
    );
  }
  return cache.get(id);
}

function UserName({ userPromise }) {
  const user = use(userPromise); // suspends until the promise settles
  return <h2>{user.name}</h2>;
}

export function UserCard({ id }) {
  return (
    <ErrorBoundary fallback={<p role="alert">Could not load user</p>}>
      <Suspense fallback={<p>Loading user…</p>}>
        <UserName userPromise={fetchUser(id)} />
      </Suspense>
    </ErrorBoundary>
  );
}

In real apps you rarely hand-roll that cache. TanStack Query's useSuspenseQuery gives the same Suspense behaviour with a real cache; its data is never undefined, so there are no loading branches:

import { useSuspenseQuery } from "@tanstack/react-query";

function UserNameQuery({ id }) {
  const { data: user } = useSuspenseQuery({
    queryKey: ["user", id],
    queryFn: () => fetch(`/api/users/${id}`).then((res) => res.json()),
  });
  return <h2>{user.name}</h2>;
}
// <Suspense fallback={<p>Loading user…</p>}><UserNameQuery id={3} /></Suspense>

Where Suspense for data fits:

• Frameworks do it best: Next.js Server Components pass promises to Client Components that use them, and routers with loaders start fetches before the route renders.
• Fetch-then-render, not fetch-on-render. Start the request as early as possible (in a route loader, an event handler, or a parent) and pass the promise down. If each component starts its own request when it renders, you get waterfalls: the child can't start until the parent has finished.
• One boundary can cover several components that load in parallel, so the user sees one spinner instead of five popping in at different times. How boundaries and transitions interact is in Suspense boundaries.

A WebSocket is a persistent, two-way connection between browser and server. After an HTTP upgrade handshake, either side can send messages at any time, which makes it the tool for chat, multiplayer, collaborative editing and live dashboards where the client also talks back.

In React terms, a socket is an external system the component synchronises with, so it belongs in useEffect with a cleanup: open it when the component mounts (or when the room changes), close it when it unmounts. Mental model: the effect is a phone call. The dependency array says who you're calling; changing it means hanging up and dialling again; the cleanup is hanging up.

My notes had the right shape: open in an effect, append messages with a functional update, ws.close() in the cleanup. Here's a version that adds what a real chat needs: the room in the dependency array, JSON messages with ids, a send function, and a cleanup that doesn't report its own close as a drop.

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

export function ChatRoom({ roomId }) {
  const [messages, setMessages] = useState([]);
  const [status, setStatus] = useState("connecting");
  const socketRef = useRef(null);

  useEffect(() => {
    const ws = new WebSocket(`wss://chat.example.com/rooms/${roomId}`);
    socketRef.current = ws;
    setMessages([]);
    setStatus("connecting");

    ws.onopen = () => setStatus("connected");
    ws.onmessage = (event) => {
      const message = JSON.parse(event.data); // { id, text }
      setMessages((prev) => [...prev, message]);
    };
    ws.onerror = () => setStatus("error");
    ws.onclose = () => setStatus("disconnected");

    return () => {
      ws.onclose = null; // we're closing on purpose: don't report it as a drop
      ws.close();
    };
  }, [roomId]); // a new room means a new connection

  function send(text) {
    const ws = socketRef.current;
    if (ws?.readyState === WebSocket.OPEN) ws.send(JSON.stringify({ text }));
  }

  return (
    <div>
      <p>Status: {status}</p>
      <ul>
        {messages.map((m) => (
          <li key={m.id}>{m.text}</li>
        ))}
      </ul>
      <button onClick={() => send("hello")} disabled={status !== "connected"}>
        Say hello
      </button>
    </div>
  );
}

import { useEffect, useEffectEvent } from "react";
import { useQuery, useQueryClient } from "@tanstack/react-query";

// Reconnects with exponential backoff: 1 s, 2 s, 4 s … capped at 30 s.
export function useSocket(url, onMessage) {
  const handleMessage = useEffectEvent(onMessage); // always the latest onMessage, never a dependency

  useEffect(() => {
    let ws;
    let attempt = 0;
    let timer;
    let stopped = false;

    function connect() {
      ws = new WebSocket(url);
      ws.onopen = () => {
        attempt = 0;
      };
      ws.onmessage = (event) => handleMessage(JSON.parse(event.data));
      ws.onclose = () => {
        if (stopped) return;
        const delay = Math.min(1000 * 2 ** attempt, 30_000);
        attempt++;
        timer = setTimeout(connect, delay);
      };
    }
    connect();

    return () => {
      stopped = true;
      clearTimeout(timer);
      ws.close();
    };
  }, [url]);
}

// Server pushes go straight into the query cache, so every useQuery(["prices"]) re-renders.
export function useLivePrices() {
  const queryClient = useQueryClient();
  useSocket("wss://prices.example.com", (update) => {
    queryClient.setQueryData(["prices"], (old = {}) => ({ ...old, [update.symbol]: update.price }));
  });
  return useQuery({
    queryKey: ["prices"],
    queryFn: () => fetch("/api/prices").then((res) => res.json()), // initial snapshot
    staleTime: Infinity, // the socket keeps it fresh; never refetch on focus
  });
}

Where state goes: for a component-local feed (one chat window), useState in the component is fine. If several components need the live data, put the socket in one place (a context provider, a store, or the query cache as above) rather than opening a socket per component. Browsers limit connections, and duplicate sockets mean duplicate messages.

Server-Sent Events (SSE) are a one-way stream from server to browser over plain HTTP. The client opens a long-lived GET with new EventSource(url); the server keeps the response open and writes text/event-stream lines (data: …, optionally event: goal and id: 42). The browser parses them into events.

Mental model: a WebSocket is a phone call (both sides talk); SSE is a radio station (you tune in and listen). It's a great fit when the server pushes and the client only listens: notifications, live scores, progress of a long job, streaming LLM responses. The browser also gives you automatic reconnection for free: if the connection drops, it reconnects and sends a Last-Event-ID header so the server can resume.

import { useEffect, useState } from "react";

export function LiveScores({ matchId }) {
  const [events, setEvents] = useState([]);
  const [status, setStatus] = useState("connecting");

  useEffect(() => {
    const source = new EventSource(`/api/matches/${matchId}/events`);

    source.onopen = () => setStatus("live");
    source.onmessage = (event) => {
      // Unnamed events ("data: ..." with no "event:" line)
      setEvents((prev) => [...prev, { id: event.lastEventId, text: event.data }]);
    };
    // Named events ("event: goal") only reach addEventListener, not onmessage.
    const onGoal = (event) => setEvents((prev) => [...prev, { id: event.lastEventId, text: `GOAL: ${event.data}` }]);
    source.addEventListener("goal", onGoal);

    source.onerror = () => {
      // The browser reconnects by itself unless readyState is CLOSED.
      setStatus(source.readyState === EventSource.CLOSED ? "closed" : "reconnecting");
    };

    return () => {
      source.removeEventListener("goal", onGoal);
      source.close();
    };
  }, [matchId]);

  return (
    <section>
      <p>Status: {status}</p>
      <ol>
        {events.map((e) => (
          <li key={e.id}>{e.text}</li>
        ))}
      </ol>
    </section>
  );
}

How they compare (a common interview question):