Fix setAttribute() after mount not updating reflected props (closes #98)

[DmitrySharabin]

Port of #109 from main. Same root cause, same fix; tests are already in place.

Per the HTML spec, customElements.define only reads Class.observedAttributes if attributeChangedCallback is non-null on the prototype at registration time. Pre-this-PR, first_constructor_static wired ACB at first instance construction — after registration — so the browser snapshotted a null ACB and never read observedAttributes. setAttribute after mount silently dropped its update.

Fix: make ACB a regular entry in the props plugin's provides so addPlugins lands it on NudeElement.prototype before any subclass calls customElements.define. The eager static observedAttributes getter on providesStatic runs defineProps() lazily. Subclasses chain via super.attributeChangedCallback(...) — same convention as connectedCallback.

Bonus: also flips "removeAttribute collapses a reflected prop to its default" green — same root cause.

Stacked on #116.

Test plan

• npx htest test/index.js → 93 pass / 5 fail / 4 skip (was 91/7/4)
• Two pins flipped green: "Post-mount setAttribute updates the property (issue setAttribute() after mount does not update the property on plain reflect props #98)" and "removeAttribute collapses a reflected prop to its default"
• No regressions — the remaining 5 failures are unchanged from the baseline

🤖 Generated with Claude Code

[LeaVerou]

What happens when this plugin is used on an element class with its own attributeChangedCallback?

[DmitrySharabin]

It should call super.attributeChangedCallback to make it work correctly. It's a trade-off of the change.

More on this here: #110

[LeaVerou]

That won't work. Try it

[LeaVerou]

How could that happen? There's nothing async here, so nothing will be executed between L88 and L89 (though I haven't checked defineProps, maybe there are async parts)

Also, this doesn't take parent classes into account at all (but maybe we're fixing that later?)

[DmitrySharabin]

How could that happen? There's nothing async here

It's synchronous re-entry, not async. defineProps() synchronously fires this.$hook("define-props", env) (props/index.js:71), and hook listeners run while we're still inside the getter. A hypothetical plugin that hooks define-props and peeks at the attr list before contributing its own:

const hooks = {
  define_props (env) {
    if (this.observedAttributes.includes("foo")) { /* … */ }
  },
};

Without the reservation:

1. Outer read → getter, cache empty, no Object.hasOwn hit.
2. Getter calls defineProps().
3. defineProps fires the define-props hook.
4. The listener above reads Class.observedAttributes.
5. Getter fires again. Cache is still empty (the assignment is after defineProps).
6. Step 5 → step 2 → step 3 → step 4 → step 5 …
7. 💥 stack overflow.

With the reservation, step 4's inner read hits Object.hasOwn and returns the in-flight [] immediately — same re-entry-guard shape as attachShadow in src/plugins/shadow/index.js.

Today no plugin actually hooks define-props, so the guard is purely defensive — but it's a public extension point and a third-party listener would legitimately reach for Class.observedAttributes.

doesn't take parent classes into account at all (but maybe we're fixing that later?)

Right — that's the // FIXME how to combine with existing observedAttributes? on L95. Out of scope for #117; merging derived attrs with user-declared/inherited static observedAttributes is the open question from #109.

[LeaVerou]

It's questionable whether an empty array is better in that case, but it's not a blocking issue