yeah your solution works well and is a popular practice

Seems the case, as there’s not really any way to control the data displayed in a RSC, especially if you use revalidate time tag. It would just overwrite the data

hey @joulev i think I have got myself into a bit of a rabbit hole haha. So up until recently I have been using server components for pretty much everything. Say we had a users component that renders a list of user components (all server-side, takes IDs and renders them etc). I think this idea of having to do something like: Users component (RSC) -> Users component (client component, accepts initial data) -> user component (client component, accepts initial users id but also a id / way to refetch) seems to be making the mental model of the code really complex. Would you say realistically though this is the only way to have fine grained refreshing for the server components?

i think the problem might be more so that i'm constantly thinking about how it should work in my head

Realistically I say that using server components religiously is never a good idea. No one forces you to use server components everywhere. Use client components where it makes sense to.

agreed 👌 Maybe using them at top levels to separate different things out and then anything that relies on stuff inside of them can accept their data as initial data

i'm not sure where I went off this train of thought though

Just think of it like this. If you feel the structure is too weird, bulky, not maintainable, or hard to reason about, you are going the wrong way. Server components are supposed to feel natural. People say server components are better than client components, they are wrong. Server components and client components serve different purposes and should not be force-used in cases where it makes not much sense to

just one last thing if possible, I wanted your opinion on this kind of setup. So I have a blogs page, Blogs RSC that fetches the latest blogs and I want to be able to refetch this specifically whenever I want. So I pass the data as initialData via a prop to a Blogs client component. This then renders out, say, a bunch of other components (that could've been server components that do their own thing, but since we switched to the client we can't do that anymore.) So i'm guessing the most efficient thing to do here would be to fetch the initial data for those other client components too in the initialdata (as part of each 'blogPost' object) and pass them in also as initialData?

Why do you need to refetch blogs regularly? Blogs are not live data, they rarely change – an auto-refreshing blog makes no sense. If you are making a real time feed, use proper real time tech.

blogs is more of an example just because that's what I was working on earlier

also in the case of our platform it is unfortunately. When you have xx,xxx clients waiting for a release haha

i think my main point is just about being able to split out what should be refetched (maybe not even specifically a next.js issue as it could also be the case further down a component tree)

i would just revalidateTag() in the server, then the next incoming request will get the fresh data, that's sufficient for the use case at my company

but if you (1) want fresh data and (2) have deeply nested server component data, you can simply run router.refresh() to get the updated data for server components

just listen to tab focus event, whenever tab focus, router.refresh()

after x seconds, router.refresh()

@joulev There is a weird thing with revalidateTag that people are not taking for granted, https://github.com/vercel/next.js/issues/71612

hopefully the next 15 cache changes fixes this

Currently, Im heavily using revalidateTag in places but I know that whatever tag I use its going to recall the rsc not matter what (feels like using it blindly)

the only side issue i see with this is:

1) server component for latest product, for example
2) say this latest product has changed in between me loading it in and me doing some kind of interaction i.e. reacting to it, thumbs up or whatever and i go ahead and call router.refresh i'm going to get an entirely different product back

so i'm guessing in this case, it would be way better to just be able to refresh just that specific component. And right now, the only way we could do that would be with a client component that takes the data as initial data and then just mutate the api request for the reactions

also calling revalidateTag in the grand scheme of things wouldn't work in a nested component in this case above, since that component could be completely removed with the data changing further up (since router.refresh() just refreshes everything)

i'm not being stupid with thinking that revalidateTag doesn't refresh these components right? you definitely have to call router.refresh after?

hmm i dont understand how it would be a different product?

say for instance the component just fetches the latest product from a database

if we just router.refreshed it when we add a reaction to it, and that latest product has changed you wouldn't even see that your reaction went to it

when you click the reaction, you are supposed to revalidateTag it not router.refresh. router.refresh is for things like auto revalidating on tab focus, after x seconds etc without an explicit user action

i'm just testing this out now... so when I run a revalidateTag, it should re-render that specific server component? (that uses that tag)

well... try it and see

giving it a try now

try giving whatever string inside revalidateTag mate, it'll rerender no matter what

just writing a demo app now

i think i've just misunderstood how it works for the past year 😂

