KATLA FÖR TYPESCRIPT
Cookiesamtycke för TypeScript: ett API, inte en script-tagg.
En typad klient för cookieförteckningen, de genererade policyerna och besökarens beslut. Inget ramverk, inget gränssnitt och ingen odokumenterad global att gissa sig till: kategorierna, samtyckestillståndet och policyspråken är typer som din editor redan känner till.
@katla.app/sdk4 kB headlessValfri bundler, valfritt ramverk
src/consent.tsInget ramverk
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 returnerar själv funktionen som avslutar prenumerationenHela guiden →
DÄRFÖR HAR TYPESCRIPT-WEBBPLATSER SVÅRT MED SAMTYCKE
En banner är ett UI-problem. Samtycke är ett dataproblem.
PROBLEMETPlattformen levererar en widget, och allt bakom den (vilka cookies som finns, vad de gör, vad besökaren valde) är inlåst i någon annans iframe.
MED KATLASDK:t är den datan. getCookies() returnerar förteckningen, getPolicy() returnerar det genererade dokumentet som markdown, onConsentChange() returnerar beslutet. Gränssnittet är den valfria delen.
PROBLEMETDet globala samtyckesobjektet är odokumenterat och olika på varje plattform, så varje integration är en gissning som tyst går sönder i produktion.
MED KATLAwindow.KatlaConsent är typat som KatlaConsentAPI, och ConsentState, CookieCategory, CookieData och de tretton policyspråken exporteras bredvid. Ett felaktigt kategorinamn blir ett kompileringsfel, inte ett supportärende.
PROBLEMETAtt blockera spårare innebär att granska varje skript för hand, och granskningen är inaktuell redan vid nästa deploy.
MED KATLAinjectGuard() definierar om document.cookie och håller inne allt vars kategori inte har tillåtits. Skanningen håller förteckningen aktuell, så det är inte en lista du behöver underhålla.
INSTALLATION
Installera, skapa en klient, villkora dina taggar.
- Installeranpm install @katla.app/sdk. Cirka 4 kB överförs, typer inkluderade.
- Skapa en klientcreateKatlaClient({ siteId }) är hela konfigurationen. Skicka med baseUrl bara om du serverar CDN:et från din egen domän.
- Injicera spärrenawait client.injectGuard(). Från och med då skrivs aldrig en cookie vars kategori inte har tillåtits.
- Villkora dina taggarPrenumerera med onConsentChange() och ladda analys- eller annonsskript när deras kategori blir true.
BYGGT FÖR TYPESCRIPT
Det här får du för ett enda beroende.
Förteckningen, typadgetCookies() returnerar varje skannad cookie och pixel grupperad per kategori, med leverantör, personuppgiftsansvarig och beskrivning, på vilket som helst av tretton språk.
CookiespärreninjectGuard() definierar om document.cookie, så en cookie utan samtycke nekas när den skrivs i stället för att raderas en stund efter att den har satts.
Policyer som datagetPolicy({ format }) returnerar cookiepolicyn, integritetspolicyn eller cookietabellen som markdown, med datumet då den genererades. Rendera den som din stack renderar markdown.
Consent Mode v2 och GPCsetupGoogleConsentMode() skickar alla fyra Google-signaler, nekade som standard och uppdaterade när beslutet fattas. isGPCEnabled() läser webbläsarens Global Privacy Control.
Byggen utan hämtning vid körningkatla pull skriver förteckningen, policyerna och spärren till .katla/, så ett bygge kan leverera dem som statiska filer och inte hämta något vid sidvisning.
Fritt från ramverkKlienten är ett vanligt objekt ovanpå fetch och window-händelser. Ingångspunkterna för React och Next.js bygger på den; Vue, Svelte och vanilla anropar den direkt.
CORE WEB VITALS
Samtycket laddar. Din SEO märker inget.
Headless betyder vad det säger: inget gränssnitt, ingen stilmall, inget webbtypsnitt och ingen andra förfrågan för att hämta något av dem. 4 kB över nätverket för spärren och samtyckes-API:t, och hämtat in i bygget med katla pull blir det ingen förfrågan alls.
Så fungerar headless-läget →4 kBÖverförtSpärr och samtyckes-API, brotli
0 msTillagd LCPJämfört med samma sida utan den
0LayoutförskjutningBannern reserverar inget utrymme i flödet
2AnropEtt skript, cachat vid kanten
Våra egna mätningar, gjorda : så gjordes de.
Frågor som TypeScript-team ställer
- Måste jag bygga min egen banner?
- Bara om du vill. Ingångspunkten för React levererar CookieBanner och CookieCatalog ostylade, och Katlas hostade widget är en enda script-tagg. SDK:t självt renderar medvetet ingenting.
- Körs det utanför webbläsaren?
- getCookies() och getPolicy() är vanliga fetch-anrop och körs överallt där fetch finns, även i Node och edge-miljöer. injectGuard() och onConsentChange() behöver en DOM, eftersom själva beslutet fattas i webbläsaren.
- Hur blir det med Vue, Svelte eller inget ramverk alls?
- Klienten är inte beroende av något ramverk, så den fungerar i alla. Bara ingångspunkterna för React och Next.js importerar React, och ingenting tvingar dig att importera dem.
- Var kommer cookiedatan ifrån?
- Från skanningen av din egen webbplats, levererad från CDN:et och cachad i edge-noderna, samma svar som widgeten läser. Cachen töms när en skanning eller en omklassificering ändrar något, så det är aldrig en kopia du behöver hålla synkad.
Ett beroende, och samtycket är typat.
Gratisplanen skannar din TypeScript-webbplats och genererar en cookiepolicy, utan kort.