Nel mio precedente articolo intitolato Framework vs Script standalone, avevo elencato tutti i vantaggi che uno sviluppatore Javascript può trarre dall'uso e dal non uso di un particolare framework. Nello specifico, se è vero che tramite una libreria famosa e collaudata possiamo creare applicazioni di nuova generazione senza avere conoscenze profonde del linguaggio, è anche corretto affermare che non sempre riempire le pagine di kb per poche mansioni risulta essere una buona abitudine.
Ci sono davvero tanti esempi di ottimi script standalone che circolano in rete e che riescono a sostituire egregiamente la presenza di un framework quando la mansione è di dimensioni ordinarie: un esempio classico sono i plug-in di Michael Leigeber ( http://www.leigeber.com/): DropDown Menu, Table Sorter, Accordion, TinyBox e cosi via.
Perchè crearsi una propria, semplice libreria
Tuttavia, realizzare molti script standalone potrebbe portare ad un inconveniente da non sottovalutare: l'impossibilità dell'interoperabilità degli stessi. È difficile infatti integrare nella stessa applicazione o nella stessa pagina script che utilizzano sintassi differenti, che ripetono le stesse operazioni o che, peggio ancora, moltiplicano il quantitativo di risorse da utilizzare da parte del browser.
Per questo motivo, è opportuno crearsi una propria metodologia di sviluppo che segua sempre le stesse regole e la stessa sintassi, e che faccia in modo che questa raccolta di script standalone possa essere integrata senza creare problemi: in questo modo, otterremo una piccola (nel nostro caso semplicissima) libreria Javascript personale.
Accorgimenti
Realizzare una libreria Javascript, per quanto semplice possa essere, richiede delle competenze piuttosto elevate da parte dello sviluppatore, prima tra tutte la buona conoscenza del linguaggio Javascript. Sono moltissimi infatti, i possibili problemi di incompatibilità che potrebbero presentarsi. Per ovviare a questo e ad altri problemi, e per fare in modo che le spiegazioni siano accessibili a tutti, negli esempi che mostrerò in questo articolo utilizzeremo i seguenti accorgimenti:
- il codice Javascript non
- gli esempi che andremo a creare non serviranno a realizzare applicazioni o widget visuali, ma adempieranno a task molto più semplici, come la manipolazione degli elementi. Questo perchè lo scopo dell'articolo è quello di fornire una metodologia, non un risultato particolare.
Fatte queste precisazioni, è il momento di passare ad analizzare le regole fondamentali
Regola #1: sintassi comune
La prima, fondamentale regola necessaria alla costruzione di una libreria personale, è assolutamente quella di utilizzare una sintassi ed uno schema di scrittura comune nel corso di tutto il progetto. Per capire meglio questo concetto, proviamo a pensare a due dei maggiori framework presenti in circolazione: jQuery e MooTools. Il primo utilizza una sintassi abbreviata e molto "compatta", mentre il secondo presenta getter e setter ben definiti:
// jQuery code
$('#myEl').attr('href');
$('#myEl').css('color', 'blue');
// MooTools code
$('myEl').getAttribute('href');
$('myEl').setStyle('color', 'blue');Se si mischiassero questi modelli, si otterrebbe una API incomprensibile, sia da leggere che da utilizzare. È bene dunque porsi, prima di iniziare la fasi di scrittura, delle regole precise. Nel nostro caso, a scopo illustrativo, utilizzeremo una sintassi piuttosto estesa, che non bada a risparmiare kb.
Regola #2: commenti
Quando si crea una libreria (in un qualsiasi linguaggio), ciò che non può assolutamente mancare è la documentazione. Nel caso delle librerie Javascript, raramente gli sviluppatori scrivono le documentazioni delle loro API in modo esterno, ma tendono a basarsi sui commenti lasciati nell'applicazione, oppure posizionati in appositi file esterni. Sarà poi compito di particolari engine server-side tramutare il tutto in XHTML comprensibile.
Ciò che interessa a noi, è fare in modo di capire quello che abbiamo scritto nella nostra applicazione, negli utilizzi futuri della stessa. Tutto questo si ottiene grazie alla presenza dei commenti. I commenti non devono assolutamente essere sottovalutati, la loro importanza è notevole.
Per questo motivo, anche nel caso dei commenti, sarà opportuno utilizzare una sintassi comune, oltre che esplicativa ed esaustiva (una buona abitudine è quella di inserire snippet di codice direttamente nei commenti, per esemplificare in modo diretto l'utilizzo delle funzioni o dei metodi). Ecco un esempio di commento ad una funzione Javascript:
/*
Function Name: setStyle
Description: imposta una proprietà css inline di un elemento ad un determinato valore.
Arguments:
[DOMElement] element : l'elemento DOM
[string] style : la proprietà css da impostare
[string] value : il valore css della suddetta proprietà
Demo:
setStyle($('myEl'), 'color', 'blue');
*/
function setStyle(element, style, value) {
// ...
}Regola #3: modello di programmazione
Come ho scritto nella sezione PHP nell'articolo Codice procedurale vs OOP, non esiste un modello unico di programmazione. Quelli più comuni sono sicuramente il modello procedurale e il modello OOP. È assolutamente sconsigliato mischiare più approcci nel corso della medesima applicazione Javascript: questo porterebbe i seguenti svantaggi:
- codice complicato da utilizzare per gli sviluppatori e per i possibili clienti della libreria;
- difficoltà elevata di estensibilità o integrazione con altri componenti della libreria;
- API non omogenee.
Per chiarire al meglio questo concetto, sempre a titolo esemplificativo, prendiamo ancora una volta in considerazione i framework jQuery MooTools
// jQuery code
$('#myEl').animate({color: 'red'}, 2000);
// MooTools code
var fx = new Fx.Morph('myEl', {duration: 2000});
fx.start({color: 'red'});Il risultato è pressoché il medesimo, entrambi sono altamente estensibili, ma... con un approccio totalmente differente
È dunque di fondamentale importanza scegliere un modello di programmazione da seguire nel corso di tutta l'applicazione, tra quelli più vicini alle nostre metodologie di programmazione e ai nostri gusti. Nei nostri esempi utilizzeremo una sintassi Object Oriented basata sulle classi, o meglio, su contenitori di metodi.
Regola #4: riutilizzo delle risorse e riduzione della mole di codice da scrivere
Lo scopo principale di una libreria è quello del riutilizzo delle risorse in essa contenute, senza la necessità di riscrivere ogni volta la stessa procedura. Per questo motivo, nel corso degli script che si avvalgono della nostra realizzazione, sarà una buona norma utilizzare e riutilizzare le risorse ogni volta che si presenti la necessità, senza l'aggiunta di snippet o codici nativi.
// funzione setStyle
function setStyle(element, style, value) {
// ...
}
// buona pratica
for(var i = 0; i < elementsLength; i++) {
setStyle(element[elementsLength], 'color', 'red');
}
// cattiva pratica
for(var i = 0; i < elementsLength; i++) {
element[elementsLength].style.color = 'red';
}Un'altra ottima possibilità offerta dalla presenza di una libreria è quella di fare in modo che la mole di codice da scrivere da parte dell'utente finale si riduca drasticamente. Per questo, possiamo modificare lo snippet precedente aggiungendo una più performante funzione setStyles, che imposti lo stile ad una collezione di elementi in un'unica riga di codice:
// funzione setStyles
function setStyles(elements, style, value) {
// ...
}
setStyles(elementsCollection, 'color', 'red');Regola #5: imparare dai migliori
Per quanto possiamo migliorare, per quanto il nostro codice possa essere di qualità, sarà sempre una buona regola dare un'occhiata agli approcci utilizzati dagli esperti del settore e, cosa fondamentale, capirne il perchè.
Se viene dichiarato deprecato un metodo, se viene preferito un determinato approccio ad un altro, se vengono introdotte tecniche e concetti nuovi, se vengono modificate le API: capire il perchè di queste strategie è di fondamentale importanza per la propria evoluzione personale in quanto sviluppatore. Una volta capito il punto di vista di uno sviluppatore esperto, allora la nostra opinione ed il nostro livello di qualità ci consiglieranno se essere d'accordo con lui o meno (magari il tutto può essere condito e supportato da qualche buon test). Promuovere o bocciare immediatamente questi concetti basandosi sul "sentito dire" è assolutamente l'approccio più errato da seguire.
Tra gli esperti del settore che offrono periodicamente consigli, pareri, opinioni e snippet Javascript in rete troviamo:
Conclusione
In questa prima parte dell'articolo abbiamo affrontato l'aspetto puramente teorico. Le regole fondamentali presentate sopra tuttavia, non vogliono rappresentare un punto da seguire alla lettera, ma rappresentano i consigli spassionati che costituiscono le basi di un progetto di qualità, scritto in Javascript.
Nella prossima parte affronteremo l'aspetto pratico e passeremo alla fase di realizzazione della nostra piccola libreria, che avrà una struttura modulare ed integrabile con altri moduli della stessa applicazione.
