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
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
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 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 courseWill read after work
pappa @.yugen.
š„ŗ
JUST FINISHED DINNER HUSH
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
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 tvBut why don't you rethink them to actually use the Handlers at that level instead? 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
await/createMessageComponent adds 1 listener per prompt
Ah yeh, I read that in terms of a listener like we do in the whole class
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
What, my way?
x = n
my x = your n
Aha
hahaha
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
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
That first one is already what I wanted to do
Yeh I know
My issue is the second one
I never said it's trash
It's very good
We can tap into it with our utils
Like prompters or menus
Possibly yeh
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
D.js's collectors add 1 listener per call
Yes
which is inefficient
Plus you'd need to filter it yourself again
yup
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
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
Should be super simple to tap into it from the global ones
Yup
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 š
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
Utils shouldn't be directly in framework
Should be something you install
yes and no
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
Mhm
But you're fine with the core idea of the global one, right?
Yeh totally
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
yuppers
See it wasn't that hard to discuss
I was shot down
so I cried loud
BABABABABAA MY OPINION IS ALSO MATTERS
Is also matters
I don't mind different opinions, why do you think I made this entire channel š
I want peoples thoughts