thomas-crane / aphid Goto Github PK

Sending a message to a channel is generally the last thing a command will do, and this involves a Promise. This Promise can reject, and the code to handle this rejection is often the same regardless of the command involved.

Command methods should be able to return an instance of a Promise which will then have the rejection handling code attached automatically.

For example

@Command({
  name: 'Ping pong',
  trigger: ['ping', 'p'],
  description: 'Replies to the command with a "Pong!" message.',
})
pingPong(client: AphidClient, message: Message, args: MessageArgs) {
  return message.reply('Pong!');
}

If the Promise returned by message.reply happens to reject, it will be properly handled instead of throwing an UnhandledPromiseRejectionWarning.

This is probably best done with an additional property added to the CommandInfo interface.

A good solution may be to introduce a onceEvery: string property which takes a time span as a value. The time specified is the minimum amount of time that must elapse between invocations of this command.

For example,

@Command({
  name: 'Ping',
  trigger: ['ping', 'p'],
  description: 'A status check to see if the bot responds.',
  onceEvery: '10s', // this command can only be used once every 10 seconds.
})
ping(client: AphidClient, message: Message) {
  // ...
}

The current spec allows for the restriction of commands to certain roles via the restrictTo property of the command decorator. However, there is currently no way to place restrictions on which channels a command may be used in.

Given that the property restrictTo has a bit of a generic name, one possible solution would be to change this to restrictToRoles and to add a new property called restrictToChannels.

However, this solution proposes some property names that are starting to get a bit lengthy, and it also makes the object which is passed to the command decorator larger.

An alternative solution could be to something similar to the @Command/@Parameter relationship and introduce a new decorator called @RestrictTo.

The new @RestrictTo decorator would take a RestrictionInfo object which is defined as follows

interface RestrictionInfo {
  /**
   * An optional array of Role snowflakes. If this is provided,
   * the command will only be useable by users who have one of
   * the specified roles. Defaults to `undefined`, which does
   * not impose any role restrictions.
   */
  roles?: string[];
  /**
   * An optional array of Channel snowflakes. If this is provided,
   * the command will only be useable in the specified channels.
   * Defaults to `undefined`, which does not impose any channel restrictions.
   */
  channels?: string[];
}

Similarly to the @Parameter decorator, the @RestrictTo decorator should be declared after the @Command decorator.

For example

@Command({
  name: 'Ping',
  trigger: ['ping', 'p'],
  description: 'A status check to see if the bot responds.',
})
@RestrictTo({
  channels: [Channels.General, Channels.AdminChat],
})
ping(client: AphidClient, message: Message) {
  // ...
}

Using this approach over just adding a new property to the command decorator has some advantages and some downsides. This approach would take longer and be a bit more difficult to implement, but it may allow for some reuse in the future such as restricting the scope of an event listener to certain channels or roles, for example

@EventListener(Event.Message)
@RestrictTo({
  channels: [Channels.AdminChat], // only listen for messages in the admin chat.
})
onAdminChatMessage(client: AphidClient, message: Message) {
  // ...
}

Using this solution would also require that the restrictTo property of the command decorator be removed.