KATLA VOOR TYPESCRIPT
Cookietoestemming in TypeScript: een API, geen scripttag.
Eén getypeerde client voor de cookie-inventaris, het gegenereerde beleid en de keuze van de bezoeker. Geen framework, geen interface en geen ongedocumenteerde global om naar te raden: de categorieën, de toestemmingsstatus en de beleidslocales zijn types die je editor al kent.
@katla.app/sdk4 KB headlessElke bundler, elk framework
src/consent.tsGeen 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 geeft zelf zijn unsubscribe terugVolledige gids →
WAAROM TOESTEMMING OP TYPESCRIPT LASTIG IS
Een banner is een UI-probleem. Toestemming is een dataprobleem.
HET PROBLEEMHet platform levert een widget, en alles daarachter (welke cookies er zijn, wat ze doen, wat de bezoeker koos) zit opgesloten in het iframe van iemand anders.
MET KATLADe SDK is die data. getCookies() geeft de inventaris, getPolicy() geeft het gegenereerde document als markdown, onConsentChange() geeft de beslissing. De interface is het optionele deel.
HET PROBLEEMDe consent-global is ongedocumenteerd en op elk platform anders, dus elke integratie is een gok die in productie stilletjes misgaat.
MET KATLAwindow.KatlaConsent is getypeerd als KatlaConsentAPI, en ConsentState, CookieCategory, CookieData en de dertien beleidslocales worden ernaast geëxporteerd. Een verkeerde categorienaam is een compileerfout, geen supportticket.
HET PROBLEEMTrackers blokkeren betekent elk script met de hand doorlichten, en die audit is bij de volgende deploy alweer verouderd.
MET KATLAinjectGuard() herdefinieert document.cookie en houdt alles tegen waarvan de categorie niet is toegestaan. De scan houdt de inventaris actueel, dus die lijst hoef jij niet bij te houden.
INSTALLATIE
Installeren, client aanmaken, tags afschermen.
- Installerennpm install @katla.app/sdk. Ongeveer 4 KB over het netwerk, types inbegrepen.
- Client aanmakencreateKatlaClient({ siteId }) is de hele setup. Geef alleen ook baseUrl mee als je het CDN vanaf je eigen domein serveert.
- Cookieblokker injecterenawait client.injectGuard(). Vanaf dat moment wordt een cookie waarvan de categorie niet is toegestaan nooit geschreven.
- Tags afschermenLuister met onConsentChange() naar de keuze en laad analytics- of advertentiescripts zodra hun categorie op true springt.
GEBOUWD VOOR TYPESCRIPT
Wat je krijgt voor één dependency.
De inventaris, getypeerdgetCookies() geeft elke gescande cookie en pixel terug, gegroepeerd per categorie, met aanbieder, verwerkingsverantwoordelijke en beschrijving, in elk van dertien talen.
De cookieblokkerinjectGuard() herdefinieert document.cookie, zodat een cookie zonder toestemming al bij het schrijven wordt geweigerd, in plaats van ergens na het zetten te worden verwijderd.
Beleid als datagetPolicy({ format }) geeft het cookiebeleid, het privacybeleid of de cookietabel terug als markdown, met de datum waarop het is gegenereerd. Render het zoals je stack markdown rendert.
Consent Mode v2 en GPCsetupGoogleConsentMode() stuurt alle vier de Google-signalen, standaard geweigerd en bijgewerkt zodra de keuze valt. isGPCEnabled() leest de Global Privacy Control van de browser.
Builds zonder fetch tijdens runtimekatla pull schrijft de inventaris, het beleid en de cookieblokker naar .katla/, zodat een build ze als statische assets kan meeleveren en bij een paginaweergave niets ophaalt.
FrameworkvrijDe client is een gewoon object bovenop fetch en window-events. De entrypoints voor React en Next.js bouwen erop voort; Vue, Svelte en vanilla JavaScript roepen hem direct aan.
CORE WEB VITALS
Zo brokkelt het koekje af. Jouw SEO niet.
Headless betekent wat het zegt: geen interface, geen stylesheet, geen webfont en geen tweede verzoek om die op te halen. 4 KB over het netwerk voor de cookieblokker en de consent-API, en met katla pull in de build opgenomen is het helemaal geen verzoek.
Zo werkt de headless-modus →4 kBOver het netwerkCookieblokker en toestemmings-API, brotli
0 msExtra LCPTegenover dezelfde pagina zonder Katla
0LayoutverschuivingDe banner reserveert geen ruimte in de paginaflow
2RequestEén script, gecachet aan de edge
Onze eigen metingen, gedaan op (zo hebben we gemeten).
Vragen die TypeScript-teams stellen
- Moet ik mijn eigen banner bouwen?
- Alleen als je dat wilt. Het React-entrypoint levert CookieBanner en CookieCatalog zonder styling, en de gehoste widget van Katla is één scripttag. De SDK zelf rendert bewust niets.
- Draait het ook buiten de browser?
- getCookies() en getPolicy() zijn gewone fetches en draaien overal waar fetch draait, ook in Node en edge-runtimes. injectGuard() en onConsentChange() hebben een DOM nodig, omdat de beslissing zelf in de browser valt.
- En Vue, Svelte of helemaal geen framework?
- De client hangt van geen enkel framework af, dus hij werkt overal. Alleen de entrypoints voor React en Next.js importeren React, en niets verplicht je die te gebruiken.
- Waar komen de cookiegegevens vandaan?
- Uit de scan van je eigen site, geserveerd vanaf het CDN en gecachet aan de edge: dezelfde responses die de widget leest. Ze worden ververst zodra een scan of een herclassificatie iets verandert, dus het is nooit een kopie die je zelf synchroon moet houden.
Eén dependency, en toestemming is getypeerd.
Het gratis abonnement scant je TypeScript-site en genereert een cookiebeleid, zonder creditcard.