This change is very simple. Just one line.
The current behavior of slack.New is that it creates a new http.Client{} every single time, and that's not a good thing because http.Client should be reused. It's true that we can override http.Client by using slack.OptionHTTPClient(). The problem is that the API still creates a new http.Client instance just to be discarded right after. That's a wasteful allocation. This PR is to get rid of that while everything should remain the same.
Pull Request Guidelines
These are recommendations for pull requests.
They are strictly guidelines to help manage expectations.
PR preparation
Run make pr-prep from the root of the repository to run formatting, linting and tests.
Should this be an issue instead
[ ] is it a convenience method? (no new functionality, streamlines some use case)
[ ] exposes a previously private type, const, method, etc.
[ ] is it application specific (caching, retry logic, rate limiting, etc)
[ ] is it performance related.
API changes
Since API changes have to be maintained they undergo a more detailed review and are more likely to require changes.
no tests, if you're adding to the API include at least a single test of the happy case.
If you can accomplish your goal without changing the API, then do so.
dependency changes. updates are okay. adding/removing need justification.
Examples of API changes that do not meet guidelines:
in library cache for users. caches are use case specific.
Convenience methods for Sending Messages, update, post, ephemeral, etc. consider opening an issue instead.
This change is very simple. Just one line. The current behavior of
slack.New
is that it creates a newhttp.Client{}
every single time, and that's not a good thing because http.Client should be reused. It's true that we can overridehttp.Client
by usingslack.OptionHTTPClient()
. The problem is that the API still creates a newhttp.Client
instance just to be discarded right after. That's a wasteful allocation. This PR is to get rid of that while everything should remain the same.Pull Request Guidelines
These are recommendations for pull requests. They are strictly guidelines to help manage expectations.
PR preparation
Run
make pr-prep
from the root of the repository to run formatting, linting and tests.Should this be an issue instead
API changes
Since API changes have to be maintained they undergo a more detailed review and are more likely to require changes.
Examples of API changes that do not meet guidelines: