Please enable JavaScript.
Coggle requires JavaScript to display documents.
Pre-rendering and Data fetching P-2 - Coggle Diagram
Pre-rendering and Data fetching P-2
SSG with Dynamic Parameters
very useful in pages with master detail pattern such as posts and posts/id
Here in posts route we will fetch all the posts in the app and have the data , and we will have the Link component point to each post
getStaticProps has an parameter called as context , getStaticProps(context) , where context contains all the parameters of objects in the URL , we can get postId using params.postId
But we get an error that all the pages with static generation with Dynamic parameters should have getStaticPaths() in it
SSG with getStaticPaths()
Basically , Next Js throws the error because the master page contains the post and we have specified the post id links in it , imagine if we have 100 link components , Next js is confused on which of those 100 posts to prerender at build time
Dynamic SSG pages always need getStaticPaths() function in it
In the getStaticPahts() function we should return an object with two values called as paths and fallback , where paths is an array of objects , the object will describe which params should be pre-rendered at the build-time
export async function getStaticPaths() {
return {
paths : [{ params: postId}],
fallback: false
}
}
Inspecting getStaticPaths() build
posts master and individual posts id detail page are hollow circled when inspected in the build
, which means
If you navigate to SSG pages with the route in it using the url bar like localhost:3000/posts/1 , then it will load the HTML file generated at the build time
If you navigate to the same page by Link component then the page is generated at the run time in the client side using the JSON and Javascript file present
Fetching Paths for getStaticPaths()
return array of 100 posts
getStaticPaths() fallback false
Can have three possible values
false
true
'blocking'
getStaticPaths() fallback false
The paths returned from getStaticPaths will be rendered to
HTML
at build time by getStaticProps
If fallback is set to false , then any path not returned by getStaticPaths will result in a 404 page
When to use ?
The false value is most suitable if you have an application with a small number of paths to prerender
When new pages are not added often
A blog site with few articles is a good example for an app with fallback set to false
getStaticPaths() fallback true
The paths returned from getStaticPaths will be rendered to
HTML
at build time by getStaticProps , which is same as the false fallback
The paths that have not been generated at build time will not result in a 404 page , Instead , Next JS will serve a fallback version of the page on the first request to such a path
In the background , Next JS will statically generate the requested path HTML and JSON. This includes running getStaticProps()
When that's done, the browser recieves the JSON for the generated path . This will be used to automatically render the page with the required props . From the User's perspective , the page will be swapped from the fallback page to the full page
At the same time , Next JS keeps track of the new list of pre-rendere pages. Subsequent requests to the same page will serve the generated page , just like other pages that are pre-rendered at the build time
When to use fallback true ?
The true value is most suitable if your app has a very large number of static pages that depends on data
A large E-Commerce site
You want all the product pages to be pre-rendered but if you have many items, then the build can take a really long time
You may statically generate a small subset of products that are popular and use fallback: true for the rest
getStaticPaths() fallback 'blocking'
It is very similar to fallback is set to true , the only diff is that instead of showing a fallback page , we will not see any new content in the UI while the page is being generated in the server
The paths returned from getStaticPaths will be rendered to HTML at build time by getStaticProps
The paths that have not been generated at buld time will not result in an 404 page . Instead , on the first request , Next JS will render the page on the server and return the generated HTML
When that's done , the browser recieves the HTML for the generated path . From the user's perspective , it will transform the browser from '' the browser is requesting the page '' to '' full page is loaded '' . There is no flashing of loading / fallback state
At the same time , Next JS keeps track of the newly pre-rendered pages . Subsequent requests of the same path will serve the generated page , just like the other pages that are pre-rendered at the build time
When to use ?
On a UX level , sometimes , people prefer the page to be loaded without a loading indicator of the wait time is only a few milliseconds , This helps avoid the layout shift
Another main reason is that , some crawlers did not support Javascript, the loading page will be rendered and then the full page will be loaded which was causing a problem
Incremental Static Regeneration
There was a need to update only those pages which needed a change without having to rebuild the entire app
With ISR , Next JS allows you to update static pages after you have built your application
You can statically generate individual pages without needing to rebuild the entire site , effectively dealing with the issue of stale data
How ?
In the getStaticProps function , apart from the props key , we specify a revalidate key
The value for revalidate is the number of seconds after which a page re generation can occur if the user refreshes the page after these number of seconds
Inspecting ISR Builds
Stale while revalidate
Lets say that the revalidate key is set to 30 seconds in the app
Within App start and before 30 secs , if we navigate to the /products route , the statically generated HTML page is served to us
After the 30 seconds window , the stale page is shown and the page regeneration happens in the background , where in the page regeneration processs the HTML page is regenerated with the new API data and after the page is regenerated in the background whenever the user requests the route again the new page is served as a statically generted file
Re-generation
A regeneration is initiated only if a user makes a request after the revalidate time
If a user visits our product details page but there is no other user hitting that page the entire day , then the regeneration doesnt happen , the cached file that is on the CDN only be served in the mean time
revalidate keyt does not mean the page will automatically be regenerated every 30s
It simply denotes the time which after if an user makes a request , a regeneration has to occur
The regenration can also fail in the mean time until then the cached file that was present earlier only will be shown until a subsequent regeneration succeeds