104 replies

The statefulness or statelessness of Interactions

1. Most likely, but it would be a nice addition if I was able to have non-state "callbacks" as mentioned in my thread before. I don't fear the restarts being a huge issue and personally I'd like to refrain from jumping back and forth between several code sources to reply to an interaction.
2. For certain things yes, but that's very usecase heavy. As mentioned above. Most of my usecases will usually be immediate replies and not collecting x for some poll or something (in which case I'd have a state).

I also think most usecases in general do not have the need to keep state and are easier done by just allowing callbacks after initiating (keeping track of them by a map or something idk)

3. Yes maybe, I would also like to add that this might be called different. Instead of

customId

customId

just call it

ID

ID

, that way we can force users to work a certain way a bit more than give the impression that they can apply any id necessary. I think it would be most beneficial to keep the same way discord/discord.js handle id's than leave it to the user. Just for the sake of consistency
4. As of our recent discussion I do get the feeling it's a bit too hard to use for the average user. Simple utilities like the

MessagePrompter

MessagePrompter

PaginatedMessage

PaginatedMessage

are a prime example of what users expect to be handed when trying to create a paginated message or something else. Instead of writing their own collectors (this is just an example on those 2, not on interactions itself).

As a last word, if I have a misunderstanding on interactions, please correct me. I did some reading before sending this and think I have quite the understanding of what you're trying to achieve. But listeners/arguments/preconditions are already hard stuff for a lot of people. Keeping it simple is key I guess. Especially when this is the most requested feature in forever.