Hybrid behaviour of getStaticProps - depending on whether it's SSR or Client side. #21182
JonCognioDigital
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
The Next.js team have done some fantastic work on static rendering over the last year but there have been some unintended side effects.
TLDR: It would be great if getStaticProps could be behave differently depending on whether it's an SSR/static generation, or whether it's a client-side request. This would help solve a lot of problems we have, especially SEO and not loading unnecessary data
Let me explain further..... When a page is loaded there are two scenarios:
The page is being request on the server (maybe by Googlebot, or just a first page load) or it's a static regeneration of the page happening in the background.
It's a client side navigation and the page hasn't yet been statically generated yet.
The second scenario can happen a lot on a large site with a long tail of URLs which don't get hit very often and aren't generated on build.
So, for scenario 1 {fallback:blocking} works very well and was a welcome feature, but it does mean that in scenario 2 we have to wait on a call to the server before the page changes. Wouldn't it be great if it we could change the page immediately and use a loading spinner, just like we can when using fallback:true?
The second problem is that if we have data which is used on every page (template data that goes in the header and footer for example) then you have to get that data from your cms on every single page request. What if getStaticProps injected a variable which told us whether we were in server or client mode? If we detected that we were in client mode then we could just shove the template data in Redux the first time and not load it on every subsequent request. When running getStaticProps client-side the data would be injected into the page props once the function has finished running (which I believe is how fallback:true works).
The code would look a bit like this...
In summary, on the client we'd have quicker page transitions and only have to load shared data on the first page. On the server (or when statically generating) we'd get the proper behaviour of loading everything and sending correct status codes.
Beta Was this translation helpful? Give feedback.
All reactions