feat(emoji)!: implement app emojis
Summary
- Closes GH-1223
Checklist
- [ ] If code changes were made, then they have been tested
- [x] I have updated the documentation to reflect the changes
- [x] I have formatted the code properly by running
pdm lint - [x] I have type-checked the code by running
pdm pyright
- [ ] This PR fixes an issue
- [x] This PR adds something new (e.g. new method or parameters)
- [ ] This PR is a breaking change (e.g. methods or parameters removed/renamed)
- [ ] This PR is not a code change (e.g. documentation, README, ...)
I marked this ready for review even though i still don't know if we should provide the ability to cache app emojis at startup, as you can see i did put a boolean argument but didn't implement any logic for it so far.
I'm strongly in favor of splitting the models into a
GuildEmojiandAppEmoji. The current approach is pretty much saying "an Emoji can have both.guild_idand.application_id, one of, or neither!"Anyhow, minor nitpicks below.
If we want to split them into different classes (I had this talk with @shiftinv in the past, but at the time they said it was fine to go with this approach) we would most likely split them into Emoji and AppEmoji to minimize breaking changes
I'm strongly in favor of splitting the models into a
GuildEmojiandAppEmoji. The current approach is pretty much saying "an Emoji can have both.guild_idand.application_id, one of, or neither!" Anyhow, minor nitpicks below.If we want to split them into different classes (I had this talk with @shiftinv in the past, but at the time they said it was fine to go with this approach) we would most likely split them into
EmojiandAppEmojito minimize breaking changes
@shiftinv did your opinion change on this?
Documentation build overview
📚 disnake | 🛠️ Build #29602396 | 📁 Comparing ffb7bde2c17c0c3b39cd1229fe26e824b40f1d61 against latest (dca108c373e9f1277dbdf223457d3bddde79b791)