b4664aa67e
The "what can this map do for you?" button can now live IN a map's control column instead of floating over it. This is the bridge only: nothing changes until a map adds the control and its gallery tab sets trigger: 'control'. - map-controls/MapInfoButton.vue (new): a MapControlButton with the info icon and the localized mapInfo.open label. Clicking it sends a bubbling, composed 'dxmaps:mapinfo-open' event out of the plugin's shadow root to the gallery pane. On mount it asks 'dxmaps:mapinfo-control' and shows ONLY if a MapInfo on the same pane answers (ack), so a standalone leaf or a partner page never shows a button that opens nothing. A MapInfo that mounts later broadcasts 'dxmaps:mapinfo-host' and the button asks again. - info/MapInfo.vue: new prop trigger, 'floating' (default, unchanged) | 'control'. In control mode it listens on its own pane: it acts only on events whose composedPath contains the pane, and stops them there. Its own floating button and pointer hide ONLY while the announced control is MEASURED usable: connected, a non-zero on-screen rect, and in no inert/aria-hidden subtree. It is re-measured by IntersectionObserver and ResizeObserver plus a 1.5 s fallback timer, never inferred from an unmount event. Escape and close return focus to the control when it is on screen, else to the floating button. aria-expanded is kept on the control. Proved on a UPG-100 pilot served locally (gallery page, 1440, MapLibre and Mapbox, en and ar), exactly one info button on screen at every step: wall 1 floating; Map 1 control (it wins its hit test and sits inside the toolbar column); opened from the control, Escape closes it with focus back on the control; toolbar hidden 1 floating, shown again 1 control; tab away and back 1; back to the wall 1 floating. 0 page errors. That pilot's wiring is not in this commit. |
||
|---|---|---|
| .. | ||
| api | ||
| charts | ||
| colors | ||
| components | ||
| composables | ||
| constants | ||
| dashboards | ||
| data | ||
| elements | ||
| i18n | ||
| layouts | ||
| lists | ||
| maps | ||
| packet | ||
| packets | ||
| scripts | ||
| stores | ||
| styles | ||
| utils | ||
| vendor/cldr | ||
| index.js | ||
| ProfileLoader.vue | ||
| README.md | ||
library/ (@map) — the shared map template
The other half of the architecture (see ../plugin-designs/README.md):
every map in plugin-designs/<your-map>/ composes the reusable, parameterized pieces that live here.
Fix something here and every map benefits on the next build; break something here and every map
breaks — read components/WARNING.md before touching shared pieces.
| Folder | What lives there |
|---|---|
ProfileLoader.vue |
The root of every bundle: parses profile-config, loads the profile, provides the stores + config |
components/ |
Shared UI — map, legends, controls, popup (PeopleGroupDetail), tables, charts, hints (README) |
composables/ |
Shared logic — map engine (useMapInstance), provider switch, shadow-DOM styles, theming |
stores/ |
Per-instance Pinia stores (ui / map / data) — provided by ProfileLoader, injected by children |
api/ |
Data-source registry (sources.json) + fetch layer — the JAMstack runtime wiring |
colors/ |
Color sets maps opt into via profile-config.colorSet |
i18n/ |
The shared string catalogs (all maps speak the same languages) |
data/ |
Small shared datasets baked at build time (big served data lives in ../data/) |
constants/ |
Shared constants |
scripts/ |
Maintainer pipelines (posters, research) — not part of any bundle |
The rule of thumb (same as WARNING.md): custom code in your app-profile, reusable code here — and things only move from the first to the second once they've earned it.