29bbab3967
Dispatch work item (5) asked for useTextHighlight in library/. RULE 2 wants a named SECOND consumer before anything moves there, and it exists: regions-dashboard's UupgsList and people-groups-grid both consume the same Fuse-compatible shim, both read match.indices, both wrap hits in <span class="search-highlight">, and both append the tail only on the last range. Line for line the same construction, apart from variable names. So library/composables/useTextHighlight.js exports highlightRanges(value, indices), and UupgsList calls it. Its local escapeHtml goes too: every caller was inside the highlight body that moved. ★ ESCAPING NOW COMES FROM library/utils/html.js, AND THAT IS A CHANGE FOR BOTH CALLERS, stated rather than smuggled. Three implementations existed and differed: library/utils/html.js escapes & < > " ' AND backtick; returns '' for null UupgsList no backtick; guarded null via String(v ?? '') people-groups-grid no backtick; NO NULL GUARD — s.replace(null) THROWS Both deltas move in the safe direction — one more character escaped, one crash removed — and neither changes the output of any value that renders today. The gate pins both, with controls proving each delta is a real difference rather than a no-op: the old copy really does leave a backtick unescaped, and their escaper really does throw on null. people-groups-grid is NOT migrated here: it is another owner's file, so it is handed over as source. The gate asserts it still builds its own highlighter, so this check states the truth rather than implying the job is finished. check:text-highlight is registered (script line, gates:post token, hand-inserted) and negative-tested: an implementation that escaped nothing fails it, and the output is asserted to depend on the indices. |
||
|---|---|---|
| .. | ||
| 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.