Problems with inline keyboard

[wauxhall]

Hi! Thank you for https://github.com/go-telegram/bot library, it's awesome and helped a lot.

But this library has several important points that made me waste lots of time.

Let's look at inline keyboard. It uses callbacks. What if our app exits/crashes, but inline button still exist in chat? Right, when the button is clicked, this request will be routed to default handler.

Okay, I made some recover mechanism in default handler that checks for callback query. But it looks such ugly. Because the data that was stored in-memory is lost, I have to put my data to callbackData (which is right way as telegram devs intented it to be used). And then parse it, removing btn num from the end which is added to callbackData by this lib.

So how I suggest to work with inline keyboard callbacks: DO NOT use callback data as some handler prefix, it's not a command text to parse. Check for message CallbackQuery is enough. If it's not nil, then we have a deal with inline button. So we should register only one handler for callbacks. And use callback query data as data container, not in-memory - there we can place keyboard name, btn num, user id and etc. Then we can parse callback data (for example, we marshalled it as json and have some basic schema for callbacks), get keyboard name and btn num and then route to necessary logic.

I'm writing this without any aggression or disrespect, you made great work, but I think this part of lib should be completely refactored. If any help needed, can make some pull requests

[negasus]

Thanks.
You can use the WithPrefix option to determine your own prefix, which will be constant between the restarts of the application.
This feature may solve your problem?

[wauxhall]

That's the problem that WithPrefix() is tricky solution - it appends btnNum to callback data. So when I define my own handler for callback (as handler registered by the lib may be no more available in memory), I have to remove this btnNum to properly parse my data. BtnNum is needed by the lib, but again, I have to handle this by myself because of possibility of restarting the app. And as I said, I think using callback data as something like prefix is not a good idea, instead, we should put to callback data json with some metadata provided by the lib (keyboard name and btn num) and payload defined by user (field with type json.RawMessage). Then lib checks that CallbackQuery is not nil and then chooses user handler for callback according to parsed metadata.

I still believe this needs to be reworked

[wauxhall]

The very abstracted pseudocode example of what I suggest:

type CallbackData struct {
    KeyboardName stirng `json:"kb_name"`
    BtnNum int `json:"btn_num"`
    Payload json.RawMessage `json:"payload"`
}

// ...

// Lib can add a public method RegisterCallbackHandler(kbName string, h inline.OnSelect)
// Inside, we call b.RegisterHandler() with match type func
// inside the match func something like:

if update.CallbackQuery != nil {
    // unmarshal update.CallbackQuery.Data
    if unmarshalled.KbName == "keyboard_name" {
         // handler matched, call handler user provided to inline keyboard from lib with unmarshalled.Payload field as []byte.
         //User must unmarshal it by himself in his code
    }
}

This just for demonstrating the idea, not ready implementation