@c15t/astro 3.0.0-alpha.1 → 3.0.0-alpha.2

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,399 @@
1
+ ---
2
+ title: Cloudflare Zaraz
3
+ description: Synchronize c15t permissions with Zaraz purposes while Cloudflare
4
+ manages your tools.
5
+ group: integrations
6
+ ---
7
+
8
+ ## Configure Zaraz before registering the bridge
9
+
10
+ This helper connects c15t to an existing Zaraz installation. It does not insert a
11
+ script, configure Cloudflare tools, or turn a standalone SDK into a server-side
12
+ integration. Configure each tool in Zaraz and remove its previous standalone
13
+ loader, including any duplicate `@c15t/scripts` helper.
14
+
15
+ In the Zaraz dashboard:
16
+
17
+ 1. Enable Consent Management and create purposes for the categories you use.
18
+ 2. Assign a purpose to every tool requiring permission. Zaraz tools without a
19
+ purpose bypass consent checks.
20
+ 3. Disable automatic display of the Zaraz consent modal. c15t owns the UI.
21
+ 4. Disable **Automatic Pageview Tracking**. Disable automatic SPA pageviews too
22
+ if your application will emit them itself.
23
+ 5. Copy the purpose IDs into the mapping below. Every active purpose returned by `zaraz.consent.getAll()` and omitted
24
+ from the mapping is denied by this bridge. Register one bridge per application.
25
+
26
+ Zaraz keeps a separate consent cookie. Its automatic pageview can run before
27
+ c15t resolves the current permissions, using a grant from a previous visit.
28
+ Disabling that pageview and emitting it from `onReady` prevents this particular
29
+ startup race. Do not send other events before synchronization, and audit any
30
+ custom triggers that run independently. DOM-ready, timer or click triggers can
31
+ run with stale permissions before the bridge mounts. The bridge cannot undo
32
+ requests sent before it starts.
33
+
34
+ Cloudflare documents [purpose assignment](https://developers.cloudflare.com/zaraz/consent-management/)
35
+ and [automatic pageview settings](https://developers.cloudflare.com/zaraz/reference/settings/).
36
+
37
+ ## Register the consent bridge
38
+
39
+ | Package manager | Command |
40
+ | :-------------- | :-------------------------- |
41
+ | npm | `npm install @c15t/scripts` |
42
+ | pnpm | `pnpm add @c15t/scripts` |
43
+ | yarn | `yarn add @c15t/scripts` |
44
+ | bun | `bun add @c15t/scripts` |
45
+
46
+ ```ts title="src/consent-scripts.ts"
47
+ import { cloudflareZaraz } from '@c15t/scripts/cloudflare-zaraz';
48
+
49
+ // Zaraz provides this global after its loader runs.
50
+ declare const zaraz: { track: (event: string) => void };
51
+
52
+ export const scripts = [
53
+ cloudflareZaraz({
54
+ purposes: {
55
+ measurement: ['your-measurement-purpose-id'],
56
+ marketing: ['your-marketing-purpose-id'],
57
+ },
58
+ onReady: () => {
59
+ zaraz.track('Pageview');
60
+ },
61
+ }),
62
+ ];
63
+ ```
64
+
65
+ Use actual IDs from your dashboard, not the purpose names. A category may map to
66
+ several purposes, but a purpose cannot appear more than once. Empty mappings,
67
+ blank IDs and duplicate IDs throw during construction. Zaraz only returns purposes attached to enabled tools from `getAll()`. IDs absent
68
+ from that result cannot receive a grant; compare the mapping with
69
+ `zaraz.consent.getAll()` when troubleshooting.
70
+
71
+ Include the mapped categories in your c15t policy. The bridge reads effective
72
+ permissions, including policy restrictions, rather than treating every allowed
73
+ category as a recorded visitor choice.
74
+
75
+ For the shared registration examples below, keep Zaraz's own loader and its
76
+ configured dashboard tools. Remove duplicate standalone vendor loaders only.
77
+ For this integration, c15t owns permission synchronization and Zaraz owns tool
78
+ loading.
79
+
80
+ ## Register the scripts
81
+
82
+ Complete your [framework quickstart](https://c15t.com/docs/frameworks) first. Keep its Inth
83
+ endpoint, policy, styles and consent UI. Remove the vendor's original script,
84
+ SDK initializer or tag-manager entry so c15t owns loading once.
85
+
86
+ The `scripts` export in `src/consent-scripts.ts` is a configuration, not an
87
+ initializer. Add it to your existing consent owner using the registration point
88
+ below. These are partial edits to that owner, not additional providers.
89
+
90
+ **Next.js**
91
+
92
+ Import the configuration into the client boundary from your router guide:
93
+
94
+ ```ts
95
+ import { ConsentRoot } from 'c15t/next';
96
+ import { scripts } from './consent-scripts';
97
+ ```
98
+
99
+ Keep the server-resolved `state` and shared `consentConfig` from your
100
+ router guide. Its manifest, init and save URLs stay in effect. Add
101
+ `scripts` as a top-level prop on the existing root:
102
+
103
+ ```tsx
104
+ <ConsentRoot state={state} config={consentConfig} scripts={scripts}>
105
+ {children}
106
+ </ConsentRoot>
107
+ ```
108
+
109
+ For a Pages Router or static-export setup using `ConsentProvider`, add
110
+ `scripts` to its existing `options` instead. Keep the router-specific setup
111
+ from [Next.js script loading](https://c15t.com/docs/frameworks/next/script-loader).
112
+
113
+ **TanStack Start**
114
+
115
+ In your existing root route component, import the scripts alongside
116
+ `ConsentRoot`. Keep the server loader from the [TanStack Start quickstart](https://c15t.com/docs/frameworks/tanstack-start/quickstart).
117
+
118
+ ```tsx
119
+ import { Outlet } from '@tanstack/react-router';
120
+ import { ConsentRoot } from 'c15t/tanstack-start';
121
+ import { scripts } from '../consent-scripts';
122
+
123
+ function Root() {
124
+ const state = Route.useLoaderData();
125
+ return (
126
+ <ConsentRoot state={state} backendURL={backendURL} initRoute={false} scripts={scripts}>
127
+ <Outlet />
128
+ {/* Keep your consent banner, dialog and preferences link here. */}
129
+ </ConsentRoot>
130
+ );
131
+ }
132
+ ```
133
+
134
+ This edits the existing route. `Route` and `backendURL` come from its setup;
135
+ keep the document shell and head components if they are part of your root.
136
+ `initRoute={false}` keeps the quickstart's direct-backend initialization.
137
+ If your app mounts a consent server route, retain its existing `initRoute`
138
+ instead. Do not return script callbacks from a server function or route loader.
139
+
140
+ **React**
141
+
142
+ Import the scripts into your existing provider component:
143
+
144
+ ```ts
145
+ import { ConsentProvider } from 'c15t/react';
146
+ import { scripts } from './consent-scripts';
147
+ ```
148
+
149
+ Keep the existing options and add `scripts`:
150
+
151
+ ```tsx
152
+ <ConsentProvider options={{ ...consentOptions, scripts }}>
153
+ {children}
154
+ </ConsentProvider>
155
+ ```
156
+
157
+ Here `consentOptions` is your existing configuration, including
158
+ `mode: hosted({ url: backendURL })`. Keep the banner, dialog and preferences
159
+ link inside the provider. See [React script loading](https://c15t.com/docs/frameworks/react/script-loader).
160
+
161
+ **Nuxt**
162
+
163
+ Attach one loader from the root `app.vue`, after the Nuxt module has
164
+ started its browser runtime. This keeps vendor callbacks in application code rather
165
+ than serialized `nuxt.config.ts` runtime configuration.
166
+
167
+ ```vue title="app/app.vue"
168
+ <script setup lang="ts">
169
+ import { onUnmounted } from 'vue';
170
+ import { createScriptLoader } from 'c15t/modules/script-loader';
171
+ import { scripts } from '../src/consent-scripts';
172
+
173
+ const nuxtApp = useNuxtApp();
174
+ const kernel = useConsentKernel();
175
+ let loader: ReturnType<typeof createScriptLoader> | undefined;
176
+
177
+ const removeMountedHook = nuxtApp.hook('app:mounted', () => {
178
+ loader = createScriptLoader({ kernel, scripts });
179
+ });
180
+ onUnmounted(() => {
181
+ removeMountedHook();
182
+ loader?.dispose();
183
+ });
184
+ </script>
185
+
186
+ <template>
187
+ <ConsentRoot />
188
+ <NuxtPage />
189
+ </template>
190
+ ```
191
+
192
+ Merge the setup code into your root and retain its footer and preferences
193
+ link. `useConsentKernel` is auto-imported by the c15t Nuxt module. Adjust the
194
+ relative script import if your `app.vue` is at the project root. This loader
195
+ waits until the module has applied browser persistence and privacy signals,
196
+ then reads the current snapshot and observes future changes. Do not also register these scripts
197
+ in another loader. See the [Nuxt quickstart](https://c15t.com/docs/frameworks/nuxt/quickstart).
198
+
199
+ **Vue**
200
+
201
+ Use the kernel already provided by the Vue plugin. Merge this setup into
202
+ `App.vue`, whose lifetime covers the application:
203
+
204
+ ```vue title="src/App.vue"
205
+ <script setup lang="ts">
206
+ import { onMounted, onUnmounted } from 'vue';
207
+ import { createScriptLoader } from 'c15t/modules/script-loader';
208
+ import { useConsentKernel } from 'c15t/vue/vue-plugin';
209
+ import ConsentRoot from 'c15t/vue/consent-root';
210
+ import { scripts } from './consent-scripts';
211
+
212
+ const kernel = useConsentKernel();
213
+ let loader: ReturnType<typeof createScriptLoader> | undefined;
214
+
215
+ onMounted(() => {
216
+ loader = createScriptLoader({ kernel, scripts });
217
+ });
218
+ onUnmounted(() => loader?.dispose());
219
+ </script>
220
+
221
+ <template>
222
+ <ConsentRoot />
223
+ <main>Your application</main>
224
+ </template>
225
+ ```
226
+
227
+ Keep your existing page content and preferences link. The plugin still owns
228
+ the kernel and persistence; this component owns only the vendor loader.
229
+ Do not register the same scripts in plugin configuration as well. See the
230
+ [Vue quickstart](https://c15t.com/docs/frameworks/vue/quickstart).
231
+
232
+ **Astro**
233
+
234
+ Point the existing Astro integration at a client module. Keep its `mode`,
235
+ `ui` and framework integration from the [Astro quickstart](../frameworks/astro/quickstart.md).
236
+ Import `fileURLToPath` in your Astro configuration:
237
+
238
+ ```js title="astro.config.mjs"
239
+ import { fileURLToPath } from 'node:url';
240
+ ```
241
+
242
+ Add this option to the existing `c15t({ ... })` call. Resolve the path from
243
+ the configuration file because Astro injects the import into a virtual module:
244
+
245
+ ```js
246
+ clientEntrypoint: fileURLToPath(new URL('./src/c15t.client.ts', import.meta.url)),
247
+ ```
248
+
249
+ Export the scripts from that module:
250
+
251
+ ```ts title="src/c15t.client.ts"
252
+ import type { C15tClientOptionsExtension } from '@c15t/astro';
253
+ import { scripts } from './consent-scripts';
254
+
255
+ export default { scripts } satisfies C15tClientOptionsExtension;
256
+ ```
257
+
258
+ The integration passes this extension to its shared browser runtime. Vendor
259
+ helpers contain callbacks, so do not put them in the serialized `scripts`
260
+ option in `astro.config.mjs`. Keep one runtime across consent islands and
261
+ `ClientRouter` navigation.
262
+
263
+ **Svelte**
264
+
265
+ Import the scripts in the component that owns your existing provider and
266
+ pass them as a top-level prop:
267
+
268
+ ```svelte title="src/App.svelte"
269
+ <script lang="ts">
270
+ import { ConsentManagerProvider, hosted } from '@c15t/svelte';
271
+ import { scripts } from './consent-scripts';
272
+
273
+ const backendURL = import.meta.env.VITE_C15T_BACKEND_URL;
274
+ if (!backendURL) throw new Error('Set VITE_C15T_BACKEND_URL');
275
+ const mode = hosted({ url: backendURL });
276
+ </script>
277
+
278
+ <ConsentManagerProvider {mode} {scripts}>
279
+ <!-- Keep your application, consent UI and preferences link here. -->
280
+ </ConsentManagerProvider>
281
+ ```
282
+
283
+ Retain the styles and consent UI from the [Svelte quickstart](https://c15t.com/docs/frameworks/svelte/quickstart).
284
+ The provider owns the loader and disposes it on unmount.
285
+
286
+ **SvelteKit**
287
+
288
+ Add the scripts to the existing root layout provider. Keep the server load
289
+ and its serializable prefetch data from the [SvelteKit quickstart](https://c15t.com/docs/frameworks/sveltekit/quickstart).
290
+
291
+ ```svelte title="src/routes/+layout.svelte"
292
+ <script lang="ts">
293
+ import { ConsentManagerProvider, hosted } from '@c15t/svelte';
294
+ import { scripts } from '../consent-scripts';
295
+
296
+ let { children, data } = $props();
297
+ const mode = hosted({ url: data.backendURL });
298
+ </script>
299
+
300
+ <ConsentManagerProvider {mode} {scripts} prefetch={data.prefetch}>
301
+ {@render children()}
302
+ <!-- Keep your consent UI and preferences link here. -->
303
+ </ConsentManagerProvider>
304
+ ```
305
+
306
+ Import vendor helpers in the layout component, not in `+layout.server.ts`.
307
+ For static hosting, keep your browser-only `mode` setup and omit request
308
+ prefetch; the `scripts` prop stays the same. If you pass an externally owned
309
+ `runtime` to the provider, register scripts when creating that runtime instead.
310
+
311
+ **JavaScript**
312
+
313
+ Attach the loader to your existing kernel before calling
314
+ `kernel.commands.init()`:
315
+
316
+ ```ts
317
+ import { createScriptLoader } from 'c15t/modules/script-loader';
318
+ import { scripts } from './consent-scripts';
319
+
320
+ const loader = createScriptLoader({ kernel, scripts });
321
+ ```
322
+
323
+ Call `loader.dispose()` when that application instance is destroyed.
324
+ `kernel` is the hosted kernel from your quickstart. A provider-owned kernel
325
+ already has a loader; do not attach a second one. See
326
+ [JavaScript script loading](https://c15t.com/docs/frameworks/javascript/script-loader).
327
+
328
+ ## Loading and updates
329
+
330
+ The helper returns an `alwaysLoad`, `callbackOnly` configuration with category
331
+ `necessary`. This lets consent synchronization run for every visitor. It does
332
+ not make the downstream analytics or advertising tools necessary.
333
+
334
+ Zaraz normally injects its own loader. If auto-injection is disabled, install
335
+ [Zaraz manually](https://developers.cloudflare.com/zaraz/advanced/load-zaraz-manually/)
336
+ once. The bridge supports either loading order: an already-ready API is updated
337
+ immediately; otherwise it waits for `zarazConsentAPIReady` and applies the latest
338
+ c15t permissions. No polling is used.
339
+
340
+ On a change, the bridge calls `zaraz.consent.set()` before
341
+ `zaraz.consent.sendQueuedEvents()`. It flushes Zaraz's queued pageviews only when
342
+ a purpose changes from denied to allowed. Revocation updates purposes to false
343
+ and does not flush events. Repeated identical permissions do not rewrite the
344
+ Zaraz cookie. `onReady` runs once after the first successful synchronization,
345
+ including when all optional purposes are denied. A pageview sent there remains
346
+ subject to Zaraz's purpose checks.
347
+
348
+ | Option | Default | Behavior |
349
+ | ------------------ | -------- | ---------------------------------------------------------------------------- |
350
+ | `purposes` | Required | Maps categories to Zaraz purpose IDs; unmapped purposes are denied |
351
+ | `hideBuiltInModal` | `true` | Hides the currently visible modal; also disable auto-display in Cloudflare |
352
+ | `sendQueuedEvents` | `true` | Replays Zaraz's queued pageviews after new grants |
353
+ | `onReady` | Unset | Runs after initial permission synchronization |
354
+ | `onError` | Unset | Receives synchronization errors so the application can report or handle them |
355
+
356
+ If a Zaraz API call throws, `onReady` does not run until synchronization
357
+ succeeds. Use `onError(error)` to report the failure and prevent application
358
+ events from relying on permissions that were not applied. The bridge retries
359
+ with the latest permissions on the next consent update or readiness event;
360
+ it does not poll or schedule automatic retries. Readiness retries remain
361
+ registered when `onError` is omitted and an error reaches the loader debug hook. A failed queued-event replay
362
+ remains pending until synchronization succeeds while that purpose is still
363
+ allowed. Revoking the purpose cancels its pending replay. Zaraz can partially
364
+ process a queue before throwing, so retries cannot guarantee exactly-once delivery. Without `onError`, synchronous
365
+ failures reach the script loader's debug events and readiness-event failures
366
+ reach the browser's error handler. A failed revocation can leave the previous
367
+ Zaraz grant in place.
368
+
369
+ If the bridge starts before saved consent or policy resolution is available,
370
+ it applies the kernel's current effective permissions and updates them when
371
+ initialization completes. Pass restored state during setup when available.
372
+ The bridge does not force a denial when the kernel already permits a purpose.
373
+
374
+ Set `sendQueuedEvents: false` if your application deliberately discards
375
+ pre-consent pageviews. Send subsequent route events only after readiness and
376
+ avoid combining manual route events with Zaraz's automatic SPA pageviews.
377
+
378
+ Removing or replacing the configuration, or disposing its loader, detaches the
379
+ readiness listener. Disposal does not revoke consent, clear vendor storage, or
380
+ stop a tool that has already initialized. Save the denied permissions before
381
+ teardown when revocation is required. Zaraz controls subsequent tool execution;
382
+ test vendor-specific behavior for scripts with their own ongoing activity.
383
+
384
+ ## Verify the configured tools
385
+
386
+ Use a test environment with isolated destinations. Check a first visit, a return
387
+ visit with stale Zaraz grants, measurement-only acceptance, marketing-only
388
+ acceptance, rejection, and revocation. Inspect both `zaraz.consent.getAll()` and
389
+ actual tool activity. An updated consent object alone does not prove that a
390
+ misconfigured tool stopped sending data.
391
+
392
+ This integration maps c15t categories to Zaraz purposes. It does not translate
393
+ IAB TCF vendor and purpose choices or replace Zaraz's separate TCF configuration.
394
+
395
+ [Cloudflare Web Analytics](./cloudflare-web-analytics.md) is a
396
+ separate analytics product with its own loader. Zaraz manages multiple tools,
397
+ which can have different consent requirements and execution costs. Moving a
398
+ tool to Zaraz can reduce browser work, but this bridge alone does not establish
399
+ a performance improvement for that tool.
@@ -32,12 +32,12 @@ Render this component inside your existing consent boundary or provider.
32
32
  ```tsx title="src/consent-embed.tsx"
33
33
  'use client';
34
34
 
35
- import { Frame } from 'c15t/next';
35
+ import { ConsentGate } from 'c15t/next';
36
36
  import { embedCategory, embedURL, embedTitle, embedAspectRatio } from './embed-config';
37
37
 
38
38
  export function ConsentEmbed() {
39
39
  return (
40
- <Frame category={embedCategory}>
40
+ <ConsentGate category={embedCategory}>
41
41
  <iframe
42
42
  src={embedURL}
43
43
  title={embedTitle}
@@ -45,12 +45,12 @@ export function ConsentEmbed() {
45
45
  allowFullScreen
46
46
  style={{ width: '100%', aspectRatio: embedAspectRatio, minHeight: 200, border: 0 }}
47
47
  />
48
- </Frame>
48
+ </ConsentGate>
49
49
  );
50
50
  }
51
51
  ```
52
52
 
53
- `Frame` keeps the iframe absent while permission is denied and removes it
53
+ `ConsentGate` keeps the iframe absent while permission is denied and removes it
54
54
  on revocation. Keep your existing consent styles and preferences dialog.
55
55
 
56
56
  **TanStack Start**
@@ -58,12 +58,12 @@ on revocation. Keep your existing consent styles and preferences dialog.
58
58
  Render this component inside your existing consent boundary or provider.
59
59
 
60
60
  ```tsx title="src/consent-embed.tsx"
61
- import { Frame } from 'c15t/tanstack-start';
61
+ import { ConsentGate } from 'c15t/tanstack-start';
62
62
  import { embedCategory, embedURL, embedTitle, embedAspectRatio } from './embed-config';
63
63
 
64
64
  export function ConsentEmbed() {
65
65
  return (
66
- <Frame category={embedCategory}>
66
+ <ConsentGate category={embedCategory}>
67
67
  <iframe
68
68
  src={embedURL}
69
69
  title={embedTitle}
@@ -71,12 +71,12 @@ export function ConsentEmbed() {
71
71
  allowFullScreen
72
72
  style={{ width: '100%', aspectRatio: embedAspectRatio, minHeight: 200, border: 0 }}
73
73
  />
74
- </Frame>
74
+ </ConsentGate>
75
75
  );
76
76
  }
77
77
  ```
78
78
 
79
- `Frame` keeps the iframe absent while permission is denied and removes it
79
+ `ConsentGate` keeps the iframe absent while permission is denied and removes it
80
80
  on revocation. Keep your existing consent styles and preferences dialog.
81
81
 
82
82
  **React**
@@ -84,12 +84,12 @@ on revocation. Keep your existing consent styles and preferences dialog.
84
84
  Render this component inside your existing consent boundary or provider.
85
85
 
86
86
  ```tsx title="src/consent-embed.tsx"
87
- import { Frame } from 'c15t/react';
87
+ import { ConsentGate } from 'c15t/react';
88
88
  import { embedCategory, embedURL, embedTitle, embedAspectRatio } from './embed-config';
89
89
 
90
90
  export function ConsentEmbed() {
91
91
  return (
92
- <Frame category={embedCategory}>
92
+ <ConsentGate category={embedCategory}>
93
93
  <iframe
94
94
  src={embedURL}
95
95
  title={embedTitle}
@@ -97,12 +97,12 @@ export function ConsentEmbed() {
97
97
  allowFullScreen
98
98
  style={{ width: '100%', aspectRatio: embedAspectRatio, minHeight: 200, border: 0 }}
99
99
  />
100
- </Frame>
100
+ </ConsentGate>
101
101
  );
102
102
  }
103
103
  ```
104
104
 
105
- `Frame` keeps the iframe absent while permission is denied and removes it
105
+ `ConsentGate` keeps the iframe absent while permission is denied and removes it
106
106
  on revocation. Keep your existing consent styles and preferences dialog.
107
107
 
108
108
  **Nuxt**
@@ -222,11 +222,11 @@ The provider from your quickstart supplies its consent state.
222
222
 
223
223
  ```svelte title="src/ConsentEmbed.svelte"
224
224
  <script lang="ts">
225
- import { Frame } from '@c15t/svelte';
225
+ import { ConsentGate } from '@c15t/svelte';
226
226
  import { embedCategory, embedURL, embedTitle, embedAspectRatio } from './embed-config';
227
227
  </script>
228
228
 
229
- <Frame category={embedCategory}>
229
+ <ConsentGate category={embedCategory}>
230
230
  <iframe
231
231
  src={embedURL}
232
232
  title={embedTitle}
@@ -237,10 +237,10 @@ The provider from your quickstart supplies its consent state.
237
237
  style:min-height="200px"
238
238
  style:border="0"
239
239
  ></iframe>
240
- </Frame>
240
+ </ConsentGate>
241
241
  ```
242
242
 
243
- The Svelte `Frame` waits until the browser is mounted and the category is
243
+ The Svelte `ConsentGate` waits until the browser is mounted and the category is
244
244
  allowed. Its default placeholder opens preferences. Revocation removes the
245
245
  iframe.
246
246
 
@@ -251,11 +251,11 @@ Keep the SvelteKit root provider and its server prefetch unchanged.
251
251
 
252
252
  ```svelte title="src/lib/ConsentEmbed.svelte"
253
253
  <script lang="ts">
254
- import { Frame } from '@c15t/svelte';
254
+ import { ConsentGate } from '@c15t/svelte';
255
255
  import { embedCategory, embedURL, embedTitle, embedAspectRatio } from '../embed-config';
256
256
  </script>
257
257
 
258
- <Frame category={embedCategory}>
258
+ <ConsentGate category={embedCategory}>
259
259
  <iframe
260
260
  src={embedURL}
261
261
  title={embedTitle}
@@ -266,10 +266,10 @@ Keep the SvelteKit root provider and its server prefetch unchanged.
266
266
  style:min-height="200px"
267
267
  style:border="0"
268
268
  ></iframe>
269
- </Frame>
269
+ </ConsentGate>
270
270
  ```
271
271
 
272
- The Svelte `Frame` waits until the browser is mounted and the category is
272
+ The Svelte `ConsentGate` waits until the browser is mounted and the category is
273
273
  allowed. Its default placeholder opens preferences. Revocation removes the
274
274
  iframe.
275
275