A short syntax for v-bind .prop modifier

[trusktr]

What problem does this feature solve?

Make things shorter and easier to write.

What does the proposed API look like?

:foo="bar" is a syntax shortcut for v-bind:foo="bar".

Similarly, .foo="bar" would be a nice shortcut for :foo.prop="bar" (and the leading . even makes sense!).

[trusktr]

This would be useful with my Custom Elements, which accept either attributes or props of the same name, and adding a whole extra .prop is not the same amount of awesome convenience as : is for v-bind.

[trusktr]

Worth noting, an attribute prefixed with . is not legal in DOM, as document.body.setAttribute('.foo', '') will throw. So taking up this symbol in Vue templates doesn't get in the way of DOM usage.

[trusktr]

Although interestingly, if a DOM element starts with an attribute like .foo="bar" in the HTML string, then that attribute gets parsed in; it is only forbidden when set via setAttribute. For example:

document.body.innerHTML = `<div .foo="bar">inspect me to see .foo attribute</div>`
document.body.children[0].getAttribute('.foo') // "bar", it exists!
document.body.children[0].setAttribute('.foo', '') // Uncaught DOMException: Failed to execute 'setAttribute' on 'Element': '.foo' is not a valid attribute name.

[yyx990803]

That's a great idea. Will consider this in 2.6.

[trusktr]

What do you think of .foo.bar.baz="..." to set a path in the object?

In my case, I can do stuff like following with my elements:

el.rotation = [0, 30, 0]

// or

el.rotation.y = 30

so the following could be convenient in the template:

<i-sphere .rotation.y="30"></i-sphere>

[yyx990803]

Anything more than a shorthand is beyond the original scope of this proposal. And no, I don't think magic path extensions are a good idea. That's like reaching into the child component's private state.

[trusktr]

It's interesting, because then, do you suggest that I refactor my custom elements to have attributes and properties like the following?

<i-mesh .rotation="" .rotation-y="" .rotation-x="" .rotation-z="">

and

el.rotation = [...];
el.rotationY = ...;
el.rotationX = ...;
el.rotationZ = ...;

It makes the JavaScript API less clean, but I can live with it. I could even automatically map .rotationY to .rotation.y, etc.

[yyx990803]

Or <i-mesh .rotation="{ x, y, z }">?

[trusktr]

Yeah, it's easy to work around.

I was concerned about performance:

  <!-- creates a new object every animation frame, causes more GC -->
  <i-mesh .rotation="{ x, y, z }"></i-mesh>

So, I'll just do it like follows by adding more properties to my custom elements:

  <!-- passes only a number every animation frame -->
  <i-mesh .rotation-y="y"></i-mesh>

Plus, this makes it clear which attributes map directly to properties, without reaching into places that are not represented as attributes. Maybe this is a good thing!

Looking forward to the prefix . notation! 👍

[trusktr]

Plus, this makes it clear which attributes map directly to properties, without reaching into places that are not represented as attributes. Maybe this is a good thing!

Well, maybe it's moot, because it's also possible that .property exists on a custom element instance without a property="" attribute being part of the element's HTML API. So, for example, SSR would just have to send the data to the client (not as an attribute, but as JS) then during hydration just send the data to the element instance property. In this case, having a notation like .rotation.y="" would work the same.

[yyx990803]

Closed via d2902ca