Thinking Angular

16 dicembre 2014

AngularJS è sempre più popolare tra chi si lavora allo sviluppo per il Web. Ne troviamo conferma anche analizzando le statistiche di ricerca di Google Trends. Il seguente grafico, ad esempio, mostra il confronto tra il numero di ricerche su Google che coinvolgono alcuni dei più popolari framework di sviluppo JavaScript:

Tuttavia l’interesse crescente verso questo framework non vuol dire che esso sia effettivamente utilizzato su larga scala. Il numero di applicazioni Web sviluppate con AngularJS non è attualmente proporzionale all’interesse suscitato. I motivi sono da ricercare da un lato alla relativa giovinezza del progetto dall’altro alla non facile digeribilità del modello di programmazione proposto quando si va oltre il classico “Hello world”.

La curva di apprendimento

Di solito il primo approccio con AngularJS seguendo un tutorial o un workshop suscita un certo entusiasmo. Vedere come con minime istruzioni è possibile avere già un prototipo funzionante è uno stimolo notevole per suscitare l’interesse dello sviluppatore.

Spesso però ci si ferma alla superficie e si immagina che tutto sia fattibile con i quattro concetti appresi nel corso della presentazione, scontrandosi invece con la reale complessità del framework. Infatti, una cosa che normalmente non viene esplicitamente detta nelle presentazioni di AngularJS è che si tratta di un framework complesso, per la cui effettiva padronanza possono servire mesi di utilizzo sul campo.

In mancanza di una consapevolezza della complessità di questo framework, la curva di apprendimento non è lineare, come ben evidenzia il grafico semiserio pubblicato da Ben Nadel sul suo blog:

Curva di apprendimento di AngularJS

Differenza tra framework e librerie

Innanzitutto occorre fare una distinzione tra framework e librerie. Sembra una cosa banale, ma spesso chi lavora con JavaScript è abituato ad utilizzare librerie che semplificano la gestione di uno o più aspetti dello sviluppo.

Ad esempio, come è noto, jQuery è una libreria che semplifica la manipolazione del DOM, Underscore invece mette a disposizione funzioni di utilità nella manipolazione di array, oggetti ed altre problematiche comuni, D3.js è una libreria specializzata nel rendering grafico di dati.

Le aspettative dello sviluppatore sono legittime, ma non tengono conto del fatto che va seguita una certa logica, un certo modo di ragionare, quello che spesso viene indicato come the Angular way.

  • Una libreria, quindi, è un insieme di funzionalità che semplificano lo sviluppo di una particolare problematica di programmazione;
  • Un framework, al contrario, è più concentrato nel fornire una infrastruttura per lo sviluppo di applicazioni che offrire funzionalità per risolvere un problema specifico.

Possiamo dire che il problema principale che un framework intende risolvere è proprio l’organizzazione dell’architettura di un’applicazione.

Ecco, AngularJS è un framework di sviluppo JavaScript con particolare propensione al supporto di Single Page Application.

È importante fare questa distinzione tra framework e librerie perché molto spesso AngularJS viene confrontato con librerie come jQuery o altre simili con risultati fuorvianti. Confrontare AngularJS con una classica libreria è sintomo che si sta partendo con il piede sbagliato, perchè ci si attende qualcosa che il framework non prevede di offrire.

Pensare in termini architetturali

Uno degli errori più comuni è pensare di utilizzare Angular per creare delle pagine HTML a cui aggiungere un po’ dinamismo con JavaScript. Questo approccio difficilmente ha successo con applicazioni Angular di una certa complessità. È opportuno pensare che le applicazioni Angular (e, più in generale, qualsiasi Single Page Application) sono “applicazioni client-side” e non “pagine Web”.

E quando si crea un’applicazione non banale la sua architettura è fondamentale per la manutenibilità.

AngularJS mette a disposizione diversi elementi per definire l’architettura di un’applicazione: controller, servizi, direttive, filtri, ecc. Ma tutti si fondano su un concetto basilare dell’organizzazione del codice: il concetto di modulo.

Una delle best practice della programmazione JavaScript consiste nell’evitare l’uso di variabili globali. L’utilizzo dei moduli ci consente allo stesso tempo di seguire questa regola fondamentale e di organizzare il nostro codice in unità eventualmente riutilizzabili.

Il modo più semplice per creare un modulo in AngularJS è il seguente:

angular.module("mioModulo", []);

Questa istruzione crea un modulo vuoto e senza dipendenze. Possiamo aggiungere al modulo i vari componenti che creano la nostra applicazione, come nel seguente esempio:

angular.module("mioModulo")
	
	.controller("mioController", function() { 
		
		// ...
	})
	
	.service("mioServizio", function() {
	
		// ...
	});

È importante sottolineare che non è necessario che la creazione del modulo e l’aggiunta di elementi in esso avvenga nello stesso file fisico. Possiamo definire un modulo ed il suo contenuto in file diversi, disaccoppiando di fatto la corrispondenza tra file ed elementi architetturali dell’applicazione.

Questo aspetto offre una grande libertà nell’organizzazione del codice, ma purtroppo spesso può essere fonte di disorientamento.

Analizzare bene l’organizzazione del codice della propria applicazione è uno degli elementi di successo principali nello sviluppo di un’applicazione Angular.

Se vuoi aggiornamenti su Thinking Angular inserisci la tua e-mail nel box qui sotto:
 
X
Se vuoi aggiornamenti su Thinking Angular

inserisci la tua e-mail nel box qui sotto:

Ho letto e acconsento l'informativa sulla privacy

Acconsento al trattamento di cui al punto 3 dell'informativa sulla privacy