An idea for generic "hooks"

[eritbh]

I have an idea for adding generic "hooks" to the bot that can run code when certain things happen (like events) and influence the execution flow by returning values (not like events). This needs research, but the idea is to have an event-like system that doesn't just emit when things happen, but also has the capability of asking the library consumer for information when it needs it.

Areas where this would be useful:

• Setting custom prefixes: This could be done as a hook that returns an array of valid prefixes. The current implementation of custom prefixes is similar to what I see happening with the "hook" system in general, and I basically want to make it more generic.
• Preventing commands from executing before commands are even processed: A hook into the early stages of the handleMessage method (which is currently run from inside messageCreate event) that lets you return a specific value if you don't want to execute commands from the created message. Or something like that.
• there's probably more but I can't think of any others atm rip

Things to think about:

• Is there a well-established way to do stuff like this?
• How will hooks and existing events coexist?
• Is this even a good idea??????

[Skillz4Killz]

Would it not be a lot simpler to perhaps just have a custom handler for handleMessage.

Option 1: Add a option on clientOptions to have a custom messageHandler which will ovveride the internal one.

// Register the message event listener
		this.on('messageCreate', this.customMessageHandler || this.handleMessage);

Option 2: (My preferance) Just remove the private aspect from the messageHandler allowing anyone who extends the client to be able to overwrite the handler.
https://github.com/Geo1088/yuuko/blob/ca13c40c7369555e3ab73c604eff89442a0c9691/src/Client.ts#L141

I don't think it's worth making Yuuko overcomplicated trying to solve 100 different things. the best part about Yuuko for me is that it is lean and simple like eris. No heavyweight stuff. It is a framework that just helps you get off the ground. If you want special complex stuff you should just have the ability to extend and overwrite it in your own code.

[eritbh]

I'll definitely remove private from the handleMessage method, but you shouldn't have to copy-paste the entire method to insert custom functionality at specific points. If all you want to do is disallow commands from being run by a certain user, for example, you shouldn't need to reimplement the command handler in your own code. That's basically what this issue is for.

[eritbh]

I've decided the way I'm gonna handle this for the command handler case is just by using a static method as a "default message handler" and provide a client option to disable registering that handler automatically. That way, we don't have to worry about "hooks" or reworking the existing events system, you can just provide your own messageCreate listener that can call Yuuko's command parsing methods itself.

I'm in the process of breaking out command handling into its own method so you should be able to use the built-in parsing logic with a single call inside a custom messageCreate listener.