This commit rewrites some parts of the README.
It removes the section about package bot, because we all should just
forget that it ever existed. Thanks, Discord.
It also removes a section that compared the library against Discordgo.
The section was written 3 years ago so it was very outdated. Instead, it
is replaced with a "Library Highlights" section, which provides much
more insights on the library itself.
This commit adds MockRequest and MockResponse to aid in testing.
It doesn't provide a MockClient, since there are multiple testing
strategies and we don't want to do them all.
Prior to this commit, gateways can send 120 events before being
throttled at a terribly slow rate of 1 send per minute.
This commit permits gateways to send 5 events before being throttled at
a rate of slightly less than 120 events per minute.
* Support SendGateway to help with voice usage
* Remove unnecessary Gateway interface function
* Add clarification comment
Co-authored-by: Tyler <admin@meow.tf>
This commit introduces a slash commands and autocompletion router. It
abstracts the switch-cases that the user has to do in each
InteractionEvent handler away.
The router is largely inspired by go-chi's design. Refer to the tests
for examples.
* feat: add support for disabling signature verification
* feat: refactor solution to not break api
* feat: make InteractionServer.ServeHTTP use InteractionServer.httpHandler
This commit separates the undocumented fields of Ready to
ReadyEventExtras. Realistically, this is never an issue for bots, but it
might cripple non-bot users when Discord makes breaking changes to the
API.
This change allows Ready to still be unmarshaled even when the
undocumented fields cannot be unmarshaled. It also adds a new json.Raw
field that allows the whole Ready event to be unmarshaled differently.
This new ReadyEventExtras is also no longer marshaled as part of Ready.
Instead, none of its field will be present. Although this is a breaking
change, it solely concerns non-bot APIs, so it's acceptable.
This is a workaround for some cases where ReadyEvent cannot be delivered
successfully, e.g. in the case of an unmarshal failure.
We should handle BackgroundErrorEvents in the future that fatally exits
on any unmarshal errors.
