Allow to parse camel case input variables from .graphql files and generate snake_case variables in Rust

[o0Ignition0o]

This pull request mimics the current codegen's behaviour for output types.

It allows the codegen to generate snake_case variables whatever the case of the .graphql schema variables, which allows variable names to use the rust case.

I've added tests in input_object_variables_schema.graphql to make sure it doesn't break the current codegen as well.

Please let me know if there's anything I can do to improve this PR :)

Jeremy

[tomhoule]

I don't have time to do a super thorough review now, but just to kick off the discussion: isn't this a breaking change for users currently using input types?

[o0Ignition0o]

Hey, thanks a lot for your comment!

I just tried to investigate a bit more, and it turns out the behavior changed between the 0.9 release and 0.10. I first thought it happened between 0.10 and master, and it was an oversight. It turns out it probably wasn't!

Regardless of whether this would be a good or a bad idea, i think this change would be a breaking one, people would have camelCase members in their rust structures, and would need to make them snake_case again.

Here are the things IMO that would help figure out whether it would be worth a breaking change or not:

• A very valid argument to discard this change is that the graphql specification is clear about names being case sensitive (albeit for the inputs and the outputs), and underscores are significant, which means myInput, my_input and myinput are three different fields.

• The "output variables" seem to always be in snake_case on the rust side, regardless of the overall schema definition (which seems to default to snakeCase), which means there somehow is a behavioral asymmetry at the moment.

• The graphql spec is close to JSON, it makes total sense to have most .graphql queries, mutation variables and definition using camelCase (which is what most of the tests do, except this exact spot https://github.com/graphql-rust/graphql-client/blob/main/graphql_client/tests/input_object_variables/input_object_variables_schema.graphql#L39 )

I by no means know the codebase and the project's history well enough to bring a better analysis at the moment.
Since there's probably a good reason behind this change between 0.9 and 0.10, I'll dig deeper and get back to you with more context :)

If you feel like keeping it as is makes more sense, or even changing the variables casing does, feel free to close this PR and/or let me know, I'll gladly give it a try or refactor what is needed :)

Thanks again for your time!

EDIT: I think this is where the snake case conversion used to happen in the inputs on 9.0, I now have to dig to find when it changed, and if it was on purpose, I hope to be able to write an EDIT2: soon :D

EDIT2: There used to be a test with a pawCount input that turned into paw_count that got commented out here (I think gh links are buggy but if you expand inputs.rs you should find it :D I'll soon write an EDIT3 pretty soon once I figure out where the behavior changed, and if it was on purpose ^^

EDIT3: Ok so it seems like it got turned into ingest_input somewhere around this commit in graphql_parser_conversion.rs and the snake_caseing somehow got lost in the refactoring, and there were unfortunately no tests to notice that.

I unfortunately cannot tell from the commits / changes alone whether this was intentional or not :/

[tomhoule]

That refactoring stretched over a way too long time and I guess this got lost :/ I'll do a more thorough review first, but I now think we should merge this PR and do a patch release.

[tomhoule]

Let's merge this — I don't have free time for graphql-client at the moment, so I don't know when I'll get around to doing a patch release unfortunately. Help is very much appreciated. Thanks for the PR :)

[o0Ignition0o]

Sure no worries, I hope I can help doing triage or whatever sometimes, if I have a bit more time :)