Sapphire - Imagine a framework•4y ago

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 just call it 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 or 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.

53 Replies

vladdy•4y ago

A common thing you're talking about is wanting to have callbacks directly in your code that calls things - think a prompt class like the one you made. That's already possible with discord.js's included methods (createMessageComponentCollector/awaitMessageComponents). The thing is, you need to think about buttons and select menus (and whatever further interactions, like autocompletes) as things that have no relation with anything past the custom id. You need a custom id to have SOMETHING happen when you press the button. Here's an example: I wrote a vote kick command for someone, which uses buttons. The listeners are abstracted from the message creation because: 1. In the event of a restart, the votekick can keep processing (thats cause I store in a db that it happens) 2. The only thing I know is that its a votekick for a user and a channel. My custom id is literally votekick.action.<user id>.<voice channel id>. I don't care about the message, I just process it in a separate file 3. Imagine if long lasting prompts - think polls, reaction roles, etc - were saved in a db by you and revived when you started the process. Abstracting the listener code should be done since they don't depend on the message's presence. Hell, the message could be uncached completely, and you'd still get a button press! I'm gonna be very opinionated unless you can help me understand your PoV better but there won't be any janky hacky callback map thing happening. With this, it's simple, to the point, like 10 lines of code total for handling any buttons, maybe 15 if you wanna filter them to only process specific buttons, etc. I get that you don't want to jump between files for handling a damn button, fair fair. But the thing is you're not abstracting them as 2 separate things, but are trying to keep them in one place/entity. Yes, messages have buttons, but soon there's another interaction for it, for autocompletes, and would you rather have to do messy code to reply to one or a simple

export default class extends InteractionHandler {
    constructor(ctx) { super(ctx, { interactionType: InteractionTypes.ApplicationCommandAutocompleteOrWhateverItsCalled }); }

    async run(interaction) { await interaction.respond([{ name: 'OwOing in the 90s', value: 'owo-90' }]); }
}

export default class extends InteractionHandler {
    constructor(ctx) { super(ctx, { interactionType: InteractionTypes.ApplicationCommandAutocompleteOrWhateverItsCalled }); }

    async run(interaction) { await interaction.respond([{ name: 'OwOing in the 90s', value: 'owo-90' }]); }
}

In fact, we could even change the filter method altogether! Instead of a custom id filter/parser, you filter on the interaction, or parse from the interaction (think: one file per autocomplete per command - ALTHOUGH THIS IS TBD and not set in stone as I might move that to the command class but I don't wanna bloat that class too much sweats

want the interface to be simple, abstract, and more in line with how Discord does it I know I won't be able to please everyone, thats a given, but a given i will accept But I'd really really really love your thoughts still @.yugen. 🥺 When you have time, of course

Gaming

Programming

The statefulness or statelessness of Interactions