Inconsistent resolvement of gql types

[theLeroy]

Bug description

I have noticed for some time that the settings I make in the Statamic GUI have an inconsistent effect on the types of the GQL API. Especially with entry and asset fields, a large number of types have to be excluded again in the front end, even though this is already clear from the GUI settings in the back end. This leads to enormous additional effort and, above all, it is inconsistent.

What exactly do I mean by this, and a few examples:

An example of where it is done well:

If you add a normal asset field and change the max allowed files to 1 the type changes form an array of assets to an asset object. This gives a clean type on the frontend and removes the need to handle both the multi-element and the single-element case.

Examples of where it is not done:

If I select one specific container in the same asset field all other containers are not getting removed for this graphql type, although by definition it is not possible for the user to select an image from another container. This means I have to check again in the frontend whether the image is in the correct container ,typically by disambiguating via the __typename field.

-Same with linked entries. If I only allow a specific collection in an entries field, I still get a normal [EntryInterface] in the GQL resolver and also in the types. This means that I have to check the type again in the frontend against all possible blueprints in all possible collections, which is also creating a lot of redundant code here.

Conclusion: I understand that the normal interfaces are used here and that these are not further resolved. However, the problem is also multiplied in replicators and grids that use fieldsets, which makes the use of graphql almost useless. One of the major advantages of GQL is the synchronisation of types from the backend to the frontend, which is almost completely lost due to the incomplete resolution of the interfaces. I wouldn't mind all the checks if it were a REST API and the frontend didn't know at all what to expect. But then at least I wouldn't have the added hassle of having to write a query as well. This also makes the graphql tree unnecessarily large and complex.

How to solve this problem?

Implementation of a correct, "to the end" resolution of the interfaces/types on a field basis for all settings of the specific field. One possible solution would be to offer collection-specific entries queries. So instead of a query entries(collection: xyz) that returns [EntryInterface], you could have an entries_xyz query that returns [Entry_Xyz_Abc] (assuming the collection xyz only has a single blueprint abc, otherwise it would be a union type of all possible blueprints).

credit also goes to @lostgeek

How to reproduce

• Set up Statamic with multiple collections.
• Create an entries field in a random blueprint and specify which collections are selectable through the entries field.
• Check in GraphiQL that all entry interfaces are still selectable.

Environment

all

Installation

Fresh statamic/statamic site via CLI

[theLeroy]

Another point would be that buttonsgroups resolve values and labels with fixed strings. Currently, the type there is simply “string | null | undefined.” It would be nice if the type were more specific there as well.

I can also offer to try to create a specific list of desired changes. If desired.