ff7b2daf7a
The Gospel x Internet dashboard needs the Driver's vertical legend on the side to select a people-group list and filter its groups by it. This is that legend, wired as a selector. It WRAPS the shared semantic tree legend rather than replacing it. That component is already the vertical legend and already drives the 26-zone tapestry, so every fix it receives -- theme-awareness, the progress bar, the mobile sheet path, scroll-to-selected -- keeps applying. A second widget would have to re-earn all of it. It emits the SELECTION, not resolved group ids, and that is ownership rather than taste. Resolving a zone to ids means joining zone membership against the group rows, and that join is not trivial: the membership keys are ASCII while the province data carries diacritics, so a naive join silently loses hundreds of groups. A legend that resolved ids would hold a second copy of that join and the copies would drift -- appearing as a wrong count, which nobody notices. The consumer already holds the rows and the join. A region row selects the union of its zones, and both a leaf and a parent return arrays, so a single zone is not a special case the consumer will eventually get wrong. A cleared selection is representable, because a dashboard must be able to drop its filter. The selection rule sits in its own module with its own check, including a negative control that a parent does not select only itself -- which would filter to nothing while looking like it had worked. The tree is a prop. Its builder lives in the plugin that owns the zoning, and a cross-plugin import is barred, so promoting that helper to the library is a separate coordinated move. |
||
|---|---|---|
| .. | ||
| api | ||
| colors | ||
| components | ||
| composables | ||
| constants | ||
| data | ||
| i18n | ||
| layouts | ||
| lists | ||
| maps | ||
| packet | ||
| 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.