the thing is I get really set on how something works from the get-go (I've been using next since 2017)

How did you think it works ? I wanna learn from you too

the way I figured it worked is it just clears the cache on the backend. I never thought about it interacting with the frontend to re-pull in that data for that specific server component

I always thought to refresh that specific server component you had to refresh all of the server components

revalidateTag purges the cache which tells the rsc to get back with fresh data, what I wanna know is if you try revalidateTag("sometag-that-is-nowhere-added") and see if it still rerenders that component with the fresh data (which it does) hence the issue I've mentioned above.

I would also like to know from your demo is: does it render only the necessary server components or the whole tree ?

i've just hooked in the main component, and it does refresh that component. writing a second one that uses another unique cache tag to see if it refreshes the other one

Which version are you testing on ?

I think of tag as tanstack\s queryKey but for server components and revalidateTag as queryClient.invalidateQuery xd

yeah something weird is going on here

so here's my main page component, it has the two server components in it. Main Test fetches a random user from an API, but cached using unstable_cache for now with a tag. There's also a client button in there that calls a server action that revalidates the tag for the random user api lookup, and re-fetches that data.

secondary component contains some code that throws a Math.random(). This also refreshes everytime i call the revalidatetag

whereas expected behaviour would be that secondary component wouldn't re-render

Yeah, even if you don't add a cache tag it will revalidate weirdly

I like to test it using the fetch's tag attribute instead of unstable_cache

I would expect to not rerender if the tag isn't found

yeah, but furthermore though is it supposed to re-render every server component?

I would like to hear some insights from @joulev too to be honest,
The documentation about revalidateTag doesn't map with how it works currently

- Will purge the client-side cache, depending on which path was provided. In case of revalidateTag the entire client-side Router Cache is purged.

but that just doesn't work for deeply nested server components

I'm confused

i think the best way I have found to do this (being able to refresh individual component data) is to have them as client components, pass them initial data from the server component and set the state on prop change. Then, we can use react-query or useSWR to set the state locally. It would definitely be an antipattern otherwise, but because of the usecase of modifying that state without refetching everything is important this is one of the only ways to do it

that way also, even if we have client components further down that should be able to re-fetch data, we can do the same thing again (update the state on prop change, or fetch it in SWR)

Yeah thats one way to go, It just doesnt feel right to always prefetch and pass the data to react query every time

I mean it sounds the right thing but I feel like it adds more code

If only someone from nextjs here would explain how does revalidateTag works and does it refetch only the necessary stuff or the whole tree

after reading this too @Korat it says partial pre-rendering is the way to go but i don’t get how you would refresh that either

thats what revalidatePath/tag are for, but we agree that currently its not working as excepted?

well currently revalidateTag refreshes all the server components, not just the ones that use that tag in them

yeah, sad that the apps Ive worked on uses it heavily but we havent seen any performance downgrades

I mean whats the point of caching when revalidateTag just refetches everything?

yeah totally agree. Maybe need to explore more about PPR though

i’ve seen it mentioned a few times now

That is still experimental afaik

Even in nextjs 15 this issue happens

@Argentine ant Actually, I might be wrong, in Next 15 the revalidateTag from actions is working as expected, I can see running just the cached component that corresponds with the tag

i tested on 15.0.1 and it refreshed both components

one of the components is uncached, the other is cached with a tag - revalidating the tag causes both of the functions to re-render

then again this was using unstable_cache

maybe they don’t like that now and have to try the new use cache directive

Yeah, Im assuming its because the other one is uncached, hence its going to rerender everytime page is called

yeah but even so this doesn’t sound like intended behaviour on the front end - surely when you call revalidateTag it should be able to re-render the RSCs using that tag

rather than just refreshing everything

I am pretty sure revalidateTag isnt refreshing everything as we might think, its only going to revalidate the cached data.

Performance wise, I think they've thought this through and I believe they do the best calculations possible for the best performance

i’ll show my code in a sec, it’s definitely re-rendering all the components in the page

to verify this is the case with revalidateTag, let's say we have one function in unstable_cache that returns the time it was last fetched (if it's cached, it will be that time in the past). Let's also create another server component that renders out the current time. When we do a revalidateTag, we'd expect the data for the tag to refresh and that RSC to update only

@Cuban Crocodile and here it is

sorry, wrong tag

Yeah, this is weird and not explainable

yeah, all clicking revalidateTag does is call revalidateTag with the tag for RSC 1 in a server action

what's interesting though is if you look at usequerystate

i'm not entirely sure how they do it under the hood, but it can refresh server components just for the components that use it

you mean nuqs ?

yeah

what i mean in particular is if you use the searchParam from nuqs in a server component elsewhere with the shallow option set to false, it only re-renders that component

i'm not entirely sure what magic is involved there however

