Subcommand and nested subcommand roots can't be invoked.

[trevorflahardy]

Motivation

Many popular libraries, such as discord.py, have support for group commands, in which the root of a group can be invoked by the user. Let's take a look at a simple example of this in dpy.

# !foo
@bot.group(invoke_without_command=True)
async def foo(ctx):
    if ctx.invoked_subcommand:
        return
    
    return await ctx.send("foo!")

# !foo cas
@foo.command()
async def cas(ctx):
    return await ctx.send('foo cas!')

# !foo bar
@foo.group(invoke_without_command=True)
async def bar(ctx):
    if ctx.invoked_subcommand:
        return
    
    return await ctx.send('foo bar!')

# !foo bar sub
@bar.command()
async def sub(ctx):
    return await ctx.send('foo bar sub!')

This is currently not possible with Slash Commands due to how subcommands and nested subcommands are managed. I feel this was a large factor in message intent based groups and can be implemented into slash commands. This could maybe strike a needed change in the json representation of a slash command?

Current Solution

Have a slash command with only it's subcommands and nested subcommands being invokable. This limits the possibility of 4 commands in one group to only 2.

For example

You can see this in practice here,

and a json representation here:

{
    "name": "foo",
    "description": "No description given.",
    "type": 1,
    "default_permission": true,
    "options": [
        {
            "name": "cas",
            "type": 1,
            "description": "No description given.",
            "options": null
        },
        {
            "name": "bar",
            "description": "No description given..",
            "type": 2,
            "options": [
                {
                    "name": "sub",
                    "type": 1,
                    "description": "No description given.",
                    "options": null
                }
            ]
        }
    ]
}

My Goal

To start a discussion about how application commands work and the improvements that can be made upon them to benefit bot developers.

What I propose

Creating a way to make the root of slash command groups invokable.

A way to do this

There are many ways to go about this. A new Option Type could be created in which a params key and value must be included, the entire application command object could be rewritten, there hundreds of good and bad ways to think about it. Let's take a look at two of the possibilities just to throw a ball in the park.

A Simple Fix

Append the root's options onto the array of options when making a group. This would be a quicker fix and allow the concept to be implemented faster. All you need to do is to add the options that aren't type 1 or 2 and append them as parameters. For example:

Invokable commands:

• /foo <member>
• /foo cas <member>
• /foo bar <member>
• /foo bar sub <member>

{
    "name": "foo",
    "description": "No description given.",
    "type": 1,
    "default_permission": true,
    "options": [
        {
            "name": "cas",
            "type": 1,
            "description": "No description given.",
            "options": [
                {
                    "name": "member",
                    "description": "Member to mention.",
                    "type": 6,
                    "required": true
                }
            ]
        },
        {
            "name": "bar",
            "description": "No description given..",
            "type": 2,
            "options": [
                {
                    "name": "sub",
                    "type": 1,
                    "description": "No description given.",
                    "options": [
                        {
                            "name": "member",
                            "description": "Member to mention.",
                            "type": 6,
                            "required": true
                        }
                    ]
                },
                {
                    "name": "member",
                    "description": "Member to mention.",
                    "type": 6,
                    "required": true
                }
            ]
        },
        {
            "name": "member",
            "description": "Member to mention.",
            "type": 6,
            "required": true
        }
    ]
}

Reworking The Object

The best way, and the way that takes the most work, is to rework the Application Command object. With a simple mockup, I separated subcommands and options. Please note I did this in 5 minutes it's not at all official.

Invokable commands:

• /foo <member>
• /foo cas <member>
• /foo bar <member>
• /foo bar sub <member>

{
    "name": "foo",
    "description": "No description provided.",
    "type": 1,
    "default_permission": true,
    "options": [
        {
            "name": "member",
            "description": "Member to mention.",
            "type": 6,
            "required": true
        }
    ],
    "subcommands": [
        {
            "name": "cas",
            "description": "No description provided.",
            "type": 1, 
            "options": [
                {
                    "name": "member",
                    "description": "Member to mention.",
                    "type": 6,
                    "required": true
                }
            ]
        },
        {
            "name": "bar",
            "description": "No description provided.",
            "type": 2, 
            "options": [
                {
                    "name": "member",
                    "description": "Member to mention.",
                    "type": 6,
                    "required": true
                }
            ],
            "subcommands": [
                {
                    "name": "sub",
                    "description": "No description provided.",
                    "type": 1, 
                    "options": [
                        {
                            "name": "member",
                            "description": "Member to mention.",
                            "type": 6,
                            "required": true
                        }
                    ]
                }
            ]
        }
    ]
}

Although both show some benefits, it's ultimately within the best interest to go with the "Simple Fix" in my opinion, in which the root's options are just appended onto the array of options. What do you think?

[ckohen]

I'm fairly certain the idea behind the default parameter (that currently does nothing) was to support a similar flow. E.g. user did not select a subcommand, so use the default.

Since actually implementing this requires a redesign of the UI first (which requires whatever database rework that keeps being mentioned) maybe there is even a chance to add a display boolean or similar to the default subcommand to hide that subcommands name in command window.

Regarding the above, I initially didn't like the command structure that this solution yields, but I do think it will make DX better on the receiving side too.

[Harmon758]

This seems like a duplicate of #3804.