Conversation bot improvements

[anpryl]

currentChatId always returns Maybe ChatId but in conversationBot we always have ChatId. It leads to meaningless boilerplate code every time ChatId is needed in handlers.
What do you think about ConversationM?
Here is example:

newtype ConversationM a =
  ConversationM { _runConversationM :: ReaderT (ChatId, Update) ClientM a }

@fizruk
Is there are any hidden issues which will block this improvement?
If you are OK with this I will try to create prototype next week.

[fizruk]

Can you elaborate on the boilerplate you get? I see how it can arise, but I'd like to know more about your specific case.

I am not sure where do you expect ConversationM to arise. Note that you don't always have a ChatId (when Update is not chat-related) or Update (e.g. in bot jobs).

[fizruk]

@anpryl note that I am working on a new release with a lot of new nice features on improvements branch. Perhaps I've implemented a solution to your problem already.

[anpryl]

In my case, I need to store a mapping (in database) between UserID in my system and telegram's ChatID. So in most handlers I need ChatId to lookup user data and it leads to boiler plate like

mchatID <- currecntChatId
case mchatID of
  Just chatID -> do something
  Nothing -> pure NoOp

I understand that update can be without ChatId. But is it possible in conversation mode? We need ChatId to lookup conversation from HashMap. After this we definitely have ChatId inside handlers.

[fizruk]

I think I see your point, but I'll have to think a little more about it.

I think we can actually make Maybe Update (or rather BotContext since v0.2) an argument to BotM:

newtype BotM context a = BotM { _runBotM :: ReaderT context ClientM a }

newtype Eff action model = Eff { _runEff :: Writer [BotM BotContext action] model }

With this we might use something similar to magnify to zoom into chatId or any other part of an update (when possible).