Proposal: phx-on-*

Phoenix Forum Chat / Discussions
, ,
#1

I’d like to propose a new Binding API, phx-on-*. This would allow you to bind to any arbitrary event on an element. There are two use-cases that come to mind immediately:

  • There are a lot of DOM events and the number keeps growing, but Phoenix does not support them all. It should not need to support them all! An example of one I miss is a form element’s input event.
  • Custom elements pair great with Phoenix, but custom elements often have their own custom events. There’s currently no way to bind to custom events outside of using a hook.

Proposal

I propose a new binding phx-on-*, with the syntax matching the existing phx-value-*. The * is the event name you want to bind to. Examples:

Form Elements

<input type="text" phx-on-input="do_something">

Custom Elements

<my-dialog phx-on-open="handle_open"></my-dialog>

Event params

For the params I propose the following rules:

  • If the Event is a CustomEvent it will contain a details property. event.details. For CustomEvents that come from places like Custom Elements this is what should be passed to params.
  • If the Event is a Form element, collect the value like you already do for form events.
  • Collect phx-value-* into params like is already done as well.
#2

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.

1 Like
#3

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?

#4

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.