Skip to content

feat: add persistTrackingPreference to let a consent tool own the tracking choice - #239

Merged
sadjow merged 10 commits into
mainfrom
feat/preference-persistence
Oct 15, 2026
Merged

sadjow merged 10 commits into
mainfrom
feat/preference-persistence

Conversation

@sadjow

@sadjow sadjow commented Oct 15, 2026 •

Copy link
Copy Markdown
Member

enableTracking() and disableTracking() save the visitor's choice in localStorage, and on later visits a saved choice takes precedence over trackingEnabled. A site that already records that choice in a consent tool then has two records that can disagree. When consent expires, or the visitor clears cookies but not localStorage, the saved true keeps tracking on although the consent tool no longer has consent.

The new persistTrackingPreference option, true by default, lets the consent tool be the only record. With false, the module starts every page load from trackingEnabled, never saves the preference, and removes one saved under an earlier configuration so it doesn't stay on the device unused. The application calls enableTracking() on each page load that should be tracked, typically from a consent callback that reports the stored choice on load. With trackingEnabled: false, every page load starts disabled, the landing route is held as in #237, and the consent callback records it.

The default keeps the current behavior, so tracking regardless of consent, and the README's utm:before-track consent check, work as before.

In the README, the Configuration table lists the option, and its trackingEnabled row now describes the preference each page load starts from. The tracking preferences section says that both methods save the preference and describes turning that off when a consent manager already remembers the choice. It recommends pairing the option with trackingEnabled: false, because with trackingEnabled: true the landing page is recorded as the app mounts, usually before the consent tool reports, and disableTracking() lasts only until the next page load. It also notes that turning the option off removes saved opt-outs, so the consent tool must already hold them. The storage table notes that the key isn't saved with the option off, and the consent section offers the option as an alternative to the consent check in the hook when the consent tool reports the stored choice on every page load. The Composable table's enableTracking() and disableTracking() rows no longer say they save the preference, since that now depends on the option.

This branch is based on #237, which changes the same README section, so its diff shows only this change. It can target main once #237 is merged.

Release note: the new persistTrackingPreference option can be set to false to stop saving the tracking preference in localStorage, so trackingEnabled and your consent tool decide on every page load.

Validation: two new unit tests in test/runtime-plugin.test.ts failed before the change, because with the option off a saved false still turned tracking off and a saved preference stayed in localStorage. They pass now, along with a test of the default, in which the preference is saved and takes precedence over trackingEnabled on the next visit. The existing browser tests that restore a saved opt-out across rendering modes still pass with the default. The package consumer fixture sets the new option, so test:package checks that it is in the published types. pnpm test (166 passed, 1 skipped), pnpm lint --max-warnings 0, pnpm format:check, pnpm test:types, and pnpm test:package pass.

Base automatically changed from fix/consent-after-navigation to main October 15, 2026 20:55
…stence

# Conflicts:
#	README.md
#	src/module.ts
#	src/runtime/plugin.ts
#	src/runtime/types.ts
#	test/package-fixture/consumer.mts
#	test/runtime-plugin.test.ts
@sadjow
sadjow merged commit e361122 into main Oct 15, 2026
9 checks passed
@sadjow
sadjow deleted the feat/preference-persistence branch October 15, 2026 21:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant