Repository navigation
RFC: getInitialServerSideProps for initial SSR, leaving CSR intact #29117
Replies: 7 comments 7 replies
|
This is an awesome idea. My use case is to issue server side redirect if a cookie isn't present. I'd love to do that without having to sacrifice the CDN cache result. To achieve this you could discriminate based on initial or XHR requests, and use the cache for XHR - as you suggest. Another way would be to configure what routes require a cookie to be set. |
|
I was going to comment that I think a Thinking about this more, I think I like how the proposed For instance, you could have a component like this: const fetcher = (...args) => fetch(...args).then(res => res.json())
function Page({ initlaPageData }) {
const data = useSWR(`https://.../data`, fetcher, { fallbackData: initlaPageData })
// Render data...
}
// This gets called on every initial HTML request
export async function getInitialServerSideProps() {
// Fetch data from external API
const initlaPageData = await fetcher(`https://.../data`);
// Pass data to the page via props
return { props: { initlaPageData } }
}
export default PageI think this is more straightforward than the other approaches outlined in the various threads (including the ideas that I proposed). This proposal achieves the goal of not blocking navigation on a network request. I hope this change is implemented within Next.js as it would represent a significant performance improvement. |
|
An additional thought related to this discussion: I really wish NextJS would rethink how it's |
|
@leerob is this something that is being worked on/could be worked on sometime soon? It's been a thorn in our side for a while now and the lack of a response from the Next.js team on this ticket/other related tickets has been a little upsetting. Something like Related discussions: |
|
Does v13 provide any solution to this issue? |
|
Hey folks! I realize this is an older discussion, but for those folks landing here from Google, wanted to drop some notes. There's been quite a bit of discussion here, and folks desiring different behaviors, so I don't want to say definitively this is solved. But β you might find the model with the App Router to enable what you're looking for here. Many of the linked discussions, and some points here, talk about mixing static and dynamic bits of data. Others talk about having further control over the cache. These things have been critical to the design of the App Router, which you can incrementally adopt.
Let me know if that's the desired behavior you were looking for. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
I've seen quite a few discussions1 come by, related to
getServerSideProps, but only wanting it on initial page load, and then using CSR for all subsequent page loads. This can be especially useful if you use something like Apollo which has quite an advanced built-in cache. Currently, when usinggetServerSideProps, this cache is rendered almost entirely useless since it will still do a fetch to the SSP API.While I think
getInitialPropsis still partially applicable here, it doesn't offer an easy way to return a 404 error or a redirect2, and given that the API forgetServerSidePropsnests the actual props, it is a way better candidate to ship new features such as redirects, managing cookies and other headers.I think having
getInitialServerSidePropsmay be a better solution to what is suggested in #19611, as it keeps a more familiar API togetStaticPropsandgetServerSideProps, and users of Next.js have become familiar withinitialmeaning 'initial server-side page load', I think.In short, I feel this approach would:
getServerSidePropswithout requiring server-side calls to Next.jsInterested to hear about your ideas and feedback. If you are interested in this as well, feel free to upvote.
An example of this, using Apollo, could be this:
Every page with Apollo wraps itself in
withApollo, which ensures the client is provided and can be used from hooks in the page. The page itself uses the newly proposedgetInitialServerPropsto 'seed' the cache, but after that, client-side navigations can use partial responses from the cache (which could be useful if you have category listings, and then click an item, and can already show the title and image that was loaded before, while the rest shows a skeleton). In addition, if in this example an order isn't found, we return a SEO friendly 404.Footnotes
getServerSidePropsyou can, withnotFound: true, orredirect: { statusCode, destination }.All reactions