Skip to content

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

Merged
merged 5 commits into from
Aug 22, 2024
Merged

add codegen HTTP client #1

merged 5 commits into from
Aug 22, 2024

Conversation

bertrmz
Copy link
Contributor

@bertrmz bertrmz commented Aug 16, 2024

Overview of Changes in this PR

  • check in generated dir

This just adds the Flex API client code generated with openapi-generator.



/// Get app information.
pub async fn get_app(configuration: &configuration::Configuration, ) -> Result<models::AppResponse, Error<GetAppError>> {

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 {

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.

Copy link
Contributor Author

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 {

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).

Copy link
Contributor Author

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.

Copy link
Contributor

@ctran88 ctran88 left a 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

@bertrmz bertrmz merged commit ffaa39f into main Aug 22, 2024
@bertrmz bertrmz deleted the add-http-client branch August 23, 2024 19:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants