-
Notifications
You must be signed in to change notification settings - Fork 2
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
fix: filter out regex names from .toArgs #25
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## next #25 +/- ##
=======================================
Coverage ? 84.02%
=======================================
Files ? 8
Lines ? 582
Branches ? 91
=======================================
Hits ? 489
Misses ? 92
Partials ? 1 ☔ View full report in Codecov by Sentry. |
commands: commands | ||
.filter((command) => typeof command.name === "string") | ||
.map((command) => command.toObject(language)), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually think it's better if we move this kind of thing to the actual setCommands
method, so users can still use toArgs
and toSingleScopeArgs
however they want. WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that make sense, but it will make the output silently uncomplainant to the telegram specification. And since both function are returning setMyCommandParams
interfaces, which are meant for passing them to the telegram api, might be misleading.
If someone wants to inspect their commands or do something with them like they could with .toArgs
they could use the .toElementals
method, which does not filter regex's and archives a very similar result.
I can add the scope and description to that interface so they become more detailed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
output looks like:
[
{
name: "bread",
language: "default",
prefix: "/",
scopes: [ { type: "default" } ],
description: "_"
},
{
name: "pan",
language: "es",
prefix: "/",
scopes: [ { type: "default" } ],
description: "_"
},
// etc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm... yeah, that makes sense. Thanks!
this will fix #24 only for regex's.
Command names containing UpperCase letters will still thrown when calling
SetMyCommand
on them.They should at least be discouraged. I don't know if it's better to enforce right from the bat the use of lowercaseonly commands or just a mention in the docs. Because they will still register and be handled correctly, but could not be pass to
SetMyCommand