Interface DataConfig

Name of the active profile to load.

Base path to the profiles directory. Default "profiles".

Content fingerprint of the profile, appended to every profile resource request.

Opaque, and never a date. The value is not read, compared or ordered — it is percent-encoded and interpolated into the ?t= parameter of each configuration URL. What matters is only that it CHANGES when the profile's content changes: a hash, a revision counter, a deployment id. A clock defeats the purpose, since it changes on every load and makes the browser and the service worker re-fetch resources that did not move.

Supplied by the embedding application, which alone knows when its profile changed — either in geoleaf.config.json or pushed into the store before boot. Writing it in profile.json is too late to have any effect: the token is resolved before that file is requested.

Absent ⟹ the token is 0, a fixed URL. That is the historical behaviour, and it is kept as the default — but a server sending a long max-age then pins the profile and all its sections for the lifetime of that header, which no cache flush on the server side can undo.

Enable POI mapping from active profile.

The active profile, handed over in memory instead of being fetched.

Carries BOTH on-disk artefacts, mirrored one to one — profile.json under profile, profile-bundle.json under bundle. They are two payloads because the bundle does not contain the profile: the compiler writes _bundleVersion plus the sections, and the assembly takes the profile as a separate argument. Handing over the bundle alone would leave the profile.json request in place.

Present ⟹ no HTTP request is issued for the profile's configuration. Absent ⟹ nothing changes: the cascade stays the default path. Data paths are still resolved from profilesBasePath; this removes configuration requests, not data ones.

⚠️ The bundle format is confronted but NOT enforced: a _bundleVersion other than the expected one produces a warning and the assembly continues. Sections the loader does not know are ignored, and sections it expects may be absent — so an injected bundle built by another version passes, quietly degraded rather than rejected.

Profiles offered by the profile-switcher capability.

Generated at deploy time by scripts/build-deploy.cjs, which harvests {id, displayLabel, icon} from every profiles/<id>/profile.json — never written by hand. A browser cannot enumerate a server directory, so the list has to be baked in; harvesting it from the same loop that copies the profiles is what keeps it from drifting.

Absent when the app runs straight from sources (no deploy step): the switcher then renders nothing, which is the intended degradation.