feat: Add signal-based binding support to ObserverMap and TemplateElement

[radium-v]

Pull Request

📖 Description

Replace the Observable.notify-based change propagation in fast-html's Observer Map and template binding system with Signal-based pub/sub from @microsoft/fast-element/binding/signal.js.

The Observer Map feature previously relied on Observable.notify(target, property) to inform bindings of deep property changes in proxied objects. This approach coupled change detection to the Observable property accessor system, which wasn't designed for the proxy-mediated, deeply-nested data patterns used in Declarative Shadow DOM templates.

This PR introduces a Signal-based notification model that follows the patterns established by the SignalBinding module in fast-element:

• Each element instance gets a unique signal channel (fh:<id>) via a WeakMap
• A hybrid ObserverMapObserver combines Signal subscriptions (for deep proxy changes) with standard Observable.binding expression watching (for direct property access like array items)
• ObserverMapBinding extends the Binding base class and supports multi-signal subscriptions for nested repeat contexts
• Proxy set traps and ObserverMap.defineChanged handlers now broadcast via Signal.send instead of Observable.notify

The public API (TemplateElement.options, ObserverMap, template syntax) is unchanged — developers use observer maps and observables in DSD exactly as before.

👩‍💻 Reviewer Notes

• The ObserverMapObserver is the central new abstraction — it's worth reviewing its dual-subscription model (Signal + Observable expression watcher) to ensure correctness across all binding contexts.
• Repeat data bindings intentionally remain plain functions (not signal bindings) to avoid double-rendering conflicts with the repeat's internal array observation.
• notifyObservables now walks up the target chain recursively so nested proxies ultimately signal the owning element.

📑 Test Plan

All existing Playwright fixture tests pass across Chromium, Firefox, and WebKit (336 tests). No new tests were added — the existing observer-map, deep-merge, and other fixture tests validate the behavioral equivalence of the Signal-based approach.

✅ Checklist

General

• I have included a change request file using $ npm run change
• I have added tests for my changes.
• I have tested my changes.
• I have updated the project documentation to reflect my changes.
• I have read the CONTRIBUTING documentation and followed the standards for this project.

[janechu]

Let's check on the performance on this change.

[mohamedmansour]

I ran some AI Review and it said, can you please look into this? The most critical performance question: The old Observable.notify path feeds into Updates.enqueue() which batches DOM updates via requestAnimationFrame. Signal-based notifications are fully synchronous. Have you verified that the FAST rendering pipeline still correctly batches DOM writes downstream of handleChange, or could this cause layout thrashing from synchronous intermediate re-renders during deep merges?

  │ Finding                           │ Severity       │ Type                  │ Action Needed                        │
  ├───────────────────────────────────┼────────────────┼───────────────────────┼──────────────────────────────────────┤
  │ Signal storm during deepMerge     │ 🟡 High        │ Perf regression risk  │ Coalesce/batch signals during merge  │
  ├───────────────────────────────────┼────────────────┼───────────────────────┼──────────────────────────────────────┤
  │ Dual observer overhead (volatile) │ 🟡 Medium      │ Perf overhead         │ Consider non-volatile inner observer │
  ├───────────────────────────────────┼────────────────┼───────────────────────┼──────────────────────────────────────┤
  │ Array signal consolidation        │ 🟢 Positive    │ Perf improvement      │ None                                 │
  ├───────────────────────────────────┼────────────────┼───────────────────────┼──────────────────────────────────────┤
  │ Recursive notifyObservables dedup │ 🟡 Medium-High │ Perf regression risk  │ Deduplicate signal names before send │
  ├───────────────────────────────────┼────────────────┼───────────────────────┼──────────────────────────────────────┤
  │ WeakMap lookup frequency          │ 🟡 Low-Medium  │ Micro-optimization    │ Cache in hot loops                   │
  ├───────────────────────────────────┼────────────────┼───────────────────────┼──────────────────────────────────────┤
  │ Subscriber object accumulation    │ 🔵 Low         │ Memory (pre-existing) │ Track for future cleanup             │
  ├───────────────────────────────────┼────────────────┼───────────────────────┼──────────────────────────────────────┤
  │ Reentrancy guard                  │ 🟢 Positive    │ Correctness           │ None                                 │
  └───────────────────────────────────┴────────────────┴───────────────────────┴──────────────────────────────────────┘

[janechu]

I ran some AI Review and it said, can you please look into this? The most critical performance question: The old Observable.notify path feeds into Updates.enqueue() which batches DOM updates via requestAnimationFrame. Signal-based notifications are fully synchronous. Have you verified that the FAST rendering pipeline still correctly batches DOM writes downstream of handleChange, or could this cause layout thrashing from synchronous intermediate re-renders during deep merges?

  │ Finding                           │ Severity       │ Type                  │ Action Needed                        │
  ├───────────────────────────────────┼────────────────┼───────────────────────┼──────────────────────────────────────┤
  │ Signal storm during deepMerge     │ 🟡 High        │ Perf regression risk  │ Coalesce/batch signals during merge  │
  ├───────────────────────────────────┼────────────────┼───────────────────────┼──────────────────────────────────────┤
  │ Dual observer overhead (volatile) │ 🟡 Medium      │ Perf overhead         │ Consider non-volatile inner observer │
  ├───────────────────────────────────┼────────────────┼───────────────────────┼──────────────────────────────────────┤
  │ Array signal consolidation        │ 🟢 Positive    │ Perf improvement      │ None                                 │
  ├───────────────────────────────────┼────────────────┼───────────────────────┼──────────────────────────────────────┤
  │ Recursive notifyObservables dedup │ 🟡 Medium-High │ Perf regression risk  │ Deduplicate signal names before send │
  ├───────────────────────────────────┼────────────────┼───────────────────────┼──────────────────────────────────────┤
  │ WeakMap lookup frequency          │ 🟡 Low-Medium  │ Micro-optimization    │ Cache in hot loops                   │
  ├───────────────────────────────────┼────────────────┼───────────────────────┼──────────────────────────────────────┤
  │ Subscriber object accumulation    │ 🔵 Low         │ Memory (pre-existing) │ Track for future cleanup             │
  ├───────────────────────────────────┼────────────────┼───────────────────────┼──────────────────────────────────────┤
  │ Reentrancy guard                  │ 🟢 Positive    │ Correctness           │ None                                 │
  └───────────────────────────────────┴────────────────┴───────────────────────┴──────────────────────────────────────┘

Good note, we are benchmarking this change next week to determine performance implications and that is why this change has not been merged.

[janechu]

Based on performance runs this change seems fairly negligible, no real improvements or degradations. I'm hesitant to put it in based on that though I do think Signal has some potential. Advise we close this for now, get a more comprehensive observer map benchmark in place and re-test it.