feat(handler): requirement class #339
Conversation
implement POC of "smart defaults", pin newest pydantic 1.5.1 (resolves issue with BaseFilter signature inspection)
Codecov Report
@@ Coverage Diff @@
## dev-3.x #339 +/- ##
===========================================
- Coverage 100.00% 98.91% -1.09%
===========================================
Files 212 213 +1
Lines 4313 4420 +107
===========================================
+ Hits 4313 4372 +59
- Misses 0 48 +48
Flags with carried forward coverage won't be shown. Click here to find out more.
|
implement POC of requirements for class based handlers
fix breaking tests, change signature of BaseHandler
| def __post_init__(self) -> None: | ||
| super(HandlerObject, self).__post_init__() | ||
| if inspect.isclass(self.callback) and issubclass(self.callback, BaseHandler): # type: ignore | ||
| self.awaitable = True |
There was a problem hiding this comment.
How do you plans to detect awaitable callbacks?
There was a problem hiding this comment.
callbacks are naturally inspected in CallableMixin. I didn't actually change the behaviour of inspection, did I? 🤔
This is check determined whether BaseHandler subclass was passed to HandlerObject and seemed redundant to me, since we can check callback once in CallableMixin's __post_init__
refactor requirements feature
# Conflicts: # poetry.lock
evgfilim1
added
stale
|
Closing this after a lot of thinking. This feature unnecessarily makes it hard to maintain. If someone wants their function called before handler gets executed, it should not be done on a new level of update handling from aiogram. It can be done in middlewares/filters already. |
Description
First and not very smart solution for handler requirements.
What is requirements in aiogram handler? They're inspired by awesome fastapi's Dependency. However, in aiogram case, I don't want "Requirements" to be "dependencies", when they're really just a sweet addition. Aiogram will take care of "initializing" those requirements by some set of rules.
Type of change
How Has This Been Tested?
You can take a look at very simple usage and play out.
Test Configuration:
Checklist:
Implementation
Details that can be unclear
We create cache, exit_stack for every event processing operation. Cache and stack are intermediate internal keys used to solve requirements (they're probably exposed in new middlewares). Filters can have requirements too. generators and asynchronous generators are nicely solved with
contextmanagerwhich, I guess, makes their usage "clear".Limitations
Currently requirement's callback cannot have any parameter which is not
Requirement