Applications monopages et changements de page

Dans une application monopage, le navigateur ne charge la page qu’une fois ; votre framework remplace ensuite le contenu et modifie l’adresse via history.pushState. Le widget détecte ces changements lui-même. Vous n’avez rien à signaler ni à redémarrer.

Intégration : une seule fois

Placez le chargeur une seule fois dans la structure principale de l’application (index.html, layout racine, _document), pas dans un composant redessiné à chaque changement de route. Une seconde intégration est sans conséquence (le second chargeur ne fait rien, voir Balise script), mais retirer puis réinsérer la balise ne redémarre pas le widget.

// Next.js (App Router), app/layout.tsx
import Script from 'next/script';

export default function RootLayout({ children }) {
  return (
    <html lang="en">
      <body>
        {children}
        <Script src="https://cdn.reactive.chat/loader.js"
                data-rc-site-key="SITE_KEY"
                strategy="afterInteractive" />
      </body>
    </html>
  );
}

L’inspecteur d’éléments est le moyen le plus simple de vérifier si un composant d’aide du framework transmet les attributs data-* au <script> généré. Si data-rc-site-key y manque, rien ne démarre.

Détection des changements de page

Le widget n’intercepte pas history.pushState ; il observe seulement :

1. la Navigation API du navigateur (navigation.currententrychange), si elle est disponible ;
2. sinon, popstate et hashchange ;
3. en complément, une minuterie qui détecte les changements d’adresse sans événement (chaque seconde, toutes les 5 secondes avec la Navigation API) ;
4. pageshow au retour du cache précédent/suivant.

Compte comme changement de page : une nouvelle adresse (chemin ou requête) et les routes par fragment de la forme #/… et #!/…. Ne compte pas comme changement de page : un simple saut vers une ancre (#section) et un replaceState vers la même adresse.

Informations transmises

400 ms après le changement (pour ignorer les états intermédiaires des redirections), le widget envoie une trame de contexte au serveur, uniquement avec le consentement :

• url, path, title, referrer – les paramètres sensibles de requête (comme email, password, token, key, card) sont d’abord retirés de url et referrer.
• locale, tz, viewport, screen, ua_hint.
• utm_source, utm_medium, utm_campaign, gclid, msclkid, fbclid, depuis l’adresse.
• nav – type de changement : load, push, replace, reload, back, forward ou traverse.

Si votre application définit le titre seulement après le changement, le widget envoie une correction après 2 secondes. Les agents voient ainsi dans l’espace agents la page actuelle du visiteur et l’assistant y rattache sa réponse.

Le widget relit aussi le texte visible de la page (pour les réponses sur la page actuelle et « Montrez-moi »), au plus tôt 1,2 seconde après le dernier changement, au maximum toutes les 5 secondes, jamais sur des pages telles que le compte, le paiement ou le panier, et jamais dans les champs de formulaire. Marquez les zones que l’assistant ne doit pas lire avec data-rc-private (Balise script).

Transmettre votre contexte par page

Aucune méthode dédiée ne signale un changement de page, et aucune n’est nécessaire. Pour transmettre des informations supplémentaires sur la page actuelle, par exemple le produit affiché, utilisez track après le changement de route :

// React Router
const location = useLocation();
useEffect(() => {
  if (produkt) {
    window.ReactiveChat('track', 'produktseite', {
      page_type: 'product', product_id: produkt.sku, price: produkt.preis,
      currency: 'EUR', in_stock: produkt.lieferbar
    });
  }
}, [location.pathname, produkt]);

Les champs transmis sont présentés sous Identifier les visiteurs et transmettre le contexte.

Turbo, htmx, Livewire

Les frameworks qui remplacent tout le <body> retirent aussi l’élément du widget. Celui-ci se rattache alors lui-même au document (au maximum dix fois par minute) ; la conversation continue.

Utilisateurs connectés dans les SPA

Si une personne se connecte sans rechargement, appelez ensuite identify avec un hachage fraîchement obtenu du serveur. En cas de changement d’utilisateur, le widget sépare le brouillon de saisie de l’utilisateur précédent. Détails sous Identifier les visiteurs.

Texte de confidentialité dans les SPA

Si votre application insère la politique de confidentialité seulement après le chargement, le widget trouve quand même l’élément data-rc-privacy (il observe le document). Voir Intégration de la confidentialité.

Suite : Sécurité et CSP