Implementation with getServerSideProps

[Meemaw]

Hi 👋

Thanks for this library -- its great. I have a question regarding data fetching. I see that currently getInitialProps is used. What is the rationale behind this?

If it would be possible to move to getServerSideProps, we could get rid of the fallback + we would be able to tree shake server code.

[rrdelaney]

There are several reasons we use getInitialProps, but the most compelling one that can't be worked around is that getServerSideProps doesn't allow you to set a fallback while fetching data. The entire page freezes and gives no feedback to the user when Next.js is compiling the page being navigated to + fetching data. This is an entirely unacceptable user experience and one of the main motivators for developing this library.

As far as tree-shaking or other advantages from using getServerSideProps, any import calls will be tree shaken automatically and shouldn't be included in the final bundle. If you're unable to remove server-side-only code when using this library I'd definitely consider that a bug we should fix 🙂

Let me know if I'm missing something other than tree-shaking, but AFAIK the seamless imports are the only bug advantage.

[Meemaw]

I partly agree, but -- what are you using for the fallback then for a good user experience? I'm not sure what to show as a fallback on a client side navigation. TBH, freezing the page for a second seems better than layout shifts / random fallbacks.

Problem is that the whole page suspends, so you cant really suspend parts of the page.

I'm not saying getServerSideProps should be the default implementation, but an alternative one.

[rrdelaney]

We're currently using just a normal skeleton and spinner set up for a fallback. I agree it's not great, but our users were experiencing navigation delays that could take up to 5 seconds for an un-cached page. Hopefully useTransition can help here when React 18 is stable, although I'm not sure how Next.js will integrate with it.

As far as an alternative implementation using getServerSideProps goes, I think that would be a bit much for us to maintain. It would be an entirely different code path we don't use at Revere so it wouldn't be tested as well as the main implementation.

[Meemaw]

I don't showing skeleton and a spinner is acceptable for us. Btw, tried to check UX on your website to see how it looks but it seems under registration.

P.S. I would like to integrate this to be used at https://opensea.io/

[rrdelaney]

Just to clarify, is the feature request here to delay page transition until the new page's data is ready? There are a lot of problems with actually implementing this library with getServerSideProps:

1. Would always have to round-trip to the server even if the data is cached on the client
2. Data from the server would have to be manually inserted into the Relay store before rendering the next page could start
3. Would lose the ability to show cached data + refetch in the background

Many of the benefits of Relay come from being able to decide when and how to perform data fetching. Forcing everything into getServerSideProps would lose advantages that come along with the framework. There might be a way to delay navigation, but rewriting this library has a host of other issues.

[Meemaw]

Makes sense. In that case I think a sensible solution would be to delay page transition until data for next page is loaded. This would only be needed on navigation to new pages, but if you navigated to somewhere you previously were, it would be cached.

Do you think that is possible?

[rrdelaney]

There's no built-in way to preload the data AFAIK, but to emulate the behavior of getServerSideProps you can do something like:

fetchQuery(env, nextPageQuery)
  .subscribe({
    complete: continueNavigation
  })

In addition you'll need to add a spinner somewhere in your app to indicate that this is loading. For more info on the issues with getServerSideProps please see vercel/next.js#13910.

Outside of Next.js (e.g. Facebook), Relay's entry points API is used for this purpose.

I'm going to close this out as it can be done in user space, there's not much that can be done at the page-level (where this library operates) to help with this.