'use cache' unstableCache cacheComponents and their relationship with full route cache and on-demand ISR

[d-plz]

I wanted to use the unstable 'use cache' directives and all the experimental caching for components/functions as I understood it would work the same way that the fetch-extended caching works with the full route cache.

But it seems the unstable directives force export const dynamic = 'auto' instead of allowing export const dynamic = 'force-static the latter being necessary for on-demand generated ISR pages to be "truly" cached both at the function/data level and at the CDN/route level.

Is this expected and normal? or over time we can expect the 'use cache' to synchronize with the full route cache?

The goal here being simple: having the same behavior fetch-caching has with on-demand ISR. Dynamically generating /[slug]/home and caching it both the data and the full route level while invalidating it via tags/path as needed.

[victormoni]

Hi @d-plz

Short answer: that’s expected today.
The current “unstable” use cache APIs turn the segment into dynamic = 'auto', so they can’t be combined with dynamic = 'force-static'. Because the segment is no longer strictly static, you won’t get the same CDN/full-route caching behavior you get with standard fetch caching + ISR. The use cache memoizes function/component results at the data/function layer; it doesn’t yet synchronize 1:1 with the full route (HTML) cache.

What to use right now

If your goal is: “generate /[slug] statically, cache it at both data and full-route level, and invalidate on-demand via tags/path,” prefer the stable path:

1. Keep the route static:

// app/[slug]/page.tsx
export const dynamic = 'force-static'; // or omit and ensure everything is static
export const revalidate = false; // use on-demand instead of time-based ISR

2. Use fetch with cache tags:

const data = await fetch(url, { next: { tags: ['post', slug] } }).then(r => r.json());

3. In a server action or API route, trigger invalidation:

import { revalidateTag, revalidatePath } from 'next/cache';

export async function invalidatePost(slug: string) {
  revalidateTag('post');     // data cache
  revalidatePath(`/${slug}`); // full route cache
}

This combo keeps the page truly static/ISR’d at the edge and lets you refresh both the data cache and the pre-rendered HTML on demand.

When to try use cache

use cache is useful for memoizing expensive computations and composing caches inside components/functions, but it currently implies dynamic = 'auto'. Until it matures, don’t rely on it for ISR-style, CDN-level full-route caching.

Bottom line: For on-demand ISR with tag/path revalidation of both data and HTML, stick to fetch caching + revalidateTag/revalidatePath and a static route. Avoid use cache for this specific use case for now.

[d-plz]

Hey @victormoni yes that has been what I have been doing. You know if there is a more technical reason that prevented this being implemented while unstable? Like different signatures or something making it more difficult to integrate with force-static? Or this has been simply done deliberately since it's unstable as to not mess with full route cache for now?

[victormoni]

Good morning @d-plz

Short answer: it’s mostly deliberate while the API is unstable. use cache/unstable_cache introduces a runtime memoization layer at the function/component level, which can depend on request-time inputs. Because of that, Next has to assume the segment is dynamic: 'auto' instead of “truly static”, so it doesn’t couple it to the CDN/full-route HTML cache yet.

Why that matters technically

1. Determinism & safety. A force-static route must be purely build/prerender-time. Once you allow use cache inside, that cache may depend on things like params, headers, or cookies (directly or indirectly). If Next kept the route static, you could leak personalized data into static HTML or poison the edge cache. Marking it dynamic avoids that risk.

2. Two different cache layers.

Function/data cache (what use cache manages)

Full-route (HTML) cache/CDN (what ISR + revalidatePath/revalidateTag target)
They have different keys, lifecycles, and invalidation semantics. Making them synchronize 1:1 requires dependency tracking across layers to prevent partial invalidation or stampedes.

3. Build vs runtime pipeline. force-static pages are produced during prerender/build. use cache populates at runtime. Mixing them would require warming/serializing function-level entries into the prerendered HTML and keeping those links consistent on invalidation—work that isn’t finalized.

4. Dynamic promotion rules. Next already promotes routes to dynamic when it detects dynamic signals (cookies(), headers(), no-store fetches, etc.). Allowing use cache to coexist with force-static would fight those rules and create surprising behavior.

Net/net: while use cache is unstable, it’s kept separate from ISR-style full-route caching on purpose. For on-demand ISR where you want both the data and the HTML refreshed, stick to a static route + fetch(..., { next: { tags } }) and invalidate with revalidateTag / revalidatePath. Use use cache mainly for memoizing expensive pure computations inside dynamic segments or server actions.

If/when the team lands cross-layer dependency tracking (tags flowing from function cache to route HTML) and a deterministic story for static output, these could converge—but today the separation is by design.