Feature Request: Have controlled update propagation

[sabbyX]

Is your feature request related to a problem? Please describe.
Updates are propagated to handlers in a uncontrolled way! Sometimes you want to have specific handler to receive updates first. This becomes very annoying when you have multiple handlers listening to all messages or similar cases

Describe the solution you'd like
It would be better to have a dedicate parameter for declaring level or something similar for handler. Similar implementation has been done in pyrogram

Additional context
Taking case in 3.x, better to have something like Router(level=1), if no levels were given then handler is considered to be least priority / level

[uwinx]

In upcoming 3.x (as of current 3.x), aiogram will have nested event routers with the hierarchy.

[sabbyX]

In upcoming 3.x (as of current 3.x), aiogram will have nested event routers with the hierarchy.

I guess update would be propagated to routers in a order of including them in Dispatcher (include_router) and same for nested routers as far as I know. If you are dynamically loading a module (literally a Router) there's no option which Router need to get update first!

[sabbyX]

I also find out that python-telegram-bot has similar implementation (named group, parameter which determines priority of handlers) more info

[Timopheym]

Is there any solution to the reised problem as for 2023? The PR is seems pretty simple and still not reviewed.
For me it's crucial, as I want to have command-specific handler to hive higher priority over wide-text. And I don't have a clue how to implement it without priority functionality.

[JrooTJunior]

@Timopheym, you should register more specific handlers before broader. It always has been and is now. You can register it as you wish.

The proposed way in the PR can be characterized as "chaotic evil", because with the current implementation you have pretty-well controlled order of registered handlers. Nevermind that is registered with decorators in diffenrent modules or via <router>.<event_type>.register(handler, *filter) method.

The most controllable way is .register method, you can register all handlers in one place and prioritize as you wish.

This solution works because events resolver search the handler from up to down and from left to the right.

It works in the same way as if-elif-...-else condition in Python or any other programming language. the preceding condition has more weight than the following one.

I mention the proposed solution as "chaotic evil" because it works on top of existing algorhytm and shuffle the existing order of handlers and in the summary you will have uncontrollable ordering.

[JrooTJunior]

So.. I'm closing this Issue and pull-request together.