Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Slash commands/application commands #93

Open
eritbh opened this issue Aug 22, 2021 · 0 comments · May be fixed by #100
Open

Slash commands/application commands #93

eritbh opened this issue Aug 22, 2021 · 0 comments · May be fixed by #100
Labels
changes: api modifies behavior of the public API enhancement something doesn't happen that should version: major semver-major, involves breaking change
Milestone

Comments

@eritbh
Copy link
Owner

eritbh commented Aug 22, 2021

I've started messing around with the structures for application commands and it seems pretty viable to integrate them into Yuuko, though I'm not exactly sure how much of the existing Command structure they can share if any. Here's my initial notes.

Key differences and some thoughts on how we could unify the two structures:

  • Application commands can be global or per-guild, Yuuko commands only apply globally unless a custom requirement restricts them to a particular guild
    • Yuuko commands could be set up to be per-guild pretty easily, it should be trivial to have them share an option for that functionality
  • Application command handlers work with interactions, traditional commands are triggered by messages
    • Some core methods like createMessage exist on both structures in Eris, which helps, but ultimately there's no working around this difference
  • Application commands can be triggered by multiple sources (slash command, context buttons), traditional commands are triggered only by messages
    • More types of "traditional" commands built into Yuuko for events like reactions being added? I don't really see many ways to do anything about this though
    • Since context button commands take a single argument, it should probably be pretty easy to emulate those actions via a text-based traditional command that specifies the argument value
  • Application commands have structured arguments, Yuuko commands work solely on text content
    • Yuuko's argument parsing has been in the works for a while, but I wanted to take the route of throwing some parsing methods inside the command body rather than storing the argument types directly as parts of the command, so that's kinda out the window now
    • That said, the structured types Discord has are relatively simple, so it shouldn't be difficult to implement their parsing functionality
    • In order to avoid limiting the possible argument types for existing text-based commands, I think it's important that using structured arguments for text-based commands is optional
  • Application command subcommands can be triggered from any argument position, Yuuko subcommands are limited to the first argument position
    • Frankly Discord's idea for subcommands here is just better, Yuuko should take inspiration from this for its own command system regardless of these changes

So essentially I think what I want is a new Command-like class that can handle app commands as well as traditional commands, more or less providing a compatibility layer between application commands and text-based commands.

Something absolutely necessary for supporting application commands: When commands are registered to the client, the client is responsible for verifying that the commands exist in the right place on the server and updating things if not. Consumers shouldn't have to worry about posting to the API to update their commands when changes are made, that's the library's job.

@eritbh eritbh added enhancement something doesn't happen that should changes: api modifies behavior of the public API version: major semver-major, involves breaking change labels Aug 22, 2021
@eritbh eritbh added this to the v3 milestone Aug 22, 2021
@eritbh eritbh pinned this issue Sep 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
changes: api modifies behavior of the public API enhancement something doesn't happen that should version: major semver-major, involves breaking change
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant