-
Notifications
You must be signed in to change notification settings - Fork 1
add codegen HTTP client #1
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
Conversation
openapi/src/apis/apps_api.rs
Outdated
|
||
|
||
/// Get app information. | ||
pub async fn get_app(configuration: &configuration::Configuration, ) -> Result<models::AppResponse, Error<GetAppError>> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Re: Is type + impl the best pattern for this?
I think defining this function as a method on Configuration
makes a lot more sense here, since the output is entirely determined by the Configuration
type.
} | ||
|
||
impl AppleUserSocialConnection { | ||
pub fn new(provider_id: String, created_at: String, last_login_at: String, provider_identifier: String) -> AppleUserSocialConnection { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
these new
methods on this and following types aren't very useful. Since all the fields of the type are pub
, the end users can construct them in the same way that this method constructs them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for calling this out.
The new
methods have been removed from the generated output in 24f953f.
OperationNotAllowed, | ||
} | ||
|
||
impl Default for Code { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Most of these Default
impls don't really make sense. It makes sense to have a default for Option<Error>
because that can be None
, but to choose one of these enums as a default doesn't make sense to me, and may cause surprising issues if end users try to use their types in their own code that derives Default
(the compiler should give an error saying that Default isn't implemented on the error types, and make the user consider this problem at compile time, rather than silently choosing an error type that may come back to bite the user at run time).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah that seems confusing. Just for posterity, you found a related issue in the codegen repo: OpenAPITools/openapi-generator#17294.
But for this PR, these Default implementations were also removed in 24f953f.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm since i see that we are mapping to different models in our wrapper funcs anyways in #2 which seem to avoid some of the pitfalls of the recently scrubbed impl and default code from the generator
Overview of Changes in this PR
This just adds the Flex API client code generated with openapi-generator.