Allow non-existing fields in GraphQL Queries

[HZSamir]

Hello,
I'm using Gatsby with the Wordpress source plugin. So far so good. But the thing is I am querying fields that might or might not be there, in this case, the featured image of a post.
Here is my query:

{
allWordpressPost(sort: { fields: [date] }) {
      edges {
        node {
          title
          excerpt
          slug
          featured_media
          better_featured_image {
            wordpress_id
            alt_text
            caption
            description
            media_type
            post
            source_url
          }
        }
      }
    }
}

It works well when the featured image is set, but fails miserably otherwise.
And so my question: Is there any way in GraphQL to query an optional field? To add a default value to a required field?

Thank you.

[m4rrc0]

I have/had the same problem with contentful. Here is my PR proposal #2037. It still needs to be polished.
Unfortunately it does not handle images atm because with this approach we would need a default image to fill in the field and it is not the expected behavior to have an image there if the user didn't put one. I don't know how we could set a 'falsy-like' value on an image field...
I am wondering how the graphiql interface handles this kind of stuff. If we query an unset field there it just returns null on that field.
Anyway, if someone has an idea to move this forward I am interested too.

[m4rrc0]

And the issue associated for reference: #1517

[HZSamir]

@MarcCoet I just noticed that this particular issue makes it also impossible to publish an empty blog. Meaning if you don't have any post in your Wordpress site for example, you run into Cannot read property 'allWordpressPost' of undefined

We really need some way to throw a warning, instead of a full-blown error in these cases

[m4rrc0]

Totally agree but I don't know how.
I feel this is something that should be solved in gatsby core because every CMS-like source plugin is going to fall in the same traps.
Sorry @KyleAMathews but I need to mention you again here. ^^'

[sebastienfi]

We solved this by publishing a dummy post with all features set.

[HZSamir]

This issue remains my biggest gripe with Gatsby. Simply returning nulls to every non-existant queried field in a GraphQL query would be the best approach in my opinion, as it is trivial to check whether the field exists in React
Just a use case that I encountered this week: One of my clients' first reflex was to delete all his posts, expecting to see a no posts page, until such a time he would start filling his blog with content, and that simply broke the build process. I had all the trouble in the world to explain to him why it worked that way.

Another, more recent one had to do with the menu, where I fetch wordpressWpApiMenusMenusItems to display the menu he creates in the Wordpress dashboard. Again, ideally not having a menu to fetch I would not display one, instead the build process breaks, same thing when trying to fetch all menus children, something like:

wordpressWpApiMenusMenusItems(name: { eq: "Main Menu" }) {
      items {
        wordpress_id
        title
        url
        type
        wordpress_children {
          wordpress_id
          title
          url
          attr
          target
          type
          wordpress_children {
            wordpress_id
            title
            url
            attr
            target
            type
          }
        }
      }
    }

If the menu does not have children, we run into the same issue.

So, I'm not sure if this is in line with Gatsby's philosophy, so maybe I'm assuming too much, but it would be much appreciated if unsuccessful GraphQL queries did not break the build, simply returning empty or null values for the fields required, then it would be up to the dev to check whether the values exist before displaying them.
What do you think of this?

[KyleAMathews]

@Unforgiven-wanda these are great examples of when this causes trouble! I have been somewhat confused why people ran into this trouble as I always build out my sites while adding content so don't ever have the problem of wanting to write a query against something that doesn't yet exist.

Thinking about this some more — I think it could be possible to turn what's now a build error into a warning. @jquense any thoughts on this that come to mind?

@Unforgiven-wanda would you like to investigate a possible solution to this? We use the Relay compiler for validating queries and we'd either need to somehow lower the warning level or catch its errors and not exit when it's a query that includes fields that don't exist.

[jquense]

Unfortunately there isn't really a good way to silence this sort of thing since it's a hard error in GraphQL. Even if you could tho you'd lose the validation for cases were you do want it, e.g. notification you are trying to query some field you spelt wrong or something. I agree that is can be frustrating and annoying in the development, but this is a hard constraint of how graphql works, it can only query stuff that is defined in the type system.

Ultimately the issue here is that if you only infer the schema from the input data, you are necessarily constrained to what the data contains. There isn't any way to tell graphql to just return null or something for fields that don't exist, because it needs to know a a lot of info waaay before that to even try and resolve that field. You also can't work backwards from the query and do inference at that point because queries don't contain enough info to do inference (e.g. you can't distinguish a List from an Object)

In terms of what Gatsby can do, the API's for handling this already exist luckily, you need to extend the graphql types manually and specify which fields you always want to exist. We might be able to make that a bit friendly for quickly specifying additional fields, but honestly, defining GQL schema is verbose and time consuming sort of inherently. (note Apollo Launchpad has a neat way of defining schemas quickly)

[HZSamir]

@KyleAMathews Of course. i'll do my utmost to resolve this issue, and if I am successful, I'll be sure to put it a pull request
I'll be closing this issue then, since as demonstrated by @jquense there is no obvious solution for now.
Thank you all.

[sebastienfi]

This also looks promising https://github.com/marmelab/graphql-schema-from-json

[diegolamanno]

@jquense I am trying to follow your recommendation to extend graphql types manually. However, I am running in some issues that I would appreciate your input.

1. I am using setFieldsOnGraphQLNodeType very similar like some of the gatsby-transform plugins do. Am I in the right path or that's not the gatsby API you were referring to?

2. So far I have been able to add more types using ☝️ that API. But I haven't found a way to setup a default value for a UnionTypes without completely overwriting the ones coming from the API,

I hope this makes any sense, thanks