Conversation
PenguinBoi12
force-pushed
the
lifecycle-events
branch
2 times, most recently
from
f3a2a27 to
f434b1b
Compare
PenguinBoi12
force-pushed
the
lifecycle-events
branch
2 times, most recently
from
93ad175 to
f1c870d
Compare
PenguinBoi12
force-pushed
the
lifecycle-events
branch
from
f1c870d to
9203697
Compare
chrisdedman
left a comment
chrisdedman
left a comment
There was a problem hiding this comment.
Just 2 comments on comments in the code, otherwise LGTM
| :type ctx: Context | ||
| """ | ||
| await self._process_commands(room, event) | ||
| # LIFECYCLE |
There was a problem hiding this comment.
It was to organise/separate the code a bit better to make it easier to read.
There was a problem hiding this comment.
Do you think it would be worth separating those into files rather than keeping all in the same file?
There was a problem hiding this comment.
Good question, I thought about it but no, those belong here. They are part of the logic of the bot; it's the bot that need to handle events it's just that we have 2 types of events now - lifecycle events (our internal events) and matrix events (the events we receive from matrix). If you look you'll see that it's mostly event related methods. The only reason why I added the comment was to cleanly create a separation between our types of events. The rest is mostly small helpers related to events (so it's still belong there).
The only thing that might be moved away since it's more "client" related is the get_room. But that would require a wrapper around AsyncClient and it's out of scope for this PR. Plus, it's not super urgent since we only have this method for now.
| def start(self) -> None: | ||
| """ | ||
| Synchronous entry point for running the bot. | ||
| # MATRIX EVENTS |
There was a problem hiding this comment.
can you explain the purpose of those comments?
chrisdedman
left a comment
chrisdedman
left a comment
There was a problem hiding this comment.
Great work. Thank you for the explanation. LGTM
2 participants
Add a hook decorator and supporting infrastructure to register lifecycle event handlers (e.g.
on_ready,on_error,on_command). Splits the existing_dispatchmethod into a generic lifecycle dispatcher and a Matrix-specific event dispatcher, and ensures hook handlers are properly propagated when loading extensions.Multiple handlers per lifecycle event are supported and fired in registration order.