How do you do ISG if you don't use fetch like firebase?
Unanswered
West African Crocodile posted this in #help-forum
West African CrocodileOP
How do you do ISG if you don't use fetch like firebase?
I know that I can set "validate=seconds" for ISR, but I don't know how to create an ISG.
I know that I can set "validate=seconds" for ISR, but I don't know how to create an ISG.
113 Replies
simply by using revalidate=number or using dynamic params would already opt you into ISR
your route needs to be static and not dynamically prerendered as ISR is a feature of SSG not Dynamically SSR at request time
West African CrocodileOP
@aardani
ISG will create something like SSG on the second request, right?
ISG will create something like SSG on the second request, right?
yep
ISR will create SSG sites when the route is invalidated
this includes if the route does not exist in a dynamic param OR that the route is invalidated after a timer OR its invalidated on demand using revalidateTag/Path
West African CrocodileOP
What exactly do I need to do to make an ISR? It doesn't just become an ISR on its own, does it?
West African CrocodileOP
Sorry , not ISR , ISG
same thing
Somali
ISG = ISR
i guess only minor differences
ok for ISR
West African CrocodileOP
If I set "validate=seconds" it would be an ISR.
How do I get it to ISG? If I don't set anything, it will just be an SSG, right?
How do I get it to ISG? If I don't set anything, it will just be an SSG, right?
Somali
Are you using dynamic routes
West African CrocodileOP
Yes
1. make sure your route is not dynamic by using
2. make sure your route is static now that you've removed all dynamic-only features by looking at the build log, otherwise you can force it to static (not recommended)
Then there are ways to trigger the revalidation/regeneration of a route
1. via route segment config ->
2. via data cache, if you have fetch and has
export const dynamic = 'error' this will throw an error if you have used features that is only for dynamic SSR at request time. You need to remove those2. make sure your route is static now that you've removed all dynamic-only features by looking at the build log, otherwise you can force it to static (not recommended)
Then there are ways to trigger the revalidation/regeneration of a route
1. via route segment config ->
export const revalidate = 60 this will invalidate the route at 60th second2. via data cache, if you have fetch and has
tags attribute in it, calling revalidateTags/Path would invalidate that route.If you use dynamic routes it will be SSRd by default unless you use
generateStaticParams()make sure you dont disable
dynamicParamsWest African CrocodileOP
export const revalidate = 60;
export async function generateStaticParams() {
const mapColRef = collection(db, "maps");
const mapSnapshots = await getDocs(mapColRef);
const mapIds = mapSnapshots.docs.map((doc) => doc.id);
return mapIds.map((mapId) => ({ mapId }));
}
export default async function MapPage({ params }: PageProps) {perfect
West African CrocodileOP
Now this would be ISR, I want it to be ISG.
ISG means creating a route that does not exist, not included in generateStaticParams
it already does that
by default
Somali
ISR is when you add revalidate in order to fetch new data
Every x number of seconds
unless you disable
export const dynamicParams = false, this will disable ISGso all good
West African CrocodileOP
So if I remove export const revalidate = 60;, does that make it an ISG?
Somali
Yes
Well you’re not using that anywhere anyway
Its already ISG with or without revalidate 60....
West African CrocodileOP
Thank you so much! I see!
Somali
He’s talking about ISR though
If i recall ISG means the creationg of a path thats not yet generated
Somali
To be more precise it’d be ISR if he added a revaluation flag right
I mentioned ISG = ISR but that small difference is what I’m pointing out
West African CrocodileOP
If I want to create an ISG
Is this all I need to do?
export default async function MapPage({ params }: PageProps) {Is this all I need to do?
If you want to create an ISG you need to use the variadic routes like
[id] where you can use generateStaticParams()If you want to use ISR then you need to make sure your path is static and has revalidation period or can be revalidated using data cache like
fetch tag inside said routeWhat do you want? ISR or ISG
West African CrocodileOP
ISG
what do you want it to do?
West African CrocodileOP
I just created this as an ISR.
I just want to convert it to ISG.
export const revalidate = 60;
export async function generateStaticParams() {
const mapColRef = collection(db, "maps");
const mapSnapshots = await getDocs(mapColRef);
const mapIds = mapSnapshots.docs.map((doc) => doc.id);
return mapIds.map((mapId) => ({ mapId }));
}
export default async function MapPage({ params }: PageProps) {I just want to convert it to ISG.
@West African Crocodile I just created this as an ISR.
js
export const revalidate = 60;
export async function generateStaticParams() {
const mapColRef = collection(db, "maps");
const mapSnapshots = await getDocs(mapColRef);
const mapIds = mapSnapshots.docs.map((doc) => doc.id);
return mapIds.map((mapId) => ({ mapId }));
}
export default async function MapPage({ params }: PageProps) {
I just want to convert it to ISG.
You dont convert ISR to ISG, they are 2 different things
can you be more specific?
You want to not invalidate the path every 60 second but allow creation of new route?
is that what you want?
West African CrocodileOP
yes,
I want to create a new path and make it ISG.
I want to create a new path and make it ISG.
and you want it to stay forever and not get invalidated?
West African CrocodileOP
Yes. If access does not come after the second time, I want it to be permanent.
what do you mean by "access does not come after the second time"?
you don't want to update the content after it is generated right?
no matter how many times you access it
West African CrocodileOP
I want to update a new page after the second access, retrieving it from a database like firebase.
you want to update after second access? so you want to rerender it at EVERY access? which will refetch new data at every access?
West African CrocodileOP
Hmm. I sure don't want to BUILD with Every access.
you dont want to build the project with every access but you want to refetch at every access
meaning that the components needs to be rerendered every access
am i right?
West African CrocodileOP
I want to update my page when the fiebase data is updated.
you can't update your page when the firebase data is updated. You need to invalidate the data in next.js either by waiting a time period or revalidate it on-demand (for example using a /revalidate route that you call manually after updating firebase data)
Next.js don't listen to data updates
West African CrocodileOP
Thanks! Roger that. I know it was a newbie question, but thanks for taking the time to answer it.
Somali
Alfonsus is a saint
West African CrocodileOP
@West African Crocodile Thanks! Roger that. I know it was a newbie question, but thanks for taking the time to answer it.
its fine, you explained what you want to make it clear, so thanks for the time to explain your case
but we havent reached a conclusion
:v
West African CrocodileOP
Yes, I think so. I don't know what to do.
given that you want the data fresh at every fetch, does that mean you want to fetch to firebase to always get FRESH data at request time?
or are you okay with it being slightly stale you know, like a blogpost, such that if theres an update, you are okay to waiting 1hr or a day for it to update
@West African Crocodile js
export const revalidate = 60;
export async function generateStaticParams() {
const mapColRef = collection(db, "maps");
const mapSnapshots = await getDocs(mapColRef);
const mapIds = mapSnapshots.docs.map((doc) => doc.id);
return mapIds.map((mapId) => ({ mapId }));
}
export default async function MapPage({ params }: PageProps) {
in the case of this, you are okay with your data getting stale for 60 second, and request on 61st second its stillshowing stale data but Next.js will do a background revalidation and regenerate the new data on the BACKGROUND such that on 62nd request or however long it takes to regenerate new data on background, it will show fresh data
but if your website hasn't had any visitor for a while its possible for the fresh data to only appear after, say 500th second
coz theres no one to trigger the background revalidation
yes, the BGRevalidation is triggered by the user not Next.js since Next.js is designed to be serverless. so noone to keep track which data is expired
if its a blogpost i suggest on-demand revalidation, after you update your data in firbase, i call Nextjs /revalidate to update data to be fresh, such that on next request to that route, it will WAIT to fetch new data, not in the background -- it will be awaited
West African CrocodileOP
I want it to be like wikipedia, where many people can participate and edit it. In that case, it's useless to BUILD in 60 seconds every time with ISR,
If you think its useless to render in 60 second everytime with ISR, then I suggest you looking into SSR where the request is rerendered at request time
im not sure how wikipedia works and/or if there is any caching involved inside that platform
@West African Crocodile I want it to be like wikipedia, where many people can participate and edit it. In that case, it's useless to BUILD in 60 seconds every time with ISR,
and you can also set it to 1 second or 2 second
if you keep refreshin it will always show new data lol
so like, can't give you the means how to do it unless you know which rendering method you want to do
West African CrocodileOP
Hmmm. Yes, it seems to be wrong from the design stage.
I'll try using ISR.
I'll try using ISR.
render fresh data at EVERY request?
or
render slightly stale data using pregenerated sites?
or
render slightly stale data using pregenerated sites?
West African CrocodileOP
This <-render slightly stale data using pregenerated sites?
then that means you use ISR, correct
that means you can do revalidate = 60 or 30 or 10 or 1 or 3600
@aardani in the case of this, you are okay with your data getting stale for 60 second, and request on 61st second its stillshowing stale data but Next.js will do a background revalidation and regenerate the new data on the BACKGROUND such that on 62nd request or however long it takes to regenerate new data on background, it will show fresh data
but do note of the disadvantage of ISR
West African CrocodileOP
The disadvantage of ISR is that there are useless updates? Or that they are out of date for a certain amount of time?
theyre out of date for a certain amount of time thats not fixed to 60
IF revalidate = 60 (seconds),
it can show FRESH data at 62, or 65 or 72, or 3600
The more visitor you have, the less this will be a problem
it can show FRESH data at 62, or 65 or 72, or 3600
The more visitor you have, the less this will be a problem
West African CrocodileOP
Thanks for taking the time to explain things to me. I would be happy to repay you in some way someday.
no its already repaid using that gif www
West African CrocodileOP
Sorry. What does this mean? What happens if I don't specify a time?
Theyre out of date for a certain amount of time thats not fixed to 60
if you don't specify a time then it is still ISR, but you only can do On-Demand Revalidation where the Regeneration happens when you call revalidatePath. This will always shows fresh data AFTER its being revalidated
but no Background Revalidation
Somali
If you don’t specify a time it won’t revalidate on 2nd / 3rd.. visit. Only when you use the revalidate tag that is discussed in the article I posted earlier
so without revalidate = 60, you need to revalidate it manually
West African CrocodileOP
For example, if I create a site where the number of pages increases depending on the URL, and I set the ISR to 60 seconds, won't that cause too many rebuilds, resulting in too much load?
yes
it can happen
you can always set it up like this
on article edit,
1. update firebase db
2. call revalidatePath('/articleName')
that way its only updated when the article is edited
on article edit,
1. update firebase db
2. call revalidatePath('/articleName')
that way its only updated when the article is edited
without needing revalidate = 60
basically what wolf said
this is still called ISR since its updating built static pages later