370446390f
Completes C1. Source only; studio rebuilds (rule 5B). Cut on top of C1a because it
depends on that move. Rebuild scope: country-posters, doxa-research-map,
research-dashboard, dashboard-plus-grid, gospel-resources.
resource.js existed as TWO identical plugin-local copies with no library original,
while library composables resolved it through the registry — so the library depended
on a plugin registering a module the library itself documented. Now it lives in
library/colors/ like the other eight, both copies are gone, and src/colors/ holds no
.js in either plugin. The local `registerStrategies(import.meta.glob('./src/colors/*.js'))`
in both index.js files is therefore DELETED: it matched nothing after the move, and a
glob that matches nothing reads as a deliberate override. Their now-unused
registerStrategies imports went with them. That also completes the shepherd's original
C1 instruction, which C1a had to defer for exactly this reason.
★ MY OWN PREDICTION HERE WAS WRONG, and the measurement is the only reason this is
clean. I predicted check:one-palette would FAIL after the move, reasoning that the
dashboards carry 6 of resource's 8 hexes (because 6 are SHARED with affinity-block and
language-family, which they legitimately ship) while the 2 unique ones — #20c997
jesusFilm and #2c3e50 noResources — are absent, and the gate fails a PARTIAL palette.
The gate PASSES: 9 strategies, 18 pairs. Once the module is in library/colors/,
_registry.js bundles it into every consumer, so all 8 hexes are present BY CONSTRUCTION.
I had reasoned about the pre-move bundle and assumed the rebuild would not change it.
That also corrects the diagnosis I gave earlier. simpleresearch was right that there
was no disagreement, but not that the 6 were coincidental substrings in minified
output: they are real hexes, genuinely present, shared across three strategies. The
gate cannot attribute a hex to a strategy — which is a real limitation worth knowing,
just not one that bites here.
Stale comments corrected rather than left to rot: five references across
useLegendData, researchLegendOptions, useWagfRegionsLegendData and my own
wagf-region.js header all claimed these palettes live in a plugin folder. One
parenthetical keeps the old path deliberately, as history.
GATES: check:one-palette PASS 9/18 (baselined 6/12 before C1a). check:library-index
PASS after regenerating the derived menu. check:no-free-identifiers PASS. All six
affected bundles build; their artifacts reverted.
85 lines
4 KiB
JavaScript
85 lines
4 KiB
JavaScript
/**
|
|
* doxa-research-map / index.js — Bundle entry
|
|
*
|
|
* Vite multi-entry build target. Emits app/doxa-maps/doxa-research-map/doxa-research-map.js.
|
|
*
|
|
* Registers ONE custom-element tag that mounts ProfileLoader:
|
|
* - <doxa-research-map> explicit tag matching the bundle name
|
|
* The legacy <doxa-map> tag is owned by the doxa-simple-map bundle — this
|
|
* bundle deliberately does not register it (see the registration comment below).
|
|
*
|
|
* The profile-config attribute is parsed by ProfileLoader (in @map). `profile`
|
|
* must match a .vue file in this bundle's folder.
|
|
*
|
|
* Profile registry — Q3 contract from the migration plan: ProfileLoader lives
|
|
* inside @map, so it cannot use import.meta.glob to reach into a bundle's
|
|
* folder. The bundle evaluates import.meta.glob('./*.vue') HERE and
|
|
* hands the result to the loader via app.provide('profileModules').
|
|
*/
|
|
|
|
import { defineCustomElement } from 'vue'
|
|
import { createPinia } from 'pinia'
|
|
import ProfileLoader from '@map/ProfileLoader.vue'
|
|
import { createAppI18n } from '@map/i18n/index.js'
|
|
|
|
// ─── Bundle-private profile registry ─────────────────────────────────────────
|
|
// import.meta.glob is evaluated by Vite at build time relative to THIS file —
|
|
// so it captures only this bundle's profiles.
|
|
const profileModules = import.meta.glob('./*.vue')
|
|
|
|
// ★ THE LOCAL COLOUR GLOB IS GONE (C1b). This bundle registered its own src/colors/*.js over the
|
|
// shared set; all three modules (doxa-region, affinity-block, resource) now live in library/colors/
|
|
// where _registry.js discovers them for every bundle, and src/colors/ holds no .js at all. The glob
|
|
// matched nothing, so leaving it would be dead code that reads as a deliberate override.
|
|
|
|
// ─── Mapbox RTL text plugin — load ONCE before any map instance ──────────────
|
|
if (typeof window !== 'undefined' && window.mapboxgl?.setRTLTextPlugin) {
|
|
try {
|
|
window.mapboxgl.setRTLTextPlugin(
|
|
'https://api.mapbox.com/mapbox-gl-js/plugins/mapbox-gl-rtl-text/v0.3.0/mapbox-gl-rtl-text.js',
|
|
null,
|
|
true // lazy
|
|
)
|
|
} catch (_) {
|
|
// Already set in this session — ignore.
|
|
}
|
|
}
|
|
|
|
/**
|
|
* Build a fresh defineCustomElement-wrapped class. Each instance gets its own
|
|
* Pinia + i18n so multiple embeds on the same page don't bleed state.
|
|
*/
|
|
function buildDoxaResearchMapElement() {
|
|
return defineCustomElement(ProfileLoader, {
|
|
configureApp(app) {
|
|
app.use(createPinia())
|
|
// Install i18n AND hand the instance to ProfileLoader by reference. The
|
|
// defineCustomElement root cannot use useI18n() (see ProfileLoader.vue);
|
|
// it drives locale through this provided instance instead.
|
|
const i18n = createAppI18n()
|
|
app.use(i18n)
|
|
app.provide('appI18n', i18n)
|
|
app.provide('profileModules', profileModules)
|
|
}
|
|
})
|
|
}
|
|
|
|
const DoxaResearchMapElement = buildDoxaResearchMapElement()
|
|
|
|
// ─── Register ONE tag — <doxa-research-map> ──────────────────────────────────
|
|
// IMPORTANT: this bundle deliberately does NOT register <doxa-map>. The legacy
|
|
// <doxa-map> tag is owned exclusively by the doxa-simple-map bundle. Why:
|
|
// customElements.define() is one-shot per tag per page session; if BOTH bundles
|
|
// registered <doxa-map>, an SPA user who visited /research first would have the
|
|
// research bundle's profileModules stuck on <doxa-map>, then any subsequent
|
|
// /home / /pray / /adopt navigation would render <doxa-map> with the research
|
|
// bundle's profile registry — which has 'research-map' but not 'doxa-simple-map',
|
|
// producing the "Profile not found" error. DoxaMapSlot already uses distinct
|
|
// tags per bundle (<doxa-map> vs <doxa-research-map>) — keep them disjoint here.
|
|
if (typeof customElements !== 'undefined') {
|
|
if (!customElements.get('doxa-research-map')) {
|
|
customElements.define('doxa-research-map', DoxaResearchMapElement)
|
|
}
|
|
}
|
|
|
|
export default DoxaResearchMapElement
|