Debug
Metodi e proprietà per debugging e telemetria.
| Method / Property | Tier | Since |
|---|---|---|
setDebug(enabled) | 1 | 1.0 |
debugModeOn() / debugModeOff() | 1 | 1.0 |
version (property) | 1 | 1.0 |
💡 Per logging strutturato e persistente come scelta architetturale, usa il config field
loggers: ['console']ologgers: [](vuoto = silent).
setDebug
Attiva o disattiva il console-logger del core. Il flag è persistito in localStorage (chiave avacy:debug) così sopravvive ai reload di pagina — utile per QA su un sito live senza modificare la config inline.
window.Avacy.setDebug(enabled: boolean): void
Parameters
| Name | Type | Description |
|---|---|---|
enabled | boolean | true forza loggers: ['console'] al prossimo boot. false rimuove l'override (non forza loggers: []): al prossimo boot vince di nuovo qualunque loggers sia impostato nella config del cliente — se quella config ha già loggers: ['console'] esplicito, resta attivo. Idempotente. |
Example
// in console del browser, durante un'investigazione bug:
window.Avacy.setDebug(true);
// → ricarica la pagina (o chiama Avacy.reload()):
location.reload();
// ora vedi log strutturati di TCF, framework init, store read/write, etc.
// quando hai finito:
window.Avacy.setDebug(false);
location.reload();
When to use it
- Riproduzione bug client in produzione, su un browser specifico, senza deploy
- Investigazione integrator-side senza modificare la config inline
- Smoke test E2E con log verbose temporaneo
Timing
Il flag prende effetto al prossimo init() o reload(), non a runtime. MainLoggerProvider viene istanziato durante Core.init e i subloggers attivi sono fissi nel ciclo di vita di quel context. Per applicare immediatamente:
window.Avacy.setDebug(true);
await window.Avacy.reload(); // re-bootstrap con loggers aggiornati
Storage
setDebug(true) scrive window.localStorage.setItem('avacy:debug', 'true'). setDebug(false) rimuove la chiave (removeItem), non la imposta a 'false' — la lettura al boot distingue "chiave assente" (nessun override) da "chiave presente ma non 'true'" (override esplicito a silenzioso). Se localStorage non è disponibile (modalità privata, WebView restrittive) la chiamata è silenziosa: il fallback è passare loggers: ['console'] esplicitamente nel config inline.
See also
- Config field
loggers: LoggerType[]inUserConfigType— controllo dichiarativo permanente reload()— per applicare il flag immediatamente
debugModeOn / debugModeOff
Scorciatoia rispetto a setDebug + reload(): persiste il flag avacy:debug e applica un reload completo della pagina (window.location.reload()), non il soft-reload di window.Avacy.reload().
window.Avacy.debugModeOn(): void
window.Avacy.debugModeOff(): void
Perché un reload di pagina intero, non il soft reload()
Le build custom (es. RAI) inizializzano con un oggetto di config hardcoded nel bundle stesso. Il soft reload() ri-esegue il boot leggendo di nuovo il #avacy-config inline in pagina — che per queste build non riflette il flag di debug appena attivato. Un reload di pagina intero garantisce che il prossimo boot (qualunque sia la sorgente della config) veda il flag persistito in localStorage.
Example
// in console del browser: attiva debug + reload immediato, un'unica chiamata
window.Avacy.debugModeOn();
// quando hai finito:
window.Avacy.debugModeOff();
Quando usare questi invece di setDebug
- Build custom con config hardcoded (RAI e simili) —
setDebugda solo non basta, il softreload()non la vede - Vuoi un'unica chiamata invece di
setDebug(true)+reload()separati