Sapphire - Imagine a framework•4y ago

How should you, the end user, define commands?

⚠️ How should you define what application commands are for what command classes, and how should they be registered for you? (SUPER IMPORTANT QUESTION) 1️⃣: Default by the command.name, otherwise command.chatInputName (for chat input commands) or command.contextMenuName for context menus, and provide a utility function on the command store that lets you register them if missing at ready (can go into more details if this option is chosen) 2️⃣: Passing in an array of @discordjs/builders in the command class's options, which get pushed to the API based on client settings (as above, with some options for handling existing commands and what not) 3️⃣: Propose a better solution

50 Replies

UndiedGFX•4y ago

Maybe letting them choose any one? Like making the constructor use an object but make it optional and use a function for builder function and make it optional too? So that people will and can use what they want

vladdyOP•4y ago

That'd be an interface hell

UndiedGFX•4y ago

I mean that's the only better solution I could get into As some people prefer objects While some prefer builder

vladdyOP•4y ago

Thats again not even the question at hand pls re-read

UndiedGFX•4y ago

I go with 1

Unknown User•4y ago

Message Not Public

vladdyOP•4y ago

well the third option is the "other" of forms that basically say "you say something else"

Unknown User•4y ago

Message Not Public

Cyber Grandma•4y ago

Application commands stands for slash commands and context menu right ?

vladdyOP•4y ago

Yes

Cyber Grandma•4y ago

Will those be treated like other commands (in the commands folder) or is it going to be something totally separated ?

vladdyOP•4y ago

That's been answered in <#894234449133322281> pretty sure-right no transcript same folder

24•4y ago

I like approach 2 more, seeing as DJS also has pushed people to use djs/builders Option 1 seems easier in theory, but I think option 2 would be easier to implement and maybe better for people moving from DJS to sapphire

vladdyOP•4y ago

I dunno... putting builders in the command options is..gonna get big fast

24•4y ago

this is true I did enjoy how the setUp method that was theorized in the slash plugin accepted a builder, or was going to

Cyber Grandma•4y ago

So in summary option 1 is that ?

export class DiceCommand extends Command {
    constructor(context: PieceContext) {
        super(context, {
            name: 'Dice',
                        chatInputName: 'dice-chat',
                        contextMenuName: 'dice-slash',
            description: 'Roll your luck !',
        });
    }

    async run(message: Message) {
        const num = Math.round(Math.random() * 5 + 1);
        message.reply(`🎲 You rolled a **${num}** !`);
    }
}

export class DiceCommand extends Command {
    constructor(context: PieceContext) {
        super(context, {
            name: 'Dice',
                        chatInputName: 'dice-chat',
                        contextMenuName: 'dice-slash',
            description: 'Roll your luck !',
        });
    }

    async run(message: Message) {
        const num = Math.round(Math.random() * 5 + 1);
        message.reply(`🎲 You rolled a **${num}** !`);
    }
}

24•4y ago

if we only care about name in the options, no. 1 is best, but if we want to register the whole command, v2 seems best (more flexible) at the cost of the biggie constructor

vladdyOP•4y ago

close, you'd have a different function for chatInputCommands and contextMenuCommands @caesarovich

Cyber Grandma•4y ago

Oh yeah sure run will be deprecated then ?

24•4y ago

run would likely be removed, no?

vladdyOP•4y ago

run is renamed to messageRun

Cyber Grandma•4y ago

A bit sad that we'll have two functions for the same command i guess then we'll only have slash commands so lol

24•4y ago

you could just make a #private method that is called from both of the run methods

vladdyOP•4y ago

24•4y ago

but the logic would be different (interaction.member, msg.member, ect) based on args

Favna•4y ago

where do you want the votes? anyway 1️⃣

24•4y ago

2️⃣

vladdyOP•4y ago

just in messages, I can figure out stuff I personally want 1

24•4y ago

wait we need a poll

Favna•4y ago

@Skyra

Skyra•4y ago

The prefix in this server is currently set to s!

Cyber Grandma•4y ago

is there a documentation for builders ? i never used that

vladdyOP•4y ago

https://github.com/discordjs/builders/blob/main/docs/examples/Slash%20Command%20Builders.md

GitHub

builders/Slash Command Builders.md at main · discordjs/builders

A collection of builders that you can use when creating your bot. - builders/Slash Command Builders.md at main · discordjs/builders

Favna•4y ago

s!poll Option 1, Option 2, Option 3 (please suggest)

Skyra•4y ago

1️⃣ → Option 1 2️⃣ → Option 2 3️⃣ → Option 3 (please suggest)

24•4y ago

ty I think I'll be very much outvoted here but I think both options are good approaches so I don't mind

vladdyOP•4y ago

it barely started lol just wait

24•4y ago

waiting??? ⌚

Cyber Grandma•4y ago

So with builders you can dynamically adapt the command to the context I guess 🤔

vladdyOP•4y ago

the builders are mostly what we'll send to discord

Cyber Grandma•4y ago

I should look into the API docs directly Quite don't get what the new features involves

𝖄𝖚𝖌𝖊𝖓•4y ago

I wouldnt differntiate the name to begin with. I dont see a use in having a different name for a slash command opposed to a chat command. It would in most cases confuse the user why something is named different. Builder could be optional espescially for very good control n your slash command. But honestly. I'd rather have the options on the main definition itself (or a sub object) turned into a builder

vladdyOP•4y ago

Wat Also like, don't forget that unlike message commands, application commands don't support aliases

𝖄𝖚𝖌𝖊𝖓•4y ago

What dont you understand from my message haha I know

Unknown User•4y ago

Message Not Public

vladdyOP•4y ago

nah you definitely got it right There's downsides and upsides for every method >w>

Unknown User•4y ago

Message Not Public

𝖄𝖚𝖌𝖊𝖓•4y ago

My opinion (in the other thread) is already that I dont consider context menus a command anyways. That goes hand in hand with my opinion here.

Unknown User•4y ago

Message Not Public

vladdyOP•4y ago

Discord considers them commands And so will we

Gaming

Programming

How should you, the end user, define commands?