Setting up CookieOfficer in single-page apps (SPAs)
Adding the CookieOfficer code to single-page apps (SPAs).
Single-page apps (SPAs), built with React, Vue, Angular, Next.js or Nuxt, mean that visitors move between subpages without reloading them. You place the CookieOfficer code in them once, in the HTML document, not in a component. Below you'll learn where to add the code depending on the type of app, and what changes in how pageviews are counted.
Before you start
Copy the code from the Installation page in the CookieOfficer panel. In the “Deployment method” section, choose “Code on the site”, then in the “Paste the code at the top of <head>” card click “Copy” next to the “CookieOfficer script” block.
Where should you put the CookieOfficer code?
An app rendered in the browser, for example React, Vue or Angular. Paste the code in the index.html file, in the <head> section, as the first script. It is the only HTML document in such an app, so it serves all routes.
An app rendered on the server side, for example Next.js or Nuxt. Paste the code in the component responsible for the document, that is, where the framework builds the <head> section for all pages. In Next.js this is the root layout or the Document component, depending on the version.
The same rule applies in both cases: our code must be in place before the other scripts. Automatic blocking covers only what runs after it.
What not to do in the app code
- Don't add the code in a view component. It will only mount after the first render, so tracking scripts will manage to start before the visitor gives consent.
- Don't inject the script dynamically from within the app. It then loses its purpose as a blocker, because it only runs after the code it was meant to stop has already started.
- Don't call anything after a view change. There is no need, as the section below explains.
What happens when the subpage changes?
Our code hooks into route changes and, on every navigation, records a pageview and checks whether the new page is excluded from the banner. A visitor's decision applies for the whole visit and doesn't need to be refreshed, so you don't have to call anything manually or reload the script.
We don't resend consent signals when the view changes. The consent state applies for the whole visit, and tags in Google Tag Manager receive it once, after the visitor's decision.
This has one consequence that's worth knowing about in advance: a route change in a single-page application counts as a pageview, just like opening a page on a classic website. Statistics and the count towards your plan limit therefore grow faster than the number of visits to the site, because a visitor browsing five subpages generates five pageviews. We also count navigating with the back and forward buttons as a pageview, while two consecutive navigations to the same address are counted once.
How do I verify the CookieOfficer setup?
Go back to the Installation page in the CookieOfficer panel and click “Verify now”. If it succeeds, you'll see the heading “Script detected and active”.
Open the app in an incognito window, make a choice in the banner, and then go to another view. The banner shouldn't appear again, and the visitor's decision should be saved in the co_consent cookie.
Finally, run a scan of your site in the panel and go to the Cookies page. There should be no message above the list of detected items about trackers running after a visitor has rejected consent.
Common mistakes to avoid
- Don't put the code outside the HTML document. Code in a component will run too late to block anything.
- Don't count on blocking scripts that the framework itself loads. Anything that runs before our code stays outside its reach.
- Don't forget about the production environment. Code added only in your local configuration won't reach the deployed app.
- Don't let the number of pageviews catch you off guard. Every transition between views is a separate pageview, including for your plan limit.