Next.js App Router: Static Build with On-Demand ISR — Force-Static vs Dynamic?
Unanswered
German Shorthaired Pointer posted this in #help-forum
German Shorthaired PointerOP
I want my Next.js App Router page to be static at build time but support on-demand revalidation (not automatic every N seconds).
Can force-static be used with ISR, or does the page have to be dynamic? When I run npm run build, the pages show as dynamic unless I use force-static. Basically I want static build and then the option to revalidate paths on demand and let Next rebuild those pages. What I don't want at all is SSR/dynamic all the time.
Update: I’m now suspecting the culprit is Supabase. I use the sever client and it uses cookies. Would I bypass this problem is I use the browser client instead? Or what’s the standard practice here?
Can force-static be used with ISR, or does the page have to be dynamic? When I run npm run build, the pages show as dynamic unless I use force-static. Basically I want static build and then the option to revalidate paths on demand and let Next rebuild those pages. What I don't want at all is SSR/dynamic all the time.
Update: I’m now suspecting the culprit is Supabase. I use the sever client and it uses cookies. Would I bypass this problem is I use the browser client instead? Or what’s the standard practice here?
5 Replies
Cinnamon Teal
No, the page doesn't need to be dynamic for ISR to work. You can have your pages built as static pages at build time and then revalidate them on demand using
By default routes are static, so if the output shows them as dynamic that means you must be using some runtime APIs. If you force the routes to be static they will mostly be undefined. Maybe you have already checked that and that's what you want, but thought it was worth noting.
revalidatePath or revalidateTag.Can force-static be used with ISRYeah, you can. https://nextjs.org/docs/app/api-reference/file-conventions/route-segment-config
By default routes are static, so if the output shows them as dynamic that means you must be using some runtime APIs. If you force the routes to be static they will mostly be undefined. Maybe you have already checked that and that's what you want, but thought it was worth noting.
@Cinnamon Teal No, the page doesn't need to be dynamic for ISR to work. You can have your pages built as static pages at build time and then revalidate them on demand using `revalidatePath` or `revalidateTag`.
> Can force-static be used with ISR
Yeah, you can. https://nextjs.org/docs/app/api-reference/file-conventions/route-segment-config
By default routes are static, so if the output shows them as dynamic that means you must be using some runtime APIs. If you force the routes to be static they will mostly be undefined. Maybe you have already checked that and that's what you want, but thought it was worth noting.
German Shorthaired PointerOP
What do you mean undefined, like they won’t be generated?
Btw I updated the description text that I use Supabase which might be the issue. Would it work if I just use the browser client instead?
Thanks for the help btw! 💪
Btw I updated the description text that I use Supabase which might be the issue. Would it work if I just use the browser client instead?
Thanks for the help btw! 💪
Cinnamon Teal
What do you mean undefined, like they won’t be generated?Runtime API's like
cookies, searchParams need a request to hit the server containing those data. Initially at build time those won't be available. https://nextjs.org/docs/app/guides/caching#dynamic-renderingundefined was quoted from the doc that I linked above, as I have never forced a route to be static, so I don't have the experience with what happens in that case.which might be the issueWhat is the issue here? The routes becoming dynamic? If so, that is the expected behavior as I mentioned above.
cookie is a runtime value so the route becomes dynamic automatically.Would it work if I just use the browser client insteadWhat are you sending in the cookie to Supabase? Is that a auth cookie? If so I don't think changing the client will have any effect as the auth cookie will need be sent on each request either way. But I haven't used Supabase client, so I am not familiar with the actual setup. I am just speaking in general.
Also if you opted to use the browser version of the Supabase client, you will be fetching data in the client. So your initial HTML won't have the data like you currently have with the server side client fetching the data.
German Shorthaired PointerOP
The data is ”public” it’s a list of tools that are published and visible to public. I think I can use the browser version, I will try that. Thanks a lot for the input it was really helpful!
Cinnamon Teal
The data is ”public” it’s a list of tools that are published and visible to public.So your site is not behind any authentication? If so what's the cookie for?
Also I personally would use the server client and do any data fetching inside server components by using it.