Differentiate gateway sticker events #3358
Replies: 4 comments 5 replies
-
I'm not against the idea of having more GUILD_STICKER_* events, but I have a feeling this to be consistent with guild emoji events (although UPDATED should be UPDATE I suppose). I'd prefer if this behavior was the same for emojis too. |
Beta Was this translation helpful? Give feedback.
-
As do I; this issue goes towards emojis as well, didn't realize that they had the same behavior until I looked at what our library does. |
Beta Was this translation helpful? Give feedback.
-
Which is the "dump cache and throw it to the user to handle" approach |
Beta Was this translation helpful? Give feedback.
-
I'd like to add here that stickers should be handled in a manner more like emojis in more ways than one. I've found that if we're looking to track stickers at all, we have limited access to sticker info, like which guild a sticker's originating from. Ideally, a list of stickers would be provided at At the moment, what information is provided regarding stickers is flawed. There is no reason to have a |
Beta Was this translation helpful? Give feedback.
-
Description
Right now, when a guild sticker gets added/removed/update, they all simply fire GUILD_STICKER_UPDATED, which, for hopefully obvious reasons is a bit of a pain in the side.
Why This is Needed
From a library dev/maintainer pov, there's two options that can be deduced when it comes to handling updates to stickers (and by extensions emojis, it seems)
Either:
Alternatives Considered
Going through a cached lookup, compare each sticker (or sticker count), and handle the appropriated event, but this is a bit cumbersome.
Beta Was this translation helpful? Give feedback.
All reactions