Proposal: phx-on-*

We listen on window, so all the event names would have to be known up front, and the values are encoded differently depending on the type of element (ie form serialization vs clicks), so this proposal would need to take both those into consideration.

Thanks Chris, I think in this case we would want to listen on the element and not the window as by default new CustomEvent does not bubble (see spec here). Is there a particular reason why Phoenix binds to the window that causes a concern?

Ok, looking at the LiveView code I now see why it binds at the window. It takes the strategy of binding to well-known events and then checking if the element contains the phx- attribute when the event occurs. That makes sense from a simplicity standpoint but also makes it harder for Phoenix to scale to adding more events.

Another strategy I use is MutationObservers to be made away when attributes are added/removed from DOM elements and then triggering actions on when they change. I even wrote a convenient library for this.

Here’s an example of how phx-click could be implemented with this library:

class PhxClick {
  connectedCallback() {
    this.ownerElement.addEventListener('click', ev => {
      let value = this.ownerElement.getAttribute('phx-click')
      // Notify the server here...
    })
  }
}

customAttributes.define('phx-click', PhxClick)

I could see going in this direction as being beneficial to LiveView and require less special-casing and provide developers with more flexibility. I’d be happy to help implement something like this for you.