For a long time, the demand for interaction handlers in Sapphire has grown exponentially with time! The good news is that I finally have something to show you, and I think this will allow for some super clean code on your side!
With this, you can now easily handle your buttons, your select menus, and further interaction types, while keeping your code focused, clean, stateless and abstract! Of course, you're not required to use this, but why wouldn't you use this? 🥺
These are interaction handlers! A simple class you can extend to handle almost all the interactions you may receive in your bot, in a simple, clean and abstract way.
They are located in the interaction-handlers
folder in your bot (just like how you most likely have a commands
folder or a listeners
folder). Same rules apply when it comes to loading and everything!
When creating your interaction handler, you have to specify the type it is. Currently, there are three types:
These types define what the handler should get. For instance, specifying a Button
interaction handler type will make that handler receive just button interactions.
But that's not all! There's also a parse
method which can be used for even more granular control (read below).
By default, there is no filter for the
parse
method! This means you'll get all interactions of that type, and if you want to override that (for example to only run that handler for certain ids), you'll want to override theparse
method in your code!
parse
methodWhen you're creating handlers, you may want to run certain handlers only when the custom id matches something you want. In order to allow filtering, as well as optional additional pre-parsing of the custom id, we provide the parse
method on handlers, which you should override with your own code. The return of the parse
method must be a Some
/ None
, which you can do with the provided shortcuts in the class: this.some()
and this.none()
.
<aside>
ℹ️ Returning a some
means that the handler's run method should be called. Returning a none
means this handler should be skipped for that interaction. If you've used our Args system, this might seem familiar with the ok
/err
that is present there.
</aside>
What you return in the some
is up to you! You can return nothing (be it null or undefined), a boolean, an object, a class, a box of hugs, you name it! But, if the handler should run, you must return a some
(you can use the this.some()
shortcut for it)
<aside>
⚠️ If this function throws an error, the handler will be skipped and an interactionHandlerParseError
event will be emitted!
</aside>
<aside>
👀 Couldn't you shove everything in the parse
method? The (sad) answer is... sort of.
You should not shove everything in the parse
method. It is meant strictly for filtering the custom id or the data received before actually working on it (for instance prefetching data from a database). It's done in this way to make you abstract the validation from the processing of the interaction.
Please don't disappoint me and shove everything in the parse method. Vladdy WILL cry if you do that. :c
</aside>