Phoenix_live_view: Discussion: reduce number of phx-* attributes

Created on 14 Apr 2019  路  2Comments  路  Source: phoenixframework/phoenix_live_view

As the functionality grows, we will see more and more attributes and their variations. We already have at least:

  • phx-click
  • phx-keyup
  • phx-down
  • phx-change
  • phx-target
  • phx-value
  • phx-blur
  • phx-focus
  • phx-submit

There will definitely be more (hover? mouseover/mouseout?). Some of them will need more parameters. For example, blur/focus can already be parametrized with phx-target. We may want to setup different values for any of the following on any number of events on each element: delay, debounce, throttle, preventDefault, bubbling and capturing (there may be more). If we introduce web components into the mix, we'll need to be able to subscribe to custom events from those.

One way to handle that is to go the Vue route and go for a common v-on scheme and modifications:

v-on:click = "action"
v-on:click.stop.prevent = "action"

This, however, doesn't really allow us to provide more complex configurations like targets or debounce values.

We could let all LiveView-related things live under a phx attribute that accept a map of things:

# catch all attribute: phx
# only allows a configuration map
phx={on: { click: { prevent: true, stop: true, event: "event" }, blur: { target: window } }}

#shortcut:
# phx:any-event-name

phx:click="event"

# same as
phx:click={event: "event"}

# same as
phx={on: {click: {event: "event"}}

This, however, is quite verbose in extreme cases, and clashes with the HTML-like nature of the templates.

However, I think we should still discuss this before the number of LiveView-specific attributes grows out of control :)

Most helpful comment

I would argue that all "Custom" attributes should start with data-*,
using custom attributes without the data prefix is considered invalid HTML. This might course problems in the future.

https://www.w3schools.com/tags/att_global_data.asp
https://html.spec.whatwg.org/multipage/dom.html#embedding-custom-non-visible-data-with-the-data-*-attributes

All 2 comments

I would argue that all "Custom" attributes should start with data-*,
using custom attributes without the data prefix is considered invalid HTML. This might course problems in the future.

https://www.w3schools.com/tags/att_global_data.asp
https://html.spec.whatwg.org/multipage/dom.html#embedding-custom-non-visible-data-with-the-data-*-attributes

If things are going to change non-BC adding the 'data-' prefix sounds sane, especially if the server side live view html templating is going into separate files and editors open, parse and even validate those (Say HTML5/HTML5 as XMLish).

Edit: I was looking through github issues before opening a ticket myself looking for the data- prefix issue.

Was this page helpful?
0 / 5 - 0 ratings