Is your feature request related to a problem? Please describe.
I've realized that a lot of our types for events are overly complex and can lead to a frustrating developer experience when it comes to handling these events. Take the memberUnbanned event. The parameter that's emitted could be either a MemberBan object, or the raw ws event data itself. This leads to having to do the following:
This is a sub-par developer experience. A developer shouldn't have to structure their event to handle two different potential objects. This isn't the only event that this happens in, as it also happens in:
Describe the solution you'd like
For events that emit either a structure or the ws data dependent on if a structure is cached or not, just go with the ws data (example, just make the type WSChatMessageDeletedPayload["d"]). That makes it a more simple interface, and also lets the user decide if they need the actual structure from cache or not.
Is your feature request related to a problem? Please describe. I've realized that a lot of our types for events are overly complex and can lead to a frustrating developer experience when it comes to handling these events. Take the memberUnbanned event. The parameter that's emitted could be either a
MemberBan
object, or the raw ws event data itself. This leads to having to do the following:This is a sub-par developer experience. A developer shouldn't have to structure their event to handle two different potential objects. This isn't the only event that this happens in, as it also happens in:
messageDeleted
messageReactionDeleted
memberRemoved
memberUpdated
memberBanned
memberUnbanned
Describe the solution you'd like For events that emit either a structure or the ws data dependent on if a structure is cached or not, just go with the ws data (example, just make the type
WSChatMessageDeletedPayload["d"]
). That makes it a more simple interface, and also lets the user decide if they need the actual structure from cache or not.