KATLA PARA TYPESCRIPT
Consentimiento de cookies en TypeScript: una API, no una etiqueta script.
Un cliente tipado para el inventario de cookies, las políticas generadas y la decisión del visitante. Sin framework, sin interfaz y sin ningún global sin documentar que haya que adivinar: las categorías, el estado del consentimiento y los locales de las políticas son tipos que tu editor ya conoce.
@katla.app/sdk4 KB en headlessCualquier bundler y framework
src/consent.tsSin 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 devuelve su propia función para cancelar la suscripciónGuía completa →
POR QUÉ A LOS SITIOS DE TYPESCRIPT LES CUESTA EL CONSENTIMIENTO
Un banner es un problema de interfaz. El consentimiento es un problema de datos.
EL PROBLEMALa plataforma te da un widget, y todo lo que hay detrás (qué cookies existen, qué hacen, qué eligió el visitante) está encerrado en el iframe de otro.
CON KATLAEl SDK son esos datos. getCookies() devuelve el inventario, getPolicy() devuelve el documento generado en markdown, onConsentChange() devuelve la decisión. La interfaz es la parte opcional.
EL PROBLEMAEl global de consentimiento no está documentado y cambia en cada plataforma, así que cada integración es una suposición que falla en silencio en producción.
CON KATLAwindow.KatlaConsent está tipado como KatlaConsentAPI, y ConsentState, CookieCategory, CookieData y los trece locales de las políticas se exportan junto a él. Un nombre de categoría equivocado es un error de compilación, no un ticket de soporte.
EL PROBLEMABloquear rastreadores significa auditar cada script a mano, y la auditoría se queda desfasada en el siguiente deploy.
CON KATLAinjectGuard() redefine document.cookie y retiene todo lo que pertenezca a una categoría no concedida. El escaneo mantiene el inventario al día, así que la lista no la mantienes tú.
CONFIGURACIÓN
Instala, crea un cliente, condiciona tus etiquetas.
- Instalarnpm install @katla.app/sdk. Unos 4 KB transferidos, tipos incluidos.
- Crear un clientecreateKatlaClient({ siteId }) es toda la configuración. Pasa también baseUrl solo si sirves la CDN desde tu propio dominio.
- Inyectar el bloqueadorawait client.injectGuard(). A partir de ahí, una cookie cuya categoría no se ha concedido nunca llega a escribirse.
- Condicionar las etiquetasSuscríbete con onConsentChange() y carga los scripts de analítica o de publicidad cuando su categoría pase a true.
HECHO PARA TYPESCRIPT
Lo que obtienes con una sola dependencia.
El inventario, tipadogetCookies() devuelve cada cookie y cada píxel escaneados, agrupados por categoría, con su proveedor, su responsable del tratamiento y su descripción, en cualquiera de trece idiomas.
El bloqueador de cookiesinjectGuard() redefine document.cookie, así que una cookie sin consentimiento se rechaza en el momento de escribirse en lugar de borrarse un rato después.
Políticas como datosgetPolicy({ format }) devuelve la política de cookies, la política de privacidad o la tabla de cookies en markdown, con la fecha en que se generó. Renderízala como tu stack renderice el markdown.
Consent Mode v2 y GPCsetupGoogleConsentMode() envía las cuatro señales de Google, denegadas por defecto y actualizadas con la decisión. isGPCEnabled() lee la señal Global Privacy Control del navegador.
Builds sin peticiones en tiempo de ejecuciónkatla pull escribe el inventario, las políticas y el bloqueador en .katla/, así que un build puede servirlos como archivos estáticos y no pedir nada al mostrar la página.
Sin frameworkEl cliente es un objeto simple sobre fetch y eventos de window. Los puntos de entrada de React y Next.js se apoyan en él; Vue, Svelte y vanilla lo llaman directamente.
CORE WEB VITALS
Las galletas se desmoronan. Tu SEO, no.
Headless significa exactamente eso: sin interfaz, sin hoja de estilos, sin webfont y sin una segunda petición para descargar nada de eso. 4 KB transferidos para el bloqueador y la API de consentimiento, y si lo integras en el build con katla pull, ni siquiera es una petición.
Cómo funciona el modo headless →4 kBTransferidoBloqueador y API de consentimiento, brotli
0 msLCP añadidoFrente a la misma página sin él
0Desplazamiento de diseñoEl banner no reserva espacio en el flujo
2PeticiónUn script, en caché en el edge
Mediciones propias, realizadas el : así se hicieron.
Lo que preguntan los equipos de TypeScript
- ¿Tengo que construir mi propio banner?
- Solo si quieres. El punto de entrada de React incluye CookieBanner y CookieCatalog sin estilos, y el widget alojado de Katla es una sola etiqueta script. El SDK en sí no renderiza nada, a propósito.
- ¿Funciona fuera del navegador?
- getCookies() y getPolicy() son simples llamadas a fetch y funcionan en cualquier entorno con fetch, incluidos Node y los runtimes edge. injectGuard() y onConsentChange() necesitan un DOM, porque la decisión en sí se toma en el navegador.
- ¿Y con Vue, Svelte o sin ningún framework?
- El cliente no depende de ningún framework, así que funciona con todos. Solo los puntos de entrada de React y Next.js importan React, y nada te obliga a importarlos.
- ¿De dónde salen los datos de cookies?
- Del escaneo de tu propio sitio, servidos desde la CDN y en caché en el edge: las mismas respuestas que lee el widget. Se purgan cuando un escaneo o una reclasificación cambia algo, así que nunca es una copia que tengas que mantener sincronizada.
Una dependencia, y el consentimiento queda tipado.
El plan gratuito escanea tu sitio de TypeScript y genera una política de cookies, sin tarjeta.