273785b2e6
go-int found both by reading the kit before importing it. Both are in landed code and both reach Big Picture in Arabic, not only a new consumer. THE DRAG HAD NO READING DIRECTION. facetW and railW were computed from (clientX - startX), written once, in LTR. Under dir=rtl the grid mirrors — the facet rail sits on the RIGHT — so dragging its handle toward the map moves clientX the other way, and in Arabic the facet handle shrank the CHARTS rail. Both handles fight and neither does what the cursor says. The delta now carries a sign read from the computed direction per drag, not cached: a host can flip dir between gestures, because our own composites set it on the custom-element host from the runtime locale. The ARROW KEYS take the same sign. If only the pointer mirrored, the two input methods would disagree about which way widens — and aria-valuenow reports the same ref for both, so the announced value would move opposite to the key for someone who cannot see the drag. AND THE LEGACY READ-THROUGH WAS MINE, FROM KIT LANDING 2. I added it so namespacing would not discard a reader's saved layout, and applied it unconditionally. So a caller passing its OWN storageKey — which is the entire point of namespacing — still inherited Big Picture's rail widths on first load. The migration written to protect one dashboard's layout was handing that layout to every other dashboard. It is gated on the default key now, and the default is a named constant rather than a repeated literal, because a fallback comparing against a copy of its own default stops matching the day someone bumps the version suffix. check:layout-key-namespaced grows arms D and E. D asserts BOTH widths take the sign and that the arrows share it — mirroring one and not the other is worse than mirroring neither, because then the handles disagree with each other. E asserts the legacy read is gated. Comments are stripped before both assertions, for the reason that is now written down four times over. Source only. STUDIO: needs a rebuild of research-dashboard and dashboard-plus-grid. NEEDS EYES: the drag is a gesture, so this wants rega in ar — drag the facet handle toward the map and confirm the FACET rail follows the cursor and the charts rail does not move, then the same with ArrowLeft/ArrowRight. |
||
|---|---|---|
| .. | ||
| api | ||
| colors | ||
| components | ||
| composables | ||
| constants | ||
| data | ||
| i18n | ||
| layouts | ||
| lists | ||
| 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.