3f103aaae7
Some checks are pending
build-gate / build (push) Waiting to run
ROOT CAUSE, proven by interception rather than inference. A COMPOSITE leaf whose
own root paints no tiles is generated TOKEN_FREE, so its page calls mount('') and
the "tk: token" assignment never runs. Intercepting setAttribute BEFORE Vue could
consume it showed profile-config arriving with keys profile/dataSource/
instanceId/assetsBase and NO tk. ProfileLoader then computed '' and provided it
to every child, so a map nested INSIDE the composite got an empty accessToken and
logged "No Mapbox access token provided" - the error reported at
dashboard-plus-grid.js:605.
The generator assumed a composite's nested maps each render in their own iframe
leaf running its own token ladder. That is false for dashboard-plus-grid: zero
iframes, and ResearchDashboard / PeopleGroupsGrid are imported as COMPONENTS, so
the nested map runs inside the shell page and needs the token the shell withholds.
ProfileLoader now falls back to window.MAP_TOKEN when config.tk is absent.
STRICTLY ADDITIVE: 10 components inject mapboxToken and today all receive ''
whenever tk is missing; now they receive the real token. An empty string becoming
a valid token cannot break a map that already worked.
Verified: the nested map inside dashboard-plus-grid now carries a real
accessToken instead of ''. Negative-tested both ways - an explicit ?tk= still
WINS over the global (per-instance precedence intact), and with no token anywhere
the code still logs "No Mapbox access token provided" rather than silently
pretending. Full build ALL GUARDS PASS, SRI consistent.
This does not make the generator's classifier correct; see
BUG-COMPOSITE-LEAVES-ARE-TOKEN-FREE-BUT-NEST-REAL-MAPS for the deeper fix.
|
||
|---|---|---|
| .. | ||
| api | ||
| colors | ||
| components | ||
| composables | ||
| constants | ||
| data | ||
| i18n | ||
| layouts | ||
| scripts | ||
| stores | ||
| styles | ||
| utils | ||
| 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.