Interaction handlers in the command instead of globally
Honestly. I would much rather add interactions from my command and from there tell to continue in (for example) a different function within that command class than have to handle the interaction in a certain "listener" and keep a state of whats what before the interaction.
34 Replies
Interesting.. thats a different mentality than what I have with them. In a bot I just finished writing for someone, the handler for buttons is a listener (bc no native support yet) and it processes the ID and does the action. Now, of course, this is 1 id, but a collector is not something you can easily revive, a listener-replica is!
Now, registering a button in the command class..gets too messy too fast
what if you send components in an event
what if you send components in a task
You could tell by sending it what should be triggered by it
Not just commands
You can't tho
Buttons in channel.send are dumb
all they store is an id, a name, optional emoji, and a style
and a type for link/non-link
where else would they be?
All you need is the id to achieve what I said tho
Dumb as in they don't have a connection to something
By the id and the listener you could determine what has been stored to be triggered
Wait, what exactly are you asking for? I'm confused
ah ok, then it relates to my #2 : i only use them in-place (with collectors), so i don't have this problem
The thing is, collectors aren't saved
if your bot restarts mid collecting, thats you loosing god knows how many interactions
You should build out your listeners in an abstract way, EXCEPT MAYBE for a one-time confirmation message
The thing is, collectors aren't savedthat's true but the only time i've used them was for a quick prompt in a command, so i didn't really care if the bot restarted (and there was really a very low chance of it restarting in this time)
Sure, but you gotta consider long lasting buttons too
Example: reaction roles, our clicky to agree, etc
yep didn't thought of it, only though of my use cases
👍
so ig it would make sense
Nothing forces you to use our handlers for your use case, but i am trying to collect a bigger picture to see what would be the ideal solution
That goes for normal messages too
message.addButton(() => this.buttonClicked())
Very rough example
Id is generated. Callback is stored somewhere. Untill timeoutNot happening, we cannot extend structures and that is an EXTREMELY LIMITING API
Extending was not intention
And yes. Its limiting in one way. But you're excegarating it's limitness
I am on my phone mind you
Yugen, it's not revivable after a reboot
Bruh
Its never reviveable unless you keep state
Or save it in a db or w/e
Thats on the user side, and it beats the point of a lot of these stateless things 
it is! You always get an event when you click a button
a global listener will always fire
it is! You always get an event when you click a button
a global listener will always fireThis for example is never gonna be saved after a reboot since you have 0 context but an id
an awaitMessageComponent won't
And then what
You dont know what for
You've never used buttons clearly
Which is fine
don't blame you
the custom id can give you a hint, you also get the full message object
so you have a LOT of info already
And then I'll have to figure out from that event what to continue on
Thats basically as much work as just creating a custom listener for it anyways
Not really?
I don't get what you're trying to reach at
And I don't think I can explain it well enough from my phone
Ill continue this tomorrow morning
You can explain it tomorrow
Yeh
There's no rush with this
Off to bed xoxo
Good night
i wanna get it right in 1 shot
nini