CMS Kronik #02: Tags Tværsamling

Idéen kom naturligt. Vi kiggede på Artikler-sektionen på webhouse.dk — fire serier, indlæg der vokser — og det oplagte spørgsmål dukkede op: hvad nu hvis et indlæg passer til mere end én serie? Hvad hvis du vil finde alt, vi har skrevet om "ai" eller "arkitektur", uanset hvilken serie det ligger i?

Et CMS uden tags er som en arkivmappe uden etiketter. Du ved omtrent, hvor tingene er, men du kan ikke trække alt relateret til et emne ud i ét træk.

Hvad vi har bygget

Tags i @webhouse/cms fungerer som en førsteklasses felt-type:

• Et tags-felt gemmer en streng-array på ethvert dokument i enhver samling.
• findMany() accepterer nu et tags-filter — dokumenter skal indeholde ALLE de angivne tags (AND-logik).
• findByTag(tag, collections?) søger på tværs af flere samlinger i ét kald.
• getAllTags() på webhouse-site returnerer en deduplikeret, sorteret liste over alle anvendte tags.

Implementeringen var lille — omkring 30 linjer fordelt på fire filer — fordi arkitekturen allerede var på plads. Tags er blot data. findMany()-filterkæden håndterede allerede status. At tilføje tags var blot ét ekstra filtertrin.

Beslutningen om AND-logik

Når du sender flere tags til findMany(), bruger forespørgslen AND — et dokument skal have alle tags. Dette er den strengere, mere præcise adfærd. Hvis du ønsker OR (ethvert af disse tags), kalder du findByTag() én gang per tag og sammenføjer resultaterne. Primitivet er sammensættelig.

Hvad det muliggør

Tagsider er det oplagte næste skridt: /tags/ai viser alle indlæg og casestudier med tagget ai, på tværs af alle samlinger. Tværsamling-opdagelse. En læser, der følger et emne, ikke en serie.

Vi vil bygge den side, når der er nok tagget indhold til at gøre det nyttigt. Indtil da er infrastrukturen på plads — og dette andet CMS-kronik-indlæg er selv tagget med cms, arkitektur og tags.

Mønsteret

Læg mærke til, hvad vi ikke har bygget: en separat tags-samling, en join-tabel, en taggingsservice. Tags er blot streng-arrayer på dokumenter. Forespørgselslaget ved, hvordan man filtrerer på dem. Det er det.

“Kompleksitet er let at tilføje senere. Enkelhed er svær at genvinde, når man først har opgivet den.”

Vi vil holde primitivet simpelt, indtil et reelt brugsscenarie kræver mere.