Im also a bit worried why my issue in github is opened for days without any feedback, when I mention it here in discord helpers tend to ignore this, isn't this what makes Next Next

yeah it is a little strange. There's also some mystification about server action executions. Like we're not telling it to do any refreshing of server components, so is that configurable

Im tempted to tag joulev once more but i dont wanna disturb him lol

I was so confused

my bad 😢

if you don't want to be further confused i wouldn't recommend reading up haha

What's the tldr

revalidateTag when used in a server component refreshes all RSCs currently

which is not great in highly dynamic components haha

and as @Korat said if you don't pass anything, it'll just refresh everything too

either revalidateTag doesn't work correctly and its an issue, or I'm stupid

so i think the underlying issue is revalidateTag just refreshes everything haha

it just doesn't make much sense to me, like this caching strategy would only work for non-nested server component realistically

Yeah, tbh we could just prefetch and useSuspenseQuery in client if tanstack is something you use, but since we are using next, in some cases I'd like to depend on next's cache too but this is a no go.

And I can't really start refactoring from revalidateTag to that strategy above.

The ideal thing would be for revalidateTag to work as we mentioned above

the issue i see with this is you're switching into the client boundary when you could still be in the server boundary

so you can't use anymore server components from that point onwards, which would just add complexity

furthermore to this, you could even have to set your first component in your page as a client component if you want to control when that refreshes. Then every child component in that would have to re-render. and if you want to pass each of those initial data, you have to fetch all of that in your first request (increasing ttfb etc)

just seems crazy

yeah just move to vitejs & tanstack router at that point

it's basically a case of like, in useSWR on the client you can mutate a specific key

we need to be able to do that from a server action in next.js

so it just refetches whatever is using that key

I'm a bit overwhelemed because all internal projects are build on top of a nextjs starter that I created pushing the use of revalidateTag, just to find out a week ago that revalidateTag("whateverheredoesn'tmatter") recalls everything which probably is bad for performance.

Still Im talking without knowing if this is intended, that's why an insight from the helpers in this channel would be nice at this point

agreed

i'm not that concerned about the performance really, it's just the UX for this would suck. Imaginge you're editing some user attribute on a user, like a checkbox on a user. Say this user is a server component too, since it would be so easily to just say revalidateTag(dashboard:users:user-{id}) and it would just refresh that result. But currently, it would refresh everything, and say that the cache revalidated (maybe by time revalidation?) you might not even have that user in-view anymore

Why do you mean by "you might not even have that user in-view anymore"

say that you edited the user from a server component that was rendered by a parent server component that fetches users

if the cache for that top-level server component revalidates and that child server component isn't even in the list anymore for example

I cant find a real case scenario with what you are taking as an example

here i'll give one. So you have an admin dashboard.

Users RSC
-- [Array of users]
-- User RSC <-- you do something here, you want to revalidate just this RSC.

if Users RSC updates, and by chance the data has changed to not return the same way and that User RSC is no longer in that list, I have to go and find that user again in the users RSC

oh wait... @Korat

now this is interesting

that value on the bottom is rendered in the page, outside of all the server components

this makes more sense

mind showing the code?

yeah one sec

here

it seems like it's supposed to do it :/

Okay hear me out, I played a bit with some code with next 15.0.3

If component isn't marked with 'use cache' and cacheTag it will be refetched everytime revalidateTag is called (as docs say this is useful for highly dynamic dashboards).

If component is marked with 'use cache' and cacheTag it will respond only when revalidateTag("withThatTag") is called an no other time.

We can think of 'use cache' as the queryKey from tanstack query, every useQueryFn has a unique queryKey, same in server components, we should mark every component that we want to have ownership on with a cacheTag in order to revalidate just that component.

But still to note that if a component isnt marked with 'usecash', it'll revalidate when revalidateTag is called (this one I don't like but it is what is is).

yeah i thought about this approach, only way this would work though is those components would have to have a unique suffix passed into them on-top if that makes sense.

a persistent, user-tied value

since again if you have your users that revalidate on a time interval even though it uses a cache key it still would refresh (i think)

what's really weird is if you have a value just in the page level, it wont refresh

only the server components do

you mean a value coming from an api ?

