(next-urql) Handling difference between static and client fetch (due to auth) and static site generation

[zachasme]

Hey, I'm trying to figure out the best way to handle a situation where the query returns different results during static site generation compared to the client-side query.

This happens because during static site generation I only wish to pre-build the public data.

However, any non-public data will briefly flash a 404 page, as seen in my reproduction with a pokedex example api, where the API hides pokemon with fizzbuzz ids from the server but not the client. If you take a look at src/pages/[id].js, you'll see I'm looking at router.isFallback, fetching and stale, and I was hoping to use those to display a loading page, both on the fallback page sent from the server, as well as on the client until the query has finished (with data if it exists and user is authorized, or no data if it doesnt exist or the user is unauthorized).

Try visiting http://localhost:3000/003 for example.

There is always a render where { fallback: false, data: false, fetching: false, stale: false }, even when the query is later performed and returns data.

Is there anyway to detect the situation where the server returned the fallback page, but urql has yet to perform the query?

Thanks!

[zachasme]

The solution we found was to not populate cache data unless we find data:

export async function getStaticProps({ params }) {
  const ssrCache = ssrExchange({ isClient: false });
  const client = initUrqlClient(getConfig(ssrCache), false);

  // This query is used to populate the cache for the query
  // used on this page.
  const { data } = await client
    .query(POKEMON_QUERY, { id: params.id })
    .toPromise();

  // Do not extract and pass urql state unless we found data
  if (!data?.pokemon) return { props: {} };

  return {
    props: {
      // urqlState is a keyword here so withUrqlClient can pick it up.
      urqlState: ssrCache.extractData(),
    },
  };
}

That is, skip passing ssrCache.extractData() as urqlState when the resource cannot be found.

That way, the client can retry the query (using auth cookies/headers) and decide whether to display a 404 or not.