Closed a-rbsn closed 4 years ago
At first glance, it looks to me like prismicContactInformation
is the Node, and not PrismicContactInformationData
. Am I wrong in that assumption? Is the data
field of prismicContactInformation
a foreign key?
If PrismicContactInformationData
is simply a data field that gets attached to prismicContactInformation
, then you probably don't need implements Node
in the type definition.
I haven't really done a thorough examination, though. You will know better than me how your data is being structured.
After a cursory examination of gatsby-source-prismic
, it looks like the data
field becomes a container of (potential) nodes, but I don't think it becomes a node itself. So, I can see how defining it as implements Node
could cause an error.
@Js-Brecht — thank-you very much for your fast response and correct solution.
Turns out removing implements Node
fixed the issue, but it's funny how it worked before. I guess something updated and this needed amending.
So learning point for me — implements Node
is only for higher level types?
As for your first question, I believe gatsby-source-prismic
puts all of the data into these Data
types, which means within the source you refer to the normal type, but if something needs inferring it's using the Data
type? Kind of confusing but it seems to be working.
yes implements Node
would be your root nodes. That's the only piece that needs the ID, and other internal types.
gatsby-source-prismic
has a type of "normalization" process that it does on the data
container. Based on the type of the data in the fields within that data
container, it performs various operations, converting fields of certain types to their respective nodes, and converting the field itself into a foreign key.
So, for something like an image field, I believe it would create an image type. That will make a brand new root node by creating a new file node, and linking it to the requisite field, like this. This, I believe, would give you access to all of the ImageSharp
data.
So, that would be how it infers the types, and how you can get so much extended information based on the information collected from your API.
There's several layers of, I would say, unnecessary abstraction going on in that plugin, which can make it a bit more difficult than it should be to reason about what it's doing... but we're not here to talk about my opinions 🤷♂
Was there any recent updates to gatsby-source-prismic
? Perhaps they used to turn the data
field into a root node itself? If they changed that behavior, it would (or should) have been a major update, because that is definitely a breaking change.
According to npm, last publish was a year ago
@Js-Brecht — yeah just seen it's been a long time since the plugin was updated, other than that I have no idea unless it was a gatsby update that caused it.
Can't say for sure. I know they were doing some work on refactoring the GraphQL schema/processing stuff, and I think they're still working on extending it to support 3rd party schemas better. It's possible that some small change could have caused it... say, if they made the ID
inferred from a Node
type non-nullable instead of being inferred from the data structure itself? As unlikely as it would be that that specific behavior would have only been added recently, that would just be a way I could see it happening
Closing this issue as resolved
I'll preface this by saying everything has been working fine up until this point and I am using
gatsby-source-prismic
for this website.The errors I am getting coincide with types that have been defined in
gatsby-node.js
as seen below — when I rungatsby develop
orgatsby build
I receive an error for each of my defined types that says:Cannot return null for non-nullable field PrismicProjectData.id.
— but according to the docs we don't need to explicitly defineid
,parent
etc:Even when I do define
id
under the types it still reproduces the same set of errors.The errors that are occurring: