We upgraded from v3 to v5 and we noticed that the dataRaw query for Embed types does not return any values anymore.
This is the relevant code in v3: prismic-gatsby/gqlTypes.ts at 6756a593f344102a37e489ded3ab1f365ee2410e · prismicio/prismic-gatsby · GitHub
You see that there are many types returned for the Embed type.
This is the code in v5: prismic-gatsby/buildEmbedType.ts at 45a2db5ff798a34f1c28d340a907f5064f347978 · prismicio/prismic-gatsby · GitHub
Which calls this function: prismic-gatsby/buildNamedInferredNodeType.ts at 45a2db5ff798a34f1c28d340a907f5064f347978 · prismicio/prismic-gatsby · GitHub
And has the
fields parameter set to
So for the Embed type now all fields are gone.
We have to fork the repo to get the fields back. Could you please update the code so that the Embed dataRaw returns the fields again? Thanks!
Thanks for sharing your solution @luc.hendriks!
I just checked with a test repository, and I found that the
dataRaw field isn't actually related to Embed fields at all. Could you please give me more details about the use case? how did you get access to
node.id on an Embed field?
I'm a colleague of Luc. We're still using the
dataRaw field in our graphql queries. The behavior of that field in v3 was that it would give any and all data stored in the document. Whereas the
data field requires specified queries. In v5 the
dataRaw field still acts as expected except for the embed type. The embed type only returns the
id value as a string.
Our code is still expecting the full embed type object with all its fields and values (width, height, title, html, description and such). We tracked the problem down to the line in
normalizeDocumentSubTree where a map operation is performed only picking the
id from the object. The expected behavior here would have been to return everything, just like in v3.
This is an undocumented breaking change which we currently fixed with a fork. We would love to see this fixed in a future release. Looking at the blame in github there doesn't seem to be any particular reason for this change. For example, the link type still has all the fields as expected.
I understand. Thanks for the feedback @thomasploeg and @luc.hendriks. We'll pay closer attention to announcing breaking changes like this one. We've added a note in the documentation's backlog to make this process transparent.
dataRaw field and other raw fields that were used in this same plugin existed cause React components like require the raw value to work. Before, if a Custom Type had a new field type that the plugin couldn't display correctly, it could at least be fetched using
dataRaw. Now, the plugin has a way of working with any data, so this isn't necessary.