Sapphire - Imagine a framework𝖄𝖚𝖌𝖊𝖓

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.

vladdy•968d 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

𝖄𝖚𝖌𝖊𝖓•968d ago

Will read after work

vladdy•968d ago

pappa @.yugen. 🥺

𝖄𝖚𝖌𝖊𝖓•968d ago

JUST FINISHED DINNER HUSH

vladdy•968d ago

owo

𝖄𝖚𝖌𝖊𝖓•968d ago

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•968d 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?

𝖄𝖚𝖌𝖊𝖓•967d ago

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•967d ago

await/createMessageComponent adds 1 listener per prompt

𝖄𝖚𝖌𝖊𝖓•967d ago

Ah yeh, I read that in terms of a listener like we do in the whole class

vladdy•967d ago

My method would only add 1 global listener across n handlers

𝖄𝖚𝖌𝖊𝖓•967d ago

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•967d ago

What, my way?

𝖄𝖚𝖌𝖊𝖓•967d ago

x = n my x = your n

vladdy•967d ago

Aha

𝖄𝖚𝖌𝖊𝖓•967d ago

hahaha

vladdy•967d ago

Yeah but then you'd abstract your code more So again..

𝖄𝖚𝖌𝖊𝖓•967d ago

I envision a world with no racism, discriminations. Complete peace. Fair wealth among everyone no jk

vladdy•967d ago

God i wish

𝖄𝖚𝖌𝖊𝖓•967d ago

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•967d ago

That first one is already what I wanted to do

𝖄𝖚𝖌𝖊𝖓•967d ago

Yeh I know

vladdy•967d ago

My issue is the second one

𝖄𝖚𝖌𝖊𝖓•967d ago

I never said it's trash It's very good

vladdy•967d ago

We can tap into it with our utils Like prompters or menus

𝖄𝖚𝖌𝖊𝖓•967d ago

Possibly yeh

vladdy•967d ago

But in general..how

𝖄𝖚𝖌𝖊𝖓•967d ago

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•967d ago

D.js's collectors add 1 listener per call

𝖄𝖚𝖌𝖊𝖓•967d ago

Yes which is inefficient

vladdy•967d ago

Plus you'd need to filter it yourself again

𝖄𝖚𝖌𝖊𝖓•967d ago

yup

vladdy•967d ago

Well actually no bc it filters by msg id Actually it does all filtering except custom id It's still more inefficient

𝖄𝖚𝖌𝖊𝖓•967d ago

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•967d ago

You're secretly bi?

𝖄𝖚𝖌𝖊𝖓•967d ago

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•967d ago

Should be super simple to tap into it from the global ones

𝖄𝖚𝖌𝖊𝖓•967d ago

Yup

vladdy•967d ago

For instance for sapph utils like paginated messages we have the filter method Which I'll actually change to a custom id parser

𝖄𝖚𝖌𝖊𝖓•967d ago

same for message prompter basically 😛

vladdy•967d ago

Mhm

𝖄𝖚𝖌𝖊𝖓•967d ago

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•967d ago

Utils shouldn't be directly in framework Should be something you install

𝖄𝖚𝖌𝖊𝖓•967d ago

yes and no

vladdy•967d ago

Bc not everyone needs them

𝖄𝖚𝖌𝖊𝖓•967d ago

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•967d ago

Mhm But you're fine with the core idea of the global one, right?

𝖄𝖚𝖌𝖊𝖓•967d ago

Yeh totally

vladdy•967d 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

𝖄𝖚𝖌𝖊𝖓•967d ago

yuppers

vladdy•967d ago

See it wasn't that hard to discuss

𝖄𝖚𝖌𝖊𝖓•967d ago