`setAttribute()` after mount does not update the property on plain `reflect` props

[DmitrySharabin]

Symptom

For a plain prop declared with reflect: true, calling el.setAttribute("v", "100") after the element has mounted does not update el.v. Pre-set attributes (set before append) parse correctly into the property; the regression only affects attribute changes after mount.

class C extends NudeElement {
  static props = { v: { type: Number, reflect: true } };
}
customElements.define("x-c", C);

let el = new C();
document.body.append(el);

el.v = 42;                        // works → el.getAttribute("v") === "42"
el.setAttribute("v", "100");
// expected: el.v === 100
// actual:   el.v === 42 (no attributeChangedCallback fired)

Root cause

Class.observedAttributes is wired via the static getter installed by first_constructor_static (plugins/props/index.js#L8–L23). That hook only runs the first time the class's constructor is called — i.e. on the first instance.

customElements.define(name, Class) reads Class.observedAttributes at registration time and caches the list. By that point, first_constructor_static has not yet run, so the static getter is undefined and the cached list is empty. Subsequent setAttribute() calls therefore never reach attributeChangedCallback.

The Props.initializeFor path manually walks observedAttributes on mount (after construction has run, so the getter is now in place), which is why pre-set attributes work.

Reproducible on

main and signals-props. Setup logic in first_constructor_static is byte-identical on both — this is pre-existing, not introduced by #91 / #97.

Suggested fix direction

Run the observedAttributes getter setup at class declaration time (e.g. via the setup static hook) instead of first_constructor_static. By the time customElements.define reads the list, the getter should already resolve to the right value.

[DmitrySharabin]

Posted on behalf of @DmitrySharabin. Investigation and writeup by Claude (Anthropic) during a planning pass; not yet implemented.

Implementation notes

After tracing through the call graph and re-reading the WHATWG custom-elements spec, the original root-cause analysis is confirmed but the fix scope turns out to be smaller than the suggested direction implied. Notes for future reference:

Confirmed root cause

Class.observedAttributes is undefined when customElements.define(name, Class) reads it, because the static getter installation lives inside first_constructor_static, which fires once-per-class on the first instance construction — strictly after registration. Browser caches the empty list and no subsequent attributeChangedCallback ever fires.

Minimal fix

Two targeted edits in src/plugins/props/index.js:

1. Add an eager observedAttributes getter to providesStatic:

   get observedAttributes () {
       this.setup();
       return this[props].observedAttributes;
   }

   Lives on the addPlugins target (NudeElement), inherited by every subclass. Reading it (e.g. from customElements.define) calls Class.setup(), which is idempotent — hooksCommon registers the setup hook with { once: true }, so the props plugin's defineProps runs once per class regardless of how many times the getter is read.

2. Delete the now-redundant if (!Object.hasOwn(this, "observedAttributes")) { … defineProperty … } block inside first_constructor_static. The eager getter inherited from the parent class supersedes it; subclass shadowing (a class declaring its own static observedAttributes = […]) happens naturally via the prototype chain.

Correction to the suggested fix direction

The original suggestion ("Run the observedAttributes getter setup at class declaration time, e.g. via the setup static hook") implies the attributeChangedCallback patch needs to move alongside the getter. It doesn't.

Per the WHATWG custom-elements spec (upgrade-an-element steps), on upgrade the browser:

1. Enqueues attributeChangedCallback reactions for each observed attribute (queued, not invoked).
2. Enqueues connectedCallback if connected (queued, not invoked).
3. Invokes the constructor — super() → this.constructed() → constructor-static hook → first_constructor_static patches attributeChangedCallback on the prototype.
4. Drains the reaction queue → the patched attributeChangedCallback fires.

So the patch installed during the constructor is in place by the time the reactions drain. It can stay in first_constructor_static untouched.

Out of scope

Three things were considered and explicitly left for separate changes:

• Issue [Props] static props not inherited from parent class #104 (deep static props hierarchy / inherited attributeChangedCallback double-call) — preserved as-is. The // TODO how does this work if attributeChangedCallback is inherited? comment stays.
• !isConnected guard in Props#attributeChanged — with setAttribute() after mount does not update the property on plain reflect props #98 fixed, the guard's actual purpose is to prevent double-processing during upgrade (browser-driven attributeChangedCallback for pre-set attributes vs. Props#initializeFor re-walking attributes at connectedCallback time). Removing it requires changing initializeFor not to re-walk — its own change with its own verification.
• Combining user-defined observedAttributes with prop-derived ones (the existing // FIXME how to combine with existing observedAttributes?). Subclass-shadowing wins today; same after the fix. Out of scope.

Sharp edge introduced

The eager getter makes it newly possible to re-enter setup if a setup hook reads Class.observedAttributes. The { once: true } mark in Hook#run is set after the callback returns, so re-entry within the same call would loop. No current setup hook does this, so leaving as a sharp edge rather than guarding against it.

Test approach

A new "Static observedAttributes (issue #98)" group in test/Props.js, peer to the existing "observedAttributes()" group (which tests Props#observedAttributes — the runtime getter on a Props instance, not the class accessor). The new group exercises the plugin path: addPlugins(Base, …) on a vanilla EventTarget subclass, then asserts C.observedAttributes returns the right list before any instance is constructed. No DOM, no jsdom — captures the timing-of-cache root cause directly.

The unit test alone doesn't exercise customElements.define's actual upgrade pass, so a real-DOM smoke test on a downstream consumer (e.g. round-tripping el.v = 42; el.setAttribute("v", "100"); el.v === 100 on a component with a reflected prop) is load-bearing as a complement.