- Events execution order is not guaranteed based on the heirarchy of the DOM when using
window.addEventListener. Insteadwindow.addEventListenerwill 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 withtruefor theuseCaptureargument.
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
removeEventListeneras well. Also adddata-use-captureto 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-hookfor scenarios that require bubbling and cancellations. - Register websocket msgs from an
addEventListenerand 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?