c63ecb9cfe
upg100 asked for two parameters on the library chart so the packet's printed calendar and the on-screen one are the same thing configured differently, rather than two implementations that drift. Both are opt-in; every default is unchanged, and the component has no other caller today, so nothing moves. fill: 'scatter' | 'top' — WHERE the shaded cells sit. The two answer different questions, which is why this is a prop and not a fix. 'scatter' says "these weeks fall somewhere in a life and we do not know where", which is the honest answer for weeks lived. 'top' makes the grid a MAGNITUDE a reader can measure against its own frame: 32 cells scattered across 5,200 are invisible confetti, while 32 stacked from the corner are an obvious sliver. A share page wants 'top'; a life page wants 'scatter'. highlightRows: Number — rows marked as a band from row 1, for the printed calendar's 33-year highlight. ROWS, not cells, because the band is read along the year axis and a cell count would drift with the column width. Derived as rows x columns and CLAMPED to the grid, so a value larger than the calendar marks the whole calendar instead of overflowing into a class nothing renders. Verified: 33 x 52 = 1716 cells, 0 -> 0, 999 rows -> 5200 not 51948. The band is an OUTLINE, not a fill, and that is deliberate: the band and the shaded cells have to be readable at the same time, and two fills in one 32x32 print cell are indistinguishable. A shaded cell inside the band still reads as shaded, because --on wins the border. topCells() is added beside scatterCells in packetCharts, not inside the component, so the packet's Node renderer and the Vue chart share ONE implementation — which is the point of the request. It takes the same (total, n) signature as scatterCells so a caller can swap one for the other without reshaping anything, is deterministic with no seed (there is nothing to randomise), and clamps: topCells(10, 99) is 10 cells, not an error. gates:pre 66/66. |
||
|---|---|---|
| .. | ||
| charts | ||
| dashboards | ||
| hints | ||
| legends | ||
| map-controls | ||
| maps | ||
| poster | ||
| qa | ||
| regions | ||
| search | ||
| tables | ||
| BackToTopButton.vue | ||
| PeopleGroupDetail.vue | ||
| README.md | ||
| ResearchMapFilterPanel.vue | ||
| ResearchMapSideMenu.vue | ||
| SideMenuDrawer.vue | ||
| ViewSelect.vue | ||
| WARNING.md | ||
library/components/ — shared Vue components
The map UI, built from parameterized pieces every app-profile reuses. Fix one here and every map benefits — never edit a shared component to customize one map.
library/components/
┌───────────────────────────────────────────┐
│ legends/ map-controls/ poster/ │
│ charts/ tables/ │
│ PeopleGroupDetail.vue SideMenuDrawer.vue │
│ ResearchMapFilterPanel.vue …SideMenu.vue │
└───────────────────────────────────────────┘
reused by every app-profile via @map/components/…
legends/,map-controls/,poster/each have their own README.- Every component uses
<script setup>, callsuseShadowStyles(), and reaches stores viainject('mapStore' | 'uiStore' | 'dataStore')— never a direct store import.
Full catalog + conventions:
../../documentation/architecture/components.md ·
per-file roles: ../../documentation/reference.md.