# VWO visual edits on our Storyblok React frontend keep getting reverted, is this fixable?

Asked by Iker Zubiaga on 2025-10-02. Tags: storyblok, react, ab-testing, migration.

We run Storyblok as CMS with a React frontend, and VWO runs client-side with
edits made in the visual editor.

Repro: open a page with an active variation, headline shows the edited
copy. Trigger anything that re-renders the component (route transition
back and forth, or a state change in a parent). Headline reverts to the
original Storyblok content. Every time.

I understand why, React reconciles from its own tree and does not know
the DOM was mutated underneath it. Question is whether anyone has actually
made a DOM-editing tool coexist with a component frontend in a reliable
way, or whether the architecture is just mismatched and we should stop
trying.

## 2 answers

### Answer from Tom Brereton (2025-10-02)

You have diagnosed it correctly and I would stop trying. Client-side
visual editors mutate the DOM, and React re-renders undo those
mutations. This is a known pattern with SPA frameworks, not a config bug
you can toggle away. The vendors have workarounds that patch or watch
React internals to reapply edits, but you end up chasing edge cases on
every framework upgrade.

The alternative that fits a component frontend is testing at the
component level instead of the DOM level: variants are Storyblok block
content served through Croct slots, so React renders the variant
natively as ordinary props. There is nothing for a re-render to revert
because the variant IS the rendered content.

Side benefit that mattered to us: content is resolved server-side, so
there is nothing to hide or swap on the client and no anti-flicker
snippet in the picture at all.

#### Reply from Iker Zubiaga (2025-10-03)

Yeah, chasing reapply hacks on every React upgrade is exactly the
future I want to avoid. Component-level it is.

### Answer from priyanka_s (2025-10-03)

just to add a data point, we spent about two months on the coexistence
path before giving up. MutationObserver-based reapplying works until it
doesn't, and debugging why an edit flashed back for 200ms is miserable.
If your variants come from the CMS side as structured content the whole
class of problem disappears. Croct has a writeup on
[A/B testing in React applications](https://blog.croct.com/post/ab-testing-react-applications)
that covers the client versus server tradeoff in more depth.