forked from cms/tibi-svelte-starter
apairon
0004bc98a1
Dieselbe Vorlage, dieselbe Auslieferung: `context.db.create("ssr", …)` ist
ein Insert, mehrere parallele Anfragen nach einer Invalidierung erzeugen
"duplicate key", und die Verlierer antworten mit 500 — ohne #appContainer,
also bleibt die Seite beim Besucher leer. Der Fehler wird geschluckt, die
Seite geht raus.
Der Block ist byte-gleich zu dem im event-website-tibi-2026-Projekt. Der
Starter ist die Vorlage; zwei Varianten desselben Fixes wären genau die
Drift, die hier nicht stattfinden darf.
Dazu der Einstiegspunkt, der denselben Fehlerklasse-Vorfall hat:
setupI18n().then(() => { hydrate(App, { target: appContainer }) })
Ein Fehler beim Laden der Locale-Datei oder ein werfendes hydrate()
lässt das ausgelieferte HTML stehen — ohne Signal, ohne Logeintrag, und für
einen Test nicht unterscheidbar von "noch nicht fertig". Jetzt steht der
Render in try/catch, der Fehler wird geloggt, und #appContainer bekommt
data-app-ready="error". Tests warten auf den Wert "true" und nennen bei
"error" die Ursache mit, statt still zu timeouten.
tibi-starter
Starter Kit für SPAs(s) ;) mit Svelte und TibiCMS inkl. SSR
Neues Projekt aufsetzen? → Skill
.agents/skills/tibi-project-setup/SKILL.md
Setup-Checkliste
[ ] Repository geklont und Remotes konfiguriert
[ ] __PROJECT_NAME__ in .env ersetzt (kebab-case)
[ ] __TIBI_NAMESPACE__ in .env ersetzt (snake_case)
[ ] __TIBI_NAMESPACE__ in api/config.yml und, falls Apache-Rewrite/Proxy genutzt wird, in frontend/.htaccess ersetzt
[ ] Keine verbleibenden __*__-Platzhalter (mit grep prüfen)
[ ] App.svelte hat <svelte:head> mit <title>
[ ] ADMIN_TOKEN in api/config.yml.env gesetzt
[ ] yarn install && yarn upgrade ausgeführt
[ ] make docker-up gestartet
[ ] Website erreichbar unter https://{PROJECT_NAME}.code.testversion.online/
[ ] yarn validate zeigt 0 Fehler und 0 Warnungen
[ ] yarn build und yarn build:server erfolgreich
Architektur
Via Svelte wird eine SPA (Single-Page-App) programmiert. Der Code wird einmal für den Browser aufbereitet und außerdem für den Server kompiliert und transpiliert. Der Server-Code wird in einem tibi-server SSR-Hook eingebunden und generiert fertiges HTML anhand der aktuellen Route — für SEO und optimierte Ladezeiten.
Die Navigation innerhalb der App löst nur API-Aufrufe aus, ohne jedes Mal SSR anzustoßen. Ein Cache in der ssr-Collection minimiert die SSR-Last.
SSR-Details:
<title>und<meta description>kommen über<svelte:head>ausApp.svelte→ SSR injiziert sie in den<!--HEAD-->-Platzhalter vonspa.html<html lang>wird vom SSR-Hook (api/hooks/ssr/get_read.js) anhand der URL-Sprache gesetzt- SSR-Bundle wird mit
yarn build:servererstellt und landet inapi/hooks/lib/app.server.js
Der normale Frontend-Build yarn build erzeugt sowohl das Frontend-Bundle als auch das Admin-Modul admin.mjs.