> the fact that you can only pass strings as attributes

This isn't true at all though. It's a lie started in the early days by React engineers that just won't die, unfortunately.

Web components are objects and they can have properties and accessors like any object. The vast majority of declarative template systems like React, Lit, Vue, Angular, Svelte, Solid, etc., will declaratively set properties - which can carry any type of JavaScript value, including complex objects and function - on web components which can then be used to update the component's DOM.

▲

_heimdall 14 hours ago | parent | next [-]

That approach passes values in JS rather than the DOM, right? I read the go comment as talking specifically about DOM attributes which can only be strings (well, you can have boolean attributes as well).

Web components can be passed objects in JS, but its news to me if that is available in HTML.

▲

bythreads 13 hours ago | parent | next [-]

Neither can react

	▲	_heimdall 13 hours ago \| parent [-]
		I didn't say it can, I never actually mentioned react at all here.

▲

moron4hire 11 hours ago | parent | prev [-]

I generally think the reflex to try to pass an object to an attribute on an element is a code-smell that the element hasn't been properly decomposed into sub-components. In those cases, I look more to adding child elements to represent those objects as an HTML serialization of the object.

▲

sporritt 11 hours ago | parent | prev [-]

It is true that web components can have properties and accessors like any object. But what you cant do is pass anything other than a string to a web component's attributes in the markup. I wrote a short article about this when I was investigating web components with JsPlumb a while ago:

https://jsplumbtoolkit.com/blog/2024/07/18/wrapping-data-in-...

TL;DR I ended up creating a context object and a BaseComponent that can access the context. Subclasses of the base component prefix their attributes with a colon to instruct the code to look in the context:

<date-label :value="now"></date-label>

	▲	moron4hire 11 hours ago \| parent [-]
		I think you might be missing out on the standard Time element in HTML5. In use, you set its datetime attribute to a machine-readable format and set its body to the user-readable format. Also, I tend to think of HTML not as my application view, but as a document that represents a serialization of your view. The actual, live view itself is the DOM. Once that document is parsed and rendered, the HTML source from whence it came doesn't matter anymore. Stringly attributes should no longer be a concern. Though, admittedly, the HTMLTimeElement's dateTime property is still a string value. I imagine that is more of a legacy issue. The Date class in JavaScript is a mess as well.