-
Notifications
You must be signed in to change notification settings - Fork 908
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
Call for comments on bot.myStatus
#1872
Comments
Is |
|
In that case, a generic implementation ( |
Bot API gives us |
I really like the idea to add helpers for status changes. They're indeed pretty confusing because they can go from any state to any other, so we should definitely do something here. However, I find it confusing to add event listeners in between the middleware. It used to be the way that all methods on the bot installed middleware, and bringing in some inconsistency here looks strange. If you want to use the middleware system and integrate with it, then you are no longer able to fire several events. This means that the only remaining suggestion is to leave the things to userland and have them call next. This will also leave a lot of the confusion to the users, unfortunately. So yeah, I don't really know how to move forward with this :( |
I understand, your concern is valid. We could leave the correct ordering of events and calling |
We're working on a feature that simplifies
my_chat_member
into a group of events:bot.myStatus("joined", handler)
will trigger when the bot is added to a groupbot.myStatus("left", handler)
will trigger when the bot leaves a group by itself (leaveChat
)bot.myStatus("blocked", handler)
will trigger when a user blocks the bot in private chatand so on. All possible events:
joined
left
banned
restricted
promoted
demoted
blocked
unblocked
You can also listen for multiple events at once, like:
However, a problem arises when one my_chat_member update can cause two changes at once. For example, restricting a bot will also demote it from admin. In that case, you'll get the event you're looking for first. For example:
This will cause
restricted
to fire, but notdemoted
.One idea I have here is when multiple events are expected on the same handler, fire all that apply for each update:
Here we can fire all that apply, so even when the bot is (which was previously promoted) restricted without demoting, handler will be called for both demoted and restricted events (even though the underlying update is only one).
Also consider the order here. Even though
restricted
is first in the array, thedemoted
event is fired first. If user intends on performing some actions based on these events, having a normalised order is useful.Take for instance:
In this case, if
promoted
was fired first, thenjoined
, the resulting state of chatSession will be inconsistent. So we must have a normalised order of firing. This could also be accomplished (without us firing multiple events per update) in userland, usingnext()
:This pattern works without us calling the handler once per event, but puts the onus on the user to write events in the correct order.
Do you agree that all matching events on a myStatus handler must be fired per update?
👍🏻 Upvote for yes (fire an ordered list of all matching events)
👎🏻 Downvote for no (just fire once and let userland handle it)
💭 Reply in thread for other responses
The text was updated successfully, but these errors were encountered: