VWO edits on our Storyblok React site keep getting wiped by re-renders
Our marketing team built a couple of tests in VWO's visual editor on our Storyblok-powered React site. The symptom is consistent: the edited headline or button appears for a moment, then any React re-render puts the original DOM back. State change, route transition, even a cart badge update is enough to undo the edit.
I understand why it happens, the editor is patching the DOM and React owns that DOM. I do not want to keep fighting it with mutation observers and hacks. What I am really looking for is an approach where variants are data that my components render, not DOM patches applied after teh fact.
1 answer
You diagnosed it correctly, and it is not really fixable from the VWO side. Client-side visual editors mutate the DOM, React reconciles against its virtual tree and wipes the mutations on the next render. VWO actually patches React internals to try to make edits stick, which tells you how fundamental the mismatch is. It will keep breaking in creative ways.
The variants-as-data approach you described is exactly how the Croct integration with Storyblok works. You add a Croct field to the block and connect it to a slot. Variants are then content served through that slot, and your own React components render whatever the slot returns, the same way they render the default Storyblok block today. There is no post-render DOM editing anywhere in the pipeline.
Since content is resolved server-side, there is also no client-side swapping at all: the page arrives already holding the right variant, so nothing exists for a re-render to undo.
The tradeoff to be upfront about: marketing edits variant content in an experience editor against your content model, not by freehand-editing the rendered page. For a component-based React site that is usually a feature rather than a loss, since edits can only produce states your components actually support.