You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One could argue if mapping all the paths for each block is necessary/a good thing, but most importantly what is lost here is this mapping:
rijk
changed the title
Custom Groq selector breaks ability to do visual mapping
Expanding body in Groq selector breaks ability to do source mapping
Jan 24, 2024
I've worked around it for now by overwriting the mappings and paths — no idea if this is ill advised, but it seems to work:
const{ data, sourceMap }=useQuery<Page|null>(PAGE_QUERY,params,{ initial })constencodeDataAttribute=useEncodeDataAttribute(data,{documents: sourceMap?.documents??[],// Overwrite the mappings because they break visual editing when you start expanding the body// array (see https://github.com/sanity-io/visual-editing/issues/747)mappings: {$: {source: {document: 0,path: 0,type: 'documentValue'},type: 'value',},},paths: ['$'],},client.config().stega.studioUrl)
In my custom components, I use
encodeDataAttribute
to map them to blocks. For example:This works, as long as the Groq query is simple, like:
As soon as the query gets more complex (which is needed to expand references), the
encodeDataAttribute
breaks:Even though nothing actually changes in the document structure returned by the query (I've diffed the two JSON objects and they are identical).
Which versions of Sanity are you using?
What operating system are you using?
macOS
Which versions of Node.js / npm are you running?
The text was updated successfully, but these errors were encountered: