KATLA PER TYPESCRIPT
Consenso ai cookie in TypeScript: un’API, non un tag script.
Un client tipizzato per l’inventario dei cookie, le policy generate e la decisione del visitatore. Nessun framework, nessuna interfaccia e nessuna variabile globale non documentata da indovinare: categorie, stato del consenso e lingue delle policy sono tipi che il tuo editor conosce già.
@katla.app/sdk4 KB headlessQualsiasi bundler e framework
src/consent.tsNessun 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 restituisce la propria funzione di annullamentoGuida completa →
PERCHÉ I SITI TYPESCRIPT FATICANO CON IL CONSENSO
Un banner è un problema di interfaccia. Il consenso è un problema di dati.
IL PROBLEMALa piattaforma fornisce un widget, e tutto ciò che c’è dietro (quali cookie esistono, cosa fanno, cosa ha scelto il visitatore) resta chiuso nell’iframe di qualcun altro.
CON KATLAL’SDK sono quei dati. getCookies() restituisce l’inventario, getPolicy() restituisce il documento generato in markdown, onConsentChange() restituisce la decisione. L’interfaccia è la parte facoltativa.
IL PROBLEMALa variabile globale del consenso non è documentata ed è diversa su ogni piattaforma, quindi ogni integrazione è un tentativo che fallisce in silenzio in produzione.
CON KATLAwindow.KatlaConsent è tipizzato come KatlaConsentAPI, e ConsentState, CookieCategory, CookieData e le tredici lingue delle policy sono esportati insieme. Un nome di categoria sbagliato è un errore di compilazione, non un ticket di assistenza.
IL PROBLEMABloccare i tracker significa verificare ogni script a mano, e la verifica è già superata al deploy successivo.
CON KATLAinjectGuard() ridefinisce document.cookie e trattiene tutto ciò la cui categoria non è stata consentita. La scansione mantiene aggiornato l’inventario, quindi non è un elenco che devi curare tu.
CONFIGURAZIONE
Installa, crea un client, subordina i tag.
- Installanpm install @katla.app/sdk. Circa 4 KB trasferiti, tipi inclusi.
- Crea un clientcreateKatlaClient({ siteId }) è tutta la configurazione. Passa anche baseUrl solo se servi la CDN dal tuo dominio.
- Inserisci il blocco dei cookieawait client.injectGuard(). Da quel momento un cookie la cui categoria non è stata consentita non viene mai scritto.
- Subordina i tagIscriviti con onConsentChange() e carica gli script di analytics o pubblicitari quando la loro categoria diventa true.
PENSATO PER TYPESCRIPT
Cosa ottieni con una sola dipendenza.
L’inventario, tipizzatogetCookies() restituisce ogni cookie e pixel scansionato, raggruppato per categoria, con fornitore, titolare del trattamento e descrizione, in una qualsiasi di tredici lingue.
Il blocco dei cookieinjectGuard() ridefinisce document.cookie, così un cookie senza consenso viene rifiutato nel momento in cui viene scritto, invece di essere cancellato qualche tempo dopo.
Policy come datigetPolicy({ format }) restituisce la cookie policy, l’informativa sulla privacy o la tabella dei cookie in markdown, con la data di generazione. Renderizzala come il tuo stack renderizza il markdown.
Consent Mode v2 e GPCsetupGoogleConsentMode() invia tutti e quattro i segnali Google, negati per impostazione predefinita e aggiornati alla decisione. isGPCEnabled() legge il Global Privacy Control del browser.
Build senza fetch a runtimekatla pull scrive l’inventario, le policy e il blocco dei cookie in .katla/, così una build può distribuirli come asset statici e non scaricare nulla a ogni visualizzazione di pagina.
Senza frameworkIl client è un semplice oggetto sopra fetch e gli eventi di window. I punti di ingresso React e Next.js si appoggiano su di esso; Vue, Svelte e JavaScript vanilla lo chiamano direttamente.
CORE WEB VITALS
I cookie si sbriciolano. La tua SEO no.
Headless significa proprio questo: nessuna interfaccia, nessun foglio di stile, nessun webfont e nessuna seconda richiesta per scaricarli. 4 KB trasferiti per il blocco dei cookie e l’API del consenso, e integrato nella build con katla pull non è nemmeno una richiesta.
Come funziona la modalità headless →4 kBDati trasferitiBlocco dei cookie e API di consenso, brotli
0 msLCP aggiuntoRispetto alla stessa pagina senza
0Spostamento del layoutIl banner non riserva spazio nel flusso
2RichiestaUn solo script, in cache all’edge
Nostre misurazioni, effettuate il : ecco come le abbiamo fatte.
Le domande dei team TypeScript
- Devo costruire il mio banner?
- Solo se vuoi. Il punto di ingresso React include CookieBanner e CookieCatalog senza stili, e il widget ospitato di Katla è un solo tag script. L’SDK in sé, di proposito, non renderizza nulla.
- Funziona fuori dal browser?
- getCookies() e getPolicy() sono semplici fetch e girano ovunque giri fetch, compresi Node e i runtime edge. injectGuard() e onConsentChange() richiedono un DOM, perché la decisione in sé si prende nel browser.
- E Vue, Svelte o nessun framework?
- Il client non dipende da alcun framework, quindi funziona con tutti. Solo i punti di ingresso React e Next.js importano React, e nulla ti obbliga a importarli.
- Da dove arrivano i dati dei cookie?
- Dalla scansione del tuo sito, serviti dalla CDN e messi in cache sull’edge: le stesse risposte che legge il widget. La cache viene svuotata quando una scansione o una riclassificazione cambia qualcosa, quindi non è mai una copia da tenere sincronizzata.
Una dipendenza, e il consenso è tipizzato.
Il piano gratuito scansiona il tuo sito TypeScript e genera un’informativa sui cookie, senza carta di credito.