Defer getServerSideProps on client-side navigation

[rafaelalmeidatk]

Feature request

Is your feature request related to a problem? Please describe.

When clicking in a link to a page that uses getServerSideProps, the navigation will be kept in hold until the server response is complete, then the navigation will start. I want to be able to defer the getServerSideProps data-fetching until the client-side navigation has been completed. Similar to the behavior of getStaticProps with fallback: true.

Describe the solution you'd like

• When directly accessing the page (e.g., typing the URL and pressing Enter), it should be server-side rendered
• When navigating to the page from another page, the navigation should happen immediately. The page will be rendered with a loading state. When the navigation is completed, the gSSP request should be fired to fetch the content and send it through the page props.

I should be able to opt-in this behavior with a flag in the return of gSSP. The router should have a flag to tell if the page is fetching data:

// pages/example.js

function Post({ post }) {
  const router = useRouter()

  // If the page data is not yet fetched, this will be displayed
  // initially until getServerSideProps() finishes running
  if (router.isFetchingAfterDefer) {
    return <div>Loading...</div>
  }

  // Render post...
}

export async function getServerSideProps(context) {
  return {
    props: { ... },
    deferOnClientSideNavigation: true,
  }
}

Describe alternatives you've considered

Using getInitialProps/getServerSideProps to detect if it is client-side navigation and send empty props, then repeat the fetch logic in the component code

[sromexs]

Hi
I'm working an next js these days and i want to do something cool. when user make http request to my page i (for SEO) i want page render in Server Side and show all data at ones (i want fetch data at Server Side). but when page load completed and user navigate between pages using next/lint i want data render in Client Side (i want fetch data in Client Side). with getInitialProps we can do this let me show you an example.

function Index({ posts }) {
  const [postsArr, setPostsArr] = useState(posts);

  useEffect(() => {
    async function fetchNewPosts() {
      const res = await fetch("https://getpost.com/");
      setPostsArr(await res.json());
    }

    if (posts.length === 0) {
      fetchNewPosts();
    }
  }, []);

  return (
    <>
      <Nav />
      <p>Hello World May I Pick Banana!</p>
      <pre>{JSON.stringify(postsArr, null, 4)}</pre>
    </>
  );
}

Index.getInitialProps = async ({ req }) => {
  let posts = [];
  if (req) {
    const res = await fetch("https://getpost.com/");
    posts = await res.json();
  }
  return { posts };
};

export default Index;

in this approach if there is request we fetch data at first place (Server Side Rendering) but if we navigating to this page with next/link it fetches data from client side (Client Side Rendering).
But with these new data fetching methods getStaticProps and getServerSideProps we cant able to do above behavior.
please fix this issue in new versions.

[JonCognioDigital]

@sadraromexs

That's exactly what I've done in my previous 2 NextJS projects. Since starting my new project I've taken the official advice and am doing everything using getServerSideProps (because I believe the current model for getStaticProps is totally broken).

My old sites were lightning fast, the new one is significantly slower, because making a trip to the API on every request is obviously going to be slower. Seems like a bad decision.

[ziimakc]

It's obvious that user should not wait a few seconds in which nothing happens (because getServerSideProps is not finished loading) when he clicks a link. He should see some action is happening, for example:

• Loading spinner
• Data template (boxes for images, text and so on), youtube example.

---

Just one question, how then you will skip graphql parallel query with router.isFetchingAfterDefer?

export function Test(): JSX.Element {
  const { data, error } = useTestQuery() // will it fire alongside getServerSideProps?

  return (
    <Main>
          {JSON.stringify(data)}
    </Main>
  )
}

export const getServerSideProps: GetServerSideProps = async () => {
  const apolloClient = initializeApollo()

  await apolloClient.query({ query: TestQuery })

  return {
    props: {
      initialApolloState: apolloClient.cache.extract(),
    },
  }
}

[fr3fou]

Any news on this issue? I'll be developing a project which has similar requirements soon and want to know whether to use getInitialProps or getServerSideProps.

[barcel0]

Same problem here. It’s my first NextJS app and I’m not sure how to handle this situation. I’m probably going to end up using getInitialProps despite of being getServerSideProps the recommended option according to the documentation. Any workaround so far?

[JonCognioDigital]

Still waiting to see what happens with this. They say that getInitialProps is still going to be supported but it's been heavily demoted in the documentation and my guess is that it will stay there but won't be worked on again (just a guess but seems reasonable).

The trouble is, the more I think about this issues the more I think it's intertwined with other issues do do with Data fetching. GetStaticProps should also work this way (blocking when generating SSG, not blocking when client side navigation) and we hope to see improvements that allow data-fetching at app/path/component level not just page level. All of this is tied together and needs a solution which brings it all together.

My hope would be that Vercel would open up an RFC for people to comment on a new props fetching solution where we can discuss all of these issues on one place and find a single solution. That's ot something for a minor release though.

[timneutkens]

The solution to this issue is covered by https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html and it's interplay with concurrent mode / suspense. Can't share the exact details yet, will keep you posted.

[vaniyokk]

Any activity on this?
It's really annoying problem!
Very common plugins (next-i18next, next-translate) are already dropped support for getInitialProps. All new examples are using getServerSideProps as preffered solution and there is NO WAY to eliminate extra network call every time route changed?
Nobody uses client-side cache? Hmm... don't believe.
Waiting for experimental react feature is not a solution for now.

You really need to think about it. I don't understand why this issue takes so little attention from community...

[ianldgs]

Any activity on this?
It's really annoying problem!
Very common plugins (next-i18next, next-translate) are already dropped support for getInitialProps. All new examples are using getServerSideProps as preffered solution and there is NO WAY to eliminate extra network call every time route changed?
Nobody uses client-side cache? Hmm... don't believe.
Waiting for experimental react feature is not a solution for now.

You really need to think about it. I don't understand why this issue takes so little attention from community...

FYI, next-i18next recently release version 8.0 that doesn't add a getInitialProps on App anymore.

[JonCognioDigital]

You really need to think about it. I don't understand why this issue takes so little attention from community...

Couldn't agree with this more.

There should be no server side call on client-side navigation. That should be the default way data-fetching works unless you opt out of it. It's especially annoying seeing as this was possible before (and technically still is if you're prepared to build a new site on deprecated features).

[Kae7in]

I really hope this feature is added because getServerSideProps is slowing down our site quite tremendously. Language used around getInitialProps makes it seem like it will be deprecated soon, and getStaticProps/Paths just doesn't make sense for our use-case because our pages have a lot of dynamic data, some of which depends on the user.

[mapsgeek]

wow, i didn't realize how fast and convenient NuxtJS async Fetch until i came to React nextjs!
don't understand why it's so hard to come up with a similar concept.