d54ece3b25
DashboardFilterChips.vue moves to library/components/dashboards/. Nothing about the rendering changed. What made the move possible was 4b, which inverted the one dependency that blocked it: this file imported useTreeLegendLabels — the People CODE -> NAME tables, research-specific and staying in plugin-designs — and a library component importing a plugin composable is what check:no-cross-plugin-imports refuses. The resolver now arrives on dashboardConfig.legend. THREE THINGS BEYOND THE MOVE, all found by assessing the file rather than by moving it: 1. THE UNCONFIGURED DEFAULT NOW JOINS A LIST. 4b's fallback returned the value untouched, so a multi-value filter (spec D1) printed String(['A012','A013']) = "A012,A013", comma-jammed, while a dashboard that DID supply a resolver got "South Asian Peoples, Bengali Peoples". Configured and unconfigured should differ in whether CODES RESOLVE, never in punctuation — the second difference reads as a rendering bug rather than as missing configuration, and go-int is the consumer who will see the unconfigured state first. 2. THE DEAD INJECTS ARE GONE. `dataStore` and `searchSourceId` existed only to construct useTreeLegendLabels and have been unused since 4b. Removed rather than left in place: an unused inject is a claim about the host, and a kit component that appears to need a research dataStore is one a new dashboard will dutifully provide before discovering it is never read. 3. AN EXPLICIT EXCEPTION TO library/components/WARNING.md, recorded in the file's own header. That file says a component graduates into the library only once MORE THAN ONE map uses it; this one is used by ZERO, because the topbar dedup pass unmounted it when SearchFilterHeader became the single source of truth for showing and clearing filters. It is here because the kit's promise runs the other way round — a NEW dashboard mounts kit components, so waiting for a second consumer before providing the first one is a deadlock. The honest consequence is written down too: a passing gate means "it mounts and degrades", not "it looks right", and nobody has SEEN this component since the dedup. Whoever wires it in is its first real reader, and must not mount it beside a SearchFilterHeader that is already showing chips. check:legend-mirrors grows arm 5, and it asserts the two things a "move" gets wrong that reading the new file cannot show: that the OLD copy is actually gone (a move that leaves the original behind is a copy, and two chip bars over one filterSet drift the moment one is edited — this tree has already paid that with useNeighborT/usePplrT at Jaccard 0.82), and that the UNCONFIGURED behaviour is right, which no dashboard here would reveal because they all supply a resolver. The default is LIFTED out of the source and RUN, the way arm 3 drives the rail's fallbacks — not mounted, because a no-op renderer cannot show a chip and the rendered result is rega's. Five mutants, all caught: old copy left behind, the join reverted to 4b's bare value, a dead inject re-added, the supplied resolver ignored, and a relative import restored. The barrel re-exports from the library for one cycle, so no consumer's import line changes in the same landing that moves the file. documentation/reference-library-index.md regenerated, per landing. PARENTED ON a285e06c (4b), not on main, because 4b edits this same file — landing them the other way round would revert 4b's inversion. Source only: research-dashboard and dashboard-plus-grid need a rebuild. |
||
|---|---|---|
| .. | ||
| architecture | ||
| assets | ||
| contributing | ||
| needs-eyes | ||
| readme-images | ||
| screenshots | ||
| CONTRIBUTING.md | ||
| develop-a-plugin-and-see-it-live.md | ||
| explanation.md | ||
| how-to.md | ||
| README-embed-example.md | ||
| README-embed-gospel-resources.md | ||
| README-SECTION-3-cli-commands.md | ||
| README.md | ||
| reference-capability-exemplars.md | ||
| reference-library-index.md | ||
| reference-universal-props.md | ||
| reference.md | ||
| tutorial.md | ||
| vendored-font-noto-serif-devanagari.md | ||
| why.md | ||
documentation/ — pick your path
"what is this?" "teach me" "how do I …?" "look it up" "all the detail"
│ │ │ │ │
why.md ──────────► tutorial.md ────► how-to.md ────► reference.md ───► architecture/
(2 min, 1 diagram) (first map) (task recipes) (tables) (contracts)
- why.md — the problem and the "map islands" idea. Start here.
- tutorial.md — build your first map, no jargon.
- how-to.md — recipes: embed, iframe, SPA, colors, CDN, mobile, tokens.
- reference.md — config fields, build scripts, the
profile-configcontract. - explanation.md — the model in 15 lines.
- architecture/ — the deep end: full contracts, the per-file catalog.
- README-embed-example.md — the drop-in README used when this bundler is embedded inside a host repo.
- README-embed-gospel-resources.md — the gospel map's URL contract for partner embeds: bring your own ISO 639-3 list, one country, one group, or the zero-access view.
Working on the repo:
- develop-a-plugin-and-see-it-live.md — ★ the golden path: zero to a plugin live, in 6 steps.
- README-SECTION-3-cli-commands.md — every command, per deployment method, with prerequisites.
- reference-capability-exemplars.md — which bundle is at which capability tier (generated).
- reference-library-index.md — the reusable
library/pieces you can import (generated). - CONTRIBUTING.md and contributing/ — how to contribute, and the bar for
library/.
Nothing on the simple path is longer than a few minutes; everything complex lives in
architecture/, linked from where you'd need it.