- Events execution order is not guaranteed based on the heirarchy of the DOM when using
window.addEventListener
. Insteadwindow.addEventListener
will run listeners in the order they are registered. - DOM3 specifies events flow down the DOM tree and then back up.
addEventListener
's are called on the way back up, but can be called as evt propogates down the tree withtrue
for theuseCapture
argument.
Taking control of event listeners for the user limits a lot of the flexibility the DOM + JS provides. See this issue for an example.
Basically, we have not covered bubbling and cancellation DOM Events with LiveView.
Options:
- Take a single pass through the DOM tree and register event listeners on the source element. Would require
removeEventListener
as well. Also adddata-use-capture
to allow event to be called as the Event travels down the DOM tree. Removeswindow.addEventListener
. Does not provide cancellation but does cover bubbling and order of execution. This would require some sort of "state" to hold the element, but could be stored in a WeakMap for weak reference to avoid potential memory issues.
class EventManager {
init(state) {
const { element } = state;
element.addEventListener(...);
}
reinstall(state) {
const { element } = state;
element.addEventListener(...)
}
}
- Add documentation for
phx-
events, including order of DOM events and limitations. Encourage use ofphx-hook
for scenarios that require bubbling and cancellations. - Register websocket msgs from an
addEventListener
and convert to Elixir structs, order properly on server and callhandle_
events based on order. Would require client side code to provide "start" and "end" gates. A "click" then "submit" is a defined series of events. A "click" then a listener on a parent "click" is another series of events. A "click" and a "blur" might be two separate series of events. Possible to be chained and thus cancelled by user Elixir side inhandle_event
?