Je vais lister les ptits trucs à fix présents ici et là dans le code à fix pour rendre le code plus lisible et homogène :
[ ] Discord/src/commands/* -> getPacket : check que la fonction est asynchrone, et que y'ait pas de fonction Promise utilisée
[ ] Discord/src/* -> utilisation d'i18n : si on utilise i18n dans une fonction, il faut au choix utiliser interaction.userLanguage (si 2 utilisations ou moins), sinon il faut faire / renommer une variable "lng" (et non language) et utiliser la propriété de clé=variable afin de réduire la taille du code.
[ ] Discord/src/* -> utilisation des informations des packets : parfois sur certains affichages, il y a une utilisation massive de beaucoup d'éléments en brut du packet dans le formattage de i18n (exemple commande classlist, fonction getListEmbed). Dans ce cas, utilisez l'auto remplissage d'objets natifs de typescript afin de réduire d'une dizaine de lignes le code (en gros au lieu de faire {v1: truc.v1, v2: truc.v2, v3: truc.v3, autrechose: surementAutreChose}, faites {...truc, autrechose: surementAutreChose})
[ ] * -> gestion des types: types objets -> quand vous avez à typer un argument de fonction qui correspond à un objet pas directement typé dans le code, typez le (même localement si utilisé localement). Ca rend le code plus lisible (surtout lors de la lecture des paramètres) et vous pourrez réutiliser la dite structure à un autre endroit sans risquer une magnifique duplication de code (exemple signature de Discord/src/commands/player/ClassesInfoCommand.ts->getDetailsEmbed avec le paramètre classDetails)
[ ] * -> gestion des types: types strings énumérés -> quand c'est possible, et que vous avez un type string dans votre code qui ne correspond qu'à une liste d'entrées bien définie et qui ne va que peu évoluer (exemple Language), pensez à lister ces différentes options dans un type afin de le réutiliser de manière précise. Cela évite des sources d'erreurs quand au passage de paramètres et réduit les vulnérabilités (car typescript va check si ta string correspond bien au type)
[ ] Discord/src/* -> gestion des emotes -> quand vous utilisez des emotes côté discord, PLEASE encadrez celui-ci de la fonction EmoteUtils.translateEmojiToDiscord. Cette fonction permet de gérer les emotes unicode qui ne sont pas traduits par discord. Si vous le faites pas, il y aura des endroits où il est probable qu'un emote problématique ne soit pas traduit, et donc que ce soit plus relou à corriger lorsqu'on en repère un nouveau (pour les curieux, la fonction regarde juste si c'est un emote listé comme un emote à problème, et si c'est le cas, il récupère à la place l'emote correspondant. Cependant celà n'est pas automatique. Il faut les lister à la main.)
[ ] Discord/src/commands/* -> gestion des arguments numéraires -> TOUJOURS préciser la base de traduction lors de l'utilisation de parseInt (en gros parseInt traduit une chaine en un nombre. De base il considère le nombre comme si c'était un nombre en base 10, mais c'est dangereux et sources de vulnérabilités. Donc précisez juste ",10" dans le parseInt et tout se passera bien)
[ ] * -> gestion des emotes -> Merci de déplacer les emotes dans DraftbotIcons et de les traduire en emote unicode (et les retirer des strings à formatter). Deux raisons à celà : la 1re est que les traducteurs peuvent par mégarde traduire certains emotes de l'anglais vers une autre langue, la 2e est que ces emotes ne passeront pas par la fonction de traduction des emotes. (issue pour fix les emotes : https://github.com/DraftBot-A-Discord-Adventure/DraftBot/issues/2613)
[ ] * -> eslint-disable -> Ne pas l'utiliser sans avoir épuisé toutes les options pour la contrer. Si vous ne voyez pas, n'hésitez pas à poster le cas dans le channel de dev afin qu'on aiguille une potentielle résolution du problème. Si vous êtes forcés de l'utiliser, merci de rajouter un commentaire sur pourquoi vous l'utilisez
[ ] Discord/src/* -> Magic strings sur les collecteurs -> Les string collect et end des collector events devraient être des constantes plutot que d'etre des stirngs dans le code
Je vais lister les ptits trucs à fix présents ici et là dans le code à fix pour rendre le code plus lisible et homogène :
{v1: truc.v1, v2: truc.v2, v3: truc.v3, autrechose: surementAutreChose}, faites{...truc, autrechose: surementAutreChose})