custom-elements-everywhere
custom-elements-everywhere copied to clipboard
New test: libraries should offer control over setting attributes vs JS properties
Now that React 19 is coming out, it will finally have better support for Custom Elements, but it is still not as good as it could be.
- https://github.com/facebook/react/issues/11347
Specifically see this reply to the OP: https://github.com/facebook/react/issues/11347#issuecomment-1732205832
What custom-elements-everywhere is missing is a test to verify that each library gives users control over setting DOM attributes vs JS properties.
Lit's html
template tag has syntax for this. For example,
-
foo=${value}
sets thefoo
attribute -
.foo=${value}
sets the.foo
JS property -
?foo=${value}
toggles the existence of thefoo
attribute based on the Boolean value
Similarly, Solid.js JSX has the following syntax:
-
foo={value}
is dynamic, it sets thefoo
attribute on a non-custom element (no hyphen in name) or thefoo
JS property in a custom element (there are reasons for this) -
prop:foo={value}
always sets thefoo
JS property -
attr:foo={value}
always sets thefoo
attribute - it does not have a special Boolean attribute syntax, custom elements are expected to handle the Boolean value in the JS property (or a stringified boolean if value is passed as an attribute)
Solid's html
has similar syntax (but with ${}
interpolations)
Pota's html
supports both Solid and Lit syntax.
Etc.
This is not just a nice to have, this is a necessity. We cannot guarantee custom elements are written a certain way.
- some elements accept attributes only
- some accept JS properties only
- some accept both
- some accept a mix
- some authors rely on attributes for styling
:host
with attribute selector - some users want to set an attribute for styling from the outside (they could set the JS prop, and the element would work, but their CSS would not be able to select the element)
- etc
It is impossible for any templating system could heuristically guess if something should be set as attribute or as property (I.e. to guess the CE author's or CE user's intent). Template systems could have defaults (like the above do), but ultimately the user needs control, and authors also need control on telling users how to use their custom elements regardless of how frameworks work.