5 commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
doxa-maps-88655c70
|
e7bc86d4f2 |
Map engine is one prop: MapLibre drops the search bar, legend rises
Simple Research showed a Fly + Clusters toolbar where the search bar used to be, and the map offered no way to pick an engine without writing a second map. FLY + CLUSTERS ARE NOW LEAF-ONLY. LegendTools renders at top:14px centred on the legend column — the search bar's exact slot — so on the Regions and Languages tabs (the legendTypes its predicate allows) it reads as having REPLACED the search bar. MEASURED on the leaf: fly toolbar at y=58 against the search bar at y=56, the two on top of each other. In a stack whose bottom half is a grid the reader is scanning, a fly-tour that moves the camera underneath fights the other half, so the composite passes legendTools:false. The standalone leaf keeps both. THE ENGINE IS ONE PROP. resolveMapProvider already read profileConfig .provider, so research-map.instances.json publishes the maplibre instance and a partner running thousands of embeds changes one value instead of maintaining a second map. Mapbox stays the default: it carries the richer feature set. MapLibre is the keyless option for volume. MAPLIBRE SHIPS NO SEARCH BAR, ON PURPOSE. GeocoderComponent's maplibre path still calls makeMapboxForwardGeocode(accessToken) (:526) — the geocoding REQUEST goes to Mapbox whichever engine draws the tiles. Shipping the bar under maplibre would keep billing the exact key the option exists to avoid while LOOKING free. Under mapbox it stays, unchanged. AND THE LEGEND RISES INTO THE VACATED SPACE. SemanticTreeLegend's --stl-top defaults to 60px that exists only to reserve room for a search bar; leaving it when the bar is gone is a dead band. MapToolbar's has-geocoder collapses its own reserved gap the same way. MEASURED against the built tree: leaf mapbox search@56 legend@104 fly@NONE (Prayer) / @58 (Regions) leaf maplibre search@NONE legend@58 — legend rose 46px composite search@NONE legend@104 fly@NONE on Regions 7/7 pre, 18/18 post. KNOWN GAP, pre-existing and NOT introduced here: the mapbox composite still shows no search bar. mapboxToken is injected per element and the composite passes neither tk nor tokenUrl to its child, so the child's geocoder gets an empty token and bails while the tiles render from another path. Isolated but not fixed. |
||
|
doxa-maps-88655c70
|
3685b196cb |
Show the cap-4 composite in the studio's Simple Research slot
The cap-5 shell's "Simple Research" tab rendered an error panel instead of the map, in both trees: Could not load <doxa-research-map> from ../../doxa-research-map/ doxa-research-map.js StackLayout already anchored sibling-bundle srcs to the tree root, but it anchored on the /doxa-maps/ segment of window.location.pathname. The studio mounts at the SERVER ROOT (/index.html), which has no such segment, so the lookup missed and the literal '../../' was returned untouched. The browser resolved it against '/', where '../' cannot climb, and requested /doxa-research-map/doxa-research-map.js — 404, both children, empty stack. That is why it survived: every gate and every screenshot used a LEAF url, and the studio is the one host that is not one. The same composite at its own leaf renders perfectly. resolveBundleSrc now falls back to bundleTreeRoot() — the bundle's OWN script URL, which rollup rewrites to document.currentScript.src in the IIFE build. That is a fact about where the code came from, not a guess about where the page is, which is the lesson stack-demo.vue wrote down when this defect appeared for the third time. It returns null in dev ESM and for any non-<name>/<name>.js layout, so it never guesses. The pathname rule stays FIRST and the untouched-string fallback stays LAST, so every path that worked before is byte-identical: this can still only fix a path, never break one. research-map-plus-grid also adopts stack-demo's bundleSrc() dev/prod helper. In dev, vite serves entries at /plugin-designs/<bundle>/index.js and there is no <bundle>/<bundle>.js to reach, so the dev surface 404'd too. import.meta.env.DEV is statically replaced, so the built output is byte-identical to the literal it replaces. Verified in a browser against the built tree, reading the screenshots: studio root -> Simple Research paints the world map with its prayer legend, on the dev server too. Negative-tested: disabling the new fallback and rebuilding restores the exact 404 and the empty canvas. No regression across every StackLayout consumer — rmpg shallow leaf, rmpg deep default/ leaf (the case the pathname rule was written for), spa -> Simple Research, dashboard-plus-grid, stack-demo — and all seven studio dashboards. 7/7 pre, 22/22 bundles, 18/18 post. |
||
|
doxa-maps-88655c70
|
4c8f6b4a6d |
Share the mobile composite too, and make the url absolute so the embed works
research-map-plus-grid had the same defect fixed yesterday on its desktop
sibling: sharing the composite emitted a link to doxa-research-map, the child it
nests. The gate said it exactly — "share URL reopened <doxa-research-map>, not
<research-map-plus-grid>" — and a recipient got the map alone, losing the grid.
Checked all four cap-4 composites rather than assuming the fix generalised.
my-upg-100-list owns its Share button directly and is fine. big-picture composes
a header plus the grid, owns no map and ships no Share button at all; the gate
reports "window.mapboxgl UNDEFINED" against it, which is its map precondition,
not a share failure — that bundle is out of this gate's scope and I put it in
the probe by mistake. So one real instance, now fixed.
Tier 1 again, for the same reason: this child also hardcodes a prop
(research-map.vue:2149 `:embed-path="'doxa-research-map/research-map/index.html'"`)
and the ladder is `embedPath || cfg?.shareEmbedPath`, so a prop outranks host
config and tier 2 is unreachable. Delivered through the profile-config attribute
rather than Vue provide, because this composite mounts its children as real
custom elements via src — there is no provide chain to reach them.
The url had to be ABSOLUTE, and the first version was not. resolveShareUrl
returns a tier-1 shareUrl verbatim (embedBase.js:95, `return whole.trim()`, no
resolution), and ShareButton feeds the same string into its embed snippet:
<iframe src="{shareUrl}">. A relative '../../…' would have resolved correctly in
the share LINK, because the browser resolves it against this page, and then
404'd in the EMBED, because it resolves against the partner's page instead. That
would have passed the gate — the gate navigates the link — while breaking the
deployment method the link exists for. Tier 1 is documented as "a WHOLE url" for
precisely this reason. Now computed with resolveEmbedBase() so it stays correct
on doxa.life, on nuxtbase.app and in a dropped tree.
Verified the desktop sibling did not have the same latent flaw: it produces a
fully absolute url, confirmed in the live gate output.
smoke:share-all now carries eleven targets. Full suite 11/11 pass · 0 fail.
Eleven gates pass, including sri, composite, composite-srcs and synced-css.
|
||
|
doxa-maps
|
236fef5682 |
Give nested ProfileLoader children the profile-config they require
Some checks are pending
build-gate / build (push) Waiting to run
Two composites nested a child by tag and URL without a profile-config. Those children do not render a component directly — their bundle entry mounts ProfileLoader, which reads profile-config.profile to choose which view to load. With none, the element still mounts and still reports its tag, so every structural check said both children were present, while the loader rendered "missing or invalid profile-config prop" where the map should be. The grid half of each page worked, which is how it survived. Found by reading a regenerated README screenshot, not by any gate. The mobile screenshot showed an error card and an empty pane; the fixed one shows the real research map with its data, controls and progress figures. research-map-plus-grid was mine, shipped that way. stack-demo predates it and had the same defect against research-dashboard. Both now pass the shape their own generated leaf pages use, so nested and standalone mounts ask for the same thing. check:composite-srcs now requires a profile-config on any child whose bundle mounts ProfileLoader, derived from which entries import it rather than a list. The first version of that check tested for the word and passed on its own explanatory comment; it now matches the quoted attribute key, and a negative test that mutates only the key fails as it should. Also regenerates three derived artifacts that had drifted behind this flight's changes: the library index, the capability exemplars table, and all twelve README screenshots. |
||
|
doxa-maps
|
b57aef457c |
Add the mobile capability-4 composite: research map above the people-groups grid
Some checks are pending
build-gate / build (push) Waiting to run
The desktop composite pairs the research dashboard with the grid. This is its mobile sibling: the monolithic 7-tab research map on top, the same grid beneath, stacked to scroll. Which one a shell shows is an aspect-ratio choice made at the SPA level, so neither plugin knows about the other and both stay embeddable. The grid's own search and filters are ON here. The desktop composite turns them off because the dashboard header owns those controls and drives the grid through props; the research map has no such header, so switching them off would leave the grid with no way to be searched at all. Composes its children by tag and bundle URL rather than importing their .vue files. Importing the research map directly would bypass its bundle entry, which is where its three bundle-private colour strategies, its profile registry, its Pinia and i18n pair and the RTL text plugin are installed — and losing those is a runtime defect in a green build, because a thrown setup() removes the subtree with an empty error. Add check:composite-srcs, which resolves every nested src against the built tree and asserts every nested tag is registered. A wrong relative depth is a 404, and the stack layout swallows a failed section on purpose so one broken child cannot take the whole stack down — which means the cost of that resilience is a silently empty band. Negative-tested both ways: breaking the depth and renaming a tag each fail with the file and path named; restoring returns to pass. |