revalidatePath vs revalidateTag for clearing either full router cache or data cache?

[bitttttten]

We have a page.tsx file which calls a function that has a tag. Let's say:

// app/hello-world/page.tsx
export default function Page() {
    const response = await fetch('/some-url', { next: { revalidate: 360, tags: ['some-url'] } })
    const json = await response.json()

    return <h1>{json.message}</h1>
}

If we were to call

revalidatePath("/hello-world")

Does it also invalidate the data cache for the "some-url" tag? Or would we also need to run

revalidateTag("some-url")
revalidatePath("/hello-world")

The docs mention "Using revalidatePath invalidates only the specific path in the server-side Route Cache.") from https://nextjs.org/docs/app/api-reference/functions/revalidatePath, however at the bottom of the docs it also mentions:

Revalidating All Data
import { revalidatePath } from 'next/cache'
revalidatePath('/', 'layout')
This will purge the Client-side Router Cache, and revalidate the Data Cache on the next page visit.

The important part being "..and revalidate the Data Cache".

So maybe I am not totally understanding but I don't quite follow it. We don't do any data caching in the "layout" file, so how come passing in "layout" as the type now also clears the data cache?

[Juneezee]

We don't do any data caching in the "layout" file, so how come passing in "layout" as the type now also clears the data cache?

The layout doesn't mean the data cache in your layout.tsx file. It means pages beneath with the same layout ¹

Footnotes

1. https://nextjs.org/docs/app/api-reference/functions/revalidatePath#revalidating-a-layout-path ↩

[bitttttten]

Gotcha, but revalidatePath('/', 'layout') will purge the Client-side Router Cache, and revalidate the Data Cache on the next page visit.

[icyJoseph]

If you wanted to make sure data remained consistent across all pages, you'd need to call both:

revalidateTag("some-url")
revalidatePath("/hello-world")

Only calling revalidatePath, would re-render the page on next visit, with fresh data, but it wouldn't schedule other paths usign the tags contained with revalidated path.

I feel like relying on knowing which cache does what, for devs using the framework is often not that ideal, and can lead to this kind of confusion.

I guess it is also fair to ask, well, then why don't we just tag data and revalidate it, to prevent this pitfalls.

For that we have to think of a page with many tags, then we'd need to call all of those tags, to ensure the page is fully revalidated. Revalidating a single tag in a page that uses several, is also a vato olid use case.

Also tags, could be user generated, right, or be part of a library/dependency, and we wouldn't necessarily know their values.

As you can see, these are rather complementary to each other.