Add entryTypes to Graphql root

[gopeter]

We're using Craft CMS as a headless CMS for a Next.js frontend. We're also using graphql-coden to create typed hooks for our Graphql queries. But since entries could be any entryType, a query like

query {
  entries {
    ... on homepage_homepage_Entry {
      id
    }
  }
}

would result in entries: Array<{ id: string } : {}>, because we have a lot of other entry types:

For sure we can use a section filter to get only results with the homepage entryType, but the codegen does not know that this filter is going to return one (or more) specific type(s) only.

Now writing a typed frontend becomes a mess, since we have to double check the typenames everywhere and extract the right types from huge unions. It would be nice if we could have something like:

query {
  typedEntries {
    homepage {
      id
    }
    faqPages {
      id
    }
  }
}

typedEntries may not be the best name, but I think you know what I mean 😄 Is this something that you may can think of? Or should I add such root nodes by myself?

[andris-sevcenko]

I understand where this is coming from, for sure. My current worry about this is that some sites would get hundreds of extra queries. Maybe the solution would be to hide queries that return a single type behind a configuration option? I'll bring this up internally and we'll talk about it. I should get back to you by the end of the week about this.

[gopeter]

Hi @andris-sevcenko. Wow, I'm always impressed by how fast you're responding to issues and discussions! 😄
I think it would suffice it we could configure this, even if it's just an opt-in array for some types in a configuration file like config/general.php.

[gopeter]

Hi @andris-sevcenko. There's another point I want to add and which relates to my initial query.

I've created a field where I can choose an entry, but with just a single entry type:

But if I want to query this with Graphql, the Schema does not know that this can be only one type:

It would be great if the only possible entry type for destination would be destinations_destinations_Entry, since I did not selected any other entry types for this relation.

[gopeter]

Yes, that's what I meant with

For sure there are cases where fields could be null, especially content fields, since we can save drafts without filling out any field.

But ID, language, etc, shouldn't be null, even for drafts without any content at all. Or do I miss something here? 🤔

[andris-sevcenko]

Or do I miss something here?

No, sorry, I just wasn't careful enough when reading your last message. You are right. I'll see if I can tighten things up a little bit around here!

[gopeter]

Thank's a lot 😊

[andris-sevcenko]

@gopeter we'll tighten the definitions, but that'll have to happen in Craft 4.0, after all.

Changing around several signatures at once does not feel like a Craft 3.7.x change, as it's a bit too significant to add it to such a minor release.

Since there's not going to be a Craft 3.8, the only other option left is to add that to Craft 4.0, which is currently slated to be in Beta in Q1 2022.

Meanwhile, you can modify the definitions using the EVENT_DEFINE_GQL_TYPE_FIELDS event. I realize it's not very convenient, but it's probably more convenient than me breaking everything and rushing to implement a change across all the API :)

[andris-sevcenko]

I tightened some of the field types for 4.0.

The union thing, however, will have to wait some more time. Unfortunately, it's impossible to return a Union and Interface at the same time (even if the union is a subset of types implementing the interface), which means that every query that lists an interface field without fragments will break.

These changes have been pushed back to Craft 5, since that's when the content model will change a bit which will directly affect GraphQL queries and likely require people to rewrite them. We can't really ask people to do that for two subsequent Craft releases, so we have to push the "unions instead of interfaces" changes back to v5 as well.

I'm still looking into adding additional queries that return unions to Craft 4, though, since that is an additional change, not an in-place change.