You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Provide a way to distinguish between initial page loads/reloads and client-side _next/data requests in getServerSideProps.
Simplify global data-fetching strategies for applications that need optimized handling of translations, tags, or other shared data.
Facilitate the migration of legacy projects still using the Pages Router and getInitialProps by offering a standard mechanism to differentiate request types.
Non-Goals
This feature does not propose changes to how client-side navigations fetch _next/data payloads.
It does not aim to replace or alter other lifecycle methods like getStaticProps or getInitialProps.
It does not affect how data fetching works in the App Router or React Server Components.
Background
Currently, there is no built-in way to determine whether a getServerSideProps call is triggered by an initial page load/reload or a client-side navigation fetching _next/data. This distinction is crucial for optimizing global data-fetching strategies, such as translations or tags.
Developers often resort to inspecting req.url for _next/data requests as a workaround:
While effective, this approach relies on internal implementation details that may change, making it brittle and harder to maintain.
Why This Feature is Needed:
It addresses a common pain point for developers managing global data across pages.
It optimizes server load and payload size by avoiding redundant fetching during client navigations.
It bridges the gap for developers migrating from getInitialProps to getServerSideProps.
Alternatives:
Continue relying on req.url inspection, which is fragile and not future-proof.
Use cookies or session storage to track state between client and server, but this adds complexity and is prone to edge cases.
Proposal
Introduce a req.isNextDataRequest property in getServerSideProps to indicate whether the request is part of a client-side navigation fetching _next/data. This property would eliminate the need for brittle URL-based workarounds.
Proposed API:
exportconstgetServerSideProps=async({ req })=>{if(req.isNextDataRequest){// Skip fetching global data during client-side navigationreturn{props: {}};}// Fetch global and page-specific dataconstglobalData=awaitfetchGlobalData();return{props: { globalData }};};
Implementation Details:
The property should be true for _next/data requests and false for initial SSR requests.
It would leverage Next.js’ existing knowledge of whether the request is fetching JSON payloads for client navigation.
Are You Interested in Contributing?
Yes, I would be happy to collaborate on the implementation or testing if needed.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Goals
_next/data
requests ingetServerSideProps
.getInitialProps
by offering a standard mechanism to differentiate request types.Non-Goals
_next/data
payloads.getStaticProps
orgetInitialProps
.Background
Currently, there is no built-in way to determine whether a
getServerSideProps
call is triggered by an initial page load/reload or a client-side navigation fetching_next/data
. This distinction is crucial for optimizing global data-fetching strategies, such as translations or tags.Developers often resort to inspecting
req.url
for_next/data
requests as a workaround:While effective, this approach relies on internal implementation details that may change, making it brittle and harder to maintain.
Why This Feature is Needed:
getInitialProps
togetServerSideProps
.Alternatives:
req.url
inspection, which is fragile and not future-proof.Proposal
Introduce a
req.isNextDataRequest
property ingetServerSideProps
to indicate whether the request is part of a client-side navigation fetching_next/data
. This property would eliminate the need for brittle URL-based workarounds.Proposed API:
Implementation Details:
_next/data
requests and false for initial SSR requests.Are You Interested in Contributing?
Yes, I would be happy to collaborate on the implementation or testing if needed.
Beta Was this translation helpful? Give feedback.
All reactions