Default variant for enums generated by fragment (union / interface types)

[visd0m]

I was wondering if this would be an appreciated feature.

I try to describe a real scenario in order to be clear 🤞 .

Given a query like this:

query {
    myBeautifulQuery {
        __typename
        ... on Foo {
            fooField
        }
        ... on Bar {
            barField
        }
    }
}

and a graphql schema like this:

union MyBeautifulQueryResponse =  Foo | Bar

The generated enum representing myBeautifulQuery Response looks like this:

#[serde(tag = "__typename")]
pub enum CanChangeSaveEffectiveDateSaveOnSaveActions {
    Foo(FooData),
    Bar(BarData),
}

If the enum covers completely the union variants everything is fine.

The problem arises if a variant is added to the union type declared in the schema and the types are not re-generated.

If a new variant is added, the enum is not correctly deserialized and a deserialization error occurs.

Speaking in terms of correctness, probably, the fact that an error occurs is fine.
Anyway sometimes a safer approach can be preferred.

Adding a default variant to the generated enum would avoid the deserialization error in case of new variants of MyBeautifulQueryResponse.

#[serde(tag = "__typename")]
pub enum CanChangeSaveEffectiveDateSaveOnSaveActions {
    Foo(FooData),
    Bar(BarData),
    #[serde(other)]
    SomethingElse
}

This ☝️ would avoid the deserialization error making possible to handle the unknown variant as desired.

It would be nice to be able to trigger this safer version of the generated code.

If this seems a desirable feature I (or some colleagues of mine) could work on it

[tomhoule]

Yes I think it would be valuable. I don't know if you are using the latest released version or the main github branch, but there are substantial differences between the two. A new stable release will go out soon and I can't remember if it touched that part of the code, but I'd assume not. So yes, a PR would be welcome :)

[tomhoule]

There's the question of whether it should be configurable, and if yes what the default should be. I'm not sure.

[visd0m]

Yes I think it would be valuable. I don't know if you are using the latest released version or the main github branch, but there are substantial differences between the two. A new stable release will go out soon and I can't remember if it touched that part of the code, but I'd assume not. So yes, a PR would be welcome :)

Yes I am aware of the differences 👍 .

Glad to hear about the new release!

So I guess we'll work on it in the next days.

[dehann]

xref:

• Unable to derive from the GraphQLQuery Macro - Expected String but got &str #507 (comment)