Web-component properties casing are treated like ordinary element attributes

[pedro00dk]

Describe the bug

I'm not sure if this is expected behavior...

I have a web-component that accepts a camelCase property. When consuming the web-component and setting its prop, the generated code lowercases the property.

What I understand is that web-components have different code generation than ordinary elements. By default, the attributes are passed as properties if no directives are provided.
However, I think the property names are being lowercased as if they were ordinary element attributes.

The behavior is also a bit weird with constant props, as they are optimized as attributes in the template string, even though they are being passed to a web-component.

I found out I can pass the property as kebab-case and the output will be transformed to camelCase, but that messes up the component types.

Your Example Website or App

https://playground.solidjs.com/anonymous/1003943b-a363-4e73-b3af-6b1c1e8fdd15

Steps to Reproduce the Bug or Issue

1. Open playground link.
2. Check output tab (client side mode)

This code does not really run anything, the point to see the output code.

Expected behavior

I expected that when declaring a web-component in JSX, the properties without directives (regardless if they are constants or expression) would be passed down to the web-component element as if they were properties, not attributes, and that the prop casing would be preserved.

Screenshots or Videos

No response

Platform

• OS: Linux
• Browser:Chrome
• Version: 114

Additional context

No response

[ryansolid]

Where we landed here was the result of conversations with the community around how to handle this and ultimately came to a place that I'm not sure is the best in hindsight but that we would handle things as as properties but that we would convert dash case to camelCase. Interestingly we using to do straight pass through but I think it caused inconsistencies when output as HTML.

The problem is HTML isn't case sensitive so the choice of passing properties without a prefix is awkward in general. I'm gathering that is why Lit defaults to attributes even if it is sort of not the best default. That being said I'm also not sure how useful the HTML compat is because you'd have to serialize the value to a string in that case anyway and without manual intervention I'm not sure you are going to get what you want.

So sort of awkward place always forcing the prop: prefix. I suppose we could inspect the value or looks at the component prototype and make a decision but that is also a bit inconsistent. I'm open to revisiting this for sure but what you have witnessed is "by design" currently.

I'm going to move this to discussions. I think this is a worthwhile topic.

[pedro00dk]

I think the way I wrote my question was misleading, it may sound as a complaint to how the transformation works right now.

However, my trouble is actually with missing documentation.
In the solid website API documentation, there is very little information regarding how attributes are passed to web components, except for the prop: and attr: directives. There is no way to know how other attributes are transformed, special cases, etc...
Maybe I could find more stuff in the repository issues and discussions, I was just a bit lazy.

Btw, I think forcing prop: to be awkard too.

Anyway, maybe as a first step for this discussion could be summarizing how the current jsx transformation works for web components.

[trusktr]

I agree, I think this is mostly pointing out that we lack documentation in that aspect.

To be honest, Ryan and most of the Solid community don't use custom elements, so enough care for custom elements documentation has not been given like with Lit (because Lit is specifically focused on custom elements, while Solid is focused on function components).

However! I'm a heavy custom-elements-with-solid user, so I should help! Here are some rules we should add somewhere. The simple rule set is this:

• Make your custom elements map dash-case attributes to camelCase properties, and everything will work well.
• Values interpolated into dash-cased props on a custom element in a template map to the camelCase JS property
• Values interpolated into dash-cased props on a non-custom element in a template map to the camelCase JS property
• use prop: to send values specifically to a JS property no matter what, regardless if custom or not.
• use attr: to send values specifically to an elment attribute no matter what, regardless if custom or not.

See this new example with added cases using including <div> (non-custom):

https://playground.solidjs.com/anonymous/aad3d77b-f905-4e19-9986-1e727b591c60

prop:foo-bar doesn't even work, causes an error (example c2 commented out). Note example d4.

I'm wondering if we should make the rules consistent based on the attributes in the template, but not based on if the value is constant or not. I.e. treat a ...="constant" the same as we currently do for ...={Math.random()}.

The alternative would be, as Ryan was mentioning would be cumbersome, to treat foo=... and foo-bar=... as always mapping to an attribute no matter what. But then this means that we'll have prop: prefixes everywhere all the time.

We landed on the current setup because, for custom elements that map from dash-case attribute to camelCase properties, we get the least verbose template, essentially always mapping to JS props (except in the constant value case which could be unexpected).

However! Now we have a whole class of custom elements being made with Lit where their convention is to map fooBar attributes (case insensitive) to the equivalent fooBar JS property (case sensitive). No dashes (unless you manually specify an attribute name yourself in the element class definition's static properties). And this poses compatibility issues.

What this means for Lit users in practice is that the convention is that templates always match with the JS class definitions, for example if your class has a .fooBar JS property, then in HTML templates you always see fooBar="123", or .fooBar="123", etc, where the template attribute name always matches the JS property name. People can write foobar="" and it will work, but that's not standard for Lit community.

If someone is writing Lit elements, and then finds themselves in a Solid app and needs to bring some Lit elements in, then they will naturally want to write

<some-element fooBar="123" />

but it won't work, and they need to write

<some-element foo-bar="123" />

Lit does not do any name mapping (only maps the lowercase attribute to the JS prop from which is was defined which may not be all lowercase), but also the .fooBar syntax for properties is a lot more concise than prop:fooBar in their template system. What it means in practice is that in Lit, the name of an attribute is never mapped to anything. So you can import dash-case-handling elements into a Lit template, and it simply works:

<non-lit-element foo-bar="123" />

That works because if the element was defined to map a foo-bar attribute to a JS fooBar property, it simply will because Lit passes it a foo-bar attribute (Lit has no idea that the element will do that mapping).

It is possible we could update Solid's html to be more like Lit's. (f.e. .foo would be treated as prop:foo in that case). This could be a separate debate. Maybe it isn't ideal for the sake of consistency with Solid JSX. But maybe that's ok? It isn't like Solid's h is totally the same as JSX or html.

This is a tricky problem!

[pedro00dk]

A small summary of the transformation cases I found:
https://gist.github.com/pedro00dk/f49bc135eff3f78ec89338d9634b49f1#file-solid-transfomation-cases-md
Probably there are more special rules and cases, but this covers a good part already.