You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The traditional commands can be easily modularized by extending a module with Discordrb::Commands::CommandContainer. With slash commands however, there is a second method to register the command on Discord. As far as I can tell, currently, only the application_command method can be factored out into separate modules in the same way as traditional commands by extending with Discordrb::EventContainer. The method register_application_command is defined as an instance method of Discordrb::Bot, which therefore is unavailable in those separate modules.
It would be nice if discordrb allowed developers to extract the application commands together with the registration to separate modules.
I’m not sure how a good implementation should look like. The method #register_application_command obviously does not belong in Discordrb::EventContainer. Also, it works differently from #application_command since it does not store anything but directly talks to the Discord API.
Maybe both could be combined in a single new module anyway, roughly like this:
Create a new module, e.g. Discordrb::ApplicationCommandContainer.
Move everything about application commands from Discordrb::EventContainer into the new module.
Define a method Discordrb::ApplicationCommandContainer#register_application_command whose usage is exactly like Discordrb::Bot#register_application_command, but instead of immediately talking to the Discord API, it yields to the block and stores the parameters and builders in a variable.
Include the new module in Discordrb::Bot. The existing Discordrb::Bot#register_application_command would then shadow the one from the new module (this could be a bad practice, not sure), which allows to still register application commands whenever one pleases.
When the bot is actually started, send the stored command registrations to the Discord API.
I think I prefer the above approach, but for backwards compatibility step 2 could be removed or postponed until 4.0 or so.
I’ld be happy to create a PR if accepted.
The text was updated successfully, but these errors were encountered:
The traditional commands can be easily modularized by extending a module with
Discordrb::Commands::CommandContainer
. With slash commands however, there is a second method to register the command on Discord. As far as I can tell, currently, only theapplication_command
method can be factored out into separate modules in the same way as traditional commands by extending withDiscordrb::EventContainer
. The methodregister_application_command
is defined as an instance method ofDiscordrb::Bot
, which therefore is unavailable in those separate modules.It would be nice if
discordrb
allowed developers to extract the application commands together with the registration to separate modules.I’m not sure how a good implementation should look like. The method
#register_application_command
obviously does not belong inDiscordrb::EventContainer
. Also, it works differently from#application_command
since it does not store anything but directly talks to the Discord API.Maybe both could be combined in a single new module anyway, roughly like this:
Discordrb::ApplicationCommandContainer
.Discordrb::EventContainer
into the new module.Discordrb::ApplicationCommandContainer#register_application_command
whose usage is exactly likeDiscordrb::Bot#register_application_command
, but instead of immediately talking to the Discord API, it yields to the block and stores the parameters and builders in a variable.Discordrb::Bot
. The existingDiscordrb::Bot#register_application_command
would then shadow the one from the new module (this could be a bad practice, not sure), which allows to still register application commands whenever one pleases.I think I prefer the above approach, but for backwards compatibility step 2 could be removed or postponed until 4.0 or so.
I’ld be happy to create a PR if accepted.
The text was updated successfully, but these errors were encountered: