Annotated optional fields with omitempty by using new optional config value

[rmennes]

It could be useful to annotate optional fields annotate with omitempty when using pointers.
By allowing this option, input fields that get removed (and not used is the executed queries) will not break.
This gives the library an advantage to be more resilient against break API changes.

To introduce this option, a new optional config value is introduced pointer_omitempty.

If optional: pointer_omitempty is set. We generate

type Task_insert_input struct {
  Id: *int `json:"id,omitempty"`
}

based on

input task_insert_input {
  id: Int
}

The @genqlient(omitempty) config will override the previous defined config.

I have:

• Written a clear PR title and description (above)
• Signed the Khan Academy CLA
• Added tests covering my changes, if applicable
• Included a link to the issue fixed, if applicable
• Included documentation, for new features
• Added an entry to the changelog

[benjaminjkraft]

Thanks! I think this is pretty close to workable. Unless I'm misunderstanding, there's a tricky edge case still, but I think it should be fairly reasonable to fix.

[benjaminjkraft]

I think you may actually need to do this in two cases, one for omitempty and one for pointer. Otherwise, pointer: true overrides the global config, which is a no-op for pointer but actually disables omitempty. I'll comment in the test below where that happens.

[benjaminjkraft]

e.g. this should I think have omitempty

[rmennes]

@benjaminjkraft Thanks for the feedback. I updated the PR accordingly. I hope I understood your suggestion correctly.

[benjaminjkraft]

Thanks for the updates! This option-checking code is getting confusing so I definitely may be missing something (a clearer test case written from scratch covering each possibility rather than or in addition to cobbling together existing ones might be more convincing). But I think it's wrong for the case where you say pointer: false -- that shouldn't remove the omitempty I don't think. Not sure how much that will come up but to avoid having to break backcompat later it's better if we can to get it correct now and avoid having to add pointer_omitempty_fixed later.

[benjaminjkraft]

here's an example, except this example doesn't matter since the RawMessage will never actually be null, but if you put the same config on a different field it would.

[klondikedragon]

@rmennes @benjaminjkraft -- this PR is exciting and looks to be the last key piece for excellent usability with my complex Hasura GraphQL schema for both queries and mutations (details in #272 (comment)).

[ysdanielkim]

This is a great change. Looking forward to it.

[bcallender]

@rmennes @benjaminjkraft is there any appetite to get this merged in at some point? This would significantly improve compatibility with Hasura as outlined in #272

[benjaminjkraft]

I'm happy for this to merge but I think my last comment still applies?

[KoduIsGreat]

Hi i'm also interested in getting this merged, is there a short punch list of what is missing to get it accepted?

[rmennes]

Hi @benjaminjkraft ,
Sorry for the (very late) reaction.
I tried to apply your suggestions. I believe this is what you had in mind?
Thanks for all the feedback.