Roll back signals and batching and reimplement them

[LeaVerou]

#91 and #102 caused several regressions (and uncovered some existing bugs). Some of which we fixed with subsequent PRs, but generally piling fixes on top of existing broken code tends to produce worse results and higher complexity than going back, fixing the spec, and reimplementing.

So I think we need to bite the bullet and do just that.

What makes the rollback tricky is that once we discovered the regressions, we added tests for them. These need to stay. FakeElement too (or use a library that does it properly). But simply keeping all the tests from the rewrite is a no-go, since many depend on internal implementation details of the rewrite (a problem in itself).
Also, there are pre-existing bugs we discovered and fixed since then.

I propose this plan:

• We roll back to e344b1f (last commit before signals)
• Let's create a list of requirements here for behavior we want to preserve and ask Claude to create tests for them
• Fix any pre-existing bugs, and add tests to prevent regressions
• Then ask Claude to implement coalescing first ([Props] Bunch up property changes #51) then signals ([Props] Use signals #79). I'll edit the issue descriptions to include more details, so we can point Claude to the issues directly.

Bugs to fix before implementing signals

• setAttribute() after mount does not update the property on plain reflect props #98
• propchange events queued while disconnected are not dispatched on reconnect #100
• [Props] static props not inherited from parent class #104
• Populate detail on first_connected shortcut re-fires #106

We should also add tests for these behaviors.

Behavioral baseline (tests to add before reimplementing)

First, we should find a library instead of implementing FakeElement ourselves and add it as a dev dependency. This cannot be a new problem.

These should all pass on e344b1f. They're the regression net protecting consumer-observable behavior through the signals refactor.

Basic API (mostly already present in test/Prop.js constructor() group — keep what's there, expand only where gaps exist):

• Construction normalizes type, default, reflect, etc.
• reflect: true | false | "name" | { from, to } parses correctly into fromAttribute / toAttribute.
• Props.observedAttributes derives from reflecting props.
• Props.add(name, spec) and Props.add({...}) both work.

Sync IDL semantics to prevent #111

• el.x = v; el.x returns v synchronously.
• el.x = 1; el.x = 2; el.x = undefined fires three propchange events in order, synchronously
• After el.x = v, reading any prop derived from x (via get, convert, or function default) returns the new derived value on the same turn.
• After el.setAttribute("x", "foo"), el.x === "foo" synchronously.

Defaults:

• Plain literal default returns on read when nothing was written.
• Function default() is reactive: re-runs when its dependencies change
• defaultProp mirrors another prop's value; severs on explicit write; restores on undefined.
• Default does NOT call setAttribute on mount. (prevent Race: external read of a Computed-backed prop before initializeFor pollutes the attribute and clobbers programmatic writes #105)
• Setting a value explicitly that happens to be the same as the default DOES call setAttribute
• removeAttribute collapses to the default.

Reflection:

• Property write reflects to the attribute.
• Pre-set attribute coerces into the typed property on mount.
• reflect: { from, to } honors asymmetric attribute names.

Computed props (get):

• get returns the derived value on read.
• Writing a tracked dep re-runs get and fires propchange for the derived prop.

Other:

• A value set as a data property on an element before its prototype accessor exists is preserved, goes through parse correctly, and any props depending on it have correct values
• Setting different values that are the same after conversion do not fire propchange

[DmitrySharabin]

• [Props] static props not inherited from parent class #104

This was a regression introduced after switching to signals. The regression tests confirm that it passes in the pre-signal era.

[DmitrySharabin]

Synthetic default props leak propchange events — fix now or leave for signals?

When a prop has a function default with dependencies, e.g.

bar: { default () { return this.base * 42 } }

the implementation creates a synthetic defaultBar prop internally to track the resolved default. That synthetic prop fires its own propchange event alongside bar's, so consumers see events for defaultBar too — an internal implementation name leaking into the public event stream.

Question: is it desired to fix this before we switch to signals, or is it OK for now and the signals reimplementation will resolve it naturally?

If fix-now: the minimal patch is to skip event dispatch in Props.propChanged for the synthetic prop while keeping the cascade, so the declared prop's re-fire still works.

[LeaVerou]

Synthetic default props leak propchange events — fix now or leave for signals?

When a prop has a function default with dependencies, e.g.

bar: { default () { return this.base * 42 } }
the implementation creates a synthetic defaultBar prop internally to track the resolved default. That synthetic prop fires its own propchange event alongside bar's, so consumers see events for defaultBar too — an internal implementation name leaking into the public event stream.

Question: is it desired to fix this before we switch to signals, or is it OK for now and the signals reimplementation will resolve it naturally?

If fix-now: the minimal patch is to skip event dispatch in Props.propChanged for the synthetic prop while keeping the cascade, so the declared prop's re-fire still works.

This is a feature, not a problem. That's how native elements work as well, e.g. form controls have a .value and a .defaultValue. It's a convenience that Nude element does this for you automatically and we should absolutely preserve this behavior!

[DmitrySharabin]

This is a feature, not a problem. That's how native elements work as well, e.g. form controls have a .value and a .defaultValue. It's a convenience that Nude element does this for you automatically and we should absolutely preserve this behavior!

Got it, thanks. The tests cover that behavior, so we have a regression guard that shouldn't allow us to regress when switching to signals.

[DmitrySharabin]

• [Props] static props not inherited from parent class #104

This was a regression introduced after switching to signals. The regression tests confirm that it passes in the pre-signal era.

Actually, no. The test was wrong. Fixing the test so we can correctly track the bug fix.