Incremental Slash Command Loading

[chakany]

The Problem

Slash commands are great, but the amount of commands you can register (only 100) can cause bots that do many things to hold off on implementing them.
It was recently mentioned during a Q&A that if the limit for slash commands were to be increased it could possibly cause older devices to heavily lag.

The Solution

Loading Slash Commands Incrementally in the UX could theoretically allow for an infinite number of slash commands. This would make the jump be easier for multiple developers, and the user wouldn't be impacted in a meaningful way.
How this would look, well i have a few ideas.

• Turning bot commands into their own tabs instead of scrolling into each other, and having the user click through them to see the commands for each bot.
• Keeping it the way it is and just throwing it in.

If anyone has any better ideas on how to implement this, then please comment.

[c-bec-k]

You can register 100 top-level commands. But each can have up to 25 sub-commands. That's 2,500 commands.

Or you can have 25 sub-command groups and 25 sub-commands per group. That 62,500 total commands.

[chakany]

Yes, and i've tried this approach before. It's honestly a bad approach with how subcommands are handled in their current state.

If my commands were grouped by category and I typed in the subcommand, it would not show up in the search. This is annoying for the user because now they have to remember the command name, and the category name. Subcommands are great for their uses, but for other types of commands they don't work as well.

[quirky-bluejay]

Fuzzy matching ( #2323 (comment) ) and an improved subcommand display are planned, I agree that the current situation isn't that great however I think something like this could make the ux potentially worse, (for example the slight delay on autocomplete, but for commands)

[IanMitchell]

In addition to the answer above, we do currently lazily load commands to display in our autocomplete box.