VisualEditing's default revalidation strategy is a bit too aggressive

[stianmartinsen]

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]

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 :)