Skip to main content

Debug

Metodi e proprietà per debugging e telemetria.

Method / PropertyTierSince
setDebug(enabled)11.0
debugModeOn() / debugModeOff()11.0
version (property)11.0

💡 Per logging strutturato e persistente come scelta architetturale, usa il config field loggers: ['console'] o loggers: [] (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​

NameTypeDescription
enabledbooleantrue 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[] in UserConfigType — 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) — setDebug da solo non basta, il soft reload() non la vede
  • Vuoi un'unica chiamata invece di setDebug(true) + reload() separati