I worked on a business app made with lit web components and all properties being stringly typed was a real drag. It didn't compare to a realtime-first component library.

▲

jdkoeck 9 hours ago | parent | next [-]

Alas, that’s a common misconception! You’re confusing properties with attributes. Attributes are set through HTML and are stringly typed, but litjs properties can be any js value.

For instance, I have a project with a small web component that displays data from a duckdb wasm connection. The connection object is passed as a property and it works flawlessly.

▲

chrismorgan 7 hours ago | parent [-]

If you’re using it with something like React, passing attributes is easy, but setting properties is much harder, requiring using the escape hatches—I believe you’ll need useRef and useEffect, and a bit of care because it’s frightfully easy to do the wrong thing.

▲

spankalee 2 hours ago | parent [-]

No, React sets properties by default now. It was one of the last holdouts, but they finally fixed this in 19.

	▲	chrismorgan an hour ago \| parent [-]
		Ah, didn’t know that, thanks for the info. From the release announcement <https://react.dev/blog/2024/12/05/react-19#support-for-custo...>: > Server Side Rendering: props passed to a custom element will render as attributes if their type is a primitive value like string, number, or the value is true. Props with non-primitive types like object, symbol, function, or value false will be omitted. > Client Side Rendering: props that match a property on the Custom Element instance will be assigned as properties, otherwise they will be assigned as attributes. And as https://custom-elements-everywhere.com/ puts it: > As of v19, React now uses a runtime heuristic to determine if it should pass data to Custom Elements as either properties or attributes. If a property is already defined on the element instance, it will use properties, otherwise it will fallback to attributes. All up it sounds fragile, and I’m not fond of how JSX syntax makes properties look like attribute, and I hate the way you lose the sometimes-crucial distinction of whether something is a property or an attribute (<input value> is the most obvious example of this), but I guess it’ll be fine in practice. I’m a little curious how they handle some of the event stuff, since React’s synthetic event system is such a legacy mess. And I never did like the way several popular libraries/frameworks (definitely not just React) special-case /^on.*/ attributes, so stupid how you now can’t safely use an attribute or property named “once”, “one” or “online”, all of which would be the most sensible name in certain situations.

▲

WickyNilliams 7 hours ago | parent | prev | next [-]

If you are consuming web components in any other framework, they will be setting properties, not attributes, by default

Attributes are the default for html

▲

spankalee 9 hours ago | parent | prev [-]

I don't understand thinking that properties had to be strings. Did you just refuse to use property bindings or what?