Un interessante articolo di Scott Gonzalez, citato da Rebecca Murphey (co-autrice di jQuery Cookbook), ha portato alla mia attenzione la necessità di organizzare il codice di un plugin di jQuery in modo più conforme alla buona pratica della riusabilità dello stesso.
Scott cita l'esempio di jQuery UI e della sua widget factory per portare alla nostra attenzione il fatto che se vogliamo evitare che i plugin di jQuery diventino ingestibili per via delle molteplici modalità di scrittura, una buona pratica sarebbe quella di aderire a convenzioni comuni e OO. $.widget() è solo un esempio: chiamatelo anche $.Class() o Class (Prototype) o anche in altri modi e modalità diversi, ma noterete che alla base di tutto c'è una rigorosa organizzazione del codice che valorizza appieno il potenziale degli oggetti in JavaScript.
Perché in JavaScript gli oggetti ci portano a organizzare il codice in componenti e a ragionare su come questi componenti interagiscono tra di loro per portare il nostro codice a fare cià per cui è stato creato. I nostri oggetti diventano parte della struttura del plugin, ed è questo che rende questo approccio un modo nuovo di scrivere plugin: far vedere all'utente la struttura.
Oggi ci sono grandi plugin, che creano effetti sbalorditivi, che non hanno bisogno di ulteriori commenti. Ma è stato per me molto difficile comprenderne la struttura senza dover passare in rassegna tutto il codice riga per riga. Certo, so che la funzione getPositions() restituisce un array dei valori degli offset delle slide, ma qual è la sua collocazione nella struttura del plugin?
La struttura è anche alla base dell'interessantissimo lavoro di documentazione che è alla base di JSDoc. Tramite commenti taggati, creiamo una view della struttura che ci permette di esclamare: "Ah, ecco, questo metodo è parte di un oggetto nel contesto X". Non solo è utile per noi, ma permette future modifiche anche da parte di chi non ha mai visto il nostro codice prima d'ora.
Forse l'esempio più lampante di dove questa passione per la struttura possa portare è rappresentato dal framework JavaScript MVC, dove jQuery sposa l'OOP nel modo più naturale possibile. Si, perchè in JavaScript niente avviene al di fuori degli oggetti.
Concludo con una nota: il senso del post non è provocatorio né vuole proporre di buttare via tutto il fantastico lavoro già svolto con i plugin. Il senso è: proviamo. Proviamo anche una via alternativa, certo non nuova, ma ricca di stimoli e sfide. E credo che di questo noi sviluppatori ci nutriamo ogni giorno nel nostro lavoro.