Confession: I avoided Suspense for data fetching for about three years because every explanation I read started with “React throws a promise” and my brain filed that under “clever thing that will eventually hurt me.”<\/p>\n
Then I counted the loading state code in one of our dashboards. Nine components, each with its own I deleted most of it in an afternoon. Here’s what I got right, what I got wrong, and the part that still trips me up.<\/p>\n This is the shape almost every React codebase has somewhere:<\/p>\n Twenty lines, and four of them exist purely to handle the case where the component unmounts mid request. I have shipped the version of this without the React 19 shipped The component that renders the data now only knows about data. Loading moved to Suspense, failure moved to the error boundary, and the unmount race disappeared because there’s no That split is the actual win. Not fewer lines, though there are fewer lines. The win is that each concern lives in exactly one place instead of being copy pasted into every leaf component by whoever wrote it that sprint.<\/p>\n Here’s where I lost an afternoon.<\/p>\n My first version didn’t have the The rule: the promise has to be stable across renders, or you’re building an infinite fetch loop with extra steps.<\/p>\n The Suspense reference<\/a> is direct about the boundaries of what it handles, and the React 19 release notes<\/a> cover how A rejected promise passed to So The pairing is not optional:<\/p>\n I went deeper on the boundary side of this in how I stopped shipping white screens<\/a>, including where to put boundaries so one failed widget doesn’t take down a whole page.<\/p>\n Worth separating two things that share a name, because I conflated them for years and it made the docs harder to read than they needed to be.<\/p>\n Suspense shipped originally for code splitting, paired with loading<\/code>, error<\/code>, and data<\/code> triple, each with a slightly different spinner because three different people wrote them. Roughly 200 lines whose entire job was to say “not yet.”<\/p>\nThe pattern I was writing before<\/h2>\n
function Profile({ userId }) {\n const [user, setUser] = useState(null);\n const [loading, setLoading] = useState(true);\n const [error, setError] = useState(null);\n\n useEffect(() => {\n let cancelled = false;\n setLoading(true);\n fetchUser(userId)\n .then((u) => { if (!cancelled) setUser(u); })\n .catch((e) => { if (!cancelled) setError(e); })\n .finally(() => { if (!cancelled) setLoading(false); });\n return () => { cancelled = true; };\n }, [userId]);\n\n if (loading) return <Spinner \/>;\n if (error) return <ErrorMessage error={error} \/>;\n return <h1>{user.name}<\/h1>;\n}\n<\/code><\/pre>\ncancelled<\/code> flag more than once and then spent an afternoon confused about a state update warning.<\/p>\nThe same component with use() and Suspense<\/h2>\n
use<\/code>, which reads a promise during render and hands the waiting off to the nearest Suspense boundary. The reference docs for use<\/code><\/a> are short and worth reading in full, partly because of one detail: despite the naming, use<\/code> isn’t a hook, so you can call it inside conditionals and loops.<\/p>\nfunction Profile({ userPromise }) {\n const user = use(userPromise);\n return <h1>{user.name}<\/h1>;\n}\n\nfunction Page({ userId }) {\n const userPromise = useMemo(() => fetchUser(userId), [userId]);\n return (\n <ErrorBoundary fallback={<ErrorMessage \/>}>\n <Suspense fallback={<Spinner \/>}>\n <Profile userPromise={userPromise} \/>\n <\/Suspense>\n <\/ErrorBoundary>\n );\n}\n<\/code><\/pre>\nsetState<\/code> to lose.<\/p>\nThe caching problem I walked straight into<\/h2>\n
useMemo<\/code>. It called fetchUser(userId)<\/code> directly in the parent’s render body. Which meant every parent re-render created a fresh promise, use<\/code> saw a new promise, Suspense fell back to the spinner, and the network tab filled up with duplicate requests. The UI flickered on every unrelated state change and I blamed React for a while before reading my own code.<\/p>\nuseMemo<\/code> is the duct tape version and it’s fine for simple cases, but React explicitly doesn’t guarantee memo persistence. In real applications you want a cache that lives outside the component. That’s most of what React Query and SWR are actually selling, and it’s why “Suspense replaces your data library” was never true. Suspense replaces your loading state. It doesn’t replace your cache, your deduplication, your revalidation, or your retry policy.<\/p>\nuse<\/code> interacts with the rest of the release.<\/p>\nSuspense doesn’t catch errors, and I keep forgetting<\/h2>\n
use<\/code> doesn’t get handled by Suspense. It propagates up to the nearest error boundary. If you don’t have one, your user sees a blank white page.<\/p>\nuse<\/code> without a wrapping error boundary is strictly worse than the useEffect<\/code> version, because at least the old one had an error<\/code> branch. I made this mistake in a staging deploy and only caught it because someone’s auth token expired at the right moment.<\/p>\n<ErrorBoundary fallback={<Retry \/>}>\n <Suspense fallback={<Skeleton \/>}>\n <Dashboard \/>\n <\/Suspense>\n<\/ErrorBoundary>\n<\/code><\/pre>\nThe other Suspense, the one you might already be using<\/h2>\n
lazy<\/code>. That version has been stable and boring since React 16.6:<\/p>\nconst Settings = lazy(() => import('.\/Settings'));\n\n<Suspense fallback={<Skeleton \/>}>\n <Settings \/>\n<\/Suspense>\n<\/code><\/pre>\n