Negli articoli precedenti abbiamo introdotto javascript come linguaggio e parlato dei diversi tipi di dato che è possibile memorizzare attraverso le variabili.
In questo articolo vedremo come utilizzare i principali browser per una serie di verifiche preliminari riguardo al codice ed eliminare possibili cause di errore e mal funzionamento.
Uno degli aspetti per cui i test vengono svolti su browser diversi è dovuto al fatto che ogni browser possiede un proprio motore di rendering e può avere interpretazioni diverse per una porzione di codice HTML, CSS o Javascript.
Oggi giorno questi casi sono più limitati che in passato e utilizzando alcuni strumenti si possono escludere le principali cause di errore.
Validazione del codice
Uno dei primi aspetti da tenere in considerazione sono possibili errori di sintassi, gli errori di sintassi possono causare il mancato funzionamento di uno script o alterarne il risultato.
Considerata la stretta relazione tra HTML, CSS e Javascript un errore di battitura in uno dei tre linguaggi può alterare il funzionamento negli altri causando problemi in fase di rendering. Per validare quindi il codice è possibile utilizzare validatori specifici per i tre linguaggi.
Per l’HTML le due migliori alternative sono il validatore W3C o il validatore del Whatwg.
Per il css abbiamo il validatore w3c destinato ai css mentre per javascript possiamo utilizzare jslint che offre numerose opzioni per la validazione.
Questi validatori sono disponibili online e per molti browser esistono toolbar per richiamarli direttamente come ad esempio la web developer toolbar per firefox o web developer per google chrome.
Tali strumenti sono disponibili anche per vari editor, per esempio per sublime text 2 esistonono pacchetti per la validazione w3c e per la validazione con jslint.
Il vantaggio di avere un tool per la validazione nell’editor è che si può anticipare la validazione prima dei test su browser riducendo così i tempi di sviluppo. Rimane comunque utile avere strumenti di controllo anche sui browser per poter effettuare verifiche veloci magari in fase di analisi di un sito.
Verificare le chiamate e le nomenclature
Un altro errore comune è rappresentato dai comuni errori di battitura, accentuanto dal fatto che javascript è un linguaggio case sensitive, capita quindi spesso su grandi quantità di codice e con un’assidua attività di programmazione di incappare in questo tipo di errori.
Per intercettare rapidamente eventuali errori presenti nelle chiamate a file esterni o librerie è utile normalmente utilizzare il pannello di sviluppo presente nel browser.
Il pannello di sviluppo è uno strumento di test e verifica per la pagina attualmente aperta nel browser, tutte le modifiche ed interventi sulla pagina sono sempre temporanei ed ovviamente limitati al nostro client (non interveniamo quindi sui file presenti sul server ma sulla copia del file scaricata dal client).
Per accedere al menu di sviluppo normalmente si può ricercare nel menu la voce “sviluppo” o “console”, per ogni browser e sistema operativo esistono shortcut diverse, è quindi importante familiarizzare con i comandi che si utilizzano di più.
Di seguito i link con elecanti i vari shortcut suddivisi per browser:
Anche a prima vista le console sembrano diverse a livello d’interfaccia, presentano tutte strumenti analoghi dai comportamenti comuni.
Un pannello comune a tutti è il pannello “rete” o “network” che mostra in una tabella le varie chiamate effettuate dalla pagina a file esterni.
Occorre ricordare che questo pannello registra le chiamate su protocolli http e https nel caso quindi di un file locale sulla propria macchina vedremo solo le chiamate a file esterni e non ai file sulla stessa macchina.
La tabella network presenta quindi una lista delle risorse chiamate con una serie di informazioni, come metodo della chiamata, parametri, tempo di caricamento e il codice di risposta del server.
Quest’ultimo è molto importante in quanto ci permette di capire come viene chiamato il file, nel caso di un percorso o nome del file errato, la risorsa esterna non sarà rintracciata e il server restituirà un errore 404. Nel caso di un errore del server avremo un errore 500 o simile. In caso di risposta 300 vuol dire che il file non viene richiamato ma preso dalla cache oppure è presente un redirect verso un altro file.
In generale sarebbe opportuno verificare che tutti i file restituiscano un 200 nel caso di cache disabilitata.
Per una lista più completa di risposte da un server è consigliata la seguente lettura.
Un esempio pratico di chiamata esterna ad un file javascript
Per fare un esempio pratico di una situazione comune in cui diventa utile valutare l’effettivo caricamento di un file javascript possiamo vedere il caso di Boilerplate e della soluzione integrata per il caricamento della libreria jquery.
Il codice a cui stiamo facendo riferimento è il seguente
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>
<script>window.jQuery || document.write('<script src="js/vendor/jquery-1.11.1.min.js"><\/script>')</script>
E’ possibile consultare il sorgente su github , in questo caso abbiamo un primo tag script che si occupa di caricare la libreria di jQuery dai server Google, questa tecnica risulta conveniente per diversi fattori come il fatto che il file viene servito sotto cache e riduce i tempi di caricamento.
L’aspetto interessante è rintracciabile nella seconda linea dove nel caso in cui l’oggetto jQuery non sia definito viene creato un tag script che linkerà la un file javascript sul proprio server per jQuery.
Questa soluzione mostra come è utile sfruttare il vantaggi di un caricamento esterno tenendo però in considerazione il fatto che una risorsa esterna non essendo direttamente gestita da noi potrebbe essere assente ed è quindi utile avere un fallback.
Un test molto rapido lo si può fare caricando la index.html di boilerplate in locale sulla propria macchina. In questo caso in assenza di un protocollo http la chiamata httpless a google fallirà ma avremo comunque il file in locale ad offrirci jQuery per il nostro sito.
Per espandere questa soluzione potremmo pensare ad una rapida integrazione di Jquery UI con sistema analogo.
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>
<script>window.jQuery || document.write('<script src="js/vendor/jquery-1.11.1.min.js"><\/script>')</script>
<link rel="stylesheet" href="//ajax.googleapis.com/ajax/libs/jqueryui/1.10.4/themes/smoothness/jquery-ui.css" />
<script src="//ajax.googleapis.com/ajax/libs/jqueryui/1.10.4/jquery-ui.min.js"></script>
<script>window.jQuery.ui || document.write('<link href="css/themes/smoothness/jquery-ui.css" \/>
<script src="js/vendor/jquery-ui.min.js"><\/script>');</script>
In questo modo duplichiamo i controlli, verificando la creazione sia dell’oggetto jQuery che dell’oggetto jQuery.ui.
Utilizzare la console
Uno degli strumenti più utili durante lo sviluppo in javascript è quello della console all’interno degli strumenti di sviluppo. La console ci permette di visualizzare errori o output di test inseriti in maniera opportuna nel codice.
In precedenza abbiamo utilizzato alert() ma dovendo normalmente testare più vaariabili e contesti risulta poco pratico utilizzare un pop up per valutare eventuali output, oltre tutto l’interruzione dello script causata da alert() potrebbe invalidare alcuni test.
Per questo motivo per verificare eventuali dati all’interno di uno script possiamo utilizzare l’oggetto console comunemente molto utilizzato con il metodo log().
console.log(miavariabile);
In questo modo possiamo valutare l’output senza interruzioni dello script e vedendo realmente nella console il risultato.
L’oggetto console possiede molti metodi utili per test e debug, per il momento consigli di prenderne visione, in seguito vedremo applicazioni pratiche sugli esempi degli script che seguiranno. Seguono alcuni link di riferimento in base al browser o plugin utilizzato per la console.
Nel prossimo articolo inizieremo a parlare degli operatori e di come utilizzarli per gestire le varie tipologie di dati presenti in javascript utilizzando in maniera più intensiva la console per valutare i risultati dei nostri script.
