Skip to content

[Rest Client] Use options for client.New#463

Merged
jhillyerd merged 7 commits intoinbucket:mainfrom
corey-aloia:rest-client-opts
Jan 25, 2024
Merged

[Rest Client] Use options for client.New#463
jhillyerd merged 7 commits intoinbucket:mainfrom
corey-aloia:rest-client-opts

Conversation

@corey-aloia
Copy link
Copy Markdown
Contributor

@corey-aloia corey-aloia commented Jan 23, 2024

The rest client does not currently allow a user to pass options, such as a custom transport. This PR extends the client.New function to allow for custom options to be passed

@coveralls
Copy link
Copy Markdown

coveralls commented Jan 23, 2024

Pull Request Test Coverage Report for Build 7652203560

  • 0 of 0 changed or added relevant lines in 0 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage increased (+0.2%) to 55.481%

Totals Coverage Status
Change from base Build 7358487704: 0.2%
Covered Lines: 2647
Relevant Lines: 4771

💛 - Coveralls

@jhillyerd
Copy link
Copy Markdown
Collaborator

The problem with this implementation is that the ClientOptions struct becomes part of our public API, limiting how we can change it in the future. The Uber method is definitely more cumbersome to implement, but allows us to keep it private.

@corey-aloia
Copy link
Copy Markdown
Contributor Author

corey-aloia commented Jan 24, 2024

Thanks for the link @jhillyerd

Actually, I can just make ClientOpts small and then it is not exposed, and still works. It looks like ubers argument is:

that there's a method of implementing this pattern with closures but we believe that the pattern above provides more flexibility for authors and is easier to debug and test for users. In particular, it allows options to be compared against each other in tests and mocks, versus closures where this is impossible. Further, it lets options implement other interfaces, including fmt.Stringer which allows for user-readable string representations of the options.

I can change from the pattern with closure to the one you and uber use with apply 👍

Looks like they used to use the closure approach but changed uber-go/guide#74

@corey-aloia corey-aloia changed the title [Draft] Adding in client-opts to the rest client [Rest Client] Use options for client.New Jan 24, 2024
@corey-aloia corey-aloia marked this pull request as ready for review January 24, 2024 10:59
Signed-off-by: Corey Aloia <[email protected]>
Signed-off-by: Corey Aloia <[email protected]>
Signed-off-by: Corey Aloia <[email protected]>
Signed-off-by: Corey Aloia <[email protected]>
Signed-off-by: Corey Aloia <[email protected]>
@jhillyerd
Copy link
Copy Markdown
Collaborator

Looks good, but apologies, I should have mentioned this before: What do you think about dropping the Client name prefix from most of the types/funcs you are introducing? I know the existing client.Client type has repetition in it, but I think we could use client.Option interface and client.WithOptTransport instead.

@corey-aloia
Copy link
Copy Markdown
Contributor Author

Looks good, but apologies, I should have mentioned this before: What do you think about dropping the Client name prefix from most of the types/funcs you are introducing? I know the existing client.Client type has repetition in it, but I think we could use client.Option interface and client.WithOptTransport instead.

Good point.... client.client* is repetitive, I also thought about changing but didnt for some reason 😄 .... will adjust 👍

@jhillyerd jhillyerd merged commit b5ccd3d into inbucket:main Jan 25, 2024
@jhillyerd
Copy link
Copy Markdown
Collaborator

Thanks a bunch!

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