c7c2c12cd0
A host page can define a tag name before our bundle loads, and customElements.define is first come, first served. DX Life's own scripts define <doxa-map>, <doxa-simple-map> and <doxa-research-map>, and our bundles defined the same names behind a silent guard, so on those pages our define was skipped and the page drew the host's element under our name (Prayer Progress on the Adopt page, and the Research page). - The doxa-simple-map bundle defines <dxm-simple-map>; doxa-research-map defines <dxm-research-map>. Each is its bundle's first define, so the manifest, the leaf pages and the gallery mount them with no other change. - The older names are defined only when the host asks: data-legacy-tags on the bundle's <script>, or window.DXM_LEGACY_TAGS = true before it loads. Off by default. - library/elements/ownTags.js: a class is branded with its bundle; a re-load is silent; a tag held by a foreign class is reported (console.error), never adopted. whenTagDefined refuses a dxm- tag held by a foreign class rather than mounting it. - research-map-plus-grid mounts <dxm-research-map>; the gallery and studio count the new tags as heavy (WebGL) elements; the studio's and the composite's composes lists name them. - check:element-namespace (gates:pre; self-test in gates:post): no host name by default, each bundle's own tag first, the manifest mounts them, one bundle per tag (people-groups-grid is the one known exception), ownTags and whenTagDefined run against a stub registry. |
||
|---|---|---|
| .. | ||
| 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.