Reflected attributes cause unexpected behavior

[JamesIves]

Components which use reflect: true, when using the @property decorator or this.setAttribute result in unexpected behavior.

To reproduce this:

1. Create a component that uses this pattern, for example use the following, and then do something like :host[is-open] {} in the CSS as a response to the attribute being present.

@property({type: Boolean, attribute: 'is-open', reflect: true})
public isOpen: boolean = false;

2. Have the component manage its own state, for instance it should run this.isOpen = true and then this.isOpen = false at some stage in its lifecycle.
3. When the first isOpen is called and set to true, it reflects the attribute into the URL bar to keep Storybook controls in sync.
4. When the second occurance happens, the attribute remains present in the URL, and does not correctly remove the attribute from the component.

As a result component previews for some interactive elements do not work in Storybook. I've tried ignoring the option with addon-controls by extending argTypes and setting controls to false to no avail. I've also tried adding a JSDoc comment as @private to see if that somehow causes it to ignore that attribute name by removing it from the generated custom elements manifest, but alas, no luck. Seems the only solution for these cases in the meantime is to not use the template method here.

[break-stuff]

After reading through this, I think this is desirable behavior. Is the is-open attribute something that is intended for users to be able to set or is primarily for internal purposes?

[JamesIves]

It's somewhat both. Either a user can set it to define some sort of default behavior, but the component similarly manages the attribute. Lit describes a couple of reasons why you might use reflected attributes here which is a similar circumstance that this component is using. Things just get out of sync after the first reflection, so I'd rather just disable addon controls for this particular property entirely.

[rstoneIDBS]

It's somewhat both. Either a user can set it to define some sort of default behavior, but the component similarly manages the attribute. Lit describes a couple of reasons why you might use reflected attributes here which is a similar circumstance that this component is using. Things just get out of sync after the first reflection, so I'd rather just disable addon controls for this particular property entirely.

Have you tried setting the renderDefaultValues property in the setWcStorybookHelpersConfig options ? I was seeing similar behaviour to what you describe and this setting cured my issue.