Introduzione
Oggi gli autori possono utilizzare molte astrazioni per creare le proprie applicazioni web. Invece di interfacciarsi direttamente con le API di livello inferiore fornite dalla piattaforma web, molti autori sfruttano i framework, gli strumenti di creazione e i compilatori per scrivere le proprie applicazioni da una prospettiva di livello superiore.
Ad esempio, i componenti basati sul framework Angular vengono creati in TypeScript con modelli HTML. All'interno di una struttura, l'interfaccia a riga di comando Angular e il webpack compilano tutto in JavaScript e in un cosiddetto bundle, che viene poi spedito al browser.
Quando esegui il debug o la profilazione delle applicazioni web in DevTools, al momento puoi vedere e eseguire il debug di questa versione compilata del codice anziché del codice che hai effettivamente scritto. Tuttavia, in qualità di autore, questo non è ciò che vuoi:
- Non vuoi eseguire il debug del codice JavaScript minimizzato, ma del codice JavaScript originale.
- Quando utilizzi TypeScript, non vuoi eseguire il debug di JavaScript, ma del codice TypeScript originale.
- Quando utilizzi i modelli, ad esempio con Angular, Lit o JSX, non è sempre necessario eseguire il debug del DOM risultante. Ti consigliamo di eseguire il debug dei componenti autonomamente.
In generale, è consigliabile eseguire il debug del codice così come è stato scritto.
Sebbene le mappe sorgente colmino già in parte questa lacuna, Chrome DevTools e l'ecosistema possono fare di più in questo ambito.
Diamo un'occhiata.
Codice creato e codice di cui è stato eseguito il deployment
Attualmente, quando navighi nella struttura ad albero dei file nel riquadro Origini, puoi vedere i contenuti del bundle compilato e spesso minimizzato. Si tratta dei file effettivi che il browser scarica ed esegue. DevTools lo chiama Codice di cui è stato eseguito il deployment.
Non è molto pratico e spesso è difficile da comprendere. In qualità di autore, vuoi vedere ed eseguire il debug del codice che hai scritto, non del codice di cui è stato eseguito il deployment.
Per compensare, ora puoi mostrare nell'albero il codice creato. In questo modo, l'albero assomiglia di più ai file di origine che puoi vedere nell'IDE e questi file sono ora separati dal codice di cui è stato eseguito il deployment.
Per attivare questa opzione in Chrome DevTools, vai a Impostazioni > Esperimenti e seleziona Raggruppa le origini in alberi di autorizzazioni e di implementazione.
"Solo il mio codice"
Quando utilizzi dipendenze o esegui il build su un framework, i file di terze parti possono intralciarti. La maggior parte delle volte vuoi vedere solo il tuo codice, non quello di una libreria di terze parti nascosta nella cartella node_modules.
Per rimediare, DevTools ha un'impostazione aggiuntiva attivata per impostazione predefinita: Aggiungi automaticamente script di terze parti noti all'elenco degli elementi da ignorare. Puoi trovarlo in DevTools > Impostazioni > Elenco degli utenti da ignorare.
Con questa impostazione attivata, DevTools nasconde tutti i file o le cartelle contrassegnati come da ignorare da un framework o uno strumento di compilazione.
A partire dalla versione 14.1.0 di Angular, i contenuti delle cartelle node_modules e webpack sono stati contrassegnati come tali. Di conseguenza, queste cartelle, i file al loro interno e altri elementi di terze parti simili non vengono visualizzati in varie posizioni in DevTools.
In qualità di autore, non devi fare nulla per attivare questo nuovo comportamento. Spetta al framework implementare questa modifica.
Codice nell'elenco di elementi da ignorare nelle tracce dello stack
I file inclusi nell'elenco di elementi da ignorare non vengono più visualizzati nelle analisi dello stack. Ora, in qualità di autore, puoi visualizzare più tracce dello stack pertinenti.
Se vuoi visualizzare tutti i frame di chiamata dell'analisi dello stack, puoi sempre fare clic sul link Mostra altri frame.
Lo stesso vale per gli stack di chiamate visualizzati durante il debug e l'esecuzione passo passo del codice. Quando i framework o i bundler informano DevTools sugli script di terze parti, DevTools nasconde automaticamente tutti i frame di chiamata irrilevanti e salta qualsiasi codice nell'elenco di ignorati durante il debug passo passo.
Il codice inserito nell'elenco di elementi da ignorare nella struttura ad albero dei file
Per nascondere i file e le cartelle inclusi nell'elenco di elementi da ignorare nella struttura ad albero dei file Codice creato nel riquadro Origini, seleziona Nascondi il codice elencato di elementi da ignorare nella visualizzazione ad albero delle origini in Impostazioni > Esperimenti in DevTools.
Nel progetto Angular di esempio, le cartelle node_modules e webpack sono ora nascoste.
Codice nell'elenco ignorato nel menu "Apri rapidamente"
Il codice nell'elenco ignorato non è nascosto solo nella struttura ad albero dei file, ma anche nel menu "Apri rapidamente" (Ctrl+P (Linux/Windows) o Comando+P (Mac)).
Ulteriori miglioramenti alle tracce dello stack
Avendo già trattato le tracce dello stack pertinenti, Chrome DevTools introduce ulteriori miglioramenti alle tracce dello stack.
Analisi dello stack collegate
Quando alcune operazioni sono pianificate per essere eseguite in modo asincrono, le tracce dello stack in DevTools attualmente forniscono solo una parte della storia.
Ad esempio, ecco un programmatore molto semplice in un file framework.js ipotetico:
function makeScheduler() {
const tasks = [];
return {
schedule(f) {
tasks.push({ f });
},
work() {
while (tasks.length) {
const { f } = tasks.shift();
f();
}
},
};
}
const scheduler = makeScheduler();
function loop() {
scheduler.work();
requestAnimationFrame(loop);
};
loop();
… e come uno sviluppatore potrebbe utilizzarlo nel proprio codice in un file example.js:
function someTask() {
console.trace("done!");
}
function businessLogic() {
scheduler.schedule(someTask);
}
businessLogic();
Quando aggiungi un punto di interruzione all'interno del metodo someTask o quando esamini la traccia stampata nella console, non viene visualizzata alcuna menzione della chiamata businessLogic() che rappresentava la "causa principale" di questa operazione.
Viene visualizzata solo la logica di pianificazione del framework che ha portato all'esecuzione dell'attività e non vengono visualizzati indicatori nella traccia dello stack per aiutarti a capire i collegamenti causali tra gli eventi che hanno portato a questa attività.
Grazie a una nuova funzionalità chiamata "Tagging dello stack asincrono", è possibile raccontare tutta la storia collegando entrambe le parti del codice asincrono.
L'API Async Stack Tagging introduce un nuovo metodo console denominato console.createTask(). La firma dell'API è la seguente:
interface Console {
createTask(name: string): Task;
}
interface Task {
run<T>(f: () => T): T;
}
La chiamata console.createTask() restituisce un'istanza Task che puoi utilizzare in un secondo momento per eseguire i contenuti dell'attività f.
// Task Creation
const task = console.createTask(name);
// Task Execution
task.run(f);
L'attività forma il collegamento tra il contesto in cui è stata creata e il contesto della funzione asincrona in esecuzione.
Applicato alla funzione makeScheduler sopra, il codice diventa il seguente:
function makeScheduler() {
const tasks = [];
return {
schedule(f) {
const task = console.createTask(f.name);
tasks.push({ task, f });
},
work() {
while (tasks.length) {
const { task, f } = tasks.shift();
task.run(f); // instead of f();
}
},
};
}
Grazie a questo, Chrome DevTools ora è in grado di mostrare una traccia dello stack migliore.
Nota come ora businessLogic() è incluso nell'analisi dello stack. Non solo, ma l'attività ha un nome familiare someTask anziché requestAnimationFrame generico come prima.
Cornici di chiamata amichevoli
Durante la creazione di un progetto, i framework generano spesso codice da tutti i tipi di linguaggi di creazione di modelli, ad esempio i modelli Angular o JSX che trasformano il codice simile a HTML in semplice JavaScript che viene eseguito nel browser. A volte, a questi tipi di funzioni generate vengono dati nomi che non sono molto amichevoli: nomi di una sola lettera dopo essere stati minimizzati o alcuni nomi ambigui o sconosciuti, anche quando non lo sono.
Nel progetto di esempio, un esempio è AppComponent_Template_app_button_handleClick_1_listener, che puoi vedere nell'analisi dello stack.
Per risolvere questo problema, Chrome DevTools ora supporta la ridenominazione di queste funzioni tramite mappe di origine. Se una mappa di origine contiene una voce di nome per l'inizio di un ambito di funzione, il frame di chiamata dovrebbe visualizzare questo nome nell'analisi dello stack.
In qualità di autore, non devi fare nulla per attivare questo nuovo comportamento. Spetta al framework implementare questa modifica.
Prospettive future
Grazie alle aggiunte descritte in questo post, Chrome DevTools può offrirti un'esperienza di debug migliore. Il team vorrebbe esplorare altre aree. In particolare, verrà spiegato come migliorare l'esperienza di profilazione in DevTools.
Il team di DevTools di Chrome incoraggia gli autori di framework ad adottare queste nuove funzionalità. Il case study: un debug di Angular migliore con DevTools offre indicazioni su come implementare questa funzionalità.