Dashlane
Question about events with no listeners
Hi! First of all, thanks for this nice lib :) I have a question: what happens, when you call an event and there are no listeners on its slot? It would be useful to describe that in the readme.
From what I tested, the promise returned by the event call just waits indefinitely. Is this your designed behavior, so a listener can still connect while the message is awaiting on the channel? If so, a nice feature would be to add an "instant delivery" mode, configured e.g. in an optional params object to the slot<Type>() function, where the call would fail (and reject the promise) if there are no connected listeners on that slot.
Hi! First of all, thanks for this nice lib :)
Thank you :)
what happens, when you call an event and there are no listeners on its slot?
This is indeed the intended behavior as described in the comments of Slot.ts, here and here.
An addition to the readme to explain this behavior would be nice indeed.
a nice feature would be to add an "instant delivery"
Agreed that this could be a useful addition. We don't need it right now in our current setup though so it's not going to rank high in our backlog. But we would happily accept a pull request wink :)
Cool I actually would like the promise to succeed if there is no listener and will make a PR.
Btw the comment on the actual Handler.ts says If no handlers are registered, the Promise is automatically fulfilled which got us caught out a bit!
I'll adjust that too.
@mikkel-labelbox if you intend to make the promise be fulfilled if there are no listeners, I think there should be some way to detect that the message actually was not handled -- do you have any ideas?
@quezak Hey, after deep diving into the code a bit I think our pattern is a bit different from the design that ts-event-bus uses. We are looking at using it for both commands and events in a decoupled services architecture.
This means that for events we want to support 0 to N different listeners, which may be distributed across several transport channels. We want to support the calling service to block until all the listeners confirm, so the current way ts-event-bus works is fine except that I notice it expects each transport to have a handler or else it will cause a timeout. For an event it's fine if there are no handlers at all.
For commands, we want there to be a single handler which might exist in any transport but there should only be one across the whole system.
I can potentially add in these semantics to ts-event-bus but if it is too far of a direction from the original use case then it's probably worth us starting clean or using something else.
Thanks!
@mikkel-labelbox did you ever come up with a solution? I think I'm trying to accomplish what you've described here and would love any pointers (:
