I have some pages that could benefit from being statically generated by implementing getStaticProps. The problem is, inside getStaticProps I need to call some api and access resources aren't available when I want to do the build (that is when building the docker container in which next.js will run).
Is there a way to tell next.js that I want to postpone the build of some pages untill they are requested for the first time? I feel like it should be possible, the revalidate option for getStaticProps almost does what I want (it re-generates the page the first time it's called if the previously generated one is older that X), problem is, it still tries to generate the page on next build.
There's also the fallback option for getStaticPaths that almost works for me because it allows to postpone the generation of a dynamic-route page. Problem is, I need it for static-route pages too.
Related
Server Side Rendering (in Nuxt, but I think this is fairly universal) has been explained to me as:
When using Nuxt SSR, you request an URL, and get sent back a
pre-rendered HTML page. After loading, the browser starts the
hydration code, at which point the static page becomes a Vue SPA application.
I presume (perhaps incorrectly) that regardless that you are now in SPA mode, if you request a new page (eg. you are on "blog/ten-blue-things" you follow a NuxtLink to "blog/ten-red-things") the browser sends a new request to the server for this page, and effectively break SPA-mode? Or am I wrong?
I really hope the answer is that it does not make a request. In my scenario all the required data is very likely already available, and if not the page would make an API call to get anything missing to dynamically render the new page "blog/ten-red-things". Fetching a pre-rendered page after the first fetch is wasteful in my scenario where everything is already on the client (to clarify this further, this is a PWA offline-first app; I'm adding SSR for the SEO and social sharing of pages).
However, I also wonder that if it indeed does not make a request, does that (generally?) hold true for crawlers as well? I'd rather they DO make a separate request for each page in order for them to get the prerendered SEO-friendly version of the URL. If a crawler has js enabled, it may execute the hydration code, and then what?
Can anybody clarify this perhaps?
Does it matter for this anwser if instead of SRR we employ ISG (incremental static generation)?
It does not break the SPA mode, once you've SSR'ed and hydrated, the app stays as SPA. You can notice the fact that you don't have any "page reload" because you're doing a vue-router client-side navigation (as to oppose to a regular a link navigation).
The rest of the app will still be SSR'ed properly, you will not go back to the server meanwhile (as to oppose to Next.js).
They are several ways to debug all of this thanks to some devtools + trying to disable the JS/inspect the source code. But yeah, crawlers will properly parse the SSR'ed content.
PS: you can also choose what kind of rendering mode you want for a given page so if you want some to be SPA-only, you can. The rest could be SSR'ed (during initial render) + SPA after the hydration.
SSR or ISG will not make any impact regarding crawlers/SEO.
It works differently from SSR of course, but the rendering part will be the same regarding the markup. Only the "freshness" will be different.
At the moment, I am trying to make an application with NEXT.JS. When I come to revalidate of page using method ISR. I very confused to understand how it works for the system or how is it auto to rebuild data of the pages in the system?
Many thanks.
You can think ISR as the combination of the SSR and SSG.
When you defined revalidate in getStaticProps, Next.js will generate the static HTML during build time because getStaticProps is exported.
When a user makes a request to the page, that Next.js app will serve the statically generally page. In fact, all the users will see the same page.
After the validation time is reached, the first user request to the page will make Next.js server-side rendered the page again. The generated page will be saved locally.
All users will be served with that newly generated HTML until the next validation. We then go back to step 3 again.
When I turn on webpack5 and call internal api(/api/*) from page after first render, the page refreshes and logs Refreshing page data due to server-side change. after refreshing once, it works fine as webpack4.
Expected Behavior
The page should not refresh on api call after first render.
I recently updated to Next JS 12 and suddenly started encountering this issue also. I'm not sure if it's necessarily related to that as I believe Next JS 11 was also using Webpack 5 for HMR, but they certainly switched over to socket communication for hot reloading, rather than server sent events as they had with previous versions. [https://nextjs.org/docs/upgrading#nextjs-hmr-connection-now-uses-a-websocket]
I have a file /inc/paths.js where I am organizing and exporting URI path string variables for different resources in my app. There were a number of paths in that module which were also being utilized by parts of my /api scripts, namely object keys for AWS S3 bucket paths. So, this module was being imported by not only React components in the /pages directory and elsewhere, but also to the modules in the /api directory. By moving all the variables used by the /api modules into their own file and making sure that none of those variables are imported by React components or pages, the error seems to have disappeared for me.
This may be related to this quote from Vercel:
Finally, if you edit a file that's imported by files outside of the
React tree, Fast Refresh will fall back to doing a full reload. You
might have a file which renders a React component but also exports a
value that is imported by a non-React component. For example, maybe
your component also exports a constant, and a non-React utility file
imports it. In that case, consider migrating the constant to a
separate file and importing it into both files. This will re-enable
Fast Refresh to work. Other cases can usually be solved in a similar
way.
https://nextjs.org/docs/basic-features/fast-refresh
Although the logic doesn't quite match up, it leads me to believe there is something occurring along those lines.
I updated next.js due to the console warning I get whenever next.js run, telling me its using using weppack 4 instead of 5
You can still use webpack 4 by changing it from your next config as it's an update issue
On the client page, I changed to call the internal API by useEffect() hook to fetch data, instead of triggering the data-fetch function by onclick. I found the issue was gone.
I have a MERN app in which I have integrated NextJS. First time with NextJS so bear with me. I have initially used SSR everywhere (getServerSideProps).
Key points:
I have over 150,000 pages with static content that it's never going to change.
Every week I add around +100 new pages.
I guess the ideal situation here would be using getStaticProps and getStaticPaths and, after an initial build of those 150k pages, just build the new added pages every week and keep what I already have built as it is since it's never going to change.
How can I achieve this? Should I use revalidate here? I have been reading about it in the documentation but I don't completely understand it.
That can be achieved with getStaticProps/getStaticPaths. You'll have to use fallback: true or fallback: 'blocking' in getStaticPaths.
With fallback: true the paths not generated at build time will serve a fallback page on the first request while Next.js statically generates the page. When this is done the page will be swapped from the fallback page to the actual full page.
With fallback: 'blocking', the paths not generated at build time will wait for the HTML to be generated by Next.js, then serve the page once that's done. Unlike fallback: true, since there's no fallback the rendering gets blocked until the page is generated, similar to what happens during server-side rendering.
In both cases the page gets added to the list of pre-rendered pages. Subsequent requests to the same path will serve the pre-generated page.
Neither of these options is supported by next export, in case you depend on that.
Note that revalidate is used in getStaticProps for Incremental Static Regeneration - in cases where you'd want to update existing, generated pages. Since you mentioned generated pages will never change, then there's no need to use revalidate.
My team's primary goal is to be able to "snapshot" a CMS-driven site to static HTML. This is straightforward using getStaticProps and next export.
But we also need to host an intranet version always fetching latest content from the CMS. Using getStaticProps this is not really possible because its output is cached, and if you use the older getInitialProps you can't "freeze" the server version of its output during export.
next dev makes this easy; it has a service that offers up fresh versions of the JSON files that will be made static during export.
On a long-running site, are there important configuration changes that would make next dev safe/safer to use?
In 9.5 Next added Incremental Static Regeneration, a fancy way of saying getStaticProps will regularly invalidate its output some time after the next time it's requested.
This is still not ideal because someone who makes a CMS edit will want to see the change reflected on the very next request, but instead they'll see the old content, wait a few seconds, and reload the page.
On static export, nothing changes: getStaticProps turns into a static JSON file.