Managed application commands

[portasynthinca3]

This pull request is intended to reduce boilerplate in projects that use application commands. Instead of requiring library users to implement a Consumer and manually handle INTERACTION_CREATE events, this pull requests enables them to define a separate module per command containing the command specification and its handling function.

As a bonus, it removes magic numbers in command specs, instead opting in for atoms, and merges some spec fields into one field (for example, name and name_localizations are represented as a tuple and value_min and value_max as a range)

[jchristgit]

Thank you for the PR, and sorry for the late review!

This looks mostly good. It suffers from one problem: when an event is received, it's passed to a random consumer, due to the way we're using GenStage at the moment.

I think a better solution than to create an internal consumer would be to simply instruct users to call handle_event or maybe just a function handle_interaction that is called directly with the received interaction.

[jchristgit]

Hi @portasynthinca3!

On master we removed GenStage in favour of :pg. In theory your usage of making a new consumer works with it, but in practice I think it's more straightforward for users to simply have an API they forward :INTERACTION_CREATE events in their consumer to.

What do you think?

[portasynthinca3]

Hi! Sorry for not replying earlier. I have a couple of design decisions that i need but cannot make:

1. Does this belong in the main library? When I originally presented my PR in the unofficial Discord API server, people there suggested that I instead make it into a separate library, so I started working on that. It even included a powerful but not-fully-complete localization engine. I stopped working on it because I kind of stopped programming for a while, but I will for certain return to it later.
2. While I do agree that users passing :INTERACTION_CREATE events to this component of the main library or my separate library, whatever shape my idea ends up taking, is more "Elixir-ian" and more true to FP dogmas, I also think that automatic handling of the events will result in less boilerplate on the user side

So, what do you think?

[jchristgit]

Does this belong in the main library? When I originally presented my PR in the unofficial Discord API server, people there suggested that I instead make it into a separate library, so I started working on that. It even included a powerful but not-fully-complete localization engine. I stopped working on it because I kind of stopped programming for a while, but I will for certain return to it later.

Hmm this is a good point. Having it separately is also how I do it in my command library and it works well. I wouldn't mind accepting it into the main library giving that Discord's builtin slash commands have gotten relatively good, and should help remove much boilerplate when writing commands, but I do understand Nostrum is still relatively low-level so I agree that a separate library would be better.

While I do agree that users passing :INTERACTION_CREATE events to this component of the main library or my separate library, whatever shape my idea ends up taking, is more "Elixir-ian" and more true to FP dogmas, I also think that automatic handling of the events will result in less boilerplate on the user side

I am a fan of reducing boilerplate, but in this case, as we currently have no way of limiting consumers to specific events, it means effectively duplicating all gateway events to the app's consumer and this one. If your bot is big enough this can cause considerable load increase, and I think we should strive to keep it relatively efficient.