Alpha: Editor React Components are currently in alpha. This feature is subject to change and may have bugs, issues, and limitations. We're actively improving it based on your feedback.
setData() and getData() read and write the data fields declared in your component's manifest. Many custom panels manage content that lives somewhere else instead, such as a Wix Data collection or content fetched from your app's backend. In that case, the editor canvas has no way to know your content changed, because nothing in the manifest changed.
This article shows how to bridge that gap: pushing a snapshot of your external content into a manifest field your component already watches, and avoiding the read-after-write timing issue that comes with combining a pushed snapshot with a live data fetch.
Make sure you have the following set up:
Your custom panel and your component run in separate contexts, and the only channel between them is the manifest's data and style values. There's no separate call for telling the canvas to refresh: the editor re-renders your component when a bound value actually changes, and not otherwise.
Take a testimonial carousel that shows quotes from a Wix Data collection instead of a single manifest-declared quote field. A Wix user picks which quotes appear and reorders them from your custom panel. The panel writes those changes directly to the collection with the Wix Data SDK, not through setData(), since the content isn't part of the manifest. Nothing bound changed, so the canvas has no way to know your content changed.
Your component still needs to query that collection itself to render the carousel. If it only queries once, on mount, it won't reflect changes the Wix user makes in the panel afterward. If you have it re-query after every panel action, you introduce a race: Wix Data replicates writes to several mirror instances, and a query issued immediately after a write can still return a mirror's pre-write data before that replication catches up. See Wix Data and Eventual Consistency.
Add a data field to your manifest that exists only to signal that your external content changed. It doesn't drive any UI in the component:
Whenever your panel writes a change to your external content, also serialize the current state into contentRevision with setData(). Always include something guaranteed to change, such as a timestamp: the editor only re-renders when a bound value changes, so writing the exact same string twice in a row does nothing the second time.
Pass the current quotes value into this function instead of reading it back from the component first with getData(). If your panel already has the value it's about to write, an extra read before the write is redundant.
Because contentRevision is a manifest field, updating it triggers the same prop update your component already receives for any other data field. No extra wiring is required.
In your component, parse contentRevision and use it as the initial source for what to render, instead of waiting on your own query to resolve:
The component now updates the moment the panel pushes a snapshot, without a round trip to your data source.
consistentRead to avoid a stale fetch overwriting the snapshotYour component likely still needs its own query, for example to load quotes the first time the panel hasn't touched contentRevision yet, or to keep the live site in sync without a panel present.
Wix Data replicates every write to several mirror database instances, and a normal read hits the nearest mirror to save time. A query issued right after your panel's write can still return that mirror's pre-write data, because it hasn't caught up yet. Pass consistentRead: true to the read so it queries the primary instance directly instead. For more information, see Wix Data and Eventual Consistency.
consistentRead costs some latency on that query. It's worth it here, since it's what guarantees your component doesn't overwrite the panel's snapshot with data read from a mirror that hasn't caught up yet.
The snapshot only exists to make the canvas refresh immediately, without waiting on this query. Your data source is still the source of truth: keep querying it.
If a value can also change outside your panel, for example a field an auto panel exposes alongside a related field your custom panel manages, subscribe to it with onChange() so your panel's own UI reflects edits made elsewhere:
Last updated: 8 September 2026