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
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
š–„š–šš–Œš–Šš–“
Will read after work
vladdy
vladdyā€¢4y ago
pappa @.yugen. šŸ„ŗ
š–„š–šš–Œš–Šš–“
JUST FINISHED DINNER HUSH
vladdy
vladdyā€¢4y ago
owo
š–„š–šš–Œš–Šš–“
Already read it tho So The thing I am trying to do, is look at it from a more user perspective. I personally sometimes get the feeling Sapphire is on such a high code level that the inner workings are sometimes way too hard for people to grasp. Mind that this framework started out for "personal" use, mainly skyra ofc. And I love to see the code produced. But ever since opening up to be the main discord.js, most of the questions people have, are simple; "I want to do X as simple as possible, how do I do it" From those questions stuff like MessagePrompter/PaginatedMessage and such toolings arise. I totally agree with your aproach, and I also know veryw ell that createMessageComponentCollector/awaitMessageComponents exist. But just like messageCollector & reactionCollector they are somehow way too hard to grasp to the average person using our framework (hell people can't even tell discord.js apart from sapphire). What I was trying to say, and what 24 agreed to before favna purged every fcking thing we said. Was that we need tooling to also make this easier on the end user. Hence my idea's of; Give them tooling that could achieve basic functionality. And not directly on the level like keeping state. Managing a database. Etc. The form of which these will be delivered. I don't care. Plugin, djs-utility, core. Idc peeposhrug But I know from a fact that in the current "idea" this will not help 80% of the people trying to use it. --- not done yet, char limit --- I also keep saying "button", as an example < important since buttons are the most basic choice. But even selects/autocompletes etc. Could be handled the same way imo. I can already think of several ways to create utilities that don't require InteractionListeners on that level. Because I can be pretty sure that a rough ~80% of the usecases of those, will be immediate replies. And not something over time and/or longer time (like polls, votekicks, etc) And to be honest, if "restarts" or "bot failures" are a factor in that decision, you'd have to rethink why the fuck your bot requires restarts/bot failures to begin with imo I did however figure that redis for these kind of things might be more perfect than a database (for a lot of cases) You can read/reply ā¤ļø Back to the tv
vladdy
vladdyā€¢4y ago
But why don't you rethink them to actually use the Handlers at that level instead? meguFace think for our own paginated messages we can use buttons now Whats better: 1 handler for all buttons that checks the id and points to the prompter map or one listener per message created? thats one example that comes to mind I get that moving listeners around is not ideal I want this to make users abstract their code a bit more, but also not to overcomplicate it This is why this channel exists, this is why I even specifically pinged you since you were the most vocal of everyone How would YOU envision it?
š–„š–šš–Œš–Šš–“
What do you mean with "one listener per message" My envision is not so much what I would use myself btw, just my perspective on how the people in #old-sapphire-support would use it
vladdy
vladdyā€¢4y ago
await/createMessageComponent adds 1 listener per prompt
š–„š–šš–Œš–Šš–“
Ah yeh, I read that in terms of a listener like we do in the whole class
vladdy
vladdyā€¢4y ago
My method would only add 1 global listener across n handlers
š–„š–šš–Œš–Šš–“
That would honestly be a better way imo Otherwise you'd trigger x listeners that will apply x filters instead of 1 listener triggering x filters
vladdy
vladdyā€¢4y ago
What, my way?
š–„š–šš–Œš–Šš–“
x = n my x = your n
vladdy
vladdyā€¢4y ago
Aha
vladdy
vladdyā€¢4y ago
Yeah but then you'd abstract your code more So again..
š–„š–šš–Œš–Šš–“
I envision a world with no racism, discriminations. Complete peace. Fair wealth among everyone no jk
vladdy
vladdyā€¢4y ago
God i wish
š–„š–šš–Œš–Šš–“
My vision is just; - Global listeners if you want to create stateful interactions/autocompletes/bigger schemes - Simple interactions that you can apply directly and respond to directly in a super easy way
vladdy
vladdyā€¢4y ago
That first one is already what I wanted to do
vladdy
vladdyā€¢4y ago
My issue is the second one
š–„š–šš–Œš–Šš–“
I never said it's trash It's very good
vladdy
vladdyā€¢4y ago
We can tap into it with our utils Like prompters or menus
vladdy
vladdyā€¢4y ago
But in general..how
š–„š–šš–Œš–Šš–“
That's where I struggle to take the decision discord.js has ways to do it, but I don't think those are optimal
vladdy
vladdyā€¢4y ago
D.js's collectors add 1 listener per call
š–„š–šš–Œš–Šš–“
Yes which is inefficient
vladdy
vladdyā€¢4y ago
Plus you'd need to filter it yourself again
vladdy
vladdyā€¢4y ago
Well actually no bc it filters by msg id Actually it does all filtering except custom id It's still more inefficient
š–„š–šš–Œš–Šš–“
A plugin/utility or whatever that adds a global listener and a simple (in memory) state with a few helper functions is all that's needed imo and ofcourse, that global listener can be extended from the first solution I'll tell you what
vladdy
vladdyā€¢4y ago
You're secretly bi?
š–„š–šš–Œš–Šš–“
I agree with your vision, for the normal listeners. I'll see if I can create the helper methods on top of that extending from your work
vladdy
vladdyā€¢4y ago
Should be super simple to tap into it from the global ones
vladdy
vladdyā€¢4y ago
For instance for sapph utils like paginated messages we have the filter method Which I'll actually change to a custom id parser
š–„š–šš–Œš–Šš–“
same for message prompter basically šŸ˜›
vladdy
vladdyā€¢4y ago
Mhm
š–„š–šš–Œš–Šš–“
but yes and if we see in #old-sapphire-support people struggling with the "built-in" method, we could always decide to move the utility into framework afterwards
vladdy
vladdyā€¢4y ago
Utils shouldn't be directly in framework Should be something you install
vladdy
vladdyā€¢4y ago
Bc not everyone needs them
š–„š–šš–Œš–Šš–“
depends on the need yes hence why I said, that decision could be made afterwards if we see a lot of demand for it
vladdy
vladdyā€¢4y ago
Mhm But you're fine with the core idea of the global one, right?
vladdy
vladdyā€¢4y ago
At least that's good I'm not completely bad šŸ˜‚ I'm totally sure with a system like this you can build some amazing utilities Especially since it points you towards abstraction
vladdy
vladdyā€¢4y ago
See it wasn't that hard to discuss
š–„š–šš–Œš–Šš–“
I KEKW was shot down so I cried loud BABABABABAA MY OPINION IS ALSO MATTERS
vladdy
vladdyā€¢4y ago
Is also matters I don't mind different opinions, why do you think I made this entire channel šŸ˜‚ I want peoples thoughts
Want results from more Discord servers?
Add your server