In context, Expose information on whether a request is a client-side transition

[tunesmith]

Feature request

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

As reported in #19426, there is potential confusion on how getInitialProps works with _app.js and page-level getServerSideProps.

It's useful to invoke logic on the server side that will only run on initial page load.

• auth, for those who wish to serve personalized pages server-side
• Other long-lasting pieces of information, like internationalized site labels

Logic and queries like this are wasteful if requested on every client-side page transition.

While the documentation says that getInitialProps runs client-side on page transitions, it suggests that testing for context.req is a valid approach for preventing logic from running during client-side page transitions. However, this is false in the case of using getInitialProps in _app.js and transitioning to a page with getServerSideProps - in this case, getInitialProps will run on the server side.

This means that inside of getInitialProps or getServerSideProps, there is not a reliable, supported way to tell if the current request is during initial page load, or during a client-side page transition.

Describe the solution you'd like

One easy solution would be to expose a boolean flag in context that indicates whether the current request is a page transition or not. I've seen mention of a isDataReq flag before. Perhaps this could be exposed.

Describe alternatives you've considered

I've noticed that on client-side page transitions, context.req.url always starts with /_next/data, and that could be conditioned upon, but it's unclear whether this is "supported" in terms of something that can be relied upon in future releases.

[kachkaev]

WDYT of using typeof window !== "undefined"?

[tunesmith]

WDYT of using typeof window !== "undefined"?

That would return false in the case of _app.js getInitialProps doing a client-side transition to a page with getServerSideProps, when this feature request is looking for something that would return true.

In other words, testing for "is this running on client side" is not the same as testing for "is this a client-side page transition". The latter is what this feature request is for.

[willviles]

I was also surprised to find that getInitialProps runs server-side on every client-side page transition.

My use case is that I'd like to allow my client to modify site navigation and app-level details from a CMS, whilst ensuring the app is SSRd. My GET request returns quite a large payload, so I really only want to fetch it once, at app-level, server side. Certainly not on every page transition.

I understand I could implement a custom server to solve this, but then I can't deploy on Vercel.

Whilst @tunesmith's solution of adding a flag to getInitialProps context could work, I believe the preferred solution would be to move away from getInitialProps pattern entirely and for getServerSideProps to be introduced to custom _app.js files. This feature would also hopefully prevent disabling of automatic static optimization.

I notice @timneutkens indicated this would be a feature coming to Next.js in #10874 (comment), when the new data fetching patterns were introduced at the start of 2020.

[rrjanbiah]

(Context and source of discussion https://stackoverflow.com/questions/64949719/nextjs-is-there-a-way-to-invoke-something-only-on-serverside-only-on-a-fresh-p )