matthewp
Proposal: phx-on-*
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
inputevent. - 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
detailsproperty.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
valuelike you already do for form events. - Collect
phx-value-*into params like is already done as well.
Most Liked
chrismccord
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.
Last Post!
matthewp
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.
Popular in Discussions
Other popular topics
Latest Phoenix Threads
Chat & Discussions>Discussions
Latest on Elixir Forum
Sponsor Spotlight
Practical resources that improve the lives of professional developers.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #elixirconf-us
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking for Elixir devs who love to ship. Start your free account.
Develop your skills with books, videos, and courses.
Producing high quality Elixir screencasts since 2017.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"