Subscribe on changes!

defineCustomElement uses incorrect props type mapping

avatar
Nov 28th 2023

The has prop, when set as an attribute on the custom element, is just a plain normal HTML attribute, not a boolean attribute.

Normal attributes are always strings.

nextTick(()=>{
  // when using setAttribute, use an empty string: 
  r.value.setAttribute('has', '') 
  // when setting as a DOM prop, use a boolean value:
  r.value.has = true
})

Either of the above will result in the boolean prop being cast correctly.

Now, we could add additional magic to properly convert 'true' and 'false' to true and false, but the current behaviour is not wrong per se.

avatar
Nov 29th 2023

The prop, when set as an attribute on the custom element, is just a plain normal HTML attribute, not a boolean attribute.has

Normal attributes are always strings.

nextTick(()=>{
  // when using setAttribute, use an empty string: 
  r.value.setAttribute('has', '') 
  // when setting as a DOM prop, use a boolean value:
  r.value.has = true
})

Either of the above will result in the boolean prop being cast correctly.

Now, we could add additional magic to properly convert and to and , but the current behaviour is not wrong per se.'true'``'false'``true``false

I think we need some magic 🦄

avatar
Dec 1st 2023

Now, we could add additional magic to properly convert 'true' and 'false' to true and false

I would advise against adding some conversion magic. The HTML Living Standard explicitly states:

A number of attributes are boolean attributes. The presence of a boolean attribute on an element represents the true value, and the absence of the attribute represents the false value.

If the attribute is present, its value must either be the empty string or a value that is an ASCII case-insensitive match for the attribute's canonical name, with no leading or trailing whitespace.

The values "true" and "false" are not allowed on boolean attributes. To represent a false value, the attribute has to be omitted altogether.

https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#boolean-attributes

avatar
Dec 1st 2023

Now, we could add additional magic to properly convert 'true' and 'false' to true and false

I would advise against adding some conversion magic. The HTML Living Standard explicitly states:

A number of attributes are boolean attributes. The presence of a boolean attribute on an element represents the true value, and the absence of the attribute represents the false value. If the attribute is present, its value must either be the empty string or a value that is an ASCII case-insensitive match for the attribute's canonical name, with no leading or trailing whitespace. The values "true" and "false" are not allowed on boolean attributes. To represent a false value, the attribute has to be omitted altogether.

https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#boolean-attributes

I personally feel that, at present, the philosophy of Vue conflicts with the HTML Living Standard. When I wrote the following code, I interpreted it with the mindset of Vue, but the outcome did not meet expectations. I believe the Vue team will make a judgment on how to choose.

avatar
Dec 7th 2023

Vue is following the spec here.

  • r.value.setAttribute('has', true) -> invalid for a boolean attribute, so casted as string "true"
  • r.value.setAttribute('has', '') OR r.value.setAttribute('has', 'has') -> valid for a boolean attribute, converted into boolean true and working as expected.
  • r.value.has = true -> directly setting the property. Works as expected.