> 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.
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.
Yes, this is what I meant. Because you want to listen to attribute changes. Anyway, I was saying it's a good thing. I've built entire complex apps where I pass everything via HTML element attributes; it has made me think about architecture and separation-of-concerns in a specific way which has been really good in terms of increasing transparancy/observability and keeping the code simple.
Simple interfaces are critical for good architecture. Forcing everything to be a string, forces pass-by-value and forces minimal communication between components. You get maximum separation of concerns; high cohesion, loose coupling.
I know exactly what inputs each component is dealing with by just looking at the HTML. This is incredibly useful... And components can output stuff by dispatching events on themselves (with bubbling for important events which may potentially affect higher level components).
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.
Wow. Yes. Great comment. So glad to come across someone else who fully gets it. Components should 'communicate' with each other. If you start passing elaborate structures, this is getting into the realm of micromanagement, not 'communication'. It means your concerns aren't properly separated.
This is not a new theory. Alan Kay, who invented OOP has been saying such things for decades. People got totally the wrong idea about OOP by focusing on mechanisms to allow passing complex structures to each other. That was never the point.
Imagine if you worked with other people towards some goal and instead of talking to each other and separating responsibilities, ready-made, complex parts would just come out of people's mouths and everyone tried to make each others' parts fit together as an afterthought... Or imagine trying to catch a taxi and you bring a steering wheel and a tank of petrol with you to give to the taxi driver. It's absurd, obviously so, but that's what a lot of people have been doing with code.
If you really need the ability to pass complex objects via an HTML attribute, you can use the same thing we used in the old jQuery and Knockout days: JSON.parse().
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:
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:
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.
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.