so say we're comparing the key here to a key you'd pass to useSWR to refetch (client-side mutation, so it's always unique to the user)

we'd need to generate a key or something that gets saved as a cookie or something (maybe via middleware) to use in cache keys

we can use cacheTag ?

which is unstable at moment

unstable_cacheTag

wait, im not following you

yeah, but with cacheTag - if you just give it a value of dashboard:users and that revalidates by means of someone else revalidating it or the time revalidation has passed, it would still have the same issue whenever you call revalidateTag

so i think the way to get around it would be to cache it uniquely for that user, so say i generate a random value that identifies me in middleware, my key could become:

1ab-2cb-3bd-:dashboard:users

then, we have to manage refreshing that ourselves, we can't do time-based revalidation etc

all because revalidateTag will refetch it

requests are isolated ?

sorry, I feel like you are talking about another issue now while I was trying to figure out how revalidateTag works hahaha.

If you don't mind repeating, what problem are you addressing now ?

haha I was just talking about your strategy of setting a cache key on the other components but that also has its issues too

i think the general idea here is when you call revalidateTag, it shouldn't basically call router.refresh() under the hood

what issues might that introduce ?

if the data is revalidated using time based revalidation / someone else revalidates it

it would still refetch that

I wouldn't say so, each incoming request is handled independently on the server. every manipualtion is scoped to that specific request.

yea but what i'm saying is if the data revalidates outside of you doing it (i.e. time based, e.g. 30 seconds, or something else causes it to revalidate), when you trigger your revalidateTag() on a completely unrelated tag it would refresh that component too

I mean, I would want to see the fresh data in this case, not an issue

yeah but when you go back to this concept:

Users RSC
-- [Array of users]
-- User RSC <-- you do something here, you want to revalidate just this RSC.

that wouldn't work

In this case, I would cacheTag("users") and cacheTag("user-1") and revalidate just user-1 ? no ?

yeah, but like i said if the data for users has revalidated too it's just going to refresh that too

Just got a badge for being talkative lol

haha we have talked about this for a while

your turn

i just don't want to have to move this kind of logic to a client component when it doesn't have to be

yeah I would expect that 🤔

yeah but we should have the ability to say what we want refreshed (by calling revalidateTag explicility in this context)

we should be able to say, refresh the component for the user only. Not the users (even if the data has changed)

because we haven't explicity asked for a refresh of any of that

Oo wait wait

In this case, I would cacheTag("users") and cacheTag("user-1") and revalidate just user-1 ?

This doesn't revalidate users

yeah but remember in this case, if that data has changed and revalidated elsewhere it's going to refresh anyways as soon as we call the revalidate on user-1

A bit late now, lemme try something fast

Yeahh, fkk its doing the way you described it

i think we just need to bow out and say anything that requires a use-case like that needs to switch to react-query / useSWR 🫡

save our sanity haha

and even that, without passing initial data, is better than frontloading all of that into the RSC to pass down as props for "initialData"

where we can't do any of the benefits RSCs are made for, like streaming that haha

Leaving it here for any nextjs hero to save us hahaha

As you can see, I previously edited the device name and deleted the interval, when revalidateTag is clicked, both changed even though the button has this revalidateTage(device-${id}-intervals)

For future readers, dont scroll up please

i think the TLDR for people who see this one is:

- Use server components where it makes sense, i.e. as a general container that you don't mind not being able to re-fresh the data on its own
- as soon as you need the functionality to control the data fetching for it, switch to client components and pass whatever initialData is critical to be displayed as-if it came from the server component (again, down the component tree)

I also think a way that's helping me visualise this is to have your components laid out in the way they render too, i.e have a server folder that renders out the component and then a client folder inside of those with the client components for those specific components

helps you keep it organised haha

feature based structure instead of type was a hot discussion a last month xD

Can't wait for 'use cache' and cacheTag to get stable.
I think it helps more when deciding what to cache and how to revalidate based on some testings I did this morning.

i think what we need is just a way to say hey server component x, revalidate

not revalidate absolutely everything

and since we can do that for all components already, surely being able to find components with a specific tag should work

it would mean we can move a lot of logic out of client components

@joulev just wanted to check in with you to see if this is something that doesn’t exist as far as you’re aware?

sorry, i am not following this conversation at all so have no idea what you all are talking about. what is your question? what doesn't exist?

hey no worries. So we’re talking about revalidateTag and how it refreshes all server components

when called in a server action

ive only used revalidateTag in the context where it would change something in the page, so making revalidateTag not revalidate the page is something ive never done before

i think it’s more of an issue when you have nested RSCs

but i suppose you can just not use a server action and use a route handler instead

revalidateTag running inside route handlers will not refresh anything, it will only update the UI for new requests

yeah, only issue there is you can’t tell next to refetch the data just for that one server component still

i think what would be good is the ability to tag a server component, and you can control when that server component should refresh

i think with streaming we should be able to tell next to refresh just a specific component, not absolutely everything

well this works for me

import { revalidateTag, unstable_cache } from "next/cache";

const getData = unstable_cache(async () => new Date().toISOString());
const getDataTagged = unstable_cache(async () => new Date().toISOString(), [], {
  tags: ["tag"],
});

async function Data() {
  const data = await getData();
  return <div>Should not change: {data}</div>;
}

async function DataTagged() {
  const data = await getDataTagged();
  return <div>Should change: {data}</div>;
}

function Revalidate() {
  return (
    <form
      action={async () => {
        "use server";
        revalidateTag("tag");
      }}
    >
      <button type="submit">Revalidate</button>
    </form>
  );
}

export default function Page() {
  return (
    <div>
      <Data />
      <DataTagged />
      <Revalidate />
    </div>
  );
}

cc @Korat

add a expiry to the other one and let it expire, then call revalidateTag

what expiry?

in your getData one, set it to expire after 30 seconds for example

then wait it out and when you call revalidateTag that will also change

well yeah because... it has expired?

if you dont want it to have expired, you need to tell nextjs it hasnt expired

here’s an example of where this doesn’t work.
Users RSC
-- [Array of users]
-- User RSC <-- you do something here, you want to revalidate just this RSC.

nextjs works like this:
* whenever it gets a revalidation request, it will try to revalidate the page
* since the data may change, the whole content of the page may change, so all other data and the resulting html needs to be recomputed. this is by design and i can't see how you can "fix" this, it's not theoretically possible
* when nextjs encounters a cached data block (e.g. by fetch or unstable_cache) it determines whether it is stale, if not it gets data from the cache, if stale that one gets recomputed too

your users RSC fetches an array of user IDs that render out a User server component, taking in the UserID as a prop to fetch those users

if we change something in one of those user RSCs, and the User RSC has changed i.e it’s the first page of users, 10 new users have signed up or whatever

the way that would be ideal is to revalidateTag the specific user so it can refetch

but if that data that’s tagged in the Users RSC has changed, that user RSC wouldn’t even be in that view anymore

then tag the list of user IDs instead of revalidate: 30 it

then if you don't revalidateTag that list it will not change

no matter how many users have signed up in the meantime

Is this bad for performance if there are other components that will rerender but don't have changes ?

while if you properly revalidateTag(userlist) when users sign up, new requests to that page will still see the updated user list

that is why you need to properly cache components to ensure they don't get recomputed

if you just do

function Component() {
  const data = new Date().toISOString()
}

it will be recomputed, but if you put it inside a unstable_cache it won't be recomputed

the data variable will be served from the cache. computing the html from the data variable is extremely fast and is not bad for performance

but only when you want to, with revalidateTag ?

So if someone signs up, the data in that component would be revalidated anyways? so when you call revalidateTag on that individual user RSC it’s going to still refresh?

when someone signs up, it's in a separate session so the user list you are seeing will not receive any changes

the user list you are seeing only receives changes when you explicitly revalidate it by revalidateTag(userlist)

yeah, but when you call revalidateTag for that individual component it is going to refresh it too

you don't do it when you hit the heart button so the user list remains stale as you wish

because the tag has been revalidated

Here let me type out an actual scenario.

I am on the dashboard. I have my Users component that computes the last 10 users who signed up. This renders out 10 individual RSCs for those users. Inside of those individual RSCs, i have a checkbox that sets a boolean for example in the backend. I revalidate that individual RSC, but in the time i’ve taken to do that 10 more users have signed up, thus invalidating my parent RSC, so causing a re-render and re-computation of all of the user IDs, so my individual RSCs have been replaced with totally different ones

to solve that we should be able to tag a component and say hey, we just want to rerender this component

or would it be best to just call it a day and turn the child RSCs into client components and they can refetch their own data

well with the time i have, im unable to find a satisfactory answer to this question

yeah it’s kind of a weird one haha

because you get all the benefits of having them as RSCs like streaming them in

but then you can’t revalidate just those easily

if im understanding @bradley correctly, this is the usecase we are talking.

Why should the tag devices-8 revalidate all the other devices (if changed before the time revalidate tag has been clicked)

@Argentine ant correct me if im wrong

I think I found a mistake in the code, I changed to this and it seems to work correctly @Argentine ant

I moved the fetches into separate functions and cached them there.

are you revaldiating the other one elsewhere first to test?