d4a8184ad7
The vertical tabs were a 999px stadium on a 48px row. That was a real earlier instruction -- imitate the YouTube active row -- and it shipped, but measured against the product it is the only thing shaped that way: the collapse button is 8px, the filter toggles are 8px, and 8px is already the most common radius in the layout file. They now read var(--vtl-radius,8px), so a consumer has one knob and the three surfaces cannot drift apart. The 48px Material row height is untouched. The YouTube rationale stays in the comment as history with an explicit note not to restore the pill from it, because a superseded rationale that still reads as current is how a reversed decision gets quietly undone. The .vtl-cap badge keeps its pill. The complaint was about the ratio of radius to size -- a 16px chip at 999px is a chip, a 48px row at 999px is a stadium. The studio opened on nothing and said "Choose an element from the list." It now resolves a tab in priority order: the URL hash, since an explicit shareable request should beat a remembered one; then localStorage, so a reload is not a fresh start; then the first row, so the pane is never empty. This lives in the studio rather than the layout because VerticalTabsLayout is controlled via v-model:active and deliberately holds no selection state. Storage is keyed by pathname so two shells on one origin do not fight over one key, every access is wrapped because localStorage throws in private mode and an exception in setup would blank the whole subtree, and the key is only written after the row is confirmed to exist so a bad key cannot poison the next load. Verified in the built shell on a settled tree: first load auto-selects with no hint and stores the key; clicking big-picture moves the selection and updates storage; a reload restores big-picture; and a deliberately poisoned key falls back to the first tab and rewrites itself rather than rendering an empty pane. |
||
|---|---|---|
| .. | ||
| api | ||
| colors | ||
| components | ||
| composables | ||
| constants | ||
| data | ||
| i18n | ||
| layouts | ||
| maps | ||
| 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.