[chrismorgan]

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]

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

[chrismorgan]

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.