Webcomponents

go~mus Webcomponents sind wiederverwendbare HTML-Elemente mit eigener Logik, ohne mitgeliefertes Styling - ein browsereigener Standard ohne Framework-Abhängigkeit. Du betreibst weiter deine Webseite, deinen Shop, dein CMS; die Komponenten kümmern sich um die standardisierten Buchungs- und Checkout-Flows.

Diese Seite ist der Architektur-Überblick. Aktuelle Komponenten-API, Properties und Beispiele leben in der offiziellen Doku - wir verlinken weiter unten.

Custom Elements als Bausteine

<go-tickets></go-tickets>
<go-cart></go-cart>
<go-checkout-form></go-checkout-form>

Diese Tags verhalten sich wie <input> oder <video>, nur selbstgebaut - lauffähig in React, Vue, Svelte, WordPress, TYPO3 oder purem HTML. Ein Bundle, alle Plattformen, kein Vendor-Lock. W3C-Standard, alle aktuellen Browser ohne Polyfill.

Die Library: @gomusdev/web-components auf npm. Live-Storybook mit Komponenten und Beispielen: webcomponents.platform.gomus.de.

Initialisierung

Die Library muss einmal pro Seite initialisiert werden. Snippet unten in den <head> einfügen. Der kleine Inline-Stub erzeugt ein go-Objekt mit gequeueten init- und config-Aufrufen, danach lädt go.load() das Library-Bundle und spielt die Queue ab.

<script>
  // use _go_src to override the default location of the webcomponents library
  // _go_src = '../dist-js/gomus-webcomponents.js'
  ;(function (w) {
    let _queue = []
    let stub = method => options => _queue.push({ method, options })
    let go = {
      _queue,
      init: stub('init'),
      config: stub('config'),
    }
    go.load = function (options) {
      var s = document.createElement('script')
      s.src =
        window._go_src ??
        'https://unpkg.com/@gomusdev/web-components@' + options.version + '/dist-js/gomus-webcomponents.iife.js'
      document.head.appendChild(s)
    }
    window.go = go
  })(window)

  // Load the web components library
  go.load({ version: 'latest' })

  // Initialize the shop
  go.init({
    shop: 'your-shop-id',
    api: 'api.gomus.de',
    locale: 'de'
  })
</script>

In Produktion eine konkrete Version pinnen (z.B. version: '2.1.x') statt 'latest'. window._go_src setzen, wenn du das Bundle selbst hostest. Nach go.init() werden alle <go-*>-Elemente auf der Seite aktiv.

Was sich damit verkaufen lässt

Produkt	Was ist das	Status
Tages-Tickets	Einzel-Eintritt, optional mit Zeitfenster	Verfügbar
Events (EPA)	Einzelplatzangebot - Veranstaltung mit Terminen, Plätze pro Teilnehmer	Verfügbar
Jahreskarten	Zeitraum-basiert, mit Personalisierung	Verfügbar
Kombi-Tickets	Mehrere Tickets als Paket (Ausstellung + Führung etc.)	Verfügbar
Gruppen-Tours	Buchung als ganze Gruppe (Paketpreis)	Roadmap
Gutscheine	Wertgutschein als verkaufbares Produkt	Roadmap
Merchandise	Physische Produkte (Katalog, Shop-Artikel)	Roadmap

Wichtig: Events ≠ Tours. Events (EPA) verkaufen Einzelplätze an einzelne Teilnehmer:innen. Tours verkaufen eine ganze Gruppe als Einheit, etwa eine private Führung für eine Schulklasse. Zwei Kategorien, zwei Workflows. Mehr in Events und Tours.

Koexistenz: was übernimmt die Komponente, was bleibt deins

Webcomponents sind Bausteine, keine Plattform. Auf deiner Webseite koexistieren sie mit allem, was schon da ist.

Komponente übernimmt:

Bezahlte Tickets und Events
Warenkorb und Checkout
Login, Registrierung, Profil
Jahreskarten-Verkauf inkl. Personalisierung

Bleibt wie vorher:

Kostenlose Event-Anmeldung als eigenes Formular
Newsletter-Anmeldung (Mailchimp, Brevo, ...)
Spendenformular (z.B. betterplace)
Veranstaltungs- und Ausstellungskalender aus dem CMS

Du behältst die Hoheit über alle anderen Touchpoints. Webcomponents kommen nur dort zum Einsatz, wo sie echten Mehrwert bieten.

Saubere Trennung deiner Logik und der Komponente

Die Webcomponents sind die standardisierte Kaufstrecke. Alles drumherum lässt sich im Shop-Gerüst frei ergänzen, ohne auf einen Library-Release zu warten.

Beispiel aus einem Produktiv-Shop. Bei bestimmten Veranstaltungen brauchst du als Besucher:in zusätzlich eine Eintrittskarte. Im Warenkorb erscheint ein Hinweis-Block, der genau auf das passende Tages-Ticket verlinkt. Diese Logik sitzt nicht im Webcomponent, sondern im umgebenden Shop-Code. Eine Tagesarbeit, ohne den Komponenten-Code anzufassen.

Was möglich wird im Shop-Gerüst rund um die Komponenten:

Museumsspezifische Hinweise und Upsells
Eigene Landingpages für Aktionen
CRM- und Newsletter-Anbindungen
Analytics, A/B-Tests, Cookie-Banner

Wer macht was:

Komponente = standardisierte Kaufstrecke, Updates konfliktfrei einspielbar
Shop-Code = museumseigene Wünsche, unter deiner Kontrolle, eigener Release-Zyklus

Beispiel-Snippet

So sieht eine minimale Ticketauswahl mit Datumspicker und Cart-Button aus:

<go-ticket-selection filters="ticket:day">
    <go-calendar></go-calendar>
    <go-timeslots></go-timeslots>
    <go-tickets>
      <go-ticket-segment>
        <go-ticket-segment-body></go-ticket-segment-body>
      </go-ticket-segment>
    </go-tickets>
</go-ticket-selection>

Mehr ist nicht nötig, um eine Tages-Ticketauswahl auf einer beliebigen HTML-Seite zu zeigen. Vollständige Komponenten-Liste, Properties, Events und Page-Beispiele für Cart, Checkout und Account-Flows: im Storybook.

Qualität in der Tiefe

Die Komponenten sind keine Demo-Library, sondern Produktiv-Software für Museumsumsätze:

Performance - lazy-loaded Bundles, Code-Splitting, optimierte Assets. Lighthouse-tauglich auf Mobile und Desktop.
Barrierefreiheit - WCAG 2.2 AA als Anspruch. Tastatur-Navigation, Screen-Reader-Tests. BITV 2.0 für öffentliche Häuser erreichbar.
Sicherheit - Content-Security-Policy-freundlich, keine inline-Skripte, Dependency-Audits im Release.
Qualität - automatisierte Tests, Storybook-getriebener Komponenten-Workflow, kontinuierliches Release-Tracking.
Mehrsprachigkeit - DE und EN out-of-the-box, weitere Sprachen per Konfiguration und Übersetzungs-Sync.
Erweiterbarkeit - museumseigene Features sauber im Shop-Gerüst eingekoppelt, ohne Komponenten-Code zu verändern. Update-sicher.

Hinweis zur Barrierefreiheit: Die Komponenten sind rein funktional und kommen ohne Styling - auf funktionaler Ebene bieten wir volle Barrierefreiheit (Semantik, Tastatur-Navigation, Fokus-Reihenfolge, ARIA-Rollen). Visuelle Barrierefreiheit - Farbkontrast, Schriftgrößen, Abstände - lebt in deinem Shop-CSS und liegt in deiner Verantwortung.

Aktive Entwicklung als Vorteil

Die Library steht unter laufender Weiterentwicklung. Zwei Tracks laufen parallel auf npm.

Track	npm-Tag	Wann nutzen
Master	`@latest`	Produktion. Stabiler Release, vollständig getestet. Die sichere Standardwahl.
Next	`@next`	Du brauchst ein Feature, das gerade gelandet ist und noch nicht in Master steckt. Evaluierung, Early Adopter, Migrations-Vorbereitung.

Wie wählen. Starte mit Master. Pinne den Major (z.B. @gomusdev/web-components@2.x), Patch- und Minor-Updates kommen sicher rein. Wechsel ein Deployment nur dann auf Next, wenn du ein Feature brauchst, das noch nicht in Master ist. Sobald das Feature in Master ankommt, zurückwechseln.

Patch- und Minor-Releases laufen auf beiden Tracks kontinuierlich. Breaking Changes stehen im npm-Changelog, bevor sie ausgeliefert werden.

Versionierung und Source-of-Truth

Die Library wird aktiv weiterentwickelt. Major-Bumps können Breaking Changes mitbringen - das ist Software, nicht Marketingcopy.

Empfehlungen:

Version pinnen in Produktion. @gomusdev/web-components@2.1.x statt @latest, sonst zieht ein Bump unverhofft mit.
Storybook ist die authoritative Doku. Properties, Events, Slots werden dort gepflegt - nicht hier. Diese Seite alterte sonst zwischen Major-Bumps.
Changelog im npm-Paket mitlesen, bevor du upgradest. Breaking-Change-Hinweise stehen dort.

Wenn du eine konkrete Komponente einbaust, schau im Storybook nach der aktuellen API. Wenn du dich grundsätzlich orientierst, ist diese Seite hier der richtige Einstieg.

Wer setzt das um

Zwei Wege, beide valide. Die Entscheidung hängt vom internen Setup, Tempo und Designanspruch ab.

	Variante A: Agentur integriert	Variante B: Spezialisierter Shop-Builder
Wer	Eure bestehende Web-Agentur	Spezialist:innen für Museums-Shops
Tempo	Tempo der Webcomponents-Roadmap	Euer Tempo, eigene Features im Shop-Code parallel
Visual	Eure Webseite + Komponenten-Embed	Eigenständiger Shop, eigene Domain
Wann sinnvoll	Agentur betreut die Webseite ohnehin, Shop-Bereich klein	Hohe Visual-Anforderungen, viele Eigen-Features

Variante	Visual	Aufwand	Wann passt das
Verlinkung in den go~mus-Shop	Bruch beim Klick	Stunden	Schnell live, einfache Ticketstruktur, Brand-Konsistenz nicht kritisch
iframe-Widget	Iframe-Grenze	Stunden	Einzelne Buchung pro Termin (z.B. Anmeldung), kein Order-Flow auf eurer Seite
Webcomponents (diese Seite)	nahtlos	Tage bis Wochen	Komplette Buchungsstrecke, hoher Brand-Anspruch

Verlinkung und Webcomponents schließen sich nicht aus. Hauptseiten als Webcomponents, Newsletter und Drittseiten verlinken in den Standard-Shop - eine verbreitete Kombination.

Die Direkte API als Ergänzung

Die direkte API ist nicht der vierte Weg neben Linking, Widget und Webcomponents - sie ist die Ergänzung, die jede dieser Varianten erst sauber macht.

Mit Webcomponents kombiniert:

Eigener Veranstaltungskalender mit Daten aus der API, Buchung passiert über die eingebettete Komponente daneben
Custom-Filter und Suchen über API, Ergebnisse werden an die Komponente übergeben
Dynamische Hinweise und Upsells im Shop-Gerüst, gespeist aus eigenen API-Calls

Mit Linking kombiniert:

Verfügbarkeiten und Preise per API auf der Übersichts- oder Detailseite anzeigen, Klick führt mit vorausgewähltem Datum in den Shop
CMS-Inhalte (Editorials, Bilder, Texte) plus API-Daten (Termine, Restplätze) auf einer Seite kombinieren
Deep-Links in den Shop sauber bauen, weil die API die nötigen IDs und Slugs liefert

Direkte API als Stand-Alone-Buchungsflow ist möglich, aber selten sinnvoll - Webcomponents und Widget übernehmen den Checkout produktreif. Die API zeigt ihre Stärke daneben, in der Übergangs- und Anzeige-Logik.