> now with events that are harder to trace than function calls would have been
I don't know how this could be true. Events are things - nouns which can be backed-up, replicated, stored, queried, rendered, indexed and searched over.
I don't know how this could be true. Events are things - nouns which can be backed-up, replicated, stored, queried, rendered, indexed and searched over.
I generally like event-driven architecture, but I need to admit that debuggability is sacrificed where it matters most.
const
myEvent = 'myEvent',
target = new EventTarget()
target.on( myEvent, () => {
console.log( "It's easy to introspect well-organized code." )
})
target.dispatchEvent( new Event( myEvent ))That's not something I have to remember or forget, it's a simple habit that is as natural as importing and referencing a function.
As a general rule, numbers and string literals should never be hardcoded. Internalizing this should be a base expectation of any high-performing team member.
Remember "callback hell"? Assumption that a function call returns after running to completion requires rather specific synchronous cascading architecture, which WILL break in multithreaded code. Most of the multithreaded function calls will set a flag in shared memory and return early, expecting caller to poll.
If your API is based on single entry-point `invokeMethod(callee, method)` it is equally untraceable to event entry point `fireEvent(producer, event)`.
Which is exactly switching from function calls to event-driven architecture, and the problems with that are exactly the problems we're talking about.
You do not even need return-early (non-blocking) semantics for these problems to manifest. You can implement a giant string-keyed vtable for all methods in your program (or use a language with advanced reflection capabilities) and will have exactly the same problems. Namely there probably won't be tooling to match caller-callee pairs, which is the core issue here.