Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optional arguments still wraped in Some #48

Closed
obmarg opened this issue Jun 14, 2020 · 5 comments · Fixed by #76
Closed

Optional arguments still wraped in Some #48

obmarg opened this issue Jun 14, 2020 · 5 comments · Fixed by #76
Labels
🐞 bug Something isn't working
Milestone

Comments

@obmarg
Copy link
Owner

obmarg commented Jun 14, 2020

#44 updated the query_dsl to use the builder pattern for specifying arguments. Might be nice to look at unwrapping the Option from optional arguments so that we don't have to do an_option(Some(xyz)) everywhere.

Though we probably do want to support people providing None so maybe need to use Into<Option<T>>?

@obmarg obmarg added the 🐞 bug Something isn't working label Jun 14, 2020
@obmarg
Copy link
Owner Author

obmarg commented Jun 16, 2020

Probably have a similar problem with String vs &str...

@obmarg
Copy link
Owner Author

obmarg commented Jun 16, 2020

Perhaps one of the answers to this is making the query_dsl smarter - take Into<Cow> or similar for Strings, wrap Options in into etc. Rather than trying to come up with some generic solution for all types.

Not sure what the approach for custom scalars would be, but at least there’s a trait to work with there - suspect references might just work if I added the right impl.

@obmarg
Copy link
Owner Author

obmarg commented Jun 17, 2020

Some work for this on the into-option branch.

@obmarg
Copy link
Owner Author

obmarg commented Jul 10, 2020

Interesting side effect of supporting Into<Option> on these args would be that making a required field optional wouldn't break downstream cynic clients - right now it does, even though technically it'd be fine at runtime.

@obmarg
Copy link
Owner Author

obmarg commented Jul 21, 2020

Pushed a first pass of this to 9d8f995 - I need to think further on how to implement it though. Suspect there might be some subtlety (or at the very least bits that can be improved) when it comes to integrating this with the custom scalar/ID work I have in mind (#51)

Also wondering if this could help with #46 - though not quite fully formed my thoughts there.

@obmarg obmarg added this to the v0.8.0 milestone Jul 27, 2020
obmarg added a commit that referenced this issue Aug 16, 2020
#### Why do we need this change?

Currently, the `cynic_arguments` attribute is pretty strict in what it accepts.  

- If an argument is `String!` you need to explicitly provide a `String` (a `&str` isn't good enough). 
- If an argument is `String` you need to explicitly provide an `Option<String>` - none of `String`, '&str`, or `Option<&str>` is acceptable.

This leads to some noisy `cynic_argument` attributes.

This also causes otherwise backwards compatible GraphQL schema changes to cause compilation errors - if a field was required before and is now optional, you'll have to explicitly add that `Some` to your definition.

#### What effects does this change have?

This PR adds an `IntoArguments<T>` trait where `T` is the type of the argument.  This trait handles converting various arguments into their expected form.

I considered using some of the built in traits like `AsRef` or `Into` but they all seemed to come with limitations for what I wanted to do.

Fixes #48 

#### Note on Lifetimes

I spent some time trying to solve #46 at the same time - at one point `IntoArgument` had a `Output` associated type that I could use to control the type being serialized.  I used this to borrow `&str` and feed it into a new lifetime on `Argument`.  This new lifetime ended up bleeding up to the `Query` struct which made things a bit unergonomic.  See note on #46 for more details on that.  At the time of writing this alternative implementation can be found on the `into-arguments` branch, though it may not stay around forever.  This PR was a partial rebase of that original branch, with some re-work afterwards.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🐞 bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant