Replies: 1 comment
-
Given this is a feature request I think this fits better as an issue. I like the idea and was honestly struggling with a good way to handle the OutputPort. Personally I view it as the weakest, and least-helpful, functionality in Please feel free to open an issue and setup a branch on a fork and I'd love to iterate on it! Thanks :) |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi! Exploring Ractor's
OutputPort
, I found a way to boost decoupling: subscribers managing their subscriptions. It aligns with the essence of event-driven systems — publishers need not know subscriber details.I introduced
OutputPortSubscriberTrait
to let subscribers connect directly toOutputPort
, simplifying setup and reinforcing separation between event generation and handling. This leans into the event-driven architecture, promoting clearer separation of concerns.Code Note:
The implementation is straightforward, focusing on message transformations via the
From
trait and leveraging the inherent knowledge of subscribers about their message types. By shifting theport.subscribe
call to subscribers, it minimizes code while maximizing clarity and decoupling.If this seems like a fit for Ractor, I'm all in for contributing a PR. Keen to hear your take!
Beta Was this translation helpful? Give feedback.
All reactions