Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VisualEditing's default revalidation strategy is a bit too aggressive #1649

Open
stianmartinsen opened this issue Aug 19, 2024 · 1 comment

Comments

@stianmartinsen
Copy link

Describe the bug

Not exactly a bug, but I'm a little bit confused by how VisualEditing in next-sanity handles revalidation when mutations happen in Sanity Studio.

When setting up Visual Editing following the Visual Editing with Next.js App Router and Sanity Studio guide, Vercel's data cache is completely purged every time a mutation happens in the studio while using the Presentation tool. This happens because VisualEditing's default refresh strategy (if no loaders are set up in live mode) is to revalidate the root layout.

Expected behavior

The Vercel data cache for the published documents in Sanity should not be purged every time an editor edits a draft in Sanity's Presentation mode.

Possible workaround

  1. Add tags: ['preview'] to the sanity fetch while in draft mode
  2. Add a custom refresh property to the VisualEditing component:
{draftMode().isEnabled && (
  <VisualEditing
    refresh={async () => {
      'use server';
      revalidateTag('preview');
    }}
  />
)}

Maybe this just needs to be a bit clearer in the readme (and in the guide), but I would love it if the next-sanity package just handled this behind the scenes automatically.

@stipsan
Copy link
Member

stipsan commented Oct 15, 2024

I would love it if the next-sanity package just handled this behind the scenes automatically

Stay tuned ;) We're working on a new API that sets tags for you under the hood :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants