next/link still triggers SSR (getServerSideProps) when shallow prop is set to true

[williamku]

Bug report

Describe the bug

Clicking on Link element (from "next/link" lib) with property "shallow" being set to true will still trigger the target page's getServerSideProps method (on the server) every single time.

To Reproduce:

(1) create 2 pages: page1 and page2 under "pages" folder.
(2) add getServerSideProps to page1 and return some mock data. Add console.log to output some msg as the first line.
(3) on page2, add a Link component as such:

  import Link from 'next/link';
  return (<Link href="/page1" shallow={true}>Click here</Link>);

(4) Run "npm run build" and "npm run start", directly launch the page2 on browser.
(5) Click on link created at the step 3. Observe the console.log on the server terminal and notice that getServerSideProps function for page1 gets triggered every single time.

Expected behavior

The expected behavior is that, if shallow prop is set to true, the target page should only do the client-transition on the browser without going back to the server. This expectation is based on the NEXT.JS doc site as follows:

Here is the quote from the NEXT.JS doc page "https://nextjs.org/docs/api-reference/next/link":
"shallow - Update the path of the current page without rerunning getStaticProps, getServerSideProps or getInitialProps. Defaults to false".

To be consistent, Router from "next/router" should behave the same way when calling its push method with option of { shallow: true }. Unfortunately I am not able to find any mentioning of "getServerSideProps" in the documentation for "next/router" lib.

A note about convention for SSR (Server-Side-Rendering) capability:

By convention, if a page is SSR-enabled, SSR operations only gets triggered by a direct hit via browser's address bar URL input or refresh. The page should still retain client side transition capability whenever it is needed for better user-perceived performance. In such case, the data is usually retrieved via Ajax. This is the behavior that I am looking for.

System information

• OS: macOS
• Browser: Chrome
• Version of Next.js: ^9.4.4
• Version of Node.js: v12.16.0

---

Thanks

[Janpot]

As per https://nextjs.org/docs/routing/shallow-routing#caveats

Shallow routing only works for same page URL changes. For example, let's assume we have another page called pages/about.js, and you run this:

Router.push('/?counter=10', '/about?counter=10', { shallow: true })

Since that's a new page, it'll unload the current page, load the new one and wait for data fetching even though we asked to do shallow routing.

[williamku]

@Janpot , thanks for the reply and clarification. If "shallow" option cannot be used to enable "Client Transition" for SSR-enabled pages, then, would it be correct to say that, under NEXT.JS framework, if a page is marked as SSR capable (via getServerSideProps), this page will never be able to do "Client Transition"? In other words, this page will be permanently locked in with the "Server Side Rendering" execution path? Every page-hit will mean a complete page reload from the web server? Please kindly confirm...

By any chance do you have a solution to allow a SSR-enabled page to do Client Transition?

Thanks again.

[Janpot]

Every page-hit will mean a complete page reload from the web server?

Not at all, next.js will only download the javascript bundle that is needed and the data generated by getServerSideProps. In a lot of cases the javascript will already be cached so it's really just data loading.

[williamku]

@Janpot , thanks again for the reply - I also done some learning and reading on my own regarding "getServerSideProps". What I learned seems to match up with what you just said: There won't be a full page reloading - it will be just JSON data being fetched to the client side. I think I will close this ticket since my questions are all resolved. Thanks again.

[sfw185]

@Janpot Can I please get an idea of the thinking behind the design decision to not support the described behaviour?

I'm having the same problem here. Scenario: we have completely separate frontend and backend applications, our backend is not written in node. We are using getServerSideProps to support SSR, and it works great, but breaks the normal React behavior in terms of forcing a roundtrip to the node server to get the server props which are delivered by our backend.

This is causing a substantial delay due to the proxying of our backend by node, which looks like it's been forced to work this way, with no way to opt out. While everything is working, the resulting experience is severely degraded and we very much wish to use getServerSideProps, but allow actual shallow rendering (normal React behaviour) on client-side route changes.

Can you please add support for this feature? It's causing a lot of grief for our team due to the massive latency it has introduced.

[sfw185]

This did the trick, thank you @koesnij!

I feel like this should be the default behaviour of shallow=true, but glad there's a workaround in the interim.

[ImTemporaryHere]

@Janpot Can I please get an idea of the thinking behind the design decision to not support the described behaviour?
I'm having the same problem here. Scenario: we have completely separate frontend and backend applications, our backend is not written in node. We are using getServerSideProps to support SSR, and it works great, but breaks the normal React behavior in terms of forcing a roundtrip to the node server to get the server props which are delivered by our backend.
This is causing a substantial delay due to the proxying of our backend by node, which looks like it's been forced to work this way, with no way to opt out. While everything is working, the resulting experience is severely degraded and we very much wish to use getServerSideProps, but allow actual shallow rendering (normal React behaviour) on client-side route changes.
Can you please add support for this feature? It's causing a lot of grief for our team due to the massive latency it has introduced.

Hello, I was facing this problem in my project and I found this :

export const getServerSideProps = wrapper.getServerSideProps(
  async ({ req, store }) => {
    const isCSR = !req || (req.url && req.url.startsWith('/_next/data'));
    if (isCSR) {
      console.log('Client Side Routing');
      return {};
    }

    console.log('Server Side Routing');
    (...)

You can skip getServerSideProps with this code

thanks, its weird that next js has no the option )

[7assenTlili]

Even though this is a great hack, next.js will always send a fetch request to the server to run getServerSideProps. I would like to start working on that PR if the maintainers accept the new behavior

[mzeinh]

Do you care to explain how this works? If you use shallow routing, there won't be a request object or the url will start with "/_next/data"? Tried to copy paste but it didn't work. So I need to understand the underlying logic to make it work for my application.

Thanks

[patrykcieszkowski]

@mzeinh if you read the response body, it's pretty clear what's happening - it forces the server to skip the SSR on CSR and responds with an updated pageProps object instead.

[cprcrack]

Two years later, is there still no way to skip the getServerSideProps request on client side navigation with next/link?

It's honestly pretty baffling that this is not supported as forcing getServerSideProps when you already have all the data on the client really degrades performance and seems to me like a very typical scenario.

In my case I want to support SSR for the intial page load but then I already have all the data I need on the client ready to be used by any other page, so performing an extra request every time the user moves to another page is completely unnecessary.

[BoilingSoup]

Two years later, is there still no way to skip the getServerSideProps request on client side navigation with next/link?

It's honestly pretty baffling that this is not supported as forcing getServerSideProps when you already have all the data on the client really degrades performance and seems to me like a very typical scenario.

In my case I want to support SSR for the intial page load but then I already have all the data I need on the client ready to be used by any other page, so performing an extra request every time the user moves to another page is completely unnecessary.

I believe there is still no "easy" way.
A workaround that I used recently is to use the old and not recommended getInitialProps.
The first time the user lands the function is run on the server, then it is run on the client per every page transition. Except when the page being navigated to has getServerSideProps, then getInitialProps will again run on the server.

It's very annoying and hacky but you can save the necessary data with a set-cookie header on the initial render. Then when getInitialProps triggers again, parse the data from the cookie and use it to populate your pages.

If anyone knows of better solutions please share. I wouldn't mind using another framework if it provides this feature.

[magicqiang]

Found a hacky workaround #32243 (comment)

[leerob]

#29117 (comment)