Add client side button transformation as interaction reply. #3415
-
Currently there is no way to reply to a button click without transforming the button style for everyone, or to reply with a new message to the interacting user. Often a new message is not necessary though, take for example reaction roles. After the button is clicked, the roles are given. There is no need to send a success message. Ideally the button would change styles just for that one user, which currently is not possible. I would propose to implement a feature, where a button changes style for that user as a valid interaction reply. To make it a less intrusive change to the API, it could be an ephemeral transformation that changes the button style for that user for a couple seconds to signal the successfull interaction. The more optimal solution would be to change the buttons style for that user permanently (or until the message is edited) but I'm uncertain of the implications of such a feature. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
This would require making message components stateful, which isn’t something we want to do. In the future we’d like to explore having Forms as a solution for stateful interactions, but that’s down the road a bit. You can kind of replicate this behavior with ephemeral messages though! Applying that as a change on top of an existing message is interesting, but I think it would lead to consistency issues for users |
Beta Was this translation helpful? Give feedback.
-
I understand that the permanent change of the buttons style would require the message component to be stateful. But what about just the temporary style change (or even any kind of volatile response, like a checkmark animation or a confirmation popup for a few seconds) ? Wouldnt such a temporary animation as interaction acknowledgement be mostly a client side front end feature (the only thing the API would have to accept is the silent acknowledgement of the interaction). |
Beta Was this translation helpful? Give feedback.
This would require making message components stateful, which isn’t something we want to do. In the future we’d like to explore having Forms as a solution for stateful interactions, but that’s down the road a bit.
You can kind of replicate this behavior with ephemeral messages though! Applying that as a change on top of an existing message is interesting, but I think it would lead to consistency issues for users