Some thoughts from Claude Opus 4.7:
Reasons it looks like a flaw:
-
Platform events for state changes (change, toggle) all bubble and are composed, so users reasonably expect the same from map-change.
-
The natural place to observe layer state is the <mapml-viewer> (single listener, works for dynamically added/removed layers). Requiring per-layer listeners forces consumers to manage subscriptions on every add/remove and misses shadow-DOM crossings without composed: true.
-
It's dispatched from inside the layer control (the Leaflet-side UI), not from the <map-layer> itself as an authoritative state signal — so semantically it's more of an internal notification than a public event.
Reasons it may be intentional:
-
The only in-tree consumer is <map-extent> listening on its parent <map-layer>. For that use case, non-bubbling is fine and avoids leaking an internal coordination signal up the tree.
-
The event carries no detail payload and isn't documented, which suggests it wasn't designed as a public API surface.
ed. note: it is documented, slightly
-
If MapML.js wants it to be public, the fix is straightforward: new CustomEvent('map-change', { bubbles: true, composed: true, detail: { checked, layer } }) . If it's meant to stay internal, a better pattern would be a direct method call or a private Symbol-keyed event, and a documented public event (e.g. change on <map-layer> for consumers. ed. note: we made it map-change to avoid clashing with existing events' names, per a platform design principle.
In sum, it looks like it should be coming from the <mapml-viewer> and it should have a detail field that identifies where it came from, and it should bubble, and it should transit SD boundaries (componsed)
Some thoughts from Claude Opus 4.7:
Reasons it looks like a flaw:
Platform events for state changes (
change,toggle) all bubble and are composed, so users reasonably expect the same frommap-change.The natural place to observe layer state is the
<mapml-viewer>(single listener, works for dynamically added/removed layers). Requiring per-layer listeners forces consumers to manage subscriptions on every add/remove and misses shadow-DOM crossings without composed: true.It's dispatched from inside the layer control (the Leaflet-side UI), not from the
<map-layer>itself as an authoritative state signal — so semantically it's more of an internal notification than a public event.Reasons it may be intentional:
The only in-tree consumer is
<map-extent>listening on its parent<map-layer>. For that use case, non-bubbling is fine and avoids leaking an internal coordination signal up the tree.The event carries no detail payload and isn't documented, which suggests it wasn't designed as a public API surface.
ed. note: it is documented, slightly
If MapML.js wants it to be public, the fix is straightforward:
new CustomEvent('map-change', { bubbles: true, composed: true, detail: { checked, layer } }). If it's meant to stay internal, a better pattern would be a direct method call or a private Symbol-keyed event, and a documented public event (e.g.changeon<map-layer>for consumers. ed. note: we made itmap-changeto avoid clashing with existing events' names, per a platform design principle.In sum, it looks like it should be coming from the
<mapml-viewer>and it should have adetailfield that identifies where it came from, and it should bubble, and it should transit SD boundaries (componsed)