feature: public raw events #3159
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
while retaining raw for use in debugging privately
bdistin
force-pushed
the
PublicRawEvents
branch
from
fcd33f3 to
3ee802c
Compare
SpaceEEC
previously requested changes
Mar 20, 2019
typings/index.d.ts
Outdated
| @@ -1277,6 +1277,76 @@ declare module 'discord.js' { | |||
| public status: Status; | |||
|
|
|||
| public broadcast(packet: object): void; | |||
|
|
|||
| public on(event: 'READY', listener: (data: any, shardID: number) => void): this; | |||
There was a problem hiding this comment.
I think you can greatly simplify those overloads via the WSEventType type:
public on(event: WSEventType, listener: (data: any, shardID: number) => void): this;
public once(event: WSEventType, listener: (data: any, shardID: number) => void): this;TIL, that's neat
appellation
approved these changes
Apr 23, 2019
vladfrangu
requested changes
Apr 23, 2019
typings/index.d.ts
Outdated
| @@ -1305,6 +1305,10 @@ declare module 'discord.js' { | |||
| public status: Status; | |||
| public readonly ping: number; | |||
|
|
|||
| public broadcast(packet: object): void; | |||
There was a problem hiding this comment.
This should be removed, as it's already mentioned in the private functions part of the class
1 task
samsamson33
pushed a commit
to samsamson33/discord.js
that referenced
this pull request
Feb 27, 2020
* add a public alternative to the private raw event while retaining raw for use in debugging privately * only emit dispatch packets * requested changes TIL, that's neat * fix padding * requested changes * Update WebSocketManager.js
samsamson33
added a commit
to samsamson33/discord.js
that referenced
this pull request
Feb 27, 2020
This reverts commit b020a47.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Please describe the changes this PR makes and why it should be merged:
This gives a public alternative to the private raw event. (The raw event isn't removed, for the purposes of library testing.) This gives devs the ability to work with d.js in a cacheless way without relying on the private raw event. Say you don't want to cache partial reactions simply to have a starboard type feature that isn't limited to your message cache, this would give you that public option to do so.
Like raw, these event's aren't disabled with ClientOptions#disabledEvents (which isn't very aptly named, since it only disables the internal d.js handlers). So you could disable all d.js handlers (and by proxy all d.js caching) and use these events to cache to Redis (microservices like scenario), or any other number of completely custom use cases.
Usage is very simple:
Client#ws.on(RawEventType, (RawEventData, shardID) =>{});This was originally suggested by @appellation as an alternative to raw/partials quite a while back. I liked the idea back then, however, the idea didn't get much traction as most people thought partials would offer what people were using the raw event for. It seems though, this idea still holds a niche that partials didn't or can't offer.
If this pr gets support, the docs/typings could be greatly improved with more detail of the api data structures. Or simply we could link to discordapp docs for each event type. I only did the basics so that this pr could be made with little wasted effort if the idea is not liked.It appears documenting specifics is something that is specifically unwanted.Status
Semantic versioning classification: