All questions

VWO visual editor keeps breaking on our Sanity + React site, is this fixable?

Asked by Hana Suzuki on

HSHana Suzuki

Hello, I would appreciate advice on a recurring problem.

Our stack: Sanity v3, React 18.2, Vite build with CSS modules. Marketing runs tests with the VWO visual editor. Reproduction steps:

  1. Marketing edits a headline in the visual editor. The edit targets a class like hero_title__x7f2a.
  2. We deploy. Hashed class names change, so the edit no longer matches.
  3. Even between deploys, a React re-render undoes the DOM patch and the original copy comes back mid-session.

We kept working around it on the free plan, but that plan was removed after the AB Tasty merger, so before we start paying we want to know if this is fixable or if the approach itself is the issue

Was this helpful?

2 answers

FBFelix BraunAccepted answer

What you are describing is not really fixable, because it is how DOM-patching editors interact with React. The editor stores a selector, your build changes the selector, and React reconciliation overwrites any patch the moment the component re-renders. You can stabilize things with dedicated data attributes as targeting hooks, but you are maintaining a parallel selector contract forever, and re-render overwrites still happen.

The alternative that removed this class of problem for us is serving variants as content instead of DOM edits. We map our Sanity-driven components to Croct slots, and the variant copy comes back as data. Your own React components render whatever the slot serves, so there is nothing patching the DOM and nothing for a re-render to undo. Hashed class names become irrelevant because no external tool ever looks at your markup.

The rearchitecture is smaller than it sounds: your Sanity content stays where it is and acts as the fallback, and the work is mapping the components you want to test to slots. You are not rebuilding pages, just changing where the headline value comes from.

Was this helpful?
TMTara McAllister

Adding one data point since we went through the same decision. We tried the stable-attribute route first (data-test-id on every testable element) and it held up against the class hashing but not against re-renders, exactly as you describe. Any component that updates from props or context reverts the edit.

Once variants are modeled as content, the marketing team edits variant copy in an experience editor instead of a visual DOM editor. It is a workflow change worth flagging to them up front, but they stopped filing "my edit disappeared" tickets, which was the whole point.

Was this helpful?
Still have questions?