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.
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.
I'm working with NextJS, I'm using context and useEffect to keep track of login session. I'm noticing that when I navigate from a page to another existing page (ex: Home -> About), Next doesn't re-compile my pages and only does a client-side routing, so my context is preserved and it's useEffect is not triggered, but when I navigate to a 404 page, the 404 page is being re-compiled by server everytime, so the state of the context goes briefly on the default state before triggering the useEffect to update it.
Is there a way to avoid re-compiling on 404 page? Like doing it client-side to preserve context?
Looking around the internet I didn't find anything about how the pages and the 404 page are compiled, so: do you have some resources to look at to understand better how NextJS pages and error pages routing and compiling works?
Also, do you know if there's a way to avoid re-compiling the 404 page everytime, to avoid that initial default state?
I reproduced the error in a CodeSandbox snippet:
Basically I have a ContextProvider in /context/context.js, in the context I have a useEffect that modifies the context state, delayed by 1sec, so you can appreciate my problem).
After the page is loaded and 1sec passed, my context "id" is set to 10, if you navigate from "Index" to "AnotherExistingPage", the context is being preserved, because the routing is client-side, when you navigate to "404 page" (that's simply rendering the same thing as the other two pages), the context is reset and the useEffect is triggered again).
As a solution for avoiding this "state loading" I thought about using SSR to fetch the login status before serving the page, but I still want to know why 404 routing triggers a full website reloading instead of a client-side routing.
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.
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.
I've set a custom server from the example but, my question is...
Can the server code access the NextJs code?
I mean, NextJs is built with webpack, therefore packed in its own context, so if I want to initialize something (let's say, database, logging system, etc.) in the server before NextJs has started, and then access it from NextJs... is it possible? I don't see how unless server code and NextJs code are in the same bundle, is it?
Yes, I guess there are some hacks that can be used, like importing files in runtime with __non_webpack_require__... but that seems like a hack (?) and only in one direction.
Any other better option?
If you use SSR in NextJS, you can access to APIs before rendering.
https://nextjs.org/docs/basic-features/data-fetching/get-server-side-props
If you export a function called getServerSideProps (Server-Side Rendering) from a page, Next.js will pre-render this page on each request using the data returned by getServerSideProps.
It fetches your data upon a user requesting your website everytime.
Thatmeans no matter what you build first on your server. Next.js will fetch for it every time. The comment above me sent the correct link. https://nextjs.org/docs/basic-features/data-fetching/get-server-side-props
TO view all data fetching techniques from next.js visit: https://nextjs.org/docs/basic-features/data-fetching/overview
PLease comment back to this to see if this helped, or if we missunderstood the question, so that we can help solve this issue, or if you resolved it. happy coding!