SPA, framework JS e Angular

1. Dai siti tradizionali alla Single Page Application

Nei capitoli precedenti abbiamo costruito un back-end: un server Node.js con Express che serve dati REST e una base MongoDB che li conserva. Ora il punto di vista cambia e guardiamo il problema dall'altra parte: che cosa succede nel browser quando l'utente interagisce con l'applicazione. Il punto di partenza è il sito web tradizionale, che le slide chiamano server-based application: la pagina viene caricata completamente ogni volta che viene eseguita una richiesta al server.

I problemi di questo modello sono facili da elencare. Lato client: la pagina viene caricata completamente ad ogni richiesta; l'utente deve aspettare che tutti i file siano scaricati (HTML, CSS, JS, immagini); il contenuto scaricato deve essere renderizzato; non c'è business logic lato client; non c'è un modello MVC; senza rete l'applicazione non funziona. Lato server: ad ogni richiesta la pagina deve essere generata dall'inizio; si consuma banda per inviare sempre gli stessi file; tutte le computazioni sono eseguite lato server; un cambio di tecnologia implica la riscrittura completa del codice che gestisce il rendering della pagina.

I vantaggi dichiarati dalle slide sono sei: interazione app-like; i bottoni Indietro e Avanti del browser funzionano; possibilità di funzionamento anche offline; transizioni fluide tra i diversi stati delle pagine; CSS e JS inviati solamente nella richiesta iniziale; i cambiamenti alla pagina avvengono via JavaScript, usando template e la manipolazione del DOM.

2. Perché jQuery non basta

La tentazione è di risolvere tutto con la libreria che già conosciamo, jQuery: si manipola il DOM, si fanno chiamate AJAX, e l'applicazione "funziona". Ma le slide elencano quattro problemi strutturali. Lo stato dell'applicazione risiede nel DOM: i dati vivono negli attributi e nei nodi, non in una struttura dati esplicita. Di conseguenza lo stato guida il comportamento, e non il contrario: per sapere "in che stato siamo" bisogna interrogare la pagina. Si accoppia logica e presentazione: il codice che decide è mescolato al codice che mostra. E infine jQuery non è pensato per gestire la logica di un'applicazione: è una libreria di manipolazione del DOM, non un framework applicativo.

3. La generazione dei framework JS

Per le SPA nascono diverse tecnologie, librerie e framework. Un momento simbolico è la conferenza Throne of JS a Toronto (2012), dove gli sviluppatori dei maggiori framework JS si riuniscono per discutere come affrontare il bisogno delle nuove architetture SPA. Da quel momento la storia dei tre protagonisti è ben definita:

La storia conta, ma da sola non basta: le slide la inseriscono tra i sei criteri del confronto, e gli altri cinque sono popolarità ed ecosistema, supporto aziendale, esperienza iniziale e curva di apprendimento, capacità richieste, completezza e performance. Il messaggio della lezione è una sola parola: dipende.

4. Il confronto: criteri, requisiti, completezza

Il supporto aziendale si riassume in una riga: Angular è sponsorizzato da Google, React da Facebook, mentre Vue.js riceve supporto da svariate organizzazioni di piccola/media dimensione, principalmente attraverso Patreon, un tool online dedicato ai creatori di servizi.

L'esperienza iniziale è molto diversa. Angular richiede di installare la CLI e impostare alcuni parametri prima di scrivere codice; React offre due guide, una con lo snippet dell'"Hello World" e una step-by-step completabile in un'ora; Vue basta includerlo con un tag <script>. La curva di apprendimento migliore è quella di Vue, seguito da React, che richiede un tempo leggermente superiore; Angular è distanziato, perché il suo scopo è consentire la realizzazione di applicazioni di nuova generazione anche a livelli di complessità elevati.

// installazione CLI
npm install -g @angular/cli
// creazione di un nuovo progetto
ng new my-app
// avvio del server ('open' apre automaticamente il browser)
cd my-app ng serve --open

ReactDOM.render(
  <h1>Hello, world!</h1>,
  document.getElementById('root')
);

<script src="https://cdn.jsdelivr.net/npm/vue"></script>
<div id="app">
  <button @click="count++">Count is {{ count }}<button>
</div>

I requisiti richiesti da ciascun framework spiegano molto della curva di apprendimento:

La voce "capacità richieste" riguarda soprattutto Angular: è stato scritto in TypeScript, quindi occorre conoscerlo per lavorarci. Uno sviluppatore JavaScript "standard" avrà maggiori difficoltà, dovendo prendere confidenza con la tipizzazione statica; un programmatore che proviene da C# o Java, linguaggi a tipizzazione statica, si troverà maggiormente a suo agio.

La completezza li divide in tre livelli. Angular è il framework nativamente più completo: la sua struttura all-in-one fornisce UI management, state management, routing, test end-to-end e molto altro. React è improntato principalmente sulla UI: per funzionalità avanzate serve estendere il core con strumenti esterni, come Redux e MobX per la gestione dello stato. Vue.js è un framework progressivo: il core è principalmente basato sul livello delle View, e per le funzionalità aggiuntive servono componenti extra, sia di terze parti sia ufficiali, come Vuex per lo state management centralizzato. Il riassunto delle slide è un criterio di scelta pratico: una soluzione full-featured come Angular potrebbe non essere la scelta migliore per un'applicazione che non necessita di tutte le sue funzionalità o che va realizzata in tempi brevi.

Sul piano delle performance: a causa della sua completezza all-in-one, Angular risulta la libreria più pesante, segue React e infine Vue. I benchmark mostrano una leggera deviazione di performance tra i tre, con Angular il più "lento" e Vue il più "veloce".

5. Angular: definizione, linguaggi e CLI

Angular è un framework open-source per lo sviluppo di Single Page Application. È una completa riscrittura, in TypeScript, di AngularJS, da parte dello stesso team di sviluppo; è un progetto manutenuto principalmente da Google e fa parte dello stack MEAN (MongoDB, Express, Angular, NodeJS).

È possibile sviluppare applicazioni in TypeScript, Dart o JavaScript: sebbene venga lasciata libertà di scelta, è consigliabile l'utilizzo di TypeScript. A disposizione c'è una Command Line Interface che semplifica la creazione della struttura dell'applicazione, basata su Node e installabile con npm install -g angular-cli. I comandi principali sono tre:

6. Moduli: gli NgModule

Angular ha un proprio sistema di moduli, chiamato Angular modules o NgModules. Ogni applicazione ha almeno un modulo Angular — il modulo root, solitamente chiamato AppModule. Un NgModule è una classe con un decoratore @NgModule, che prende in input un oggetto metadata le cui proprietà descrivono il modulo:

7. Componenti e ciclo di vita

I Component sono le unità di base delle UI delle applicazioni Angular: un'applicazione è un albero di componenti. Un Component è una classe "adornata" con il decoratore @Component: questa classe rende disponibili dei dati al template e gestisce la logica di interazione con l'utente. Le proprietà principali del decoratore sono selector (il selettore CSS che identifica il componente in un template), template/templateUrl (la vista, inline o in un file esterno) e styles/styleUrls (lo stile, inline o esterno).

Il modo in cui si progetta un albero di componenti è illustrato con il mockup di una Inventory Management App: dato il disegno della pagina, si suddividono gli elementi in componenti di alto livello — Navigation Component, Breadcrumbs Component e Product List Component — e poi si scende di livello: Product List può essere diviso in Product Row, e ogni Product Row in Product Image, Product Department e Price Display.

I lifecycle hook

I metodi "hook" sono eventi a cui è possibile registrarsi e che vengono chiamati da Angular durante il ciclo di vita di direttive e componenti. Questi metodi di callback sono chiamati dopo la chiamata al costruttore, nell'ordine riportato dalle slide. Esplorateli con il widget: ogni hook descrive il momento in cui Angular lo invoca.

8. Template e data binding

Il template rappresenta la vista del componente, ovvero come deve essere renderizzato; è composto da tag HTML e dalla sintassi di Angular per il template. Il data binding è il meccanismo per coordinare la comunicazione tra un componente e il suo template: aggiungendo al template HTML il markup per eseguire il binding, si specifica ad Angular come connettere il DOM e il Component. Le direzioni possibili sono quattro, ed è importante distinguerle:

La interpolazione usa le doppie parentesi graffe: l'espressione viene valutata e infine convertita in una stringa. Sono proibite espressioni che hanno side effect (come gli assegnamenti), e le espressioni possono contenere proprietà del Component che controlla la vista. Il property binding usa le parentesi quadre: l'espressione tra i doppi apici viene valutata e assegnata all'attributo di un elemento del DOM, con le stesse considerazioni dell'interpolazione.

<p>
  <img src="{{heroImageUrl}}"> is the
  <i>interpolated</i> image.
</p>
<p>
  "<span>{{title}}</span>" is the
  <i>interpolated</i> title.
</p>

<p>
  <img [src]="heroImageUrl"> is the
  <i>property bound</i> image.
</p>
<p>
  "<span [innerHTML]="title"></span>"
  is the <i>property bound</i> title.
</p>

L'event binding consente di definire un handler per un determinato evento, ad esempio i movimenti del mouse o i click: <button (click)="onSave()">Save</button>. Il two-way data binding è l'unione di property ed event binding: il valore fluisce dal DOM al component e viceversa, con la sintassi "banana in a box" — <input [(ngModel)]="element" /> — che è l'abbreviazione di [ngModel] più (ngModelChange)="element = $event". Il data binding è importante anche per la comunicazione tra component padre e figlio.

9. Pipe e direttive

Le Pipe sono un modo di scrivere trasformazioni di un valore direttamente nel template: {{ value | pipe }}. È possibile parametrizzarle — Today is {{ curdate | date:"dd/MM/yy" }} — e concatenarle. Le pipe built-in includono DatePipe, UpperCasePipe, CurrencyPipe e PercentPipe; pipe personalizzate si creano con il decoratore @Pipe.

Le direttive sono di tre tipi: i Components, che sono direttive con un template; le direttive strutturali, che cambiano il layout del DOM aggiungendo o rimuovendo elementi; le direttive dell'attributo, che cambiano l'aspetto o il comportamento di un elemento, componente o di un'altra direttiva.

Direttive strutturali

Si applicano a un elemento "host", con cui la direttiva fa tutto quello che deve fare (anche con i suoi discendenti), e sono semplici da riconoscere: il loro nome è preceduto da un asterisco. Le built-in sono ngIf, ngSwitch e ngFor.

• *ngIf visualizza o meno un elemento in base alla condizione: se il risultato dell'espressione è falsy, l'elemento è rimosso dal DOM. Esempi: *ngIf="false" (mai visualizzato), *ngIf="a > b", *ngIf="str == 'yes'", *ngIf="myFunc()" (visualizzato se restituisce truthy).
• ngSwitch (con *ngSwitchCase e *ngSwitchDefault) mostra elementi diversi in base a una condizione: [ngSwitch]="myVar" con i casi 'A', 'B', 'C' e il default "Var is something else".
• *ngFor ripete l'elemento del DOM su una collezione: *ngFor="let city of cities". La sintassi estesa è *ngFor="let item of items; index as i; trackBy: trackByFn" ed esporta index (numero), first/last (booleani), even/odd (booleani sulla parità dell'indice).

Direttive dell'attributo

Idealmente, una direttiva dovrebbe lavorare in modo da essere "component agnostic" e non legata ai dettagli implementativi. Le built-in sono ngClass, ngNonBindable e ngStyle:

• ngClass setta o cambia le classi CSS di un elemento: [ngClass]="{bordered: false}", [ngClass]="{bordered: isB}" — si usa un object literal le cui chiavi sono i nomi delle classi e i valori le condizioni.
• ngNonBindable specifica una sezione della pagina che non sarà compilata né bindata: <span class="pre" ngNonBindable>{{ variablename }}</span> stampa letteralmente {{ variablename }}.
• ngStyle setta una proprietà CSS a un elemento del DOM: <span [ngStyle]="{color: color}">{{ color }} text</span>.

Infine <ng-container> è un elemento di raggruppamento che non interferisce con lo stile o con il layout, perché Angular non lo aggiunge al DOM: si usa quando non si ha a disposizione un elemento "contenitore" o quando si vuole applicare una direttiva a semplice testo.

10. Servizi e dependency injection

I servizi sono una vasta categoria che comprende qualsiasi valore, funzione o caratteristica di cui l'applicazione ha bisogno; un servizio è tipicamente una classe con uno scopo ben definito, come il logging o il caricamento di dati. Angular non ha una definizione formale di servizio: non prevede una classe base né un posto obbligatorio in cui registrarli.

La divisione dei compiti è netta: il compito del Component è di gestire la User eXperience. Un Component non dovrebbe caricare i dati dal server o validare l'input di un utente: questi compiti devono essere delegati ai servizi.

La dependency injection è un modo di fornire una nuova istanza di una classe con le dipendenze che richiede pienamente formate. Molte dipendenze sono servizi, e Angular stabilisce di quali servizi un component necessita guardando i tipi dei parametri del costruttore. Quando crea un componente, Angular chiede all'injector i servizi richiesti; l'injector mantiene un container delle istanze dei servizi già creati e, se l'istanza richiesta non c'è, la crea e la aggiunge al container; quando tutti i servizi sono risolti, chiama il costruttore con quelli come argomenti.

11. Form, HTTP, routing e architettura dei dati

Angular mette a disposizione strumenti completi per la gestione dei form: FormControl incapsula in un oggetto l'input del form e il suo stato (valido, sporco, con errori); FormGroup è un wrapper di una collezione di FormControl; i Validator validano l'input; gli Observer rilevano cambiamenti e reagiscono di conseguenza.

Per le chiamate API esterne c'è una libreria HTTP propria, asincrona, con i metodi get, post, put e così via. I tre approcci principali alla programmazione asincrona sono Callbacks, Promises e Observables: l'approccio scelto da Angular sono gli Observables — i metodi di HTTP restituiscono degli Observables, e Angular incorpora RxJS e lo usa internamente.

Per la navigazione tra più pagine c'è il modulo Router. Servono quattro passaggi: inserire il tag html <base> nella pagina principale; definire le rotte come array di oggetti che mappano i path ai component; inserire la direttiva router-outlet nella view principale; definire dei link con l'attributo routerLink.

Sulla data architecture Angular è estremamente flessibile: ci sono molti modi per ottenere dati — richieste AJAX, Websockets, local storage, Service Workers — e Angular non consiglia un'architettura particolare ma cerca di rendere facile l'uso di quella scelta. Le architetture più utilizzate sono MVC/two-way data binding, Flux (pattern basato su un flusso di dati unidirezionale) e Observables (ci si iscrive a stream di dati e si eseguono azioni in reazione ai cambiamenti).

Due note di integrazione. Nonostante le differenze tra AngularJS e le versioni successive esistono costrutti per l'interoperabilità: è possibile creare applicazioni ibride che eseguono contemporaneamente AngularJS e Angular, molto utile per aggiornare incrementalmente le applicazioni basate su AngularJS. E NativeScript è un framework per lo sviluppo cross platform di applicazioni mobile basato su JavaScript, TypeScript o Angular: come React Native e Xamarin, non renderizza una web view ma utilizza i componenti UI nativi, migliorando le performance. Chiude il quadro la Style Guide della documentazione ufficiale, che regola sintassi, convenzioni e struttura dell'applicazione con raccomandazioni divise in Do (dovrebbe essere sempre seguita), Consider (dovrebbe generalmente essere seguita), Avoid (non dovrebbe mai essere fatto) e Why? (il motivo della raccomandazione).

Verifica le tue conoscenze