6e958bc22f
Some checks are pending
build-gate / build (push) Waiting to run
Measured at the rendered layer: the legend opened on REGION at desktop and mobile. That is the Driver's first complaint about this legend word for word — "it shouldn't have me sitting there on Regions, I don't know what to do, it's confusing" — and the card recorded that part as shipped. Every source signal said it worked. LEGEND_DEFAULT_TAB = 1 existed, defaultTab was a declared prop, it seeded a local ref, and it was named in a watch fallback. The root cause is one layer down. SemanticTreeLegend resolves its tab as `instance ? instance.activeTab.value : localActiveTab.value`, and usePplrInstance initialises activeTab to ref(0). Zero is indistinguishable from "the user chose tab 0", so for every profile sharing an instance store the defaultTab prop was dead — read on every render, never able to win. An activeTabTouched sentinel fixes it: the store only wins once something actually chose a tab, meaning a tab click or a node selection that jumps to that node's generation. A sentinel rather than a new default, so no other profile's landing tab moves as a side effect. And a regression of my own, from the previous commit. There was only one :default-tab left in the profile and it was on <LegendMobile>, where defaultTab is not a prop. Last tick I "dropped the inert attribute" with a string replace that matched the DESKTOP block first, deleting the working one and leaving the inert copy. A dropped attribute is silent, so the build stayed green. Restored to SemanticTreeLegend, and LegendMobile now has a real defaultTab prop so the phone honours it too. Both widths open on "UPG-100 Lists", and on ?lang=es both open on "Listas UPG-100" — locale-independent. A user's own choice still sticks: clicking Region holds at 0, and selecting a row does not snap back, so the sentinel is not a trap. check:legend-export-reachable still passes and now selects a real zone rather than a region, because the legend opens on the Lists tab. The two fixes compound: a phone user lands on the lists and can export the one they pick. |
||
|---|---|---|
| .. | ||
| api | ||
| colors | ||
| components | ||
| composables | ||
| constants | ||
| data | ||
| i18n | ||
| layouts | ||
| maps | ||
| packet | ||
| 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.