This custom element exposes some properties (with getters/setters) as a way of accessing and changing state:
color (string)api (string)url (string)multiclap (boolean)
The state itself is stored as attributes of the custom element, and the accessors for the above properties read from / write to the corresponding attribute, so they can also be accessed directly as attributes.
However, of the above properties only color is an observed attribute; the remaining attributes will not trigger any side-effects if changed via setAttribute() instead of via the property setter. Currently that doesn't matter, because only color change has any side-effects, but it is still a source of confusion.
There seems to be no particular reason for this, but we seem caught between two implementation styles. Sometimes properties are preferred as those can be any value, not just strings, but here we are only interested in string values, aside from "multiclap" which is boolean, and that is easily represented as "true".
If we change the API then we introduce a breaking change, so we are likely stuck with this. But I would be very interested to know if developers are accessing any of these properties from their code, and if so, is there a reason they prefer property access over attributes?
This custom element exposes some properties (with getters/setters) as a way of accessing and changing state:
color(string)api(string)url(string)multiclap(boolean)The state itself is stored as attributes of the custom element, and the accessors for the above properties read from / write to the corresponding attribute, so they can also be accessed directly as attributes.
However, of the above properties only
coloris an observed attribute; the remaining attributes will not trigger any side-effects if changed via setAttribute() instead of via the property setter. Currently that doesn't matter, because onlycolorchange has any side-effects, but it is still a source of confusion.There seems to be no particular reason for this, but we seem caught between two implementation styles. Sometimes properties are preferred as those can be any value, not just strings, but here we are only interested in string values, aside from "multiclap" which is boolean, and that is easily represented as "true".
If we change the API then we introduce a breaking change, so we are likely stuck with this. But I would be very interested to know if developers are accessing any of these properties from their code, and if so, is there a reason they prefer property access over attributes?