A question about SSG cache

[mousedown]

When pre-rendering dynamic pages via getStaticPaths and props, the generated .json is stored , and loaded from a hashed folder. e.g.

.next/server/static/{hash}/pages

With a new deployment, doesn't the build process then create a new set of .json files to be served invalidating cache?

[lfades]

It doesn't invalidate the cache of the old deployment, although if you replace the old deployment with the new one then you'll lose the cache.

[lfades]

That's temporal as we're definitely going to be working on re-using the cache of previously generated pages that didn't change

[mousedown]

Is this feature roadmapped yet?

[chknwaffles]

That's temporal as we're definitely going to be working on re-using the cache of previously generated pages that didn't change

Will this feature be coming sooner than later? Just curious because it would be pretty handy

[mousedown]

Thanks, Ifades. Reusing the cache sounds like a good feature. I'll keep my eyes open for that. I'm still a little confused. Can you elaborate for me please? Sorry, I failed to mention I am using now to deploy. Perhaps i should have asked there.

if you replace the old deployment with the new one then you'll lose the cache

1. I deploy to production using now --prod
2. The build generates 1K product pages via getStaticPaths 🥳
3. These pages are all served from the edge , cached and very fast. No DB reads required.
4. I need to redeploy and do so.

Am I correct to assume, the entire (client) cache is now broken? And any dynamic pages that have not been previously generated as the build (e.g. fallback: true) will need to be generated on the fly again?

[timneutkens]

It's not "broken", it's invalidated if you deploy your application to production, eg you change the data fetching of a page, it has to be invalidated (as expected). Next.js will also automatically force a full refresh when the data can't be loaded on that route anymore, so that ensures the person that is on an old version of your application sees the new version as soon as possible.

So to answer your question, yes the fallback behavior means that if you redeploy the pages that were previously generated have to be re-generated. There's some optimizations that we can do here still like revalidating in the background