SWR + Suspense for client-side data fetching

[dbk91]

I know that data-fetching on the server using server components is one of the major features with the App Router, but I wanted to gain some insight and clarity on client-side data fetching, specifically using Suspense to leverage the error.js and loading.js special files. I'll use SWR in my example since that's what I'm familiar with and it's also what the Next docs recommend.

While there are straight-forward and documented ways to use SWR without Suspense, there doesn't seem to be much communication in the way of using Suspense with libraries like SWR. I've done quite a bit of testing around this, and it appears that this is the most reliable solution:

"use client";

import { useSearchParams } from "next/navigation";
import useSWR from "swr";

async function getProfile(username: string) {
  const res = await fetch(`https://api.github.com/users/${username}`);
  return res.json();
}

export default function GithubProfile() {
  useSearchParams();
  const { data } = useSWR("dbk91", getProfile, { suspense: true });

  return (
    <div>
      <h2>{data.name}</h2>
      <p>{data.bio}</p>
    </div>
  );
}

The reason useSearchParams is invoked is to opt the client component out of static-rendering. If this is invoked prior to useSWR, the production build of this will work with no issues and display a loading state provided the following files exist.

// page.tsx

import GithubProfile from "./GithubProfile";

export default function Page() {
  return <GithubProfile />
}

// loading.tsx

export default function Loading() {
  return <p>Loading profile...</p>
}

Like I mentioned before, this achieves the traditional SPA approach to data fetching while improving DX using the special files for loading and error states. The only drawback to this solution is that SWR throws an error about requiring fallbackData during SSR when this code is run in next dev. However, if you were to circumvent this error by providing fallbackData, you lose the loading state since the initial data is placed in SWR on the server-side and hydrated on the client. Initially I thought SWR would have to change something on their end to accommodate this use-case, but then it occurred to me that it's more likely the error is thrown since Next is not opting the component out of static-rendering for dev.

My questions from all of this are:

1. Why does Next opt client components into static-rendering in next dev despite the fact that they use useSearchParams?
2. Is it safe/stable to use Suspense this way despite the recommendation against using React use, yet?

Aside from that, thanks to the Next team for improving upon an already great framework. We've been early adopters of App Router and aside from a few minor snags, it's been a pure joy to use. 👍

[axelle-bch1]

Hello!
It probably doesn't answer your question, and you might already know this, but it seems that using Suspense along with SWR isn't recommended (source: SWR documentation here : https://swr.vercel.app/docs/suspense)

[dbk91]

Hey @axelle-bch1, appreciate the response. Yes, I saw this a while back. My only confusion still is if React still doesn't recommend this or if there is a limitation using Suspense with SWR outside of React stability. It's likely both, but I get the sense it might be more of the latter since it seems React Query doesn't have a similar disclaimer and appears to support Suspense. I don't know with certainty since I haven't used React Query, but the docs seem to indicate it's possible and that only streaming is experimental.

Either way, this has become less relevant to me since server components are working well for my use-case, so I can leverage Suspense boundaries there.