These numbers print. A packet is handed to a reader on paper: no hover, no tooltip, no correction, no redeploy. So the arithmetic lives in its own module and is asserted against the shipped data rather than a fixture. DOXA IS NOT A SLICE. Of its 2,107 groups, 2,082 are unreached and 1,745 are frontier, so 25 are not unreached at all and 362 are not frontier. That is one group in six. A chart drawing DOXA as a fourth band nested inside frontier misstates 17.2% of the list with a clean shape and no error of any kind, which is why steps and overlays are different props and an overlay reports whether it is a slice rather than being assumed to be one. upg100 asked for the numbers to reach the caption as text too, because a printed band nobody can hover over explains nothing. Three bugs I wrote, each caught by an assertion rather than by review: The publisher warning sat in the wrong function. I put "Joshua Project counts 16,426 where IMB counts 12,379" into the nesting error, and the test proved the claim false: 16,426 on top of 12,379 is perfectly monotonic. The two are not the same kind of count, and no comparison of magnitudes can see that, so it needed a separate check reading what the numbers are OF. An error message naming a cause its own code cannot detect sends the next reader to look for the wrong thing. A percent read as a fraction filled 3,189 cells of 5,200 instead of 32. My heuristic was "above 1 means percent", and pctEvangelical is 0.6133, which is a valid fraction and a valid percent with nothing in the value to separate them. The refusal I added catches a percent of 1 or more and provably cannot catch ours, and every share this packet prints is below 1% because the subject is unreached peoples. So the guard is not the protection, the name is: fractionFromPercent states the unit in the source line. Both halves are asserted, including the half that does not work, because a guard believed to cover more than it does is the worse failure. And the rounding flags were untested until the test used values that could reach them. 0.6133% of 5,200 is 31.9 cells; the reader sees 32 and cannot see 31.9, so the exact value goes in the caption and a share too small to fill one cell is flagged rather than drawn as one. |
||
|---|---|---|
| .. | ||
| api | ||
| colors | ||
| components | ||
| composables | ||
| constants | ||
| data | ||
| 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.