Nell'ultimo trimestre del 2019, il team di Chrome DevTools ha iniziato a migliorare l'esperienza degli sviluppatori in DevTools per quanto riguarda i cookie. Questo è stato particolarmente importante perché Google Chrome e altri browser avevano iniziato a modificare il loro comportamento predefinito dei cookie.
Durante la ricerca degli strumenti già forniti da DevTools, ci siamo spesso trovati in una situazione come la seguente:
Ұ La console era piena di avvisi e messaggi di errore, che contenevano spiegazioni piuttosto tecniche e a volte link al sito chromestatus.com. Tutti i messaggi avevano lo stesso importanza allo stesso modo, rendendo difficile capire quale risolvere per primi. Aspetto ancora più importante, il testo non rimandava a informazioni aggiuntive all'interno di DevTools, il che rendeva difficile comprendere cosa è successo. Infine, spesso il messaggio lasciava interamente allo sviluppatore web il compito di capire come risolvere il problema o persino di conoscere il contesto tecnico.
Se utilizzi la console anche per i messaggi provenienti dalla tua applicazione, a volte avrai difficoltà a trovarli tra tutti i messaggi del browser.
Così come le persone, è anche difficile per i processi automatizzati interagire con i messaggi della console. Ad esempio, gli sviluppatori potrebbero utilizzare Chrome Headless e Puppeteer in uno scenario di integrazione continua/deployment continuo. Poiché i messaggi della console sono solo stringhe, gli sviluppatori devono scrivere espressioni regolari o qualche altro parser per estrarre informazioni utilizzabili.
La soluzione: report sui problemi strutturati e strategici
Per trovare una soluzione migliore ai problemi che abbiamo scoperto, abbiamo iniziato a pensare ai requisiti e li abbiamo raccolti in un documento di progettazione.
Il nostro obiettivo è presentare i problemi in modo che siano spiegati chiaramente e come risolverli. Dal nostro processo di progettazione ci siamo resi conto che ogni numero deve contenere le seguenti quattro parti:
- Titolo
- Descrizione
- Link alle risorse interessate in DevTools
- E un link ad altre indicazioni
Il titolo deve essere breve e preciso, in modo che gli sviluppatori possano capire il problema principale e che spesso forniscano già suggerimenti per risolverlo. Ad esempio, un problema relativo ai cookie ora dice semplicemente:
Contrassegna i cookie cross-site come sicuri per consentirne l'impostazione in contesti tra siti
Ogni problema contiene informazioni più dettagliate in una descrizione che spiega cosa è successo, fornisce consigli pratici su come risolverlo e link ad altri riquadri di DevTools per comprendere il problema nel contesto. Forniamo anche link ad articoli approfonditi su web.dev per consentire agli sviluppatori web di conoscere l'argomento in modo più dettagliato.
Una parte importante di ogni problema è la sezione delle risorse interessate, che rimanda ad altre parti di DevTools per semplificare l'analisi ulteriore. Per l'esempio relativo al problema di cookie, dovrebbe essere presente un elenco di richieste di rete che hanno attivato il problema. Se fai clic sulla richiesta, vieni indirizzato direttamente al riquadro Rete. Ci auguriamo che questa soluzione non sia solo pratica, ma confermi anche quali riquadri e strumenti all'interno di DevTools possono essere utilizzati per eseguire il debug di un determinato tipo di problema.
Pensando all'interazione degli sviluppatori con la scheda Problemi a lungo termine, immaginiamo la seguente evoluzione dell'interazione con gli sviluppatori:
- La prima volta che riscontrava un problema specifico, uno sviluppatore web leggeva l'articolo per comprenderlo in modo approfondito.
- La seconda volta che riscontriamo il problema, ci auguriamo che la descrizione del problema sia sufficiente a ricordare allo sviluppatore l'oggetto del problema e a indagare immediatamente per risolverlo.
- Dopo aver riscontrato un problema per un paio di volte, ci auguriamo che il titolo del problema sia sufficiente per consentire a uno sviluppatore di riconoscere il tipo di problema.
Un altro aspetto importante che volevamo migliorare è l'aggregazione. Ad esempio, se lo stesso cookie ha causato lo stesso problema più volte, volevamo segnalarlo una sola volta. Oltre a ridurre notevolmente il numero di messaggi, questo spesso consente di identificare più rapidamente la causa principale di un problema.
L'implementazione
Tenendo presenti questi requisiti, il team ha iniziato a studiare come implementare la nuova funzionalità. I progetti per Chrome DevTools di solito coprono tre diverse aree:
- Chromium, il progetto open source scritto in C++ dietro a Google Chrome
- frontend DevTools, l'implementazione JavaScript di Chrome DevTools
- Chrome DevTools Protocol (CDP), il livello che collega i due
L'implementazione è stata quindi suddivisa in tre attività:
- All'interno di Chromium abbiamo dovuto identificare i componenti con le informazioni che vogliamo mostrare e renderle accessibili al protocollo DevTools senza compromettere la velocità o la sicurezza.
- Abbiamo quindi dovuto progettare il protocollo CDP di Chrome DevTools per definire l'API che espone le informazioni ai client, ad esempio il frontend DevTools.
- Infine, dovevamo implementare un componente nel frontend di DevTools che richiedesse le informazioni al browser tramite CDP e le visualizzasse in un'interfaccia utente appropriata, in modo che gli sviluppatori possano interpretare e interagire facilmente con le informazioni.
Per quanto riguarda il browser, abbiamo innanzitutto esaminato come sono stati gestiti i messaggi della console, perché il loro comportamento è molto simile a quello che avevamo in mente per i problemi. CodeSearch è in genere un buon punto di partenza per esplorazioni come queste. Ti consente di cercare ed esplorare l'intero codice sorgente del progetto Chromium online. In questo modo abbiamo scoperto l'implementazione dei messaggi della console e abbiamo potuto creare un modo Parallelo, ma più strutturato per soddisfare i requisiti raccolti per i problemi.
Il lavoro qui è particolarmente impegnativo a causa di tutte le implicazioni sulla sicurezza che dobbiamo sempre tenere a mente. Il progetto Chromium consente di separare gli elementi in diversi processi e fare in modo che comunichino solo attraverso canali di comunicazione controllati per evitare fughe di informazioni. I problemi potrebbero contenere informazioni sensibili, perciò dobbiamo fare in modo di non inviare tali informazioni a una parte del browser che non dovrebbe essere a conoscenza.
Nel frontend DevTools
DevTools è un'applicazione web scritta in JavaScript e CSS. È molto simile a molte altre applicazioni web, ad eccezione del fatto che esiste da più di 10 anni. Naturalmente il backend è fondamentalmente un canale di comunicazione diretto con il browser: il protocollo Chrome DevTools.
Per la scheda Problemi, abbiamo innanzitutto pensato alle storie degli utenti e a cosa dovrebbero fare gli sviluppatori per risolvere un problema. Le nostre idee si sono evolute soprattutto perché la scheda Problemi sia un punto di partenza centrale per le indagini che collegavano le persone ai riquadri che mostravano informazioni più dettagliate. Abbiamo deciso di inserire la scheda Problemi insieme alle altre schede nella parte inferiore di DevTools in modo che possa rimanere aperta mentre uno sviluppatore interagisce con un altro componente di DevTools, ad esempio il riquadro Rete o Applicazione.
Partendo da questo presupposto, il nostro designer UX ha capito l'obiettivo e ha prototipato le seguenti proposte iniziali:
Dopo varie discussioni sulla soluzione migliore, abbiamo iniziato a implementare il design e a ribadire le decisioni per arrivare gradualmente all'aspetto attuale della scheda Problemi.
Un altro fattore molto importante è stata la rilevabilità della scheda Problemi. In passato, molte fantastiche funzionalità degli strumenti per sviluppatori non erano rilevabili senza che lo sviluppatore sapesse cosa cercare nello specifico. Per la scheda Problemi, abbiamo deciso di evidenziare i problemi in diverse aree per assicurarci che gli sviluppatori non perdano problemi importanti.
Abbiamo deciso di aggiungere una notifica al riquadro della console, perché alcuni messaggi della console ora sono stati rimossi a causa di problemi. Abbiamo anche aggiunto un'icona al contatore di avvisi ed errori in alto a destra nella finestra DevTools.
Infine, la scheda Problemi non solo rimanda ad altri riquadri di DevTools, ma include anche le risorse correlate a un problema che rimandano alla scheda Problemi.
Nel protocollo
La comunicazione tra il frontend e il backend funziona secondo un protocollo chiamato protocollo DevTools (CDP) di Chromium. Il CDP può essere considerato come il backend dell'app web Chrome DevTools. Il CDP è suddiviso in più domini e ogni dominio contiene una serie di comandi ed eventi.
Per la scheda Problemi, abbiamo deciso di aggiungere un nuovo evento al dominio Controlli che si attiva ogni volta che si verifica un nuovo problema. Per assicurarci di poter generare report anche sui problemi che si verificano quando DevTools non è ancora aperto, il dominio Audits archivia i problemi più recenti e li invia non appena DevTools si connette. DevTools raccoglie tutti questi problemi e li aggrega.
Il CDP consente inoltre ad altri client di protocollo, come Puppeteer, di ricevere ed elaborare problemi. Ci auguriamo che le informazioni strutturate sui problemi inviate al CDP facilitino l'integrazione nell'infrastruttura di integrazione continua esistente. In questo modo, i problemi possono essere rilevati e risolti anche prima del deployment della pagina.
Profilo
Prima di tutto, molti più messaggi devono essere spostati dalla console alla scheda Problemi. Questa operazione richiederà del tempo, soprattutto perché vogliamo fornire una documentazione chiara e fruibile per ogni nuovo problema che aggiungiamo. Ci auguriamo che in futuro gli sviluppatori cerchino i problemi nella scheda Problemi anziché nella console.
Inoltre, stiamo valutando come integrare nella scheda Problemi i problemi di altre fonti oltre al backend di Chromium.
Stiamo cercando modi per tenere ordinata la scheda Problemi e migliorare l'usabilità. La ricerca, l'applicazione di filtri e una migliore aggregazione sono nel nostro elenco per quest'anno. Per strutturare il numero crescente di problemi segnalati, stiamo introducendo categorie di problemi che, ad esempio, consentirebbero di mostrare solo i problemi relativi a imminenti ritiri. Stiamo anche pensando di aggiungere una funzionalità di posticipazione, che uno sviluppatore potrà utilizzare per nascondere temporaneamente i problemi.
Per consentirci di risolvere i problemi, vogliamo semplificare l'individuazione della parte di una pagina che ha generato un problema. In particolare, stiamo valutando la possibilità di distinguere e filtrare i problemi che si verificano in maniera significativa nella tua pagina (ovvero i problemi proprietari) e che nascono dalle risorse che incorpori, ma che non sono direttamente sotto il tuo controllo (ad esempio una rete pubblicitaria). Come primo passo, sarà possibile nascondere i problemi relativi ai cookie di terze parti in Chrome 86.
Se hai suggerimenti per migliorare la scheda Problemi, faccelo sapere inviando un bug.
Scarica i canali in anteprima
Prendi in considerazione l'utilizzo di Chrome Canary, Dev o beta come browser di sviluppo predefinito. Questi canali in anteprima ti consentono di accedere alle funzionalità di DevTools più recenti, di testare le API per piattaforme web all'avanguardia e di individuare eventuali problemi sul tuo sito prima che lo facciano gli utenti.
Contattare il team di Chrome DevTools
Utilizza le opzioni seguenti per discutere delle nuove funzionalità e delle modifiche nel post o di qualsiasi altra cosa relativa a DevTools.
- Inviaci un suggerimento o un feedback tramite crbug.com.
- Segnala un problema DevTools utilizzando Altre opzioni
> Guida > Segnala i problemi di DevTools in DevTools. - Tweet all'indirizzo @ChromeDevTools.
- Lascia commenti sui video di YouTube o sui suggerimenti di DevTools in DevTools Video di YouTube.