Group-like syntax commands

[marcantoinegodde]

Hello :)

Following issue #157 and PR #168, we don't properly handle group-like syntax command (/command@botname), right?

It seems that even with MatchTypeCommand and MatchTypeCommandStartOnly we can't recognise the command because it's considered as a different one by data[e.Offset+1:e.Offset+e.Length] == h.pattern.

How would you do things differently? Search for pattern inclusion?

Best

[IlyaSemenov]

I use this for the time being:

func (s *TelegramService) registerCommandHandler(command string, handler bot.HandlerFunc) {
	commandText := "/" + command
	commandTextPrefix := commandText + "@"
	matchFunc := func(update *models.Update) bool {
		if update.Message != nil {
			for _, e := range update.Message.Entities {
				if e.Offset == 0 {
					part := update.Message.Text[e.Offset : e.Offset+e.Length]
					if part == commandText || strings.HasPrefix(part, commandTextPrefix) {
						return true
					}
				}
			}
		}
		return false
	}
	s.bot.RegisterHandlerMatchFunc(matchFunc, handler)
}

(Note that it's somewhat sub optimal as we should really be checking only the first entity instead of checking every and compare offset to 0).

[steindvart]

Yes, currently matching command in this format is not built into the library. But this can be easily implemented by creating your own matching function (MatchFunc) and registering a handler with this function via RegisterHandlerMatchFunc(matchFunc MatchFunc, f HandlerFunc, m ...Middleware).

For example:

...
b, err := bot.New(cfg.Token, opts...)
if err != nil {
    return nil, err
}

b.RegisterHandlerMatchFunc(MatchCommandTestWithParams, CommandTest)
...


func MatchCommandTestWithParams(update *models.Update) bool {
	if update.Message == nil {
		return false
	}

	return strings.HasPrefix(update.Message.Text, "/test@")
}

func CommandTest(ctx context.Context, b *bot.Bot, update *models.Update) {
	if update.Message == nil {
		return
	}

	parts := strings.SplitAfter(update.Message.Text, "@")
	commandPart := parts[0]
	paramPart := parts[1]

	partsText := fmt.Sprintf("Command: %s\nParameter: %s", commandPart, paramPart)

	b.SendMessage(ctx, &bot.SendMessageParams{
		ChatID: update.Message.Chat.ID,
		Text:   fmt.Sprintf("`%s` command received!\n\n%s", update.Message.Text, partsText),
	})
}

Result:

---

To simplify, the /test command was hardcoded and the @ character was not dropped when dividing into a command and its parameters. It can be done, but that's not the goal. The goal is to demonstrate the general idea. That is not so difficult to make your own MatchFunc, which will be able to process commands in the format /command@param and any others.

[steindvart]

And I think that a similar MatchFunc for commands with parameters would be very useful as part of the library.

@negasus

[parmetra]

@steindvart Hello! Thanks for the great idea!
I combined your approach with the one from PR #196, and this is what I came up with.
It's probably not perfect yet, but it works fine.
I'd be happy to hear any feedback or suggestions for improvement! 😊

// internal/telegram/router.go
package telegram

import (
	"context"
	"strings"

	"github.com/go-telegram/bot"
	"github.com/go-telegram/bot/models"
)

// RouterDeps contains all dependencies required to create a Router instance.
type RouterDeps struct {
	Bot            *bot.Bot
}

// Router is responsible for routing incoming Telegram updates to appropriate handlers.
type Router struct {
	tg             *bot.Bot
	botUsername    string // cached bot username (without @)
}

// NewRouter creates a new Router instance and fetches the bot's username using GetMe.
func NewRouter(deps RouterDeps) (*Router, error) {
	myBot, err := deps.Bot.GetMe(context.Background())
	if err != nil {
		return nil, err
	}

	return &Router{
		tg:             deps.Bot,
		botUsername:    myBot.Username,
	}, nil
}

// RegisterHandlers registers all command and message handlers for the bot.
func (r *Router) RegisterHandlers() {
	// Simple commands that only match when used with leading slash and nothing else
	r.tg.RegisterHandler(bot.HandlerTypeMessageText, "start", bot.MatchTypeCommandStartOnly, r.StartHandler)

	// Custom commands that should work both as /cmd and /cmd@botname
	r.tg.RegisterHandlerMatchFunc(r.commandMatcher("mute"), r.MuteHandler)
}

// commandMatcher returns a MatchFunc that accepts a command both in plain form
// (/command) and when addressed directly to the bot (/command@BotUsername).
func (r *Router) commandMatcher(pattern string) bot.MatchFunc {
	return func(update *models.Update) bool {
		if update.Message == nil {
			return false
		}

		for _, e := range update.Message.Entities {
			if e.Type != models.MessageEntityTypeBotCommand || e.Offset != 0 {
				continue
			}

			// Extract the command text without the leading slash
			cmd := update.Message.Text[e.Offset+1 : e.Offset+e.Length]

			// Match either /pattern or /pattern@OurBotUsername (case-insensitive)
			if strings.EqualFold(cmd, pattern) || strings.EqualFold(cmd, pattern+"@"+r.botUsername) {
				return true
			}
		}

		return false
	}
}

[steindvart]

@parmetra

I'd be happy to hear any feedback or suggestions for improvement! 😊

1. You can make the function commandMatcher more flexible if you add the ability to specify with an argument which character is considered the separator of the command and its parameters. Like this:

func (r *Router) commandMatcher(pattern string, delim runa) bot.MatchFunc {
	return func(update *models.Update) bool {
      ...
			if strings.EqualFold(cmd, pattern) || strings.EqualFold(cmd, pattern+delim+r.botUsername) {
				return true
			}
		}

		return false
	}
}

2. And you can improve the naming. This function is not just a "command match", but a "command match with parameter" - commandMatcher -> commandWithParamMatcher.

[marcantoinegodde]

I was having a look at @Interstellar750's work (PR #196) and I agreed with both the intent and the reason for which the PR got closed.
I really don't understand why PR #32 was made in the first place. My understanding is that bots must have a username. So why give the option to prevent retrieving the context? Shouldn't we push for deprecation of this method?