RFC: getInitialServerSideProps for initial SSR, leaving CSR intact

[jeroenvisser101]

I've seen quite a few discussions¹ come by, related to getServerSideProps, but only wanting it on initial page load, and then using CSR for all subsequent page loads. This can be especially useful if you use something like Apollo which has quite an advanced built-in cache. Currently, when using getServerSideProps, this cache is rendered almost entirely useless since it will still do a fetch to the SSP API.

While I think getInitialProps is still partially applicable here, it doesn't offer an easy way to return a 404 error or a redirect², and given that the API for getServerSideProps nests the actual props, it is a way better candidate to ship new features such as redirects, managing cookies and other headers.

I think having getInitialServerSideProps may be a better solution to what is suggested in #19611, as it keeps a more familiar API to getStaticProps and getServerSideProps, and users of Next.js have become familiar with initial meaning 'initial server-side page load', I think.

In short, I feel this approach would:

• Allow users of Next.js to keep providing a fast and responsive client-side rendered app, with server-side rendering for all initial loads
• Expand the familiar and useful API of getServerSideProps without requiring server-side calls to Next.js
• Offer users a more advanced approach to caching data while retaining SSR capability

Interested to hear about your ideas and feedback. If you are interested in this as well, feel free to upvote.

An example of this, using Apollo, could be this:

---

Every page with Apollo wraps itself in withApollo, which ensures the client is provided and can be used from hooks in the page. The page itself uses the newly proposed getInitialServerProps to 'seed' the cache, but after that, client-side navigations can use partial responses from the cache (which could be useful if you have category listings, and then click an item, and can already show the title and image that was loaded before, while the rest shows a skeleton). In addition, if in this example an order isn't found, we return a SEO friendly 404.

// withApollo.tsx

// Helper functions
export function getServerSideClient(
  ctx: GetServerSidePropsContext
): IApolloClient {
  return createApolloClient(undefined, ctx, true);
}

export function getServerSideApolloProps(
  _ctx: GetServerSidePropsContext,
  client: IApolloClient
): IApolloProps {
  return {
    apolloState: client.cache.extract() as NormalizedCacheObject,
  };
}

// Higher order component that wraps the page in an apollo provider
export const withApollo = (
  PageComponent: NextPage<any, any>
) => {
  const WithApollo = ({
    apolloClient,
    apolloState,
    ...pageProps
  }: IApolloProps) => {
    const client = apolloClient ?? maybeReuseApolloClient(apolloState);

    return (
      <ApolloProvider client={client}>
        <PageComponent {...pageProps} />
      </ApolloProvider>
    );
  };

  return WithApollo;
};

// pages/orders/[id].tsx
export const getInitialServerSideProps: GetServerSideProps = async (
  context: GetServerSidePropsContext
) => {
  const client = getServerSideClient(context);
  const id = context.query.id?.toString();

  try {
    await Promise.all([
      client.query<ICurrentUserQuery>({ query: CurrentUserDocument }),
      client.query<IOrderNodeQuery, IOrderNodeQueryVariables>({
        query: OrderNodeDocument,
        variables: { id },
      }),
    ]);
  } catch (error) {
    const authErrorResponse = maybeHandleAuthenticationError(error, context);
    if (authErrorResponse) return authErrorResponse;

    if (hasErrorCode(error, "not_found")) {
      return { notFound: true };
    }
  }

  return {
    props: {
      ...getServerSideApolloProps(context, client),
    },
  };
};

Footnotes

---

1. See these:
   • Does `getServerSideProps()`run only the first time user visits the page, or is it also being executed when the user navigates to the page using `next/link`? #28782
   • I want to fetch some data server-side, and make it available on all the pages of my app. How can I do that? #28780
   • How do I get getServerSideProps to work with Apollo cache? #28253
   • Add option to disable getServerSideProps on client-side navigation #19611
   • Use getServerSideProps for a specific request once for multiple pages #11431
   • Isn't SPA experience very poor when using getServerSideProps? #26201
   • Allow bypass "getData" of page component on client side navigation #23921
   • Defer getServerSideProps on client-side navigation #13910
2. Using getServerSideProps you can, with notFound: true, or redirect: { statusCode, destination }.

[jokull]

This is an awesome idea.

My use case is to issue server side redirect if a cookie isn't present. I'd love to do that without having to sacrifice the CDN cache result. To achieve this you could discriminate based on initial or XHR requests, and use the cache for XHR - as you suggest. Another way would be to configure what routes require a cookie to be set.

[jokull]

I have now solved this with the new middleware feature. If there is no cookie a middleware will intercept and do the redirect.

[davidbarratt]

I was going to comment that I think a getClientSideProps() might be a better option. Effectively if that function is preset, then getServerSideProps() would only execute on initial render.

Thinking about this more, I think I like how the proposed getInitialServerSideProps() works with the existing ecosystem somewhat better.

For instance, you could have a component like this:

const fetcher = (...args) => fetch(...args).then(res => res.json())

function Page({ initlaPageData }) {
   const data = useSWR(`https://.../data`, fetcher, { fallbackData: initlaPageData })
  // Render data...
}

// This gets called on every initial HTML request
export async function getInitialServerSideProps() {
  // Fetch data from external API
  const initlaPageData = await fetcher(`https://.../data`);

  // Pass data to the page via props
  return { props: { initlaPageData } }
}

export default Page

I think this is more straightforward than the other approaches outlined in the various threads (including the ideas that I proposed).

This proposal achieves the goal of not blocking navigation on a network request. I hope this change is implemented within Next.js as it would represent a significant performance improvement.

[UlyssesInvictus]

I'm slightly confused about the wording of your proposal, so just to confirm --

• I'm not a huge fan of getClientSideProps(), because as your example code demonstrates, most of the time the data loading code will already have been written into the main component as a hook (e.g. with SWR or Apollo), and it would be inconvenient to essentially have to proxy all of that data through NextJS as a static method.
• I do love getInitialServerSideProps(), because that precisely solves the issue at hand, where we want to execute SSR on initial page loads, but not block on a page load and instead defer to the client code to know how to fetch props.

I do think it's a little silly to have to define a new method rather than just having a way to update getServerSideProps to alert NextJS, but I suppose I don't see a way around that.

[UlyssesInvictus]

An additional thought related to this discussion: I really wish NextJS would rethink how it's shallow prop is defined in its docs. Even though the caveat/warning is literally on the same page as the shallow prop definition (in Link or Router), it's still confusing that it only applies on routing between the same page, and it'll be even more confusing once a putative getInitialServerSideProps exists. I wish NextJS would just deprecate the shallow prop and assume some kind of default behavior. I understood there's all sorts of backwards support reasons this wouldn't work on its own, but I can only assume a lot of confusion having both shallow and getInitialServerSideProps to exist.

[Francesco-Lanciana]

@leerob is this something that is being worked on/could be worked on sometime soon? It's been a thorn in our side for a while now and the lack of a response from the Next.js team on this ticket/other related tickets has been a little upsetting. Something like getInitialServerSideProps would make a huge difference for our app. Considering 12.1 was released today with no reference to this issue it will be at least another 3 months before we get any kind of solution so any update you could provide would be immensely helpful.

Related discussions:
#11211
#11386
#12111
#14855
#18210
#19459
#19611
#23642
#23921
#26201
#28253
#28782
#29117
#29225
#31786
#32021
#32234
#32243
#33067

[everdrone]

Does v13 provide any solution to this issue?

[jokull]

Yes it will. There is now a concept of a cache on the client which will be used on secondary client based navigations to routes.

See: https://twitter.com/timneutkens/status/1558896085870985220?s=61&t=B4h75edscBW2MDulzJnmew

[leerob]

Hey folks! I realize this is an older discussion, but for those folks landing here from Google, wanted to drop some notes. There's been quite a bit of discussion here, and folks desiring different behaviors, so I don't want to say definitively this is solved.

But – you might find the model with the App Router to enable what you're looking for here. Many of the linked discussions, and some points here, talk about mixing static and dynamic bits of data. Others talk about having further control over the cache. These things have been critical to the design of the App Router, which you can incrementally adopt.

• https://nextjs.org/docs/app/building-your-application/data-fetching/fetching-caching-and-revalidating
• https://nextjs.org/docs/app/building-your-application/caching

Let me know if that's the desired behavior you were looking for.

[ZimM-LostPolygon]

@leerob Caching doesn't solve the problem in any way, just somewhat alleviates it. In case I'm not using caching, there's still no way to BOTH keep the app responsive, while maintaining full SSR for initial loads.

[spacepolice10]

Hi, @leerob could you please clarify if it is RSC-specific or Next.js-specific behaviour, that devs cannot ignore SSR fetching during client navigation? e.g. prerender data using server fetching when user visits page first time or reloads it & pass data to component from client-caching systems like SWR if user is already on the site & goes from page to page when every bit of data is available without the necessity to fetch it again server-side. It is possible with Pages router & tools like Remix though

[daveycodez]

This doesn't work for Hybrid Next.js Capacitor apps that need dynamic routes.

[akhmadshin]

#32243 (comment)