KATLA FÜR TYPESCRIPT
Cookie-Einwilligung für TypeScript: eine API, kein Script-Tag.
Ein typisierter Client für das Cookie-Inventar, die generierten Richtlinien und die Entscheidung des Besuchers. Kein Framework, keine Oberfläche und kein undokumentiertes Global zum Raten: Kategorien, Einwilligungsstatus und Richtlinien-Locales sind Typen, die Ihr Editor schon kennt.
@katla.app/sdk4 KB headlessJeder Bundler, jedes Framework
src/consent.tsOhne Framework
import { createKatlaClient, type ConsentState } from '@katla.app/sdk'
const katla = createKatlaClient({ siteId: 'your-site-id' })
// Refuse non-consented cookies before anything can set one
await katla.injectGuard()
// The scanned inventory, grouped and typed by category
const { cookies } = await katla.getCookies()
cookies.marketing.forEach((c) => console.log(c.name, c.platform))
// Every decision, for as long as you listen
const off = katla.onConsentChange((consent: ConsentState) => {
if (consent.analytics) loadAnalytics()
})onConsentChange gibt seine eigene Abmeldefunktion zurückVollständige Anleitung →
WARUM TYPESCRIPT-WEBSITES MIT DER EINWILLIGUNG KÄMPFEN
Ein Banner ist ein UI-Problem. Einwilligung ist ein Datenproblem.
DAS PROBLEMDie Plattform liefert ein Widget, und alles dahinter (welche Cookies es gibt, was sie tun, was der Besucher gewählt hat) steckt im iframe von jemand anderem fest.
MIT KATLADas SDK sind genau diese Daten. getCookies() liefert das Inventar, getPolicy() das generierte Dokument als Markdown, onConsentChange() die Entscheidung. Die Oberfläche ist der optionale Teil.
DAS PROBLEMDas Consent-Global ist undokumentiert und auf jeder Plattform anders, also ist jede Integration ein Ratespiel, das in Produktion leise scheitert.
MIT KATLAwindow.KatlaConsent ist als KatlaConsentAPI typisiert, und ConsentState, CookieCategory, CookieData und die dreizehn Richtlinien-Locales werden daneben exportiert. Ein falscher Kategoriename ist ein Compile-Fehler, kein Support-Ticket.
DAS PROBLEMTracker zu blockieren heißt, jedes Skript von Hand zu prüfen, und die Prüfung ist beim nächsten Deploy schon veraltet.
MIT KATLAinjectGuard() definiert document.cookie neu und hält alles zurück, dessen Kategorie nicht erlaubt ist. Der Scan hält das Inventar aktuell, die Liste müssen Sie also nicht selbst pflegen.
EINRICHTUNG
Installieren, Client erstellen, Tags absichern.
- Installierennpm install @katla.app/sdk. Es werden etwa 4 KB übertragen, Typen inklusive.
- Client erstellencreateKatlaClient({ siteId }) ist das ganze Setup. Übergeben Sie baseUrl nur dann zusätzlich, wenn Sie das CDN von Ihrer eigenen Domain ausliefern.
- Guard einbindenawait client.injectGuard(). Ab diesem Moment wird ein Cookie, dessen Kategorie nicht erlaubt ist, nie geschrieben.
- Tags absichernAbonnieren Sie onConsentChange() und laden Sie Analytics- oder Werbeskripte, sobald ihre Kategorie auf true wechselt.
GEBAUT FÜR TYPESCRIPT
Was Sie für eine einzige Abhängigkeit bekommen.
Das Inventar, typisiertgetCookies() liefert jedes gescannte Cookie und Pixel nach Kategorie gruppiert, mit Anbieter, Verantwortlichem und Beschreibung, in jeder von dreizehn Sprachen.
Der Cookie-GuardinjectGuard() definiert document.cookie neu, sodass ein Cookie ohne Einwilligung schon beim Schreiben abgewiesen wird, statt irgendwann nach dem Setzen gelöscht zu werden.
Richtlinien als DatengetPolicy({ format }) liefert die Cookie-Richtlinie, die Datenschutzerklärung oder die Cookie-Tabelle als Markdown, mit dem Datum der Erstellung. Rendern Sie es so, wie Ihr Stack Markdown eben rendert.
Consent Mode v2 und GPCsetupGoogleConsentMode() sendet alle vier Google-Signale, standardmäßig verweigert und mit der Entscheidung aktualisiert. isGPCEnabled() liest die Global Privacy Control des Browsers.
Builds ohne Laufzeit-Fetchkatla pull schreibt Inventar, Richtlinien und Guard nach .katla/, sodass ein Build sie als statische Assets ausliefern kann und beim Seitenaufruf nichts abruft.
Ohne FrameworkDer Client ist ein einfaches Objekt über fetch und Window-Events. Die Einstiegspunkte für React und Next.js bauen darauf auf, Vue, Svelte und Vanilla JS rufen ihn direkt auf.
CORE WEB VITALS
So krümelt der Keks. Ihr SEO bitte nicht.
Headless heißt, was es sagt: keine Oberfläche, kein Stylesheet, kein Webfont und keine zweite Anfrage, um irgendetwas davon zu laden. 4 KB Übertragung für Guard und Consent-API, und per katla pull in den Build gezogen ist es gar keine Anfrage.
So funktioniert der Headless-Modus →4 kBÜbertragenGuard und Consent-API, Brotli
0 msZusätzlicher LCPGegenüber derselben Seite ohne Katla
0Layout-ShiftDas Banner reserviert keinen Platz im Seitenfluss
2RequestEin Skript, am Edge gecacht
Unsere eigenen Messungen vom : so wurden sie erhoben.
Was TypeScript-Teams fragen
- Muss ich mein eigenes Banner bauen?
- Nur wenn Sie wollen. Der React-Einstiegspunkt liefert CookieBanner und CookieCatalog ungestylt mit, und das gehostete Widget von Katla ist ein einziges Script-Tag. Das SDK selbst rendert bewusst nichts.
- Läuft es auch außerhalb des Browsers?
- getCookies() und getPolicy() sind einfache Fetches und laufen überall, wo fetch läuft, auch in Node und Edge-Runtimes. injectGuard() und onConsentChange() brauchen ein DOM, weil die Entscheidung selbst im Browser fällt.
- Was ist mit Vue, Svelte oder ganz ohne Framework?
- Der Client hat keine Framework-Abhängigkeit und funktioniert daher mit allen. Nur die Einstiegspunkte für React und Next.js importieren React, und nichts zwingt Sie, diese zu importieren.
- Woher kommen die Cookie-Daten?
- Aus dem Scan Ihrer eigenen Website, ausgeliefert vom CDN und am Edge gecacht: dieselben Antworten, die auch das Widget liest. Der Cache wird geleert, wenn ein Scan oder eine Neuklassifizierung etwas ändert, es ist also nie eine Kopie, die Sie synchron halten müssen.
Eine Abhängigkeit, und die Einwilligung ist typisiert.
Der kostenlose Tarif scannt Ihre TypeScript-Website und erstellt eine Cookie-Richtlinie, ohne Karte.