Chrome, persistent authoring in devtools.

Post aggiornato in data 13 Aprile 2020

Google Chrome ha un ottimo, forse il migliore, sistema di debug attualmente sul “mercato“. Partito con poche opzioni al suo debutto, oggi si può fare debug in modo piuttosto approfondito analizzando tutto quello che passa per il browser e che deve esso stesso interpretare. Una delle opzioni sicuramente più utilizzate è la modifica in anteprima delle classi CSS per cambiare l’aspetto di una pagina o di un elemento. Queste pseudo-modifiche hanno effetto visivo in tempo reale, ma sono tali fintanto che abbiamo aperto il debugger. Per cui una volta raggiunto il proprio scopo si deve salvare tutto all’interno del file “reale” presente sul proprio ambiente di sviluppo. Questa pratica di authoring, come la chiamano loro, non è molto efficiente perché appunto bisogna copiare le porzioni di codice che abbiamo modificato sul file “vero” e salvare.

Finché si tratta di un file CSS di un centinaio di righe non è un gran problema, ma quando questo diventa complesso ed articolato l’opzione di copia incolla dove tocca saltare da una parte all’altra del foglio di stile è il momento in cui si comincia a prestare il fianco ad errori.

Da qualche versione di Google Chrome è stato introdotto il “persistent authoring” che in qualche modo sorpassa quanto detto poco sopra, e permette di “agganciare” la visualizzazione di debug ad una mappatura su disco locale, o disco di rete, dove quello specifico file esiste realmente. Nella pratica le modifiche che effettueremo in modalità di debug saranno scritte direttamente sul file vero senza dover fare dei noiosi copy and paste.

Questa manovra prevede qualche passaggio. Prima di spiegare il tutto è bene rimarcare che si tratta di uno strumento adatto alle versioni di sviluppo di un sito web, come un classico LAMP ad esempio. Per cui non è adatto/consigliato a modifiche su un sito in produzione dove generalmente si deve effettuare una sessione SSH o FTP.

Partiamo con l’entrare in modalità di Debug, generalmente lo faccio con tasto destro sulla pagina e “Ispeziona Elemento“, oppure con la combo di tasti CTRL+SHIFT+I (CMD+OPT+I su osx). Una volta dentro nelle Tab in alto andate a cercare la voce “Sources“. Si vedrà sostanzialmente la struttura file del vostro sito web, o perlomeno la parte che è stata interessata/caricata. Nell’albero alla vostra sinistra potremo fare tasto destro in uno dei rami e scegliere “Add folder to workspace“. Si veda l’immagine sottostante.

Possiamo benissimo indicare la cartella root del nostro WordPress che abbiamo sull’ambiente di sviluppo. Può essere fornita una cartella sul PC o una cartella di rete. Verrà chiesto, con un barra di notifica posta in alto, l’autorizzazione a poter scrivere (da parte del browser) sul nostro sistema. E’ una richiesta che si limita solo all’utilizzo della modalità di debug e può essere revocata in qualsiasi momento. A questo punto abbiamo indicato una posizione fisica al debugger.

Ora dobbiamo “mappare” la versione interpretata con quella presente nel workspace. In pratica scegliendo il file css, ma la cosa funziona anche per un file php, javascript o html, con il tasto destro andremo a scegliere la voce “Map to file system resource…“.

Apparirà una finestra in popup con l’albero della Workspace locale. Sceglieremo tramite il cerca, o navigando, il file che vogliamo mappare ad esempio il foglio di stile. Verrà ricaricata la pagina e da questo momento in poi ogni modifica fatta, anche e sopratutto nella tab Elements, sarà automaticamente scritta nel file di sviluppo.

Inizialmente la cosa tende un po’ ad essere sconcertante, poiché di fatto non si preme mai nessun pulsante “Salva” poiché le modifiche sono in tempo reale. Questo può essere negativo ad esempio quando ci si rende conto che le modifiche che stavamo tentando non vanno e vogliamo tornare indietro. Ci viene in aiuto la modalità “Local modifications…” che vedete anche nella immagine precedente. Si aprirà nella parte bassa del debugger una vista che mostra tutti i file modificati, se più di uno, e la possibilità di ritornare alla versione originale (o parte di esso, infatti i revert possono anche solo interessare alcune modifiche). L’importante è non chiudere il debugger.

E’ anche possibile effettuare delle ricerche che coinvolgono tutti i file delle workspace. Nella sezione “search” in basso, oppure attraverso la combo CTRL+SHIFT+F (CMD+OPT-F su osx) apparirà la possibilità di cercare qualcosa, anche utilizzando espressioni regolari. Nel caso invece si voglia cercare all’interno del file corrente si utilizzerà la combo CTRL+O (CMD+O su osx).

La parte locale rimane persistente sul vostro browser, per cui una volta chiuso il debugger e riaperto continuerete a vedere la cartella locale. Per fare in modo di cancellarla potete scegliere con il solito tasto destro la voce “Remove folder from workspace“. Con questa manovra abbiamo anche revocato il diritto di scrittura di cui abbiamo accennato in precedenza.

Questa descritta è una parte, sebbene fondamentale, delle funzioni di Persistent Authoring, ad esempio è possibile creare un nuovo file, escludere porzioni della cartella locale o salvare i file con nome differente. Sicuramente Google aggiungerà moltissime opzioni in futuro, se non addirittura arrivare ad una funzione di IDE o Editor vera e propria.