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

[csharp][netcore-httpclient] Refactor of constructors #9145

Merged
merged 6 commits into from
Apr 16, 2021
Merged

[csharp][netcore-httpclient] Refactor of constructors #9145

merged 6 commits into from
Apr 16, 2021

Conversation

lucamazzanti
Copy link
Contributor

@lucamazzanti lucamazzanti commented Mar 31, 2021

It tries to reduce the number of constructors introduced in previous PR.
Related to: #9060, #9085

Refactor on constructors

In the previous PM I created too much constructors.
This is an emprovement to reduce them:

  1. I kept the HttpClient service as first parameter when available in signature
  2. Then the configurations
  3. Then the optional HttpClientHandler

With this PM we have in ApliClient:

  1. ctor()
  2. ctor(string basePath)
  3. ctor(HttpClient client, HttpClientHandler handler = null)
  4. ctor(HttpClient client, string basePath, HttpClientHandler handler = null)

(point 1-2 marked as obsolete)
and in ApiClass:

  1. ctor()
  2. ctor(string basePath)
  3. ctor(Configuration configuration)
  4. ctor(HttpClient client, HttpClientHandler handler = null)
  5. ctor(HttpClient client, string basePath, HttpClientHandler handler = null)
  6. ctor(HttpClient client, Configuration configuration, HttpClientHandler handler = null)
  7. ctor(ISynchronousClient client, IAsynchronousClient asyncClient, IReadableConfiguration configuration)

(point 1-3 marked as obsolete)

Obsolete constructors

Marked constructors without the explicit HttpClient parameter as obsolete.

Spaces and indentations

Unfortunatly I had a different setup for spaces and indentations on my IDE and I did not see it on my local versioning tool.
So the changes have some spaces because I fixed my previous PM, moving some tabs to 4 spaces.
They are a few lines not so much, but this is why you see some noise in the diffs, its a fix to keep and I will avoid it at all in the future.

PR checklist

  • Read the contribution guidelines.
  • Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
  • Run the following to build the project and update samples:
    ./mvnw clean package 
    ./bin/generate-samples.sh
    ./bin/utils/export_docs_generators.sh
    
    Commit all changed files.
    This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
    These must match the expectations made by your contribution.
    You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
    For Windows users, please run the script in Git BASH.
  • File the PR against the correct branch: master, 5.1.x, 6.0.x
  • If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

@mandrean (2017/08) @frankyjuang (2019/09) @shibayan (2020/02) @Blackclaws (2021/03)

Updated samples

Fixed a bug of previous commit

Refactor on constructors
@auto-labeler
Copy link

auto-labeler bot commented Mar 31, 2021

👍 Thanks for opening this issue!
🏷 I have applied any labels matching special text in your issue.

The team will review the labels and make any necessary changes.

@wing328
Copy link
Member

wing328 commented Mar 31, 2021

Minor suggestions: better indentation in the documentation comments and use 4-space instead of tabs

@wing328 wing328 added the Enhancement: Code Cleanup General refactoring, removal of deprecated things, commenting, etc. label Apr 3, 2021
@wing328 wing328 added this to the 5.1.1 milestone Apr 3, 2021
@Blackclaws
Copy link
Contributor

Blackclaws commented Apr 6, 2021

Mark the constructors without HttpClient as obsolete already. I think we all agree that they should not be used except as a compatibility fallback. Aside from that it looks good

@lucamazzanti
Copy link
Contributor Author

lucamazzanti commented Apr 6, 2021

Ok, give me a feedback on the message if it fits, i will change it as you prefer

@Blackclaws
Copy link
Contributor

I would change the Message to: Constructors without HttpClient have non-trivial drawbacks and are thus considered deprecated. Check README.md for details Aside from that LGTM

@lucamazzanti
Copy link
Contributor Author

I will change the message to "Constructors without HttpClient have non-trivial drawbacks and are thus considered deprecated. Check README.md for details." asap.

@lucamazzanti
Copy link
Contributor Author

If you have time to review it and merge it, it's all done.

@Blackclaws
Copy link
Contributor

LGTM

@wing328
Copy link
Member

wing328 commented Apr 16, 2021

Marked constructors without the explicit HttpClient parameter as obsolete.

I have a different opinion on this. Will submit a PR with a use case to start the discussion later (before 5.1.1 release)

Will merge this one to keep the ball rolling.

@wing328 wing328 merged commit 3929aff into OpenAPITools:master Apr 16, 2021
@wing328
Copy link
Member

wing328 commented Apr 29, 2021

I ran out of time to submit a PR. Here is what I would suggest:

Do NOT mark constructors (e.g. PetApi()) without the explicit HttpClient parameter as obsolete.

The reason is to cater simple use cases. Consider that the situation in which I want to make a simply call (e.g. GetPetById) to the API server and get something back. All I need is a simple call to get some objects (e.g. Pet) from the server and I only need to make the call once. Performance is not a concern/requirement in the use case.

The goal is to make the auto-generated C# SDK easy-to-use.

What do you guys think?

@lucamazzanti
Copy link
Contributor Author

If you want to go in the milestone without the obsolete marker and postpone the brainstorm further I will remove the attributes in a few hour.

They were put after the discussion on slack/here to emprove the usate, I think in a .net core application you will embrace the bootstrap and DI so the httpClient is the proper way to go.

Said that, for sure in a smaller project the easier constructor Is preferred. So maybe an obsolete attribute is too much, it is enough to have the new constructors and the readme.

Let me know if i can help you to reach the needs in time.

@wing328
Copy link
Member

wing328 commented Apr 30, 2021

Yes, please file a PR hwen you've time.

@lucamazzanti
Copy link
Contributor Author

Done in PR #9373.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Client: C-Sharp Enhancement: Code Cleanup General refactoring, removal of deprecated things, commenting, etc.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants