Prismic v5 dataRaw for the Embed type is broken

Developing with Prismic
1

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!

2

It was a different problem. This is the line that breaks it: prismic-gatsby/normalizeDocumentSubtree.ts at 45a2db5ff798a34f1c28d340a907f5064f347978 · prismicio/prismic-gatsby · GitHub

It returns only the node.id, but it should return node.

4

Thanks for sharing your solution @luc.hendriks!

1 Like
5

No problem! I assume this is going to be fixed in a future release of GitHub - prismicio/prismic-gatsby: Gatsby plugins for building websites using Prismic?

6

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?

7

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.

8

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.

The 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.