Using Osano in Single-Page Applications (SPAs)

Single-page applications (SPAs) behave differently from traditional multi-page websites because they load most of their JavaScript up front and do not fully reload when a user navigates between views. This architectural difference directly impacts how consent changes should be handled within an SPA environment.

This document outlines why SPAs require a page reload after consent changes and provides a recommended implementation pattern using Osano’s Consent Manager.

Why SPAs Need a Page Reload After Consent Changes

In a single-page application:

• The majority of the application’s JavaScript—including third-party scripts—is downloaded and executed on the initial page load.

• When a user updates their consent preferences, Osano updates the consent state in the browser, but:

• JavaScript that has already executed continues running.

• Scripts previously loaded are not automatically stopped, unloaded, or re-evaluated.

• Because SPAs do not perform traditional navigation-based reloads, the browser environment remains active and unchanged after consent updates.

What this means for consent enforcement

To fully apply newly saved consent preferences, the environment must be reinitialized. In traditional multi-page sites, this happens naturally as users navigate page-to-page. In SPAs, however, a manual or programmatic reload is required so that:

• Scripts that are no longer allowed are not reloaded.

• Only scripts permitted under the updated consent settings are downloaded and executed.

• The application's state reflects the user’s current consent accurately and compliantly.

Recommended Implementation for SPAs

Osano provides events that notify you when consent has changed or been saved. In an SPA, you can use these events to detect changes and trigger a reload to ensure the environment resets using the updated consent state.

Example Implementation

<script src="https://cmp.osano.com/[...]/osano.js"></script>

<script>
  // Check whether the user is in an implicit consent region
  const isImplicit = window.Osano.cm.consentModel === 'implicit';
  // Check whether the user has previously saved consent
  const hadPriorConsent = !!localStorage.getItem('osano_consentmanager');
  let consentChanged = false;
  // Triggered when the user toggles any consent category
  window.Osano.cm.addEventListener('osano-cm-consent-changed', () => {
    consentChanged = true; // Tracks that a change was made before saving
  });
  // Triggered when the user saves their selections
  window.Osano.cm.addEventListener('osano-cm-consent-saved', () => {
    if (consentChanged && (!isImplicit || hadPriorConsent)) {
      window.location.reload(); // Ensures new consent is applied correctly
    }
  });
</script>

How this works

• osano-cm-consent-changedFires when the user modifies any consent preference.

• osano-cm-consent-savedFires when the user saves the updated preferences in the Consent Manager.

• If the user made changes, the script triggers a full page reload, ensuring:

• Non-consented scripts do not run.

• Newly allowed scripts load properly.

• The SPA initializes in a clean, compliant state.

Best Practices

• Do not load third-party scripts before Osano initializes and evaluates consent.

• Ensure non-essential scripts (analytics, marketing, personalization) use Osano’s script-blocking or conditional loading.

• Allow the SPA to reload after consent is saved so that previously running scripts don’t continue.

• Avoid assuming client-side route changes will enforce new consent—they won’t in SPAs.

Summary

SPAs require special handling for consent changes because they do not naturally reload pages. To ensure proper consent enforcement:

• Detect consent state changes using Osano’s events.

• Programmatically trigger a page reload after consent is saved.

• Ensure all scripts load in alignment with the user’s updated preferences.

Implementing the script above ensures compliance and provides consistent behavior with how consent is applied on traditional multi-page sites.