We are consistently experiencing the issue when fields defined in our content types, both in Slices and regular ones, are missing from GraphQL introspection result and GraphQL explorer. We tried publishing pages after changes, saving, resaving with no success.
GraphQL is not very useful without the schema/introspection and this kind of inconsistent behavior makes GraphQL implementation not reliable.
EDIT: After reading other topics I verified that missing fields are indeed using "camelCase". Is there any reasoning behind "camelCase" fields names not being supported in GraphQL and dropped silently? We have already a bunch of content published under the type, so we can't really change the field names. Are there any plans to address this issue?
Thanks for contributing to the Prismic community.
I will try to reproduce this issue on my side and it would be great if you can share with us an example of some fields that are being dropped.
Also, it will be great if you can share with us your repository name (in a private message if necessary).
I experienced the same issue on my implementation, see image in the appendix.
Mared in red (camelCase) is not working. Marked in green (all lowercase) is working
camelCase named fields are not visible in GraqhiQL.
It would be great to highlight this issue on the documentation, as I spent quite some time figuring out why its not working.
Is this issue just related to the GraphQL explorer or is this a generic issue of the GraphQL engine? I'm asking because Postman has built in support for GraphQL.
I did perform some tests with Postman and was able to receive valid data, but I hit a couple of issues:
Postman sends the query in the body and not as an encoded parameter. When I added the encoded query as a parameter, it worked. It sounds to be a much more sensible way than encoding a potentially huge json object and attaching that as a parameter. Does Prismic's GraphQL engine support queries to be send in the body? If yes, how?
Postman uses POST to retrieve the schema. It uses the same header as the actual query and also puts the request into the body which might be the issue as per above, but I noticed that the error is different
{"message":"'<api_key>' not a valid key=value pair (missing equal-sign) in Authorization header: 'Bearer <api_key>'."}
Can someone shed some light how to retrieve the Schema with Postman or is the Prismic GraphQL incompatible with Postman?
@Priyanka@Pau Could you guys please fix this? I'm running into maximum depth issues with graphQuery on the rest client, and wanted to bypass that with the GQL client. But, I created all my fields and 90% of my types with camelCase names. I'm now stuck because I can't fetch the documents and fields I need.
Hey @gijs, we don't have plans to update the current behavior of the GraphQL endpoint naming conventions. You can still query the fields with their API IDs without the Camel Case: exampleTitle would appear in the schema as exampletitle. I understand this might not be ideal for the developer experience, but it is the quickest workaround, instead of having to rename all fields.
Is there any possibility to revisit this and possibly make a change? Because to me it feels "wierd" to name for example following field as:
homelandingpage, instead of naming it "homeLandingPage". Ofc I could just ignore this and make it as "home_landing_page" as for better readability.
Also when I started using Prismic for first time, and was playing around with default Prismic client for fetching data, there is no issue pulling data with camelCase, which gave me illusion that I could pull data the same way from GraphQL, which was not the case.
This is a worth thing to mention at documentation as a suggestion!
Hey @aarnipavlidi, there is no news to change this at the moment. But I'll share your comments with the Education team so they can see how to make this clearer in the documentation.
