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

UndiedGFX•953d 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

vladdy•953d ago

That'd be an interface hell

UndiedGFX•953d ago

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

vladdy•953d ago

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

UndiedGFX•953d ago

I go with 1

Unknown User•953d ago

Message Not Public

vladdy•953d ago

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

Unknown User•953d ago

Message Not Public

Cyber Grandma•953d ago

Application commands stands for slash commands and context menu right ?

vladdy•953d ago

Yes

Cyber Grandma•953d ago

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

vladdy•953d ago

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

24•953d 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

vladdy•953d ago

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

24•953d 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•953d 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•953d 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

vladdy•953d ago

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

Cyber Grandma•953d ago

Oh yeah sure run will be deprecated then ?

24•953d ago

run would likely be removed, no?

vladdy•953d ago

run is renamed to messageRun

Cyber Grandma•953d 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•953d ago

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

vladdy•953d ago

24•953d ago

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

Favna•953d ago

where do you want the votes? anyway 1️⃣

24•953d ago

2️⃣

vladdy•953d ago

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

24•953d ago

wait we need a poll

Favna•953d ago

@Skyra

Skyra•953d ago

The prefix in this server is currently set to s!

Cyber Grandma•953d ago

is there a documentation for builders ? i never used that

vladdy•953d 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•953d ago

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

Skyra•953d ago

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

24•953d ago

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

vladdy•953d ago

it barely started lol just wait

24•953d ago

waiting??? ⌚

Cyber Grandma•953d ago

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

vladdy•953d ago

the builders are mostly what we'll send to discord

Cyber Grandma•953d ago

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

𝖄𝖚𝖌𝖊𝖓•953d 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

vladdy•953d ago

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

𝖄𝖚𝖌𝖊𝖓•953d ago

What dont you understand from my message haha I know

Unknown User•953d ago

Message Not Public

vladdy•953d ago

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

Unknown User•953d ago

Message Not Public

𝖄𝖚𝖌𝖊𝖓•953d 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•953d ago

Message Not Public

vladdy•953d ago

Discord considers them commands And so will we

Sapphire - Imagine a framework Join

Welcome to the Sapphire Discord server! The next-gen object-oriented Discord.js bot framework can be found here.

2.2KMembers

View on Discord

Want results from more Discord servers?

Add your server

Preconditions with missing handlers! What do?**Preconditions**: What should happen with preconditions (global or not) that need to run on a messa Context Menus vs Application Commands - separate or not?**Question time** ❓ Context menus.. they exist. They're like used once a blue century. How should Interaction Handlers after usageWant to give interaction handlers a shot **now**? Well, you can! Just run the command below and giv Interaction Handlers!!Hello peeps! I know, I know, allllll of you (myself included) are just basically begging me for app Initial Commit ThoughtsI've pushed the initial commit for interaction handlers: heavily wip, totally untested and raw (just The statefulness or statelessness of Interactions1. Most likely, but it would be a nice addition if I was able to have non-state "callbacks" as menti Interaction handlers in the command instead of globallyHonestly. I would much rather add interactions from my command and from there tell to continue in (f Reply sess 2**1.** Yes. This also follows the design pattern that we more-or-less employ already for Sapphire. W dont feel like creating a review on GitHub...PR is up: https://github.com/sapphiredev/utilities/pull/152 CC @kyra 🩵🩷🤍🩷🩵 @vladdy

Gaming

Programming

How should you, the end user, define commands?