> Look at the data passed to the event. The callstack starts at the function attached as a listener to the event.
> Is the event data incorrect? Then the problem is in the code that triggers the event.
> Is the event data correct? Then the problem is in the code listening to the event.
It's difficult to reason about the event triggering code when it's call stack is not available. For a larger code base where an event is trigger in multiple locations with different logic in each location, it may be difficult to pinpoint the triggering code, let alone reason about that code. Direct function calls are much easier to debug because you can walk up the chain of calls and inspect the variables and state of each frame.
> For a larger code base where an event is trigger in multiple locations with different logic in each location, it may be difficult to pinpoint the triggering code, let alone reason about that code.
Populate the event with the event source.
> Direct function calls are much easier to debug because you can walk up the chain of calls and inspect the variables and state of each frame.
If your listener depends on knowing the state of the triggering code, it is a sign your events are too granular. If you require a complete stack trace to be able to debug a listener to the event, that sounds like you have a bigger architectural problem to deal with.
Events are coarse. The listener should not care about why the event was fired, only that the event has occurred. Events are not a replacement for direct function calls. They are a mechanism for de-coupling pieces of code that can be independent of each other. It doesn't sound like your situation is one where there's that independence.
> If your listener depends on knowing the state of the triggering code, it is a sign your events are too granular.
That isn't practical debugging. If I'm debugging an event that was fired and I don't know why, or the payload doesn't match my expectations, it would be very useful to inspect the state of the triggering function and see where things went wrong.
This library uses jQuery events which are synchronous. I.e. the event handler's callstack will include the triggerer a few levels up. Not any harder to debug than a direct call version.
> Is the event data incorrect? Then the problem is in the code that triggers the event.
> Is the event data correct? Then the problem is in the code listening to the event.
It's difficult to reason about the event triggering code when it's call stack is not available. For a larger code base where an event is trigger in multiple locations with different logic in each location, it may be difficult to pinpoint the triggering code, let alone reason about that code. Direct function calls are much easier to debug because you can walk up the chain of calls and inspect the variables and state of each frame.