Context getters

Where getters work

Svelte has no consent hooks or stores. @c15t/svelte exports context getters instead. Call one at the top level of a component's <script>, inside ConsentProvider, and read its properties in markup or in $derived. The properties read the provider's $state, so the component updates when consent changes.

A getter uses Svelte's getContext, so it throws when you call it:

• in an event handler, an effect or a timer,
• in a component rendered outside the provider,
• in a plain .ts module.

Call it once at the top level and keep the returned object; its methods work from event handlers later. The same getters are exported from @c15t/svelte/headless.

Read a permission or a recorded choice

A permission answers "may this run now?" A recorded choice answers "what did the visitor decide?" They differ. Under an opt-out policy a category can be allowed before the visitor chooses anything, and Global Privacy Control can deny a category the visitor allowed. Load scripts and render optional features from permissions; use the recorded choice only to show or report what the visitor decided.

<script lang="ts">
	import { getConsentManager } from '@c15t/svelte';

	// Call getters at the top level of the component, inside the provider.
	const consent = getConsentManager();

	// A permission: may measurement code run now?
	const measurementAllowed = $derived(consent.has('measurement'));
	// A recorded choice: what did the visitor decide? `null` until they choose.
	const measurementChoice = $derived(
		consent.explicitChoice?.categories.measurement?.value
	);
</script>

<dl>
	<dt>Measurement may run</dt>
	<dd data-testid="measurement-permission">
		{measurementAllowed ? 'Yes' : 'No'}
	</dd>
	<dt>Visitor's measurement choice</dt>
	<dd data-testid="measurement-choice">
		{measurementChoice === undefined
			? 'Not chosen'
			: measurementChoice
				? 'Allowed'
				: 'Denied'}
	</dd>
</dl>

Before the visitor chooses, this component shows "No" and "Not chosen". How consent works explains the difference.

Read the policy and the UI state

Record a choice

Call the methods from event handlers. Save methods return a promise.

<script lang="ts">
	import { ConsentDialog, getConsentManager } from '@c15t/svelte';

	const consent = getConsentManager();

	// Record one category from your own button. setConsent changes the draft;
	// saveConsents('custom') records it.
	const allowAnalytics = async () => {
		consent.setConsent('measurement', true);
		await consent.saveConsents('custom');
	};
</script>

<button type="button" onclick={() => consent.setActiveUI('dialog')}>
	Privacy settings
</button>
<button type="button" onclick={allowAnalytics}> Allow analytics </button>
<ConsentDialog />

Clicking Allow analytics records measurement as allowed and leaves the other categories as they were. Privacy settings opens the dialog.

A save updates permissions in the same task, so registered scripts and ConsentGate react before the backend request finishes. A failed request is kept and retried; it does not undo the choice, and the provider's onError callback reports it. When a save withdraws a category that was granted, the provider reloads the page by default so code that already ran is gone. Set reloadOnConsentRevoked={false} on the provider to handle that yourself.

Only call save methods from a visitor's action. Saving on page load records a choice the visitor never made.

Work with the draft

consent.draft is the unsaved state every preference surface on the page shares: the dialog, ConsentWidget and your own UI.

The draft's code loads with the first preference surface, so a page that only shows the banner does not ship it. ConsentWidget and ConsentDialog bring it with them, and their switches render seeded on the first render, on the server too. Headless code that reads or writes the draft without either one starts the load itself: until it lands, values and vendors are empty objects and isStale is false, and they update reactively once it does. Writes made before then apply in order, draft.reset() drops them, and saveConsents('custom') waits for the draft before it records.

When isStale is true, saveConsents('custom') throws "The policy changed. Review your preferences before saving." Show the visitor the current categories, call draft.reset(), and let them save again.

Read and change IAB TCF consent

getConsentManager().iab is the live IAB state, or null when IAB is off. getIAB() returns the same object at the moment you call it; read .iab on the manager for values that update.

Until the TCF add-on finishes loading, the action methods queue and replay. See IAB TCF for setup.

Listen to consent events

getConsentKernel() returns the consent kernel behind the provider. Its events.on(type, listener) subscribes to one event and returns an unsubscribe function. Subscribe in $effect so Svelte removes the listener when the component unmounts:

<script lang="ts">
	import { getConsentKernel } from '@c15t/svelte';

	// Read the kernel at the top level; subscribe in an effect so the
	// listener is removed when the component unmounts.
	const kernel = getConsentKernel();
	let lastRecorded = $state<string | null>(null);

	$effect(() =>
		kernel.events.on('choice:recorded', ({ snapshot }) => {
			const { measurement } = snapshot.effectivePermissions;
			lastRecorded = measurement ? 'measurement allowed' : 'measurement denied';
		})
	);
</script>

<p data-testid="last-recorded">
	{lastRecorded ?? 'No choice recorded on this page yet'}
</p>

choice:recorded fires for an explicit accept, reject or save. permissions:changed fires for any change to what may run. For callbacks that cover the whole app, use the provider's callbacks prop instead; see callbacks.

The kernel also has subscribe(listener), which runs on every snapshot change, getSnapshot(), and commands for init(), save(), dismissNotice() and identify(). Prefer the manager's methods; they keep the draft and the open surface in step, which the raw commands do not. getSnapshot() from @c15t/svelte returns the snapshot at the moment you call it and does not update.

Other exports