Definitions

What is Incremental Static Regeneration

• Closely related to SSG and pages that are revalidated either at build time or at runtime.
• Lets you update static content without having to rebuild your entire site.
• Reduces server load by serving most requests with pre-rendered static pages.
• Automatically applies proper cache-control headers to pages.
• The value specified in revalidate will automatically be applied to any fetch calls in the page as the cache-control revalidate value.
• ⚠️ However, if you set fetch to use the force-cache option, the automatic setting is ignored. In that case, you need to manually specify the revalidate option.
• Lets you handle large numbers of pages without incurring a long next build time.
• If you add generateStaticParams, then dynamicParams is automatically set to true.
• During the build, only the pages for parameters defined in generateStaticParams are generated.
• If a request comes in at runtime with a parameter that wasn't included in generateStaticParams, the page will be generated at that time and revalidation will be applied.

🔗 References:

• Next.js Docs - ISR
• Next.js Docs - revalidate
• Next.js Docs - dynamicParams

What are Intercepting Routes?

• Designed to dynamically load content.
• Allows you to show new content without leaving the current layout or navigating to a different route.
• Because of that, Intercepting Routes cannot be used with ISR.

🔗 Reference:

• Next.js Docs - Intercepting Routes

How Does Next.js Handle Caching?

Caching Types

Next.js has different caching layers:

• Persistent (but revalidatable) server-based caches include the Full Route Cache and the Data Cache.
• However, the Full Route Cache requires storing HTML and RSC payloads. That means it is generally used when an actual route can be cached, like with SSG or ISR.
• So if you want to cache responses in a way similar to SSG/ISR (for incoming requests), your only option is the Data Cache.

🔗 Reference:

• Next.js Docs - Caching

The Question

Can we make an Intercepting Route behave like ISR?
• Is it possible to use ISR for Intercepting Routes?
As noted above, Intercepting Routes only alter the address within the current layout rather than serving an entirely separate page route. Therefore, they cannot be cached as an ISR page.

• What does "behave like ISR" really mean?
In many cases, it means:

1. Caching data as much as possible.
2. Using the latest data after a specified interval. Let's look into how we can address these requirements.

The Core Issues to Solve

1. Caching data as much as possible**

Revisiting the available caches in Next.js, we can categorize them by storage location and lifespan:

1. Server + Persistent (revalidatable)
• Full Route Cache
• Data Cache

2. Server + Within a single request
• Request Memoization

3. Client-Side
• Router Cache

The caches that live on the server and can persist across multiple requests are Full Route Cache and Data Cache. However, because Full Route Cache stores the HTML/RSC for entire pages (as with SSG/ISR), that option isn't suitable for Intercepting Routes.

That leaves the Data Cache as our tool of choice.

2. Using fresh data at a specified interval

To leverage Data Cache, you can use the fetch option in Next.js:

fetch('url', {
  cache: 'force-cache',
  next: {
    revalidate: 86400, // 1 day in seconds
  },
});

Here, you set the cache behavior to force-cache, and specify a revalidate interval (in seconds) within the next property. This allows Next.js to revalidate your data cache at the given interval, effectively mimicking the "ISR-like" behavior of periodically refreshing your data - without actually using a separate ISR route.

🔗 Reference:

• Next.js Docs - Caching

That's how you can approximate ISR-like caching and revalidation for Intercepting Routes. While you can't truly make them into ISR pages, you can still benefit from Next.js's Data Cache to cache and periodically refresh the data used within those routes.