d03b24e613
On a partner page or a standalone preset page the ⓘ control rendered nothing, because only the gallery answered it and the ⓘ's text lived in the gallery's settings. Now the map carries its info (plugin-designs/doxa-simple-map/src/mapInfo.js) and a host only adds placement: - MapInfoButton gains an opt-in `standalone` prop. When no host answers and the map carries info, it asks the map for a popup of its own (the 'standalone' event). If a real host appears later, the map's popup is dropped and the host takes over. Never inside the gallery (its panes carry data-doxa-gallery): there the gallery alone decides, its own info:false included. - MapInfo gains `popupOnly` (with trigger 'control'): no floating button, since the map's control is the only button; it answers that control from inside the map, points at it once per page load, and opens the same popup (the bottom sheet on phones). It announces itself as local, so the control can tell it from a real host. - Prayer Progress mounts that popup beside its control column, only when asked. Per preset: the text describes the prayer map, so a map that shows the Prayer tab has info (the full profile and the prayer preset); the engagement-only and adoption-only presets have none and show no ⓘ, as before. A host's profile-config info:false removes the ⓘ. Every other MapInfoButton consumer is unchanged (standalone is off by default). doxa-simple-map grows by 20,590 bytes raw (5,699 gzipped), for compiling MapInfo. Rebuilt doxa-simple-map and doxa-maps-spa, then tree + SRI. |
||
|---|---|---|
| .. | ||
| 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.