667c6331c8
The Driver asked for square controls by name. The fact that shaped this: the square look is not a DX-life design at all. Their CountryMap.vue adds NavigationControl + FullscreenControl and overrides nothing, so what he admired is the ENGINE'S default grouped card -- which makes the target published and exact instead of a matter of taste. Every value here is read from node_modules/maplibre-gl/dist/maplibre-gl.css, and the check compares ours against that file rather than against my memory of it. SQUARE IS NOT A RADIUS SWAP, which is why it lives on the TOOLBAR. Round controls are separate floating circles with a gap and a shadow each; the engine's square form is ONE panel that owns the background, the 4px corners and the 2px ring while its buttons own nothing and are divided by 1px lines. Setting border-radius:0 on the buttons alone gives squares floating 8px apart -- neither shape. So MapToolbar takes controls="round"|"square", and MapControlButton keeps a shape prop only for a button used outside a toolbar, where a lone control gets the engine's 4px. THE 29px IS DELIBERATELY NOT PORTED. Ours stay --map-btn-size, capped to 32px in this toolbar. 29px would cut the touch target below what this project has already ruled on twice, so the variant takes the shape and leaves the size. It is therefore not pixel-identical to the engine, and that is a choice, stated. No overflow:hidden. Clipping was the quick way to round the panel, but it also clips a focus ring on any inner button, and the engine does not do it -- it rounds the first and last buttons instead. Ported as their mechanism. MapControlMenu teleports out of the toolbar, so clipping would not have hidden a menu; the focus ring was the real cost, and the invisible kind. Forced colours ship with it, which the round buttons never had: an rgba() ring and a #ddd divider both vanish under a replaced palette, leaving one undifferentiated block where the controls were. BLAST RADIUS: round is the default and none of the nine MapToolbar consumers passes controls=, so every map renders exactly as before. Asserted, not claimed -- opting one consumer in turns the check red. The regions dashboard is NOT switched. Its map already uses the engine's native controls, ported from DX-life, so it already looks like this; replacing them with ours would risk clone parity to arrive at the same picture. One near-miss, recorded because of how it hid: the first cut added a second :class to a <button> that already had one, and Vue rejects a duplicate attribute, so the SFC did not parse. check:sfc-parse said so IMMEDIATELY -- and I had piped it through `head -2`, which printed its counting line and cut off the FAIL beneath. The block count fell 133 -> 132 in that same output, I noticed, and then checked script TAGS rather than parseability and talked myself out of it. Two separate signals, both read past. The two bindings are merged into one; the count is 133 again. |
||
|---|---|---|
| .. | ||
| 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.