Iniziamo a vedere come creare un’applicazione in Angular e per farlo utilizziamo il tool Angular CLI che consente di inizializzare l’applicazione stessa, creare e configurare moduli, servizi, direttive, pipe e molto altro ancora. Si tratta di uno strumento estremamente interessante e ricco di funzionalità che adopereremo nel corso di tutta la guida. In teoria potremmo tranquillamente creare un’applicazione da zero e occuparci di tutta la configurazione, ma si tratterebbe di un lavoro ripetitivo e dispendioso in termini di tempo. Angular CLI fornisce invece dei semplici comandi che permettono allo sviluppatore di rivolgere la propria attenzione solamente sull’architettura e sulla realizzazione della nuova applicazione.
Installare Angular CLI
Per installare Angular CLI utilizzeremo un package manager. Per questa guida abbiamo optato per NPM, in alternativa è possibile usare anche Yarn. Per poter usare NPM dovremo per prima cosa installare Node.js. Per maggiori informazioni potete leggere la nostra guida a Node.js o consultare il sito ufficiale.
Una volta installato NPM, possiamo impartire il seguente comando che installa Angular CLI globalmente in modo da poter successivamente eseguire i comandi via linea di comando.
npm install -g @angular/cliDopo aver completato l’installazione correttamente, possiamo lanciare il seguente comando per visualizzare maggiori informazioni su Angular CLI e l’ambiente di sviluppo.
ng --version
_ _ ____ _ ___
/ _ __ __ _ _ _| | __ _ _ __ / ___| | |_ _|
/ | _ / _ | | | | |/ _ | __| | | | | | |
/ ___ | | | | (_| | |_| | | (_| | | | |___| |___ | |
/_/ __| |_|__, |__,_|_|__,_|_| ____|_____|___|
|___/
Angular CLI: 7.0.3
Node: 8.11.3
OS: darwin x64
Angular:
...
Package Version
------------------------------------------------------
@angular-devkit/architect 0.10.3
@angular-devkit/core 7.0.3
@angular-devkit/schematics 7.0.3
@schematics/angular 7.0.3
@schematics/update 0.10.3
rxjs 6.3.3Il comando ng –help mostra invece un elenco delle opzioni e dei comandi disponibili. Per maggiori dettagli sui singoli comandi useremo invece ng [nome-comando] –help. (Per esempio ng new –help mostra l’elenco di tutte le opzioni che è possibile usare in fase di inizializzazione di un nuovo progetto)
Creare un nuovo workspace con ng new
Il comando ng new (oppure semplicemente ng n) permette di creare e configurare l’ambiente di sviluppo della nostra applicazione Angular. Accetta un unico argomento opzionale, ovvero il nome dell’applicazione e una serie di opzioni, anch’esse facoltative, che consentono di personalizzare la configurazione iniziale. Nella versione corrente ng new crea una nuova area di lavoro che prende il nome di Angular Workspace all’interno del quale vengono generati vari file di configurazione e le cartelle contenenti il codice vero e proprio. Oltre all’applicazione principale, contenuta all’interno della cartella src, in un Angular Workspace è possibile avere vari progetti secondari come altre applicazioni e/o librerie che, qualora presenti, sono situate nella cartella predefinita projects. (È possibile modificare il nome e il percorso di tale cartella) In questo modo si può suddividere un’applicazione di grandi dimensioni in moduli più piccoli, evitando così ripetizioni e semplificando notevolmente la condivisione del codice fra progetti diversi. Per esempio è possibile creare delle librerie grazie alle quali sarà più semplice riutilizzare dei componenti o dei servizi.
Il comando ng new funziona in due diverse modalità. Nella prima dovremo specificare tutte le opzioni via linea di comando. Come per altri comandi disponibili in Angular CLI, anche ng new offre una seconda modalità interattiva, ma meno personalizzabile, che permette di selezionare all’interno della shell come configurare il Workspace corrente. Partirà quindi il processo di inizializzazione dell’area di lavoro, saranno creati gli opportuni file e cartelle e saranno scaricate le dipendenze necessarie dal registro NPM.
Come già detto in precedenza, il comando ng new accetta anche varie opzioni. Fra queste, una delle più utili è –dry-run. Eseguendo il comando ng new –dry-run saranno elencati nella shell quali file e cartelle verrebbero creati in mancanza dell’opzione –dry-run, senza però modificare la directory di lavoro che rimarrà nello stato precedente all’esecuzione del comando. In questo modo è possibile sperimentare fra i vari comandi senza che nessun file venga scritto sul disco e senza scaricare alcuna dipendenza da NPM.
Vediamo un semplice esempio per capire meglio di cosa si tratta e all’interno di una nuova cartella impartiamo il seguente comando:
ng new my-angular-app --dry-run --no-interactive
CREATE my-angular-app/README.md (1029 bytes)
CREATE my-angular-app/angular.json (3840 bytes)
CREATE my-angular-app/package.json (1321 bytes)
CREATE my-angular-app/tsconfig.json (408 bytes)
CREATE my-angular-app/tslint.json (2837 bytes)
CREATE my-angular-app/.editorconfig (245 bytes)
CREATE my-angular-app/.gitignore (503 bytes)
CREATE my-angular-app/src/favicon.ico (5430 bytes)
CREATE my-angular-app/src/index.html (299 bytes)
CREATE my-angular-app/src/main.ts (372 bytes)
CREATE my-angular-app/src/polyfills.ts (3234 bytes)
CREATE my-angular-app/src/test.ts (642 bytes)
CREATE my-angular-app/src/styles.css (80 bytes)
CREATE my-angular-app/src/browserslist (388 bytes)
CREATE my-angular-app/src/karma.conf.js (964 bytes)
CREATE my-angular-app/src/tsconfig.app.json (166 bytes)
CREATE my-angular-app/src/tsconfig.spec.json (256 bytes)
CREATE my-angular-app/src/tslint.json (314 bytes)
CREATE my-angular-app/src/assets/.gitkeep (0 bytes)
CREATE my-angular-app/src/environments/environment.prod.ts (51 bytes)
CREATE my-angular-app/src/environments/environment.ts (662 bytes)
CREATE my-angular-app/src/app/app.module.ts (314 bytes)
CREATE my-angular-app/src/app/app.component.css (0 bytes)
CREATE my-angular-app/src/app/app.component.html (1141 bytes)
CREATE my-angular-app/src/app/app.component.spec.ts (1002 bytes)
CREATE my-angular-app/src/app/app.component.ts (218 bytes)
CREATE my-angular-app/e2e/protractor.conf.js (752 bytes)
CREATE my-angular-app/e2e/tsconfig.e2e.json (213 bytes)
CREATE my-angular-app/e2e/src/app.e2e-spec.ts (310 bytes)
CREATE my-angular-app/e2e/src/app.po.ts (208 bytes)
NOTE: The "dryRun" flag means no changes were made.L’output del comando evidenzia che nessun cambiamento è stato effettuato all’interno della directory corrente, ma se lanciassimo lo stesso comando omettendo l’opzione –dry-run, verrebbero creati i file elencati all’interno di una cartella ‘my-angular-app’ che è il nome usato per questo progetto.
Struttura di un’applicazione inizializzata con Angular CLI
Se dunque eseguiamo il comando ng new my-angular-app --no-interactive, Angular CLI provvede a scaricare e installare i pacchetti NPM necessari all’interno di una cartella principale denominata my-angular-app. Crea quindi i seguenti file e cartelle:
tree -a -L 2 --dirsfirst -F
.
my-angular-app/
e2e/
node_modules/
src/
.editorconfig
.gitignore
README.md
angular.json
package-lock.json
package.json
tsconfig.json
tslint.json
4 directories, 8 files- Una cartella e2e/ contenente i file necessari per i test end-to-end di Protractor.
- Una cartella node_modules/ in cui sono presenti tutti i package scaricati da NPM e elencati nel file package.json fra le dipendenze.
- Una cartella src/ contenente i file sorgente e di configurazione dell’applicazione iniziale che è l’applicazione predefinita per i comandi di Angular CLI. Come detto in precedenza, Angular CLI supporta più applicazioni e librerie all’interno di un unico Workspace, ma le applicazioni e le librerie "secondarie" saranno inserite all’interno di un’altra cartella projects (se non specificato diversamente) all’interno della cartella base.
Nella directory base sono anche presenti dei file di configurazione:
- Il file README.md (in formato Markdown) contiene una breve descrizione del progetto appena generato con alcuni dei comandi base come ng serve e ng build di cui parleremo a breve.
- I file tsconfig.json e tslint.json rappresentano i file di configurazione per TypeScript e il rispettivo linter TSLint usato per analizzare il codice sorgente.
- I file di configurazione di NPM package-lock.json e package.json contengono diverse informazioni utili sul progetto corrente come la lista delle dipendenze. All’interno del file package.json è anche presente una sezione scripts che possiamo personalizzare a seconda delle nostre esigenze per esempio per lanciare un comando di Angular CLI con delle determinate opzioni.
- Il file .gitignore è invece usato da Git per determinare quali file e directory ignorare prima di effettuare un commit.
- Il file .editorconfig aiuta gli sviluppatori a definire e mantenere stili coerenti tra diversi editor e IDE. Per esempio permette di definire il tipo di indentazione (indent_style = space) e il numero di spazi o tab da utilizzare (indent_size = 2).
- Il file angular.json è il file di configurazione del Workspace generato e modificato da Angular CLI. Tale file è stato rinominato a partire dalla versione 6 di Angular CLI. In progetti che usano una versione precedente di Angular CLI è possibile trovare al suo posto un file angular-cli.json. Se apriamo questo file noteremo che per Angular CLI sono attualmente presenti due progetti nel nostro Workspace: my-angular-app-e2e e my-angular-app che è quello predefinito. Per l’applicazione di default è stata impostata la proprietà prefix pari al valore app. Vedremo che in questo modo tutti i nomi dei selettori dei componenti avranno proprio app come prefisso. Sulla documentazione ufficiale è consigliato di personalizzare il prefisso in fase di inizializzazione di un nuovo progetto attraverso l’opzione –prefix del comando ng new. Così facendo si diminuisce il rischio di conflitto dei nomi dei selettori dei componenti. Notiamo inoltre che la cartella in cui verranno create delle librerie o applicazioni secondarie sarà la cartella projects.
Passiamo ora alla sottocartella src/ all’interno della quale troviamo invece i file di configurazione e il codice sorgente specifico dell’applicazione predefinita del Workspace. Alcuni di questi file vengono usati direttamente da Angular e non è necessario modificarli per lo sviluppo di una semplice applicazione.
tree my-angular-app/src -a -L 2 --dirsfirst -F
my-angular-app/src
app/
app.component.css
app.component.html
app.component.spec.ts
app.component.ts
app.module.ts
assets/
.gitkeep
environments/
environment.prod.ts
environment.ts
browserslist
favicon.ico
index.html
karma.conf.js
main.ts
polyfills.ts
styles.css
test.ts
tsconfig.app.json
tsconfig.spec.json
tslint.json
3 directories, 19 filesAll’interno della cartella src/ troviamo quindi i seguenti file:
- i file di configurazione per TypeScript e TSLint specifici per l’applicazione e i test di unità (tsconfig.app.json, tsconfig.spec.json e tslint.json) che estendono la configurazione dei rispettivi file presenti nella cartella base del Workspace.
- il file test.ts che è l’entry point per i test di unità e presenta alcune configurazioni per l’esecuzione dei test stessi.
- il file karma.conf.js serve invece per configurare il test runner Karma usato per eseguire i test di unità.
- il file polyfills.ts comprende i polyfill necessari per supportare i browser meno recenti. Un polyfill è un frammento di codice Javascript impiegato per rimediare alla mancanza di certe funzionalità su browser meno recenti che non le supportano in modo nativo.
- il file style.css è il foglio di stile in cui potremo inserire le regole globali valide per l’intera applicazione. Nel nostro caso si tratta di un normale file .css, ma in fase di esecuzione del comando ng new avremmo potuto indicare la volontà di usare un preprocessore CSS. Per esempio se avessimo optato per SASS, ci ritroveremmo con un file avente estensione .scss o .sass a seconda della scelta fatta attraverso la modalità interattiva o tramite l’opzione –style.
- il file favicon.ico rappresenta la favicon di default usata come icona nella scheda del browser in cui è aperta la nostra applicazione e nella barra dei segnalibri.
- il file browserslist è attualmente usato da Autoprefixer per modificare delle regole CSS a cui vengono eventualmente aggiunte le dichiarazioni con gli appositi vendor prefixes al fine di supportare i browser specificati proprio nel file browserslist. Quest’ultimo presenta una lista di browser la quale viene utilizzata da vari strumenti per lo sviluppo di applicazioni web.
- il file main.ts è il punto di ingresso (entry point) della nostra applicazione e contiene il codice per avviare il modulo base (root module) dell’applicazione stessa. Nella prossima lezione analizzeremo in maggiore dettaglio il codice in esso contenuto per capire meglio in che modo Angular esegue la fase di bootstrap dell’applicazione.
- il file index.html è la pagina HTML principale che viene mostrata all’utente quando qualcuno accede alla nostra applicazione. Angular CLI dietro le quinte utilizza Webpack e provvede ad inserire automaticamente tutti i file Javascript e CSS necessari durante la fase di build dell’applicazione. Quindi in genere non è necessario aggiungere nessun elemento <script> o <link> manualmente al suo interno.
Insieme ai file sopra elencati troviamo poi tre cartelle:
- assets contiene immagini e altre risorse da copiare nella cartella in cui verranno inseriti i file della nostra applicazione in seguito alla fase di build. Inizialmente troviamo al suo interno un file vuoto .gitkeep. Non si tratta di un file speciale, ma è la convenzione che viene spesso usata per chiedere a Git di tenere traccia di una cartella che se fosse vuota sarebbe ignorata dal software di controllo versione.
- environments presenta diversi file in cui possiamo definire delle variabili d’ambiente. Possiamo aggiungere dei nuovi file o modificare quelli presenti. Di default ci sono solo due file, ovvero environment.ts e environment.prod.ts. In entrambi sono definiti due oggetti environment aventi la proprietà production settata rispettivamente a false e true. Vedremo che tale proprietà verrà usata all’interno del file main.ts.
- la cartella app/ contiene sostanzialmente il cuore della nostra applicazione. Al suo interno verranno creati i file necessari per definire per esempio dei componenti che sono l’elemento fondamentale su cui si basa la costruzione di un’applicazione in Angular. Dopo aver eseguito il comando ng new, nella cartella app/ troviamo i seguenti file:
- app.component.ts in cui è presente la logica del componente base della nostra applicazione denominato AppComponent. Si tratta di una classe TypeScript a cui è associato un decoratore particolare @Component che permette di definire il componente stesso.
- app.component.html contiene il template HTML associato al nostro componente. Vedremo nelle prossime lezioni che Angular offre la possibilità di definire il template di un componente in un file esterno solitamente denominato <nome-componente>.component.html o aggiungendo il codice HTML direttamente nell’oggetto che viene passato come argomento al decoratore @Component.
- app.component.css presenta le regole CSS per l’omonimo componente. Le regole definite in questo file saranno valide solo per il componente AppComponent.
- app.component.spec.ts definisce i test d’unità per il componente AppComponent.
- app.module.ts contiene il codice TypeScript che definisce il modulo base (root module) AppModule. Un modulo in Angular può essere visto come un contenitore che raggruppa diverse parti di un’applicazione aventi una qualche relazione fra loro.
Per il comando ng new esistono numerose opzioni che possono risultare utili, ma che trascuriamo al momento. Con il comando ng new –help possiamo però ottenere un elenco completo. Il significato di alcune di queste opzioni potrebbe sembrare di difficile comprensione al momento, ma risulterà più chiaro dopo aver completato le prossime lezioni.
Ampliare un’applicazione con ng generate
Il comando ng generate è probabilmente uno dei comandi più utile durante la fase di sviluppo perché consente di modificare opportunamente la configurazione di un’applicazione e generare i file necessari per definire moduli, componenti, servizi, pipe (affronteremo ciascuno di questi argomenti nelle prossime lezioni) e creare applicazioni o librerie secondarie. In tutti i casi la sintassi è simile ed è la seguente:
ng generate <schematic>Senza voler entrare troppo nello specifico, possiamo pensare a uno schematic come un modello che definisce quali file devono essere aggiunti o modificati nel nostro progetto. In termini pratici è possibile per esempio creare:
- un nuovo componente eseguendo ng generate component <nome-componente>
- un nuova direttiva con ng generate directive <nome-direttiva>
- un nuovo servizio grazie a ng generate service <nome-servizio>
- un nuovo modulo lanciando ng generate module <nome-modulo>
- una pipe eseguendo ng generate pipe <nome-pipe>
- una semplice classe tramite il comando ng generate class <nome-classe>
- un’interfaccia attraverso ng generate interface <nome-interfaccia>
E quelli appena elencati sono solo alcuni esempi che permettono di capire quanto sia versatile il comando ng generate <schematic> (o in maniera equivalente ng g <schematic>) il quale accetta anche varie opzioni come –interactive e –dry-run che hanno un effetto simile a quello visto in precedenza con il comando ng new.
Illustriamo allora quali file verrebbero creati nel caso in cui lanciassimo il comando ng generate component. Per lasciare intatta la cartella di lavoro corrente, usiamo l’opzione –dry-run.
ng g c my-new-component --spec false --dry-run
CREATE src/app/my-new-component/my-new-component.component.css (0 bytes)
CREATE src/app/my-new-component/my-new-component.component.html (35 bytes)
CREATE src/app/my-new-component/my-new-component.component.ts (307 bytes)
UPDATE src/app/app.module.ts (432 bytes)
NOTE: The "dryRun" flag means no changes were made.Nel frammento di codice riportato sopra, abbiamo impartito il comando "ng generate component" utilizzando una sintassi abbreviata. Il nuovo componente creato sarà automaticamente inserito in una nuova directory (my-new-component) che raggruppa tutti i file ad esso associati. Manca il file dei test di unità visto che abbiamo specificato con l’opzione spec=false di non crearlo. Inoltre possiamo notare che Angular CLI aggiorna il file app.module.ts perché di default il nuovo componente è parte del modulo base AppModule
Se non volessimo inserire i file del nuovo componente in una cartella separata, ma volessimo lasciarli nella directory app/, potremmo usare l’opzione flat=true come mostrato sotto.
ng g c my-new-component --flat true --dry-run
CREATE src/app/my-new-component.component.css (0 bytes)
CREATE src/app/my-new-component.component.html (35 bytes)
CREATE src/app/my-new-component.component.spec.ts (686 bytes)
CREATE src/app/my-new-component.component.ts (307 bytes)
UPDATE src/app/app.module.ts (415 bytes)Il comando ng generate consente di creare anche delle applicazioni o librerie secondarie.
ng g app my-new-app --dry-run
CREATE projects/my-new-app/src/favicon.ico (5430 bytes)
CREATE projects/my-new-app/src/index.html (295 bytes)
CREATE projects/my-new-app/src/main.ts (372 bytes)
CREATE projects/my-new-app/src/polyfills.ts (3234 bytes)
CREATE projects/my-new-app/src/test.ts (642 bytes)
CREATE projects/my-new-app/src/styles.css (80 bytes)
CREATE projects/my-new-app/src/assets/.gitkeep (0 bytes)
CREATE projects/my-new-app/src/environments/environment.prod.ts (51 bytes)
CREATE projects/my-new-app/src/environments/environment.ts (662 bytes)
CREATE projects/my-new-app/browserslist (388 bytes)
CREATE projects/my-new-app/karma.conf.js (967 bytes)
CREATE projects/my-new-app/tsconfig.app.json (172 bytes)
CREATE projects/my-new-app/tsconfig.spec.json (270 bytes)
CREATE projects/my-new-app/tslint.json (317 bytes)
CREATE projects/my-new-app/src/app/app.module.ts (314 bytes)
CREATE projects/my-new-app/src/app/app.component.css (0 bytes)
CREATE projects/my-new-app/src/app/app.component.html (1141 bytes)
CREATE projects/my-new-app/src/app/app.component.spec.ts (990 bytes)
CREATE projects/my-new-app/src/app/app.component.ts (214 bytes)
CREATE projects/my-new-app-e2e/protractor.conf.js (752 bytes)
CREATE projects/my-new-app-e2e/tsconfig.e2e.json (219 bytes)
CREATE projects/my-new-app-e2e/src/app.e2e-spec.ts (306 bytes)
CREATE projects/my-new-app-e2e/src/app.po.ts (208 bytes)
UPDATE angular.json (7913 bytes)
UPDATE package.json (1321 bytes)
NOTE: The "dryRun" flag means no changes were made.Nell’esempio riportato sopra, creiamo un’applicazione secondaria con il comando ng generate application (equivalente a ng g app). I file verranno inseriti in ‘my-new-app’ nella sottocartella ‘project’ della directory base ‘my-angular-app’. In questo caso verrebbe modificato anche il file di configurazione angular.json per tener traccia della nuova applicazione creata.
Preparare la versione finale di un’applicazione con ng build
Il comando ng build compila un’applicazione in una directory predefinita denominata dist/ che è possibile tuttavia personalizzare con l’opzione –outputPath con la quale indicheremo il percorso completo per la nuova directory di output, relativa all’area di lavoro corrente. Eseguendo ng build eventuali file presenti nella cartella assets/ vengono copiati nella directory di output così come il file index.html e i file Javascript necessari per il funzionamento dell’applicazione stessa.
ng build --stats-json
Hash: f96a9185c64be18d1a67
Time: 10061ms
chunk {main} main.js, main.js.map (main) 8.64 kB [initial] [rendered]
chunk {polyfills} polyfills.js, polyfills.js.map (polyfills) 228 kB [initial] [rendered]
chunk {runtime} runtime.js, runtime.js.map (runtime) 6.22 kB [entry] [rendered]
chunk {styles} styles.js, styles.js.map (styles) 16.7 kB [initial] [rendered]
chunk {vendor} vendor.js, vendor.js.map (vendor) 3.14 MB [initial] [rendered]Nell’esempio abbiamo usato l’opzione –stats-json la quale crea un file stats.json in cui sono mantenute le informazioni per generare una rappresentazione visiva del contenuto dei file attraverso ‘webpack-bundle-analyzer’ che possiamo aggiungere al nostro progetto attraverso il comando npm i webpack-bundle-analyzer --save-dev. Dopo aver scaricato tale pacchetto dal registro NPM, se eseguiamo npx webpack-bundle-analyzer dist/my-angular-app/stats.json, otteniamo un risultato simile a quello mostrato nella seguente immagine (npx è un tool disponibile a partire da NPM 5.2 che cerca nella cartella locale /node_modules un pacchetto e, se non riesce a trovarlo, lo scarica e lo esegue evitando di dover installare quel pacchetto globalmente. Senza npx avremmo dovuto eseguire ./node_modules/.bin/webpack-bundle-analyzer dist/my-angular-app/stats.json).
All’interno della cartella dist/ nella directory base dell’area di lavoro troviamo quindi i seguenti file:
tree dist
dist
my-angular-app
favicon.ico
index.html
main.js
main.js.map
polyfills.js
polyfills.js.map
runtime.js
runtime.js.map
styles.js
styles.js.map
vendor.js
vendor.js.map
1 directory, 12 filesIl semplice comando ng build, senza altre opzioni, genera quindi un’applicazione in tempi brevi, ma non è pronta per essere distribuita. Analizzando più attentamente i file ottenuti, osserviamo infatti che:
- viene generato un file vendor.js da oltre 3MB all’interno del quale è presente il compilatore JIT (Just-In-Time) che compila il codice a runtime nel browser;
- vengono generati i file sourcemap utili in fase di debugging del codice. Tali file permettono inoltre di utilizzare un tool come source-map-explorer che, in maniera simile a quanto accade con webpack-bundle-analyzer, consente di analizzare la dimensione e la composizione dei file javascript creati;
- non viene eseguito nessun processo di minificazione (processo di rimozione di spazi vuoti, commenti e token facoltativi come parentesi graffe e punto e virgola) e uglification (processo di trasformazione del codice che abbrevia i nomi di variabili e funzioni) sui file Javascript;
- non è presente alcun file con estensione .css. Le regole presenti nei fogli di stile vengono iniettate nell’applicazione finale attraverso il codice presente nel file styles.js.
Possiamo quindi concludere che il comando ng build senza altre opzioni può risultare comodo in fase di sviluppo, ma l’applicazione ottenuta non è ottimizzata per essere pubblicata.
È possibile creare una versione ottimizzata di un’applicazione utilizzanto l’opzione –prod (production) del comando ng build.
ng build --prod --stats-json
Hash: b13b04580ffcd9d3f069
Time: 20592ms
chunk {0} runtime.ec2944dd8b20ec099bf3.js (runtime) 1.44 kB [entry] [rendered]
chunk {1} main.819728934af9e4b89e03.js (main) 171 kB [initial] [rendered]
chunk {2} polyfills.c6871e56cb80756a5498.js (polyfills) 38.4 kB [initial] [rendered]
chunk {3} styles.3a83a5ab412aca915268.css (styles) 16 bytes [initial] [rendered]
tree dist -h
dist
[ 340] my-angular-app
[ 21K] 3rdpartylicenses.txt
[5.3K] favicon.ico
[ 594] index.html
[167K] main.819728934af9e4b89e03.js
[ 37K] polyfills.c6871e56cb80756a5498.js
[1.4K] runtime.ec2944dd8b20ec099bf3.js
[ 16] styles.3a83a5ab412aca915268.css
1 directory, 7 filesIn questo caso Angular CLI impiega una serie di accorgimenti e ottimizzazioni:
- viene utilizzato il meccanismo di compilazione AOT (Ahead-of-Time Compilation) che converte il codice HTML e TypeScript in codice javascript efficiente durante la fase di build, dunque prima che il browser scarichi ed esegua quel codice. In questo modo l’applicazione avrà tempi di download, di parsing e di esecuzione più bassi. I file javascript avranno complessivamente una dimensione inferiore considerato soprattutto che viene rimosso il compilatore JIT che non è più necessario;
- vengono utilizzate tecniche di minificazione, uglification, tree-shaking e dead code elimination per ottimizzare al massimo il codice finale;
- viene separato il codice CSS all’interno di fogli di stile;
- vengono utilizzate eventuali variabili d’ambiente presenti nel file environments/environment.prod.ts invece del file environments/environment.ts
È possibile avere un’idea più chiara delle scelte effettuate da Angular CLI quando viene usata l’opzione –prod per il comando ng build analizzando la configurazione presente nel file angular.json di cui riportiamo un breve frammento qui sotto.
/* file angular.json */
"configurations": {
"production": {
"fileReplacements": [
{
"replace": "src/environments/environment.ts",
"with": "src/environments/environment.prod.ts"
}
],
"optimization": true,
"outputHashing": "all",
"sourceMap": false,
"extractCss": true,
"namedChunks": false,
"aot": true,
"extractLicenses": true,
"vendorChunk": false,
"buildOptimizer": true,
"budgets": [
{
"type": "initial",
"maximumWarning": "2mb",
"maximumError": "5mb"
}
]
}
}L’applicazione così creata nella cartella dist/ è pronta per essere distribuita.
Visualizzare un’anteprima di un’applicazione con ng serve
L’ultimo comando che vediamo in questa lezione è ng serve che consente di visualizzare in fase di sviluppo un’anteprima della nostra applicazione nel browser. Infatti, eseguendo ng serve, viene creato un web server locale all’indirizzo predefinito http://localhost:4200 che è comunque possibile personalizzare attraverso le opzioni –host e –port. Una delle funzionalità più interessanti messe a disposizione dal server locale è il live reloading che aggiorna automaticamente la pagina ogni volta che viene effettuata una modifica ai file sorgente. In questo modo sarà possibile visualizzare in tempo reale lo stato corrente di un’applicazione senza dover aggiornare manualmente il browser.
Come già detto in precedenza, può essere conveniente consultare la documentazione (ng serve –help) per una lista dettagliata delle opzioni che garantiscono un elevato livello di persanalizzazione a seconda delle proprie esigenze.
Riepilogo
In questa seconda lezione abbiamo introdotto uno strumento essenziale come Angular CLI che semplifica notevolmente lo sviluppo di un’applicazione grazie a una serie di comandi altamente personalizzabili. Abbiamo brevemente illustrato solo alcuni di questi, ma sono presenti altri comandi molto utili come ng test e ng e2e per eseguire test di unità e end-to-end. Per una lista completa dei comandi disponibili in Angular CLI, possiamo lanciare ng help o consultare la documentazione ufficiale di Angular CLI che è possibile aprire in un browser anche attraverso il comando ng doc <parola-chiave>. Nella prossima lezione vedremo come viene effettuata da parte di Angular la fase di avvio dell’applicazione.
