add tag to fetch based on response
Unanswered
Chippiparai posted this in #help-forum
Original message was deleted.
9 Replies
Albacore
I'm bumping this, because OP never received a response and I am encountering a situation where I need this as well, but I don't know if it's possible? Can anyone help?
Next needs to know the tag before the fetch request is made. So I don't think there's a way around that.
You'd have to make the request twice and pass it to the second call, but something tells me that's not good practice.
You'd have to make the request twice and pass it to the second call, but something tells me that's not good practice.

Albacore
Hmmmm. I am wondering why Next needs to know the tag before the fetch is made? I don't know how the internals of this works, but it kind of seems like at least in theory, an implementation could allow us to do something like...
// This code snippet demonstrates a theoretical API that I pulled out of my butt. It does not actually work.
import { asyncTag } from 'next/cache';
const myTag = new asyncTag();
const response = await fetch('/api/stuff', {next: {tags: [myTag, 'other-tag']}});
const responseJson = await response.json();
await myTag.setTag(responseJson.id);
// ... somewhere else...
revalidateTag(id) // id === responseJson.idAlbacore
The reason why I want this is so that I can make two kinds of requests for the same data which both need to be revalidated by a tag later. I can fetch user data by email, or by user ID - but when fetching user by email, I don't know their ID until I receive the user object response, and opposite for fetching by ID, I don't know their email until response. Both types of requests are returning the same data from the same source so when one request is invalidated, the other should be too.
When the user makes updates to their data, I need to invalidate the cache for both requests. I will always have the ID when updating data. So I can
When the user makes updates to their data, I need to invalidate the cache for both requests. I will always have the ID when updating data. So I can
revalidateTag(id). But if I haven't been able to set the tag on those requests made by email, they can't be invalidated this way.Just to understand. Is there a reason why you're trying to cache this type of data? I'm assuming you're building some kind of user dashboard and usually for that use case it's ok to not cache the response you get. That's more important when dealing with marketing websites that may query data from a cms and need to have really fast response times.
And do you have some kind of technical limitation that requires two api endpoints to fetch the same user data?
And do you have some kind of technical limitation that requires two api endpoints to fetch the same user data?
@Albacore Hmmmm. I am wondering why Next needs to know the tag before the fetch is made? I don't know how the internals of this works, but it kind of seems like at least in theory, an implementation could allow us to do something like...
js
// This code snippet demonstrates a theoretical API that I pulled out of my butt. It does not actually work.
import { asyncTag } from 'next/cache';
const myTag = new asyncTag();
const response = await fetch('/api/stuff', {next: {tags: [myTag, 'other-tag']}});
const responseJson = await response.json();
await myTag.setTag(responseJson.id);
// ... somewhere else...
revalidateTag(id) // id === responseJson.id
It's definitely an interesting suggestion. Unfortunately this type of behaviour is controlled by the framework and we can't hack around it. We'd have to wait for the team at Vercel to implement such a feature.
Albacore
It is a SPA-type web app using Sanity. Some pages contain forms for the user to edit and submit data, and other pages process and display it immediately after it's been submitted. Many of the pages depends on the previous information entered, so as soon as it is submitted it needs to be invalidated - but others don't touch it, so it would be more practical to use the cache. I guess turning off caching is an option but we'd like to take advantage of the vercel cache to avoid making unnecessary hits to Sanity.
And do you have some kind of technical limitation that requires two api endpoints to fetch the same user data?Just avoiding making the same request twice when searching by email vs id
Chippiparai
I'm just scratching the surface of how the cache works under the hood, and it makes sense why Next would need to know the tag name(s) ahead of time. Ideally the Vercel team can figure out a way around that to achieve the functionality we're looking for.
However, if those tags truly can't be modified, maybe the answer could be the concept of "Tag Groups". On a dynamic route page, you could conditionally add the tag used to a tag group. Then there would need to be a
However, if those tags truly can't be modified, maybe the answer could be the concept of "Tag Groups". On a dynamic route page, you could conditionally add the tag used to a tag group. Then there would need to be a
revalidateTagGroup function to revalidate by group—this would essentially work the same as calling revalidateTag() for all the tags in the group.// app/[slug]/page.tsx
...
const pageData = fetch(`https://...`, { next: { tags: ['page', `page:${slug}`] } });
if ( pageData.body.find(section => section._type === "recentPosts") {
addTagToTagGroup(`page:${slug}`, "postCollection");
}
...// app/api/revalidate/route.ts
...
if (body._type === "post") {
revalidateTag(`posts`);
revalidateTag(`post:${body.slug}`);
revalidateTagGroup("postCollection");
}
...