@museumwnf/viewer-core 1.16.1 → 2.0.0

package/README.md

@@ -452,8 +452,6 @@ under the main partner it belongs to.
 
 | Export | Meaning |
 | --- | --- |
-| `projectName(key, t)` / `useProjectName()` / `PROJECT_ENTRIES` ⚠️ deprecated | a project's name by its legacy key (`ISL`, `EPM`, `DBA`, `BAR`, `AWE`, `DCA`, `DGA`, `EXTHE`, `GALLERIES`), through `core.project.*`; an unknown key reads as itself |
-| `projectFamily(key)` / `PROJECT_FAMILIES` ⚠️ deprecated | a project's colour family by the same legacy key (ISL and EPM share `ISLandEPM`, every exhibition shares `EXH`, …) — legacy's own class names, so a site's CSS reads as the stylesheet it was copied from; an unknown key reads as itself |
 | `useSection()` | the `meta.section` of the current route — see Routing |
 | `useFeaturedRecord(entity, { withImage = true, seed })` | one record at random for a landing page's spotlight, among those with an image; null until the entity is loaded; `seed` pins the pick |
 | `sectionMeta(chrome = [])` | returns `meta(section, ...entities) => ({ section, entities: [...chrome, ...entities] })` — a route's `meta` in one call, `chrome` being the entities every page of the site loads regardless of which one it is |
@@ -461,26 +459,24 @@ under the main partner it belongs to.
 
 #### Projects, from the data package (epic metanull/inventory-app#1727)
 
-`manifest.projects` — a project UUID → `{ name: { <lang>: '…' }, site_url, related_database_url, artistic_introduction_url }` map, emitted by every exporter since #1727 phase 2 — is project data moved out of viewer-core and into the data package a project's own exporter writes. It is additive: a package built before phase 2 simply has no `projects` key, and every function below reads that exactly like an unknown project id — `null`, never a throw.
+`manifest.projects` — a project UUID → `{ name: { <lang>: '…' }, site_url, related_database_url, artistic_introduction_url }` map, emitted by every exporter since #1727 phase 2 — is project data read from the data package a project's own exporter writes, not carried in viewer-core. It is additive: a package built before phase 2 simply has no `projects` key, and every function below reads that exactly like an unknown project id — `null`, never a throw.
 
 | Export | Meaning |
 | --- | --- |
 | `projectLabel(manifest, projectId, lang)` | `manifest.projects[projectId].name[…]`, with the same language fallback every translated field in this package follows (`resolveRecordLanguage`): `lang`, then this package's base language (`en`), then the entry's first carried language. `null` when the package has no `projects` section, `projectId` isn't a key of it, or the entry names nothing. |
 | `projectLinks(manifest, projectId)` | `{ siteUrl, relatedDatabaseUrl, artisticIntroductionUrl }` from the same entry (camelCased, individually nullable — a project may simply have no value for one). `null` for the whole result when the package predates the section or doesn't carry `projectId`. |
-| `useProjects()` | `{ label(projectId, lang?), links(projectId) }` bound to the installed data package and active language — the manifest-driven analogue of `useProjectName()`. |
+| `useProjects()` | `{ label(projectId, lang?), links(projectId) }` bound to the installed data package and active language. |
 
-Migration mapping, from the epic's design comment (§B) — what each of the five usages moves to:
+What each of the sites' former legacy-key usages reads now, from `manifest.projects` (see CHANGELOG.md 2.0.0 for the full removal/migration notes):
 
-| Today (deprecated) | Reads from `manifest.projects` instead |
+| Formerly | Now reads |
 | --- | --- |
-| RecordView citation line (`projectName(record.project_key, t)`) | `projectLabel(manifest, record.project_id, lang)` / `useProjects().label(record.project_id)` — tracked on viewer-layout#81 |
-| ItemSheet "Source database" line + `mwnf-chip--<family>` colour | same `projectLabel`, plus a site-config map from project UUID to a CSS token (no more `projectFamily`) |
+| RecordView citation line (`projectName(record.project_key, t)`) | `projectLabel(manifest, record.project_id, lang)` / `useProjects().label(record.project_id)` |
+| ItemSheet "Source database" line + `mwnf-chip--<family>` colour | `projectLabel`, plus a site-config map from project UUID to a CSS token |
 | "Search related database" block | `projectLinks(manifest, projectId).relatedDatabaseUrl`, rendered iff non-null |
 | Artistic Introduction link | `projectLinks(manifest, projectId).artisticIntroductionUrl`, iff non-null |
-| Search-scope include-EPM checkbox | unchanged by this phase — stays the site's own `dataset.config.js` scope list (epic decision 5) |
-| Partner Museums/Institutions split | unchanged by this phase — `partner.project_uuids` matched against a site-config list (epic decision 5) |
-
-`PROJECT_ENTRIES`, `PROJECT_FAMILIES` and `projectFamily` are deprecated as of this phase and will be removed in the cleanup wave once every site has migrated (phase 4); `projectName()`/`useProjectName()` are unaffected for now — they still resolve a *legacy key* through the installed texts for whatever hasn't migrated yet.
+| Search-scope include-EPM checkbox | the site's own `dataset.config.js` scope list (epic decision 5) |
+| Partner Museums/Institutions split | `partner.project_uuids` matched against a site-config list (epic decision 5) |
 
 ### `@museumwnf/viewer-core/legacy`
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@museumwnf/viewer-core",
-  "version": "1.16.1",
+  "version": "2.0.0",
   "description": "Application engine for MWNF websites: turns a dataset.config.js into a mounted Vue application.",
   "type": "module",
   "license": "SEE LICENSE IN LICENSE.md",

package/src/conventions.js

@@ -7,88 +7,11 @@ import { resolveRecordLanguage } from './composables/useRecordLanguage.js'
 
 // Three small conventions each website had written for itself.
 
-// ── Project names ──────────────────────────────────────────────────────────
-//
-// `mwnf3.projectnames`, the whole table rather than the projects a website
-// happens to borrow from, since that set moves with every reimport. The key
-// on the left is data; the entry on the right is a shared text
-// (`core.project.*` in viewer-i18n), written out so a reader can see the
-// eight this asks for. A key that is not here reads as itself.
-//
-// @deprecated Project data belongs in the data package, not in viewer-core.
-// Read a project's name from `manifest.projects` via `projectLabel()` /
-// `useProjects()` instead (epic metanull/inventory-app#1727, phase 3) — see
-// the migration table below. Kept only for sites that have not migrated yet
-// (phase 4); removed in the cleanup wave.
-export const PROJECT_ENTRIES = Object.freeze({
-  ISL: 'core.project.islamicArt',
-  EPM: 'core.project.explorePartners',
-  DBA: 'core.project.baroqueArt',
-  BAR: 'core.project.baroqueArt',
-  AWE: 'core.project.sharingHistory',
-  awe: 'core.project.sharingHistory',
-  DCA: 'core.project.carpetArt',
-  DGA: 'core.project.glassArt',
-  EXTHE: 'core.project.tableIsSet',
-  GALLERIES: 'core.project.galleries',
-})
-
-/** The name of a project by its legacy key, through `t`; the key itself when unknown. */
-export function projectName(key, t) {
-  const entry = PROJECT_ENTRIES[key]
-  return entry ? t(entry) : (key ?? '')
-}
-
-/** `projectName` bound to the installed texts, for a component. */
-export function useProjectName() {
-  const { t } = useI18n()
-  return (key) => projectName(key, t)
-}
-
-// A member is borrowed from the MWNF project that originally published it,
-// and legacy names and colours that project on the item sheet and in the
-// results grid — two separate mappings, because legacy keeps them separate:
-// the name is per project key (`PROJECT_ENTRIES` above), the colour is per
-// project *family*, so ISL and EPM share a swatch and every exhibition
-// shares another. The two exhibition sites re-hard-coded this table as
-// English literals next to their own copy of the name table, which is why a
-// project name translates on the galleries and not on the exhibitions.
-//
-// @deprecated Chip colour is a per-project site-config map keyed by the
-// project UUID (epic #1727 decision 1: no family/parent relation is modeled
-// anywhere, this table was always a frontend invention). Removed in the
-// cleanup wave alongside `PROJECT_ENTRIES`.
-export const PROJECT_FAMILIES = Object.freeze({
-  ISL: 'ISLandEPM',
-  EPM: 'ISLandEPM',
-  DBA: 'DBA',
-  BAR: 'DBA',
-  AWE: 'AWE',
-  awe: 'AWE',
-  DCA: 'DCA',
-  DGA: 'DGA',
-  EXTHE: 'EXH',
-  GALLERIES: 'Galleries',
-})
-
-/**
- * A project's family by its legacy key — legacy's own class names, so a
- * site's CSS reads as the stylesheet it was copied from. A key with no
- * entry falls back to itself, the same rule `projectName` applies.
- *
- * @deprecated See `PROJECT_FAMILIES`.
- */
-export function projectFamily(key) {
-  return PROJECT_FAMILIES[key] ?? (key ?? '')
-}
-
 // ── Projects, from the data package ─────────────────────────────────────────
 //
-// `manifest.projects` (epic metanull/inventory-app#1727, phase 2 —
-// `scripts/exporters`) is what `PROJECT_ENTRIES`/`PROJECT_FAMILIES` above
-// should have been: project data belongs in the data package a project's own
-// exporter writes, not in a table viewer-core carries for every website. Its
-// shape, one entry per project UUID:
+// `manifest.projects` (epic metanull/inventory-app#1727 — `scripts/exporters`)
+// is project data from the data package a project's own exporter writes.
+// Its shape, one entry per project UUID:
 //
 //   manifest.projects[projectId] = {
 //     name: { <lang>: '…' },                    // per-language title
@@ -99,21 +22,8 @@ export function projectFamily(key) {
 //
 // A data package built before this phase simply has no `projects` key at
 // all; `projectLabel`/`projectLinks` answer `null` for that case exactly as
-// they do for an unknown `projectId` — a site notices nothing until it
-// migrates. Migration mapping, from the epic's design comment (§B):
-//
-//   RecordView citation line           → projectLabel(manifest, record.project_id, lang) (viewer-layout#81)
-//   ItemSheet "Source database" line   → same, plus a site-config colour map keyed by project UUID (no more `projectFamily`)
-//   "Search related database" block    → projectLinks(manifest, id).relatedDatabaseUrl, rendered iff non-null
-//   Artistic Introduction link         → projectLinks(manifest, id).artisticIntroductionUrl, iff non-null
-//   search-scope include-EPM checkbox  → stays the site's own dataset.config.js scope list (not modeled here — decision 5)
-//   partner Museums/Institutions split → partner.project_uuids matched against a site-config list (decision 5)
-//
-// `PROJECT_ENTRIES`, `PROJECT_FAMILIES` and `projectFamily` are deprecated by
-// this section and removed in the cleanup wave once every site has moved
-// (phase 4). `projectName()`/`useProjectName()` are unaffected — they still
-// resolve a *legacy key* through the installed texts, for whatever has not
-// migrated yet.
+// they do for an unknown `projectId`. See CHANGELOG.md 2.0.0 for the
+// migration notes from this package's former legacy-key conventions.
 
 /** One entry of `manifest.projects`, or `null` when the package predates
  * the section or does not carry `projectId`. */
@@ -156,9 +66,8 @@ export function projectLinks(manifest, projectId) {
 
 /**
  * `projectLabel`/`projectLinks` bound to the installed data package and
- * texts, for a component — the manifest-driven analogue of
- * `useProjectName()`. `label(projectId)` reads the site's active language;
- * pass a language explicitly to read another.
+ * texts, for a component. `label(projectId)` reads the site's active
+ * language; pass a language explicitly to read another.
  */
 export function useProjects() {
   const { manifest } = useDataPackage()

package/src/dxa/exhibition/useExhibitionData.js

@@ -168,9 +168,8 @@ export function useExhibitionData(config = {}) {
   // A member is borrowed from the MWNF project that originally published
   // it. The name is the data package's own `manifest.projects` entry
   // (populated by the importer/exporter), keyed by this record's
-  // `project_id` (a UUID) — not viewer-core's deprecated, legacy-key-keyed
-  // `projectName()`/`projectFamily()`, and not an exhibition's own
-  // project-key comparisons either. The manifest already names an
+  // `project_id` (a UUID) — not a legacy-key lookup, and not an exhibition's
+  // own project-key comparisons either. The manifest already names an
   // exhibition's own native project under its own uuid (the sibling
   // `Collection` the importer creates alongside every `Project` carries the
   // same title), so there is no special case here for a native member any

package/src/index.js

@@ -39,8 +39,7 @@ export { groupByCountry, partnerHierarchy } from './record/partners.js'
 
 // Conventions every website had written for itself.
 export {
-  PROJECT_ENTRIES, PROJECT_FAMILIES, mwnfLinks, projectFamily, projectLabel,
-  projectLinks, projectName, sectionMeta, useFeaturedRecord, useProjectName,
+  mwnfLinks, projectLabel, projectLinks, sectionMeta, useFeaturedRecord,
   useProjects, useSection,
 } from './conventions.js'