30dc9a1457
library/composables/useViewAddress.js is the page's address for the view a reader is on: ?tab= &pane= &place=, with a level rule, an id whitelist, and ONE history write (commitUrl). It keeps history.state and sets its `current` to the new URL, so a link survives the next in-app navigation on a Vue Router host. The OUTERMOST owner writes, named by profile-config urlOwner: - 'app' writes history itself; - 'host' hands its router one dxm-address; - absent, nothing is written and links are still read. Nested elements announce dxm-view. Back/Forward is read and never written. useShareableView's filter write used to call replaceState(null, ...) itself, which wiped the router's state. It now goes through commitUrl (writeFilterView). A filter write keeps tab/pane/place, and a tab/pane/place write keeps the filters. Level 2 is `pane`, not `view`: ?view= is already published by four of our pages. check:view-address (gates:pre) runs on a simulated browser history. It covers: - the whitelist and the level rule; - one push per tab change, with state + current kept; - no write when unchanged, on a partner page, or by a host owner; - the filters and the view keys keeping each other through writes, Back and Forward; - a census of every history writer in library/ and plugin-designs/ (6 today). A new writer fails until it is listed. The self-test has 14 poisons, each caught. Real-source mutations are caught too: drop current, drop the unchanged guard, drop the level rule, an uncomposed event, no length cap, an aliased pushState in a plugin. |
||
|---|---|---|
| .. | ||
| api | ||
| charts | ||
| colors | ||
| components | ||
| composables | ||
| constants | ||
| dashboards | ||
| data | ||
| elements | ||
| i18n | ||
| layouts | ||
| lists | ||
| maps | ||
| packet | ||
| packets | ||
| 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.