serenity
serenity copied to clipboard
serenity-rs
ComponentsV2 support
Opened early, but getting a PR open sooner rather than later doesn't hurt.
TODO:
- [x] Base typing
- [x] Test thoroughly to make sure everything deserializes
- [x] Assure that I'm typing this correctly and not making things vague where it shouldn't be
- [x] Make
Component& others more resilient to discord changes- Right now any change discord makes to components could knock out our Message deserialization.
- [x] Mark under
unstablefeature flag- This is still getting breaking changes and we should wait until rollout before marking this as stable.
- [x] Use FixedString everywhere relevant.
- [x] Add relevant builders
- [x] Document, including updating limits.
Additionally, we really need to PR to current and modify the deserialization to not fail if the top level component is not an ActionRow or it will not deserialize. (See #2963) (Done in #3127)
Once merged, as usual a PR to poise@serenity-next to add support over there too!
Clippy failure does not seem like my fault? But this should be complete now.
I forgot the new field for webhooks, will add later.
Seems like this applies prior to ComponentsV2 too, though the restriction here is that they can only use non-interactive components on non application owned webhooks when sending this query param.
This can be implemented separately as this works on link buttons from my understanding and the information on https:discord/discord-api-docs#7368.
So... this PR should be done completely and now just needs a review (and fixing whatever funky stuff is going on with our CI?)
rebased for review reasons, but due to a timecrunch i haven't added V2 support on webhooks yet, will do in a couple hours when i get back.
rebased for review reasons, but due to a timecrunch i haven't added V2 support on webhooks yet, will do in a couple hours when i get back.
Disregard this comment, i didn't have time to properly check but what was needed was added cleanly in the rebase.
Rebased, history will be a little weird because i removed the macro and stuff entirely from the history, doesn't really matter though, makes even sense while going through.
Will refer to unofficial docs and get this in as best of a state I can before monday, when the draft PR for docs will drop.
A little note to myself (i'm about to test if i messed this up) i'm not sure if putting an enum over the media items is required/better, nullablity is not confirmed completely yet and we won't know until the docs on monday, i'll go over everything one last time then and hopefully nail it.
I have gone ahead and updated it to match official documentation in discord/discord-api-docs#7487, I am technically doing undocumented stuff right now as for whatever reason they didn't add the extra fields for the unfurled media item, not sure if thats intentional or not yet.
This feature has now been officially released! I (hopefully) have nailed it now and it should be ready for any reviews before merge!
I did remove the loading state in the most recent commit, we don't reflect that for embeds (which i think have one too, under the hood) as the docs do not show this.
I will leave it under the unstable feature gate until a little bit after merge (even though its on the next branch) as a precaution as I don't know how stable the de-serialization and stuff is. I've been running it on my bot for a few days and it has been stable though!
Can we remove the unstable gate? It is expected for next to be unstable, the gate is just for undocumented features.
Can we remove the unstable gate? It is expected for next to be unstable, the gate is just for undocumented features.
Done as its documented now, hopefully I removed all the flags lol
Merging due to approving review, also tested it myself for about a month and other users have also been using it for a while and have not reported any issues. I'll get a PR ready for poise soon:tm: (or somebody else can do that)