Avanceret embedding

Content-Security-Policy

Hvis dit site sætter en Content-Security-Policy-header, har widgeten brug for tre direktiver for at indlæses og forbinde: - script-src skal tillade vores CDN, https://cdn.clarifier.dk - connect-src skal tillade https://api.clarifier.dk til config-hentning og wss://api.clarifier.dk til chat-WebSocket - style-src skal have 'unsafe-inline' eller en nonce til de styles, widgeten injicerer

Content-Security-Policy:
  script-src 'self' https://cdn.clarifier.dk;
  connect-src 'self' https://api.clarifier.dk wss://api.clarifier.dk;
  style-src 'self' 'unsafe-inline';

Widgeten renderes i en Shadow DOM, men værtssidens CSP gælder stadig for de style-elementer, den indsætter — at tilføje 'unsafe-inline' til style-src er den enkleste løsning. Kan du ikke tillade inline styles, så kontakt os, så finder vi en nonce-baseret opsætning.

Shadow DOM og styling

Widgeten monteres i en lukket Shadow DOM-rod. Det giver dig en garanti: intet på din side — global CSS, framework-styles, tema-overrides — kan lække ind og bryde widgetens layout. Til gengæld kan du heller ikke restyle widgeten udefra; styling konfigureres via dashboardet (primær farve, position, header-ikon). Mangler du en visuel tilpasning, dashboardet ikke tilbyder, så ræk ud — de fleste ønsker kan løses med en ny dashboard-mulighed frem for et custom build.

Single-page apps og route-skift

Widgeten monterer sig selv direkte på document.body, ikke i din frameworks rod-komponent. Klient-side route-skift afmonterer den ikke — den bliver, hvor den er, på tværs af navigationer, hvilket er det, du vil have. Gør din app noget usædvanligt (omskriver document.body, fulde re-renders der løsriver fremmedelementer), kan widgeten forsvinde efter et route-skift. Workaround: kald window.Clarifier.destroy() og kør derefter embed-scriptet igen. Vi arbejder på en renere re-init-API; sig til, hvis du støder på det.

Programmatisk API

Når widgeten er indlæst, eksponerer den tre metoder på window.Clarifier:

// Open the chat programmatically (e.g., from a "Help" button)
document.querySelector('#help-button')
  .addEventListener('click', () => window.Clarifier.open())

// Close it
window.Clarifier.close()

// Remove the widget entirely (e.g., before re-initializing in an SPA)
window.Clarifier.destroy()

Metoderne er kun tilgængelige, efter widgeten er booted (efter DOMContentLoaded). Hvis du binder en click-handler, der kalder window.Clarifier.open() under page load, så tjek for, at globalen ikke er undefined, eller vent til window.Clarifier dukker op.

Tving et bestemt sprog

Som standard læser widgeten sidens html lang-attribut, derefter den besøgendes browsersprog, og falder så tilbage til engelsk. For at overstyre: sæt window.__CLARIFIER_LANG til en 2-bogstavskode, før embed-scriptet kører. Det er primært nyttigt til preview og test — produktionssites bør sætte html lang korrekt i stedet.

async vs defer vs lazyOnload

Standard-snippet'en bruger async, som lader browseren hente scriptet parallelt med HTML-parsing og køre det, så snart det ankommer. Det er det rigtige valg for langt de fleste sites — hurtigt, blokerer ikke rendering, widgeten dukker op så hurtigt som muligt. Optimerer du for absolut hurtigste first paint og kan leve med, at widgeten dukker op et øjeblik senere, så brug defer eller Next.js' strategy="lazyOnload". Widgeten initialiserer sig selv, når DOM'en er klar, uanset hvilken loading-strategi du vælger.