Proposition d'écriture de commande

[Sebastien-Ahkrin]

Ce que nous avons imaginé

Pour le moment, nous pensons faire une implémentation de la création de commande de cette façon:

const options: ClientOptions = {
  prefix: '!',
  commands: join(__dirname, 'commands')
}

const client = new Client(process.env.DISCORD_TOKEN as string, options);

import Command from "../../package/commands/command";

const command = new Command<[string, number]>('hello', async (args, message) => {
  await message.reply('Hello, World!');
});

export default command;

La commande serait donc utilisée de cette façon:
!hello arg1 arg2
Les deux arguments (arg1, et arg2) seraient du type générique définie plus haut ([string, number]), les arguments ne seraient donc pas nommée, mais cette façon de faire n'est pas exclue !hello --arg1 Hello --arg2 123, de plus, il doit être possible d'avoir une chaine de plusieurs mots en arguments.

Toutes les commandes seraient donc chargés par le dossier qu'on donnerais dans la config (ClientOptions).

Que pensez-vous de tout cela ? Avez-vous des idées ? des choses à ajouter ?

[Mesteery]

import Command from '../../package/commands/command';
import isOwner from 'quelquepart'

class HelloCommand extends Command<[string, number]> {

  constructor () {
    super({
      name: 'hello',
      aliases: ['salut', 'bonjour'],
      permissions: {
        client: ['ADMINISTRATOR'], // les permissions requises pour le bot
        user: ['MANAGE_MESSAGES', 'BAN_MEMBERS'], // les permissions requises pour l'utilisateur 
        // et/ou
        customCheck: (client, user) => client.ownerID === user.id /* ou appeler une méthode privé (ou une fonction) */ isOwner
      },
      throttling: {
        duration: 10000,
        usages: 2 // 1 par défaut
      } // l'utilisateur peut seulement exécuter 2 fois cette commande en 10 secondes
    });
  }

  async run (message, args) {
    await message.reply('hello !');
  }

}
export default HelloCommand;

Je préfère faire les commandes dans des classes, c'est bien plus pratique
Et je trouve le système d'arguments limités (en utilisant la généricité), c'est mieux de pouvoir déclarer les arguments avec des types, des noms (pour y accéder comme args.example), des valeurs par défauts, des vérificateurs de types custom (par exemple avec une fonction fléché, une méthode privé ou une fonction).

[
  {
    name: 'target',
    description: 'La personne que vous voulez saluer', // pratique pour l'aide
    example: '767019913465430048', // ou 'ESC Community#3172', ^
    type: ?, // j'ai pas trop d'idée de comment définir le type des arguments
    default: null // = argument optionnel qui vaut par défaut null
  },
  // ...
]

Pouvoir ajouter des options pour les permissions, autoriser ou refuser l'accès à une commande.

On peut aussi un peu s'inspirer de certains frameworks déjà existants (comme discord-akairo, discord.js-commando, Klasa, YAMDBF, DiscordThingy ou même d'escape)

[Xstoudi]

Je préfère faire les commandes dans des classes, c'est bien plus pratique

Peux-tu préciser en quoi cela est-il plus pratique ?

[Mesteery]

Pour moi c'est plus pratique, pour plusieurs raisons :

• permet de personnaliser la commande facilement (comme dans l'exemple)
• on peut avoir des méthodes pour plusieurs choses (des méthodes "utilitaires" qu'on peut utiliser dans le run, des méthodes qui sont appelées par le command handler, ...)

Il y a sûrement d'autres raisons, mais celles-ci sont celles qui me viennent en premier à l'esprit

[Xstoudi]

• Rien de ce qui n'est fait dans ton exemple n'est pas reproductible via une simple fonction.
• Rien n'empêche ta fonction handler exportée et d'avoir d'autres fonctions non exportées aside.

Vraiment, je ne vois toujours pas l'intérêt.

[Mesteery]

Tu verras bien qu'une fonction suffit pas

[DraftProducts]

Up ! Yes, pour le coup pour avoir bosser sur un bot discord depuis maintenant 2 ans @Xstoudi (draftbot), j'étais au début sur des fonctions handler exportés (il y a 2 ans) et je t'assures que je suis pas resté longtemps là dessus.
Je rejoint @Mesteery sur ce point, le fait d'être sur une class te facilitera grandement la tache !

[Xstoudi]

L'argument d'autorité ne fait pas tellement avancer la question: soit on a besoin de la classe, soit ce n'est pas le cas. Là ça ferait bien avancer les choses de savoir exactement ce qui est facilité par l'utilisation de classe plutôt que d'une fonction.

[DraftProducts]

Principalement la maintenabilité des commandes, dans mon cas j'en avait de plus en plus.
Derrière ça te permet d'éviter le duplicata et d'avoir différents types de fonctionnements, étant donné que tu créé une class qui extends d'une base tu peux formater des données en entrée comme tu l'entends.
Ensuite tu as tout l'aspect des options, qui devient beaucoup plus simple a gérer lorsqu'il te suffit juste de les définir dans ton constructeur pour qu'elles ailles override celles de ta principal. Ensuite rien ne t'empêche d'avoir des surcouches pour certaines commandes: dans le cas où tu as un type de commande qui ne fait que fetch une api et afficher des résultats, tu pourrais avoir une classe qui embarque tous ses outils et son formatage.
Pour être honnête avec toi, si vous n'avez que 3 ou 4 commandes c'est full useless mais au contraire si tu vises un truc complet ça deviendra vite rébarbatif au niveau du code si tu fais de simples export de données.
Voici quelques libs et bots opensource qui te permettra de voir un peu l'utilité que ça peut avoir:

• https://github.com/SwitchbladeBot/switchblade/blob/dev/src/commands/misc/flathub.js
• https://github.com/discordjs/Commando/blob/master/src/commands/util/ping.js

Du coté de Switchblade tu as quelque chose qui rejoint un peu l'idée des surcouches avec les "types de commandes" tandis qu'avec discord-commando tu as quelque chose de plus léger dans le même type que ce qu'à proposé @Mesteery.

De mon coté sur DraftBot j'ai quelque chose d'encore plus que Switchblade avec des types de commandes dédiés à leur utilisation (modération, configuration, gifs d'emotions ect).

[Xstoudi]

Pour être honnête avec toi, si vous n'avez que 3 ou 4 commandes c'est full useless

Merci bien !

[Mesteery]

Ça m'étonnerai qu'il y ai seulement 3-4 commandes

[Xstoudi]

Pour l'instant y a surtout zéro issue labelisée "idée", donc l'estimation me semble pas déconnante ^^

[Mesteery]

Oui je suis d'accord là dessus avec toi, mais 3-4 commandes c'est très peu pour un bot, et c'est peu probable d'avoir seulement 4 commandes. Les commandes s'ajouteront au fur et à mesure, donc je ne pense pas qu'attendre d'avoir plus de 4 commandes pour modifier le framework et accepter les classes soit une bonne idée.
Après j'ai envie de dire, si y aura vraiment seulement 3-5 commandes simples : pourquoi pas

[Mesteery]

J'ai une autre proposition : le framework peut accepter les fonctions et les classes
Les commandes très simples utilisent les fonctions. Et les autres utilisent les classes.

Après, c'est peut-être pas la meilleure proposition (je le pense aussi).

[DraftProducts]

Bof, si tu décides de suivre un paterne, tu le suis, ça risque de devenir vite le bordel si on switch de l'un à l'autre sans cesse.
Après tu peux obtenir un résultat similaire si tu export une fonction options et une option run dans ta commande et gérer tes options avant l'exécution de la commande.
Si le but c'est que ce soit des commandes simples sans vraiment de configuration, de dépendances avec l'auteur de la commande et d'autres éléments qui changeraient le comportement de la commande c'est kiff kiff.