Changed addHandler() and removeHandler()

[lifestreamy]

Changed HandlersDsl.kt to account for changes in addHandler

You can now add handlers in dispatcher specifying their names, every handler is added in a mutableMap with its name as a key. If no name is specified then it is either defaulted to null or to main parameter of handler

[lifestreamy]

This commit is made to address this issue that I have posted recently
#262

[vjgarciag96]

Thanks for the contribution @lifestreamy! This will take me some time to review as I'll have to thoroughly go through your proposal and think about it because it's changing a very core part of the library and I'm not sure this is the behaviour we want, and in case we want it, I'll need to check whether this is the way we'd want to implement it. I'll add a suggestion on your issue on how you could solve the issue without changing the library in the meantime if that works for you.

[lifestreamy]

Alright. Thank you for the answer.

[lifestreamy]

And yes, it probably is not the best way to solve the problem and it could be improved. But it works for me for now, although I don't really like some pieces in my code.

So it is more of a suggestion to get attention rather than an actual pull request.

[lifestreamy]

Some clarification: in addHandler() it is written so that it does not replace existing handler with the same one (same id and type). If types are different it replaces the handler previously added under the same id

[lifestreamy]

Also it would be cool to be able to add
a nested handler like this

callbackQuery("cb1", chatId){}

This way it will be only added to the selected chat

And, to avoid cluttering, I think it is alright to restart the backend periodically,
but it is probably possible (and would be better) to improve the library so that you could just reset the bot every select interval.

Also, there is a problem with dispatcher that you can't just send message every time the bot starts or on some backend event (like when there is an update a message will be sent to every person using the bot with the news)

Currently I have to manually send such messages using telegram API directly.

Like when the bot is started, it sends only to my own chat "Backend started"

I can't just write bot.sendMessage in dispatcher, it is not allowed by the library.

Right now the bot can only send messages from inside a handler block.

[vjgarciag96]

I take note of all the feedback. The suggestion around making it easier to add/remove handlers, and adding the same handler several times will be in the roadmap for new features of the library. The handler per chat id, we'll have to give that a thought and see whether we want that or not. And the ability to reset the bot sounds like a good idea too.

Also, there is a problem with dispatcher that you can't just send message every time the bot starts or on some backend event (like when there is an update a message will be sent to every person using the bot with the news)
Currently I have to manually send such messages using telegram API directly.
Like when the bot is started, it sends only to my own chat "Backend started"
I can't just write bot.sendMessage in dispatcher, it is not allowed by the library.
Right now the bot can only send messages from inside a handler block.

The dispatcher block is not the place where you want to use the bot as it should only be used to define handlers for updates or errors. If you want to send a message when you start a bot you can do something like the next:

fun main() {
    val bot = bot {
        dispatcher {
            // whatever goes here
        }    
    }
    bot.startPolling()
    bot.sendMessage(ANY_CHAT_ID, ANY_MESSAGE)
}

[lifestreamy]

Thank you for your replies! It is great that you answer and care about your product, keep up the good work! Meanwhile I will use my fork. And yes, I haven't run any tests before making pull request. Whoops lol

[lifestreamy]

https://github.com/lifestreamy/kotlin-telegram-bot/blob/main/README.md
Please, check this out.

Again, just to get some attention to the issue.

I can (and will) delete this pull request on your demand.