grammers
grammers copied to clipboard
Is other types of Update planned to be added?
If there's a plan or something, maybe I can help with the PR.
My intention is to keep the API surface as small as possible, while still covering for very common use cases (such as dealing with messages, users, and such). The raw API will always be available for some more niche needs (which reduces on maintenance burden on my part). There may be an update type for message reactions since there's been a few people asking about it.
Oh, this was grammers, not Telethon, derp. Yes, I want to at least match Telethon's updates. Feel free to work on a similar design to the linked one and send a pull request, starting with those you have a need for.
Great! So first I would like to add a raw Update variant to expose other not-yet-supported but exist update from telegram. Is that sounds good to you?
I don't know if it's a good idea to expose raw updates through client.next_update. On the one hand, you get both the benefits of friendly updates when possible, and raw when not, at the cost of polluting the client API with the raw API.
Another option is to have a client.next_raw_update which could be more discouraged and is clearly "lower level", but then one would lose on the friendly updates where possible.
What do you think?
I still prefer the variant way. The user logic will be "Oh I get a new update. If it's well known, I can deal with a friendlier type, otherwise I can still handle the lower level raw data". In comparison, two separated methods will not have this fallback-ish process.
Also I don't think raw data will be a pollution to client side api. Users can just ignore it if they don't want to handle it.
Opened a WIP PR #103
even telethon has a raw updates variant so it is required
If we ever implement "chat update" (such as user left, joined, etc.), here is a helpful image taken from https://github.com/pyrogram/pyrogram/pull/741#issuecomment-897579351:
