revalidate tag does not rerender the entire route

if it did there wouldnt be much point of the the separation of those functions 😉

revalidate path does

They both invalidate the caches so the routes have to be rerendered after they refetch the data

I believe

you arent thinking deep enough. The docs cannot explain every possible scenario, and use top level fetches in pages as the example

additionally, ISR addresses a significant portion.

so how much it re-renders is fully dependent on how well you create your branch/leaf structure

ISR involves rerendering the routes at some interval or when the caches are invalidated which revalidateTag/Path does

ISR has nothing to do with intervals

you may choose to trigger ISR at an interval

but it itself has no concept of an interval

Yeah thats what I mean

then… what is the question lol

ISR doesn't help make revalidateTag/path more efficient

if you fetch in a server component that is nested, and you invalidate that tag, your page is only going to rerender that component

i do it in many components across many sites.

Wouldn't it need to rerender the whole route on the server to make a new entry for the Full Route Cache? (for static routes)

If i was building a static site i wouldnt be using nextjs

the primary benefit of nextjs is SSR.

SSR involves static routes

and static rendering

sigh

ok ill let you argue with someone else. i came in here to answer your question not debate nonsense

You didn't answer my question of why it is not slower than just getting pure json data

For example, it would need to rerender the whole route because it needs to be sent to the client no?

revalidateTag/Path invalidates the Router cache so all the RSC Payload is gone

client = call for everyone every time. cache is scoped to user.
server = call for everyone 1 time. cache is scoped to application.

if SPA stood for single person app yes it would be faster. But as a single page app, it is slower by scale.

RevalidateTag/Path would invalidate the cache

jesus. christ.

I'm listening but I think you are giving me the wrong info tbh

you arent listening at all

you have already decided what you think is right

and are dismissing literally everything else that doesnt fit what you have decided

Tell me where I'm wrong

at the beginning

if you have a page. and that page has data. and that data is cached for 1 day.

and 100 people go to it

it renders very quickly

except for the first person

then revalidate is called

the first person it is slow again

then it is fast for everyone again

because the cache is server side

revalidating has nothing to do with the client

the client gets a changed result, but is not the target

What if the data is personalised?

what does that matter

There is only the first person and no other person

the point of the cache is for subsequent calls

if you are going to show them new data every time why are you caching to begin with

Right you wouldn't even need to call revalidatePath/Tag

But it is still slower than the tradtional spa?

what are you talking about

how is it slower if you arent using it

are you conflating server fetching with server actions? they are not the same thing

So if you aren't caching data, the route uses dynamic rendering. Every time a user wants to create a new item, you would use a server action to create the item and then send back the new data.

no

well

depends

you can do it multiple ways.

the benefit of a server action in that specific case is the privacy of access to the data

creating a new todo means storing something in a database which the client shouldnt have access to.

So you would use a server action then?

to click create? yep. i wouldnt cache tho

not if the entire premise is live data

For example, I'm thinking about a user's todo. It is static data until they create/delete/update a todo

it is not faster to be pure json.

Why not?

because the user may look at their todos more than once ever in their life without modifying their todos

Yes that makes sense

this has literally nothing to do with the conversation.

and you are going to immediately make it veer off track

ok

to open and shut that irrelevant door, that would still be server side. He is trying to grasp why calling server at all is better than client.

i was under the assumption that we were thinking about server side calls

from here

this thread alone may have used all the patience i have for the day

Server actions by itself would be slower than just getting json data but I guess the caching nextjs does makes everything else faster

you shouldnt be using server actions just to get json data in the first place

thats not what they are for

I know, they receive RSC payload when they renreder the server components but if it could just get json data while keeping the benefit of the caching on the serverside, it would be faster

what

RSC payload is irrelevant here

@Palomino traditionally, what you do is fetch your JSON data from the frontend and have an api handler that returns this data
With a server action, you basically mitigate this, and return the data directly in the same step

there is no separation of "fetching" and "providing" if that makes sense

still no

damn 💔

if you are just fetching data it should be done directly in a server compnent

no server action needed

at all

OK

let me clarify

sorry

include a database in there

still no

What don't you understand?

you still fetch it in a server component,

How that sentence had any relevance or accuracy at all

no as in, in an SPA you'd have the api handler GET() call db.get(query) and return (json data), and on the client side return the fetched json

whereas with server action you don't need fetch

just call db.get directly

and use that data

at least that's my understanding of use case

thats not true

you are calling post

just like with an api route

ok i give up i should actually leave

my bad

server actions are simply purpose built slimmed down and isolated route handlers.

yeah sorry my bad

with the caviat that they are meant for MUTATION based api calls

Server actions (revalidatePath):
1. client makes request to server
2. update DB
3. invalidate cache
4. Turn server components to RSC Payload
5. Respond with RSC to client
yes?

no

4 and 5 are wrong

and for extreme clarity, 2 and 3 arent server actions either

they are just things you may call in one

Ok what is your version?

its not my version

its just how they work

Like give me your step by step of how server actions work

you need to read the docs

I have read it

It doesn't say

Can you specify?

section

massive main section

not 20% of the way down

i think you skimmed it

This isn't relevant?

re word this or my patience is gone and someone else can baby step you through this.

This isn't relevant.

Ill leave you with a thought. When you want to learn something, its smarter ask questions than make statements, as argumentative, stubborn, and ignorant of the topic all at once wont get many people to help you.

Thanks for explaning how it is relevant