Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: allow setting the c. menu with cms with no handler and mark them for inspection #60

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

carafelix
Copy link
Member

As discussed in the telegram group

allows for stuff like:

const commands = new CommandGroup();
commands.command("start", i18n.t(DEFAULT_LOCALE, "commands.start.description"))
    .localize("de", "start", i18n.t("de", "commands.start.description"));

await commands.setCommands(bot);

changes:

  • Add next-only handler at command creation if no handler is pass
  • Mark commands with no handler for inspecting them with toElementals or toArgs or toSingleScopeArgs

…mark them for inspection with a new property called "noHandler"
src/command.ts Outdated Show resolved Hide resolved
Co-authored-by: KnorpelSenf <[email protected]>
@@ -507,13 +520,14 @@ export class Command<C extends Context = Context> implements MiddlewareObj<C> {
*/
public toObject(
languageCode: LanguageCode | "default" = "default",
): BotCommand {
): BotCommand & { noHandler?: boolean } {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we create our own BotCommand type? maybe AugmentedBotCommand or BotCommandX (taking inspiration from the hydration plug-in)

Copy link
Member Author

@carafelix carafelix Dec 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we have something like that indeed with CommandElementals

commands/src/types.ts

Lines 37 to 44 in 3b332bc

export interface CommandElementals {
name: string;
prefix: string;
language: LanguageCode | "default";
scopes: BotCommandScope[];
description: string;
noHandler?: boolean;
}

Maybe is better to use a Picked type from it in the toObject function? I might have gotten a little lazy just adding that way hehehe

In any case, I think its more easy to read the simpler BotCommand & { noHandler?: boolean }, which implies and directly links to, the official grammy interface for setting commands. Since everywhere toObject is used is in preparing commands for setting onto the command menu

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I was just looking to be a lit bit more DRY

Copy link
Member Author

@carafelix carafelix Dec 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The main difference between CommandElementals and BotCommand is that it's property its called name instead of command for clarity and separation, but maybe that can be get rid of and we simply extend BotCommand.

That difference was introduced because, basically: name its plug-in centered, meaning its nature coming from a simple name string or a name regex turned into string, and command it's always API-centered.

DRY-wise it make sense to just extend it, and change the relevant parts in the code that use that interface, but in someparts, it would be less readable imo, specially for inspection , like in:

name: local.name instanceof RegExp
? local.name.source
: local.name,

and
const bestMatch = cmds.reduce(
(best: CommandSimilarity, command) => {
const similarity = JaroWinklerDistance(userInput, command.name, {
...options,
});
return similarity > best.similarity ? { command, similarity } : best;
},
{ command: null, similarity: 0 },
);

Copy link
Contributor

@roziscoding roziscoding Dec 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it would be less readable imo

because we'd have command.command?

Copy link
Member Author

@carafelix carafelix Dec 27, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup, but it's used so scarcely around the code that we could just make a BotCommandX

test/integration.test.ts Outdated Show resolved Hide resolved
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants