Understanding revalidatePath vs current documentation #81385
Replies: 3 comments 13 replies
-
|
Hi!
About your example: Summary:
Hope this clears things up! Let me know if you have more questions or want to discuss in more detail. |
Beta Was this translation helpful? Give feedback.
-
|
I agree, their docs really need some clarification. It doesnt help that cache works different out of box in 14 and 15 version. |
Beta Was this translation helpful? Give feedback.
-
|
The key to understanding this is knowing that Next.js uses two separate caches that are affected here: The Data Cache (Server-Side): This is a cache that lives on the server. It stores the result of your fetch requests and the rendered HTML of your pages. This is the cache the docs are primarily talking about when they say "invalidates the cache when the included path is next visited." The Router Cache (Client-Side): This is a cache that lives in the user's browser. It stores the pages the user has already visited so that navigating back and forth is instantaneous. When you call revalidatePath() from a Server Action, it interacts with both of these caches. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I was trying to understand
revalidatePathbut current docs seem a bit confusing to me, here it is:To which cache does the first bullet apply? It does not say. Is it client side router cache? If yes, then next bullet is confusing because it says that all routes are invalidated. Or is it full route cache? What about data cache?
Because I got confused in the following example when I call
deleteItemserver function, the data gets refreshed immediately.But the docs above say after it is next visited. So I was not expecting it to get refreshed immediately. So which part of above quote explains this behavior?
Example:
@icyJoseph
Beta Was this translation helpful? Give feedback.
All reactions