mirror of
https://github.com/lightpanda-io/browser.git
synced 2026-03-22 04:34:44 +00:00
There are two main ways to dispatch events, both via the EventManager: dispatch and dispatchWithFunction. dispatchWithFunction came about from having to dispatch to function callbacks in addition to event listeners. Specifically, firing the window.onload callback. Since that original design, much has changed. Most significantly, with https://github.com/lightpanda-io/browser/pull/1524 callbacks defined via attributes became properly (I hope) integrated with the event dispatching. Furthermore, the number of non-tree event targets (e.g. AbortSignal) has grown significantly. Finally, dispatching an event is DOM-based event is pretty complex, involving multiple phases and capturing the path. The current design is largely correct, but non-obvious. This commit attempts to improve the ergonomics of event dispatching. `dispatchWithFunction` has been renamed to `dispatchDirect`. This function is meant to be used with non-DOM event targets. It is optimized for having an event path with a single target andh no bubbling/capture phase. In addition to being a little more streamlined, `dispatchDirect` will internally turn a `js.Function.Global` or `js.Function.Temp` into a local. This makes the callsite simpler, but also provides optimization opportunity - not having to create a new scope for the common case of having no callback/listener. This lays the groundwork for having a `hasDirect` guard clause at the callsite to avoid unnecessary event creation (todo in a follow up commit). `dispatch` remains unchanged. While `dispatch` is primarily meant to handle the DOM-based EventTarget, it will forward non-DOM EventTargets to `dispatchDirect`. This is necessary since JS code can call `signal.dispatchEvent(....)`. Two notes: 1 - The flow of dispatchDirect is an optimization. The spec makes no distinction between DOM and non-DOM based EventTargets. 2 - While the window (as an EventTarget) should probably be thought of as a DOM-based EventTarget, we use `dispatchDirect with it. This is because it sits at the root and thus can safely go through the faster `dispatchDirect`.