I’m trying to build a chat app. When receiving IRC messages that use an emote, that message contains the emote ID and its position.
The emotes documentation insists quite a lot that one should not be trying to guess the supported scales, themes, and formats for a given emote, but instead use the helix/chat/emotes/set route to get more info about the emote and use the returned info and template URL to craft the emote’s image URL.
Unfortunately, this route only accepts an emote set ID, and all I have when receiving the message is the emote ID.
What is the officially recommended behavior in this case? Is it safe to request an emote with a light theme if it doesn’t explicitly support it? With a 3.0 scale? The problem seems less obvious for the format since it accepts a default parameter, which is animated if the emote supports it and properly falls back to static. Should there be a Helix endpoint that accepts an emote ID instead of an emote set ID?
default - then its aniamted if it is and static if it isn’t 2.0 for size - what size you want to use will depend on your app and it’s scaling and if you want retina display/etc and so on dark/light twill depends on the user using my chat app and let them theme selete, but generally I use dark as my default
The format of the image to get. For example, a static PNG or animated GIF. Use default if you want the server to return an animated GIF if it exists, otherwise, a static PNG.
Default makes life easier as you don’t need to know what formats a given emote supports.
Generally speaking all emotes have a 1.0/2.0/3.0 so you don’t need to worry about that.
So there is a happy default you can use to construct URL’s with.
The logic here is that you are operating on a single channel set of emote, not all emotes across all of Twitch, it would seem. So you generally only need to fetch one set of emotes, or only the emotesets the authenticated user has access to.