Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

136
Università degli Studi di Padova Dipartimento di Matematica "Tullio Levi-Civita" Corso di Laurea in Informatica Sviluppo di un’interfaccia web e analisi delle differenze fra Angular e React Tesi di laurea triennale Relatore Prof. Lamberto Ballan Laureando Alessandro Zangari Anno Accademico 2017-2018

Transcript of Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

Page 1: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

Università degli Studi di Padova

Dipartimento di Matematica "Tullio Levi-Civita"

Corso di Laurea in Informatica

Sviluppo di un’interfaccia web e analisi delledifferenze fra Angular e React

Tesi di laurea triennale

Relatore

Prof. Lamberto Ballan

Laureando

Alessandro Zangari

Anno Accademico 2017-2018

Page 2: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

Alessandro Zangari: Sviluppo di un’interfaccia web e analisi delle differenze fra Angulare React, Tesi di laurea triennale, c© Settembre 2018.

Page 3: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

Sommario

Il presente documento descrive il lavoro svolto durante il periodo di stage, della duratadi circa trecento ore, dal laureando Alessandro Zangari presso l’azienda Sync LabS.r.l. L’obiettivo dello stage era lo sviluppo di un’applicazione con la libreria React.jse lo svolgimento di un confronto fra la citata libreria e il framework Angular, che èriportato in un apposito capitolo nell’appendice A del documento.

iii

Page 4: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React
Page 5: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

Ringraziamenti

Innanzitutto, vorrei esprimere la mia gratitudine al Prof. Lamberto Ballan, relatoredella mia tesi, per l’aiuto e il sostegno fornitomi durante la stesura del lavoro.

Uno speciale ringraziamento anche al tutor aziendale Fabio Pallaro che mi ha seguito econsigliato durante questa esperienza di lavoro in azienda.

Infine desidero ringraziare con affetto i miei genitori ed amici per il sostegno e per imomenti passati durante gli anni di studio.

Padova, Settembre 2018 Alessandro Zangari

v

Page 6: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React
Page 7: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

Indice

1 Introduzione 11.1 Convenzioni tipografiche . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 L’azienda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2.1 Profilo aziendale . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2.2 Servizi offerti . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2.3 Settori di impiego . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Lo stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Piano di lavoro 52.1 Obiettivo del progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Requisiti e obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.1 Prodotti attesi . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.2 Obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.3 Pianificazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Analisi dei requisiti 93.1 Funzionamento del prodotto . . . . . . . . . . . . . . . . . . . . . . . . 93.2 Attori del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.3 Casi d’uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.3.1 Casi d’uso per l’utente base . . . . . . . . . . . . . . . . . . . . 363.4 Tracciamento dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . 45

4 Progettazione e codifica 514.1 Tecnologie e strumenti . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.1.1 Ambiente di sviluppo . . . . . . . . . . . . . . . . . . . . . . . 514.1.2 Strumenti di supporto allo sviluppo . . . . . . . . . . . . . . . 524.1.3 Linguaggio utilizzato . . . . . . . . . . . . . . . . . . . . . . . . 524.1.4 Principali dipendenze . . . . . . . . . . . . . . . . . . . . . . . 524.1.5 Creazione di un server fittizio . . . . . . . . . . . . . . . . . . . 53

4.2 Funzionamento di Redux e React.js . . . . . . . . . . . . . . . . . . . . 554.2.1 Struttura a componenti . . . . . . . . . . . . . . . . . . . . . . 554.2.2 Redux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.3 Progettazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.3.1 Elenco di endpoint . . . . . . . . . . . . . . . . . . . . . . . . . 614.3.2 Gestione dell’accesso . . . . . . . . . . . . . . . . . . . . . . . . 634.3.3 Struttura del Redux Store . . . . . . . . . . . . . . . . . . . . . 664.3.4 Componenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.3.5 Responsiveness . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

vii

Page 8: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

viii INDICE

4.3.6 Compatibilità . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5 Verifica e validazione 775.1 Pacchetti utilizzati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775.2 Validazione delle pagine HTML . . . . . . . . . . . . . . . . . . . . . . 785.3 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

5.3.1 Tracciamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

6 Descrizione delle pagine 876.1 Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 876.2 Homepage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 886.3 Gestione prenotazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

6.3.1 Selezione del giorno . . . . . . . . . . . . . . . . . . . . . . . . 886.3.2 Scheda Vista pasti . . . . . . . . . . . . . . . . . . . . . . . . . 896.3.3 Scheda Vista utenti . . . . . . . . . . . . . . . . . . . . . . . . 896.3.4 Form di aggiunta di una prenotazione . . . . . . . . . . . . . . 89

6.4 Gestione dei menù . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 926.5 Gestione dei piatti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

6.5.1 Form di aggiunta di un piatto . . . . . . . . . . . . . . . . . . . 93

7 Conclusioni 957.1 Consuntivo finale delle ore . . . . . . . . . . . . . . . . . . . . . . . . . 957.2 Raggiungimento degli obiettivi . . . . . . . . . . . . . . . . . . . . . . 957.3 Considerazioni personali . . . . . . . . . . . . . . . . . . . . . . . . . . 97

7.3.1 Tecnologie apprese . . . . . . . . . . . . . . . . . . . . . . . . . 977.3.2 Corsi propedeutici . . . . . . . . . . . . . . . . . . . . . . . . . 97

A Un confronto fra React.js e Angular 99A.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99A.2 Statistiche di utilizzo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100A.3 Architettura a componenti . . . . . . . . . . . . . . . . . . . . . . . . . 102

A.3.1 Condivisione di dati fra componenti in React . . . . . . . . . . 104A.4 Potenzialità diverse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

A.4.1 Gestione dello stato . . . . . . . . . . . . . . . . . . . . . . . . 106A.4.2 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107A.4.3 Gestione di richieste Http . . . . . . . . . . . . . . . . . . . . . 108A.4.4 Scoping del foglio di stile . . . . . . . . . . . . . . . . . . . . . 108

A.5 React, Redux e la gestione dello stato . . . . . . . . . . . . . . . . . . 110A.5.1 Cos’è Redux? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110A.5.2 React e Redux . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

A.6 Routing: React router e Angular router . . . . . . . . . . . . . . . . . 113A.7 Data binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114A.8 DOM e Virtual DOM . . . . . . . . . . . . . . . . . . . . . . . . . . . 115A.9 Ciclo di sviluppo e mantenimento . . . . . . . . . . . . . . . . . . . . . 116A.10 Strumenti di controllo statico dell’accessibilità . . . . . . . . . . . . . . 117A.11 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

A.11.1 Curva di apprendimento . . . . . . . . . . . . . . . . . . . . . . 118

Glossario 121

Bibliografia 125

Page 9: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

Elenco delle figure

1.1 Logo aziendale di Sync Lab . . . . . . . . . . . . . . . . . . . . . . . . 1

4.1 Raffigurazione del passaggio di props e invocazione di callback nell’alberodi componenti di React.js . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.2 Ciclo di interazione React-Redux . . . . . . . . . . . . . . . . . . . . . 584.3 Schema del funzionamento del token con i microservizi . . . . . . . . . 644.4 Le tre parti di un JWT token . . . . . . . . . . . . . . . . . . . . . . . 654.5 Albero dello stato dell’applicazione salvato nel Redux Store . . . . . . 674.6 Esempio di alcuni componenti all’interno del componente ResPage . . 684.7 Diagramma delle classi che descrive la struttura di Auth . . . . . . . . 714.8 Ciclo di aggiornamento di un componente con un Redux middleware . 734.9 Metodi statici della classe Http . . . . . . . . . . . . . . . . . . . . . . 734.10 La pagina di selezione del giorno con il componente react-calendar . 74

6.1 Form della pagina di accesso all’applicazione . . . . . . . . . . . . . . . 876.2 Homepage dell’applicazione per la sezione di amministrazione . . . . . 886.3 Calendario per la selezione del giorno . . . . . . . . . . . . . . . . . . . 896.4 Elenco di piatti prenotati della scheda Vista pasti . . . . . . . . . . . . 906.5 Elenco di utenti prenotati della scheda Vista utenti . . . . . . . . . . . 906.6 Utilizzo dell’attributo title per evidenziare la funzione del pulsante . 916.7 Form di aggiunta di una prenotazione nella scheda Vista utenti . . . . 916.8 Pagina di gestione del menù . . . . . . . . . . . . . . . . . . . . . . . . 926.9 Elenco di piatti e casella di ricerca . . . . . . . . . . . . . . . . . . . . 936.10 Pannello modale per l’aggiunta di un piatto . . . . . . . . . . . . . . . 93

A.1 Download settimanali di React.js e Angular da npm nel periodo daLuglio 2016 a Luglio 2018 . . . . . . . . . . . . . . . . . . . . . . . . . 100

A.2 Download mensili di React.js e Angular da npm nel periodo da Luglio2016 a Luglio 2018 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

A.3 Utilizzo di framework e librerie JavaScript fra sviluppatori raggruppatiper linguaggio di utilizzo primario . . . . . . . . . . . . . . . . . . . . 101

A.4 Interazione fra componenti e servizi in Angular . . . . . . . . . . . . . 102A.5 Esecuzione di callback verso un componente genitore in React.js . . . . 105A.6 Passaggio di props in React.js . . . . . . . . . . . . . . . . . . . . . . . 105A.7 Flusso dei dati in React con e senza Redux . . . . . . . . . . . . . . . 108A.8 Ciclo di aggiornamento con React-Redux dall’emissione di un evento

dalla view all’aggiornamento del componente . . . . . . . . . . . . . . 111

ix

Page 10: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

Elenco delle tabelle

3.1 Tabella di tracciamento dei requisiti funzionali . . . . . . . . . . . . . 453.2 Tabella di tracciamento dei requisiti qualitativi . . . . . . . . . . . . . 483.3 Tabella di tracciamento dei requisiti prestazionali . . . . . . . . . . . . 493.4 Tabella di tracciamento dei requisiti di vincolo . . . . . . . . . . . . . 49

5.1 Tabella di tracciamento dei test sui reducer . . . . . . . . . . . . . . . 795.2 Tabella di tracciamento dei test delle azioni asincrone effettuati . . . . 825.3 Tabella di tracciamento dei test sui componenti . . . . . . . . . . . . . 85

7.1 Requisiti facoltativi non soddisfatti . . . . . . . . . . . . . . . . . . . . 96

Elenco dei blocchi di codice

4.1 Esempio di componente in React.js . . . . . . . . . . . . . . . . . . . . 554.2 Una funzione action creator . . . . . . . . . . . . . . . . . . . . . . . . 574.3 Struttura della cartella nella quale sono definiti i reducer . . . . . . . . 584.4 Organizzazione della cartella del progetto . . . . . . . . . . . . . . . . 604.5 Definizione del container ViewTabs . . . . . . . . . . . . . . . . . . . . 694.6 Il componente Auth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

A.1 Dichiarazione di un servizio di Angular . . . . . . . . . . . . . . . . . . 102A.2 Dependency injection di un servizio in un componente Angular . . . . 103A.3 Un componente in React.js . . . . . . . . . . . . . . . . . . . . . . . . 104A.4 Dichiarazione di un foglio di stile privato in Angular . . . . . . . . . . 109A.5 Una action di Redux . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110A.6 Dichiarazione di un componente connesso in React . . . . . . . . . . . 112A.7 Esempio di doppio binding dei dati in Angular . . . . . . . . . . . . . 114A.8 Componente Angular per il template del codice sopra riportato . . . . 114A.9 Funzione di callback in React . . . . . . . . . . . . . . . . . . . . . . . 115

x

Page 11: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

Capitolo 1

Introduzione

Nel presente capitolo è brevemente descritta l’azienda ospitante Sync Lab S.r.l. ed è ri-portata una panoramica generale sull’idea che ha portato ad intraprendere l’attività di stage.

1.1 Convenzioni tipograficheIn tutto il presente documento sono state adottate le seguenti convenzioni tipografiche:

• I termini tecnici, alcuni nomi e termini ambigui o di uso non comune menzionatinel documento vengono definiti nel glossario, situato alla fine del documento;

• Per la prima occorrenza dei termini riportati nel glossario viene utilizzata laseguente nomenclatura: parola da glossario[g];

• La prima occorrenza per ogni capitolo di un termine inserito nel glossario èmarcata con la seguente notazione: parola da glossario. Questo con l’eccezionedella prima occorrenza nell’intero documento per cui vale la notazione al puntoprecedente;

• I termini in lingua straniera, facenti parti del gergo tecnico oppure i termini chesi vogliono enfatizzare sono evidenziati con il carattere corsivo.

1.2 L’azienda

1.2.1 Profilo aziendale

Figura 1.1: Logo aziendale di Sync Lab

1

Page 12: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

2 CAPITOLO 1. INTRODUZIONE

Sync Lab S.r.l. è una società di consulenza informatica fondata nel 2002 con sedi aNapoli, Roma, Milano e Padova.Fin dai primi anni Sync Lab è rapidamente cresciuta nel mercato ICT, consolidando irapporti con clienti e partner, raggiungendo un organico aziendale di oltre 200 risorse,una solida base finanziaria e una diffusione sul territorio attraverso le sue quattro sedi.L’organico aziendale è andato crescendo in modo continuo e rapido, in relazioneall’apertura delle varie sedi ed alla progressiva crescita delle stesse.La grande attenzione alla gestione delle risorse umane ha fatto di Sync Lab unriferimento in positivo per quanti volessero avviare o far evolvere in chiave professionalela propria carriera.Il basso turn-over testimonia la voglia dei collaboratori di condividere il progettocomune, assumendo all’interno di esso ruoli e responsabilità che solo un processoevolutivo così intenso può offrire.I ricavi hanno avuto un incremento proporzionale alla crescita dell’azienda beneficiandodell’approccio adattativo e diversificato al mercato.

1.2.2 Servizi offerti

Sync Lab S.r.l. è un’azienda leader nella consulenza tecnologica, impegnata in unprocesso continuo di identificazione e messa in opera di soluzioni per i clienti finalizzatealla creazione di valore. L’azienda supporta le esigenze di innovazione di tutte leorganizzazioni ed in ogni settore di mercato nell’ambito Information Technology, conservizi in ambito:

• Business Consultancy ;

• Project Financing ;

• IT Consultancy.

Sync Lab ha come punti di forza la qualità dei servizi offerti (certificazioni ISO 9001,ISO 14001, ISO 27001, OHSAS 18001) ed un’accurata gestione delle risorse umane.L’approfondita conoscenza di processi e tecnologie, maturata in esperienze altamentesignificative e qualificanti, fornisce l’expertise e il know-how necessari per gestireprogetti di elevata complessità, dominando l’intero ciclo di vita: Studio di fattibilità,Progettazione, Implementazione, Governance e Post Delivery.L’offerta di consulenza specialistica trova le punte di eccellenza nella progettazione diarchitetture software avanzate, siano esse per applicativi di dominio, per sistemi disupporto al business (BSS), per sistemi di integrazione (EAI/SOA) o per sistemi dimonitoraggio applicativo/territoriale.Il laboratorio RD (Ricerca e Sviluppo) dell’azienda è sempre al passo con i nuoviparadigmi tecnologici e di comunicazione, ad esempio Big Data, Cloud Computing,Internet delle Cose, Mobile e Sicurezza IT, per supportare i propri clienti nella creazioneed integrazione di applicazioni, processi e dispositivi.Le attività in ambito Educational ed RD hanno permesso di acquisire una profondaconoscenza degli strumenti di finanza agevolata fruendone direttamente ed interagendocon enti di supporto ai progetti innovativi dei propri clienti. L’azienda, grazie alla retedi relazioni a livello nazionale ed internazionale, ha ottenuto importanti finanziamentiin progetti RD europei (FP7 e H2020).

Page 13: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

1.3. LO STAGE 3

1.2.3 Settori di impiegoSync Lab si sta sempre più specializzando in vari settori d’impiego: dal mondo bankingall’assurance con una nicchia importante nell’ambito sanità in cui vanta un prodottod’eccellenza per la gestione delle cliniche private.L’azienda inoltre ha recentemente fondato una collegata Sync Security che si occupaespressamente del mondo della cyber security e sicurezza informatica in genere.

1.3 Lo stageLo stage si è svolto nell’arco di otto settimane, nel periodo dal 18 giugno al 27 agosto2018, presso la sede di Sync Lab, situata in Galleria Spagna 10 a Padova.Il progetto di stage ha coinvolto me e altri due studenti del Corso di Laurea in Infor-matica dell’Università di Padova, e prevedeva quindi un certo grado di collaborazionetra membri del gruppo.L’obiettivo del progetto era lo sviluppo di un’applicazione web per aiutare una mensaa gestire la preparazione di pasti per gli studenti. Questo applicativo è stato commis-sionato dal collegio Gregorianum1 a Padova, che vuole utilizzarlo per permettere aglistudenti iscritti di prenotare i pasti, riuscendo quindi a regolare la quantità di cibo dapreparare ogni giorno ed evitare gli sprechi.Ognuno dei tre partecipanti aveva un compito diversificato dagli altri. Lo studenteSamuele Bisello aveva il compito di realizzare il back-end[g] dell’applicazione utilizzan-do Java e Spring[g], e di progettare eventuali database con MongoDB[g]. Lo stagistaManfredi Smaniotto doveva realizzare l’intero front-end[g] con il framework Angular 6,che è lo strumento favorito dall’azienda per realizzare applicazioni web.Negli ultimi anni, tuttavia, la libreria React.js ha avuto una crescita notevole nel-l’adozione anche per utilizzi commerciali. Sync Lab desiderava quindi esplorare lepossibilità offerte da questa libreria, per poterne valutare l’utilizzo in futuri lavori.Lo scopo primario del mio stage è stato quindi apprendere come utilizzare questatecnologia, ed effettuare un’analisi comparativa con le soluzioni fornite da Angular,con eventuali considerazioni sulla migliore idoneità dell’uno e dell’altro in relazionealla complessità di un progetto. Lo stage quindi prevedeva un lavoro di ricerca ditecnologie da utilizzare con React ed in seguito la loro applicazione nella realizzazionedel front-end dell’applicazione per la mensa.Durante lo sviluppo del progetto, d’accordo con il tutor aziendale, abbiamo decisodi rendere obbligatoria solo la realizzazione in React della parte dell’applicazioneutilizzabile dagli account di amministrazione, dedicando la rimanente parte delle oreallo studio di Angular ai fini del confronto da realizzare.

1Situato in Via Marcel Proust 10, 35128, Padova

Page 14: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React
Page 15: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

Capitolo 2

Piano di lavoro

In questo capitolo è descritto nel dettaglio l’obiettivo del progetto di stage, ed è riportatala pianificazione inserita nel piano di lavoro.

2.1 Obiettivo del progetto

Si richiede allo stagista di intraprendere uno studio autonomo dell’ecosistema di sviluppoofferto da React.js concretizzando quanto imparato nello sviluppo di una Single PageApplication[g] commissionata dal collegio Gregorianum con sede in via Marcel Proust10 a Padova.Questo collegio offre un servizio di ristorazione, attivo a pranzo e a cena, accessibile atutti gli studenti iscritti.Il committente è interessato ad utilizzare una piattaforma online che permetta aglistudenti di effettuare l’accesso con il proprio account, possibilmente utilizzando gliaccount già esistenti nel sistema informatico del collegio, e scegliere il menù chedesiderano per ogni giornata.Il personale della mensa deve poter accedere tramite account di amministrazione evisualizzare le prenotazioni effettuate, in modo da sapere in anticipo il tipo ed ilnumero di pasti da preparare. Inoltre il personale dovrà poter definire il menù per ognigiornata.Essendo possibile che il progetto sia realmente utilizzato dal proponente ed al finedi esaminare gli strumenti di test utilizzabili con React, sarà necessario garantireun’adeguata copertura di test di unità e di sistema, qualora questi ultimi siano ritenutiopportuni e fattibili nel tempo a disposizione. Oltre a realizzare l’applicativo appenadescritto lo stagista dovrà apprendere il funzionamento di base del framework Angulared alla conclusione del periodo di stage dovrà realizzare una relazione sulle differenzeriscontrate fra Angular e React.js, riportando le differenze sull’approccio di sviluppo,notabili differenze nello schema architetturale e tutto quanto ritenuto importante.Queste informazioni saranno di aiuto per l’azienda nel valutare l’adozione di React.jscome libreria di sviluppo di applicazioni web.

5

Page 16: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

6 CAPITOLO 2. PIANO DI LAVORO

2.2 Requisiti e obiettivi

2.2.1 Prodotti attesi

Al termine del tirocinio lo studente dovrà aver prodotto:

1. Un’interfaccia grafica completa realizzata con React.js, che sia utilizzabile nelcontesto d’uso dell’applicazione web da realizzare, con caratteristiche consone aibisogni del soggetto proponente.

2. Una relazione sintetica che illustri le differenze riscontrate nell’utilizzo di React.jse Angular, evidenziandone i punti di forza e debolezza, con attenzione alle seguenticaratteristiche:

• l’architettura impiegata al loro interno;

• i paradigmi di sviluppo che portano ad utilizzare (design pattern[g], para-digmi di programmazione);

• la completezza in termini di quantità di funzionalità offerte;

• possibilità di integrazione e di utilizzo con altre soluzioni;

• maturità del framework, supporto, ciclo di sviluppo impiegato da chi limantiene;

• performance e capacità di creare pagine nativamente responsive;

• curva di apprendimento e semplicità di utilizzo, anche in relazione alla do-cumentazione disponibile e al supporto dato dalla comunità di sviluppatori.

2.2.2 Obiettivi

Nel piano di lavoro sono stati inseriti i seguenti obiettivi classificati per priorità. Irequisiti desiderabili aggiungono valore al percorso formativo permettendo l’appro-fondimento di tecnologie di progetto. Gli obiettivi facoltativi riguardano attività dasvolgere solo nel caso le altre attività di stage siano terminate in anticipo.

• Obbligatori

– O01 : Sviluppo di una interfaccia utente utilizzando la libreria React.js;

– O02 : Redazione di una relazione che evidenzi le differenze fra la piattaformaAngular e la libreria React.js;

– O03 : Implementazione dei test.

• Desiderabili

– D01 : Approfondimento delle tecnologie del back-end.

• Facoltativi

– F01 : Studio dei tool/approcci esistenti di deployment del front-end, conparticolare riguardo alla scalabilità del prodotto.

Page 17: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

2.2. REQUISITI E OBIETTIVI 7

2.2.3 PianificazioneDi seguito è riportata la pianificazione settimanale effettuata prima dell’inizio dell’atti-vità di stage.

• Prima Settimana - Formazione ed analisi preliminare

– Definizione dei requisiti del prodotto da realizzare contattando il collegioproponente;

– Formazione sul funzionamento della libreria React.js.

• Seconda Settimana - Formazione e raffinamento dell’analisi

– Analisi della possibilità di integrazione con i servizi già offerti dal collegioagli studenti;

– Raffinamento dei requisiti e definizione della struttura di navigazione del-l’applicativo web;

– Formazione sul framework Angular 6.

• Terza Settimana - Ricerca e scelta delle tecnologie aggiuntive

– Ricerca e studio di eventuali altre librerie o piattaforme da utilizzare assiemea React.js;

– Codifica delle pagine dell’applicazione.

• Quarta Settimana - Realizzazione di un proof-of-concept

– Sviluppo di un proof-of-concept del prodotto utilizzando gli strumenti messia disposizione dalla libreria React.js;

– Formazione sul testing e realizzazione dei primi test di unità;– Preparazione della documentazione associata.

• Quinta Settimana - Raffinamento dell’applicazione e testing

– Completamento di una prima versione dell’interfaccia che includa i requisitiminimi necessari;

– Completamento dei test di sistema;– Preparazione della documentazione.

• Sesta Settimana - Integrazione e analisi

– Confronto con l’interfaccia sviluppata con Angular e scelta della soluzioneda adoperare;

– Integrazione con il back-end ;– Approfondimento delle tecnologie del back-end (come SpringCloud).

• Settima Settimana - Raffinamento e collaudo

– Richiesta di feedback dal proponente;– Raffinamento del prodotto;– Completamento dei test.

• Ottava Settimana - Stesura delle conclusioni

– Analisi dei risultati ottenuti;– Preparazione della documentazione per l’azienda.

Page 18: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React
Page 19: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

Capitolo 3

Analisi dei requisiti

Nel capitolo è riportato nel dettaglio la descrizione delle pagine dell’applicazione e i casid’uso dell’interazione con l’utente.

3.1 Funzionamento del prodottoL’applicazione deve permettere al personale della mensa di accedere tramite accountdi amministratore per visualizzare e gestire le prenotazioni degli utenti e definire ilmenù di ogni giornata, sia per il pranzo, che per la cena, con possibilità di modificarloo eliminarlo. Una volta selezionato il menù di una giornata gli utenti saranno abilitatia prenotare al massimo un piatto per tipo fra quelli offerti nel menù del giorno.Un utente base potrà accedere all’applicazione, visualizzare il menù di ogni giornatadisponibile, ed effettuare al massimo una prenotazione per ogni pasto (ovvero pranzo ocena). Potrà inoltre rimuovere le prenotazioni effettuate precedentemente.Le pagine dell’applicazione accessibili dall’amministratore del sistema sono le seguenti:

• Homepage: riporta un messaggio di benvenuto per l’amministratore riassumendole funzionalità dell’applicazione;

• Gestione piatti : in questa pagina è possibile visualizzare, aggiungere e rimuoverei piatti disponibili nel sistema. Ogni piatto è costituito da un nome, un tipo(primo, secondo, contorno o dessert) e una descrizione opzionale;

• Gestione menù: permette di definire quali piatti, fra quelli inseriti nel sistema,siano disponibili nel menù di una giornata. Un tab permette di cambiare lavisualizzazione fra menù del pranzo o della cena.

• Gestione prenotazioni : da qui l’amministratore può visualizzare, per ogni giornata,tutti i piatti che sono stati prenotati da almeno uno studente. Al click su unpiatto questo visualizzerà l’elenco di utenti che lo hanno prenotato e l’orario chehanno specificato. È anche possibile applicare un filtro in modo da visualizzaresolo i primi piatti, secondi piatti, ecc.Selezionando la scheda Vista utenti si può visualizzare l’elenco delle prenotazionistavolta ordinate per utente (invece che per piatto). Premendo un appositopulsante su ogni elemento della lista è possibile eliminare la prenotazione di unutente. Inoltre l’amministratore può aggiungere prenotazioni compilando unform apposito con i seguenti campi:

9

Page 20: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

10 CAPITOLO 3. ANALISI DEI REQUISITI

– Nome: il nome dell’utente, che va selezionato da un menù a tendina checontiene tutti gli utenti del sistema;

– Primo piatto: vengono visualizzati i primi piatti inseriti nel menù del giornoed è possibile selezionarne al massimo uno;

– Secondo piatto: permette la selezione del secondo piatto con modalitàanaloga al campo Primo piatto;

– Contorno: permette la selezione del contorno con modalità analoga al campoPrimo piatto;

– Dessert : permette la selezione del dessert con modalità analoga al campoPrimo piatto;

– Orario: per agevolare la preparazione dei pasti è richiesto inserire un orarioal quale lo studente desidera consumare il pasto. Viene comunque fornitoun orario di default nel caso l’utente non desideri compilarlo;

– Pranzo a sacco: un checkbox permette di specificare che si desidera ricevereun pranzo confezionato per asporto. Questa opzione disabilita i campi diselezione del menù e dell’orario;

Anche in questa pagina è presente un tab per selezionare la scheda del pranzooppure della cena.

Le pagine Gestione menù e Gestione prenotazioni visualizzeranno un calendario mensileper selezionare le giornate con un click.Le pagine dell’applicazione accessibili con account base sono solamente due:

• Homepage: riporta un messaggio di benvenuto per l’utente base riassumendo lefunzionalità dell’applicazione;

• Prenota: scegliendo un giorno dal calendario vengono visualizzate le prenotazionieffettuate per quella giornata (al massimo una per pranzo e una per cena) e vienedata la possibilità di eliminarle e aggiungerle, nel caso non siano già presenti. Ilform di aggiunta di una prenotazione è analogo a quello già descritto per l’utenteamministratore, con l’unica differenza che l’utente base non dovrà selezionarel’intestatario della prenotazione, ma dovrà indicare se la prenotazione è perpranzo oppure per cena.

In accordo con il tutor aziendale, abbiamo deciso di rendere facoltativo lo sviluppodella pagine accessibili dall’account base, mantenendo come requisiti obbligatori ilcompletamento della parte amministratore e la redazione della relazione di comparazionefra React.js e Angular.

Page 21: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

3.2. ATTORI DEL SISTEMA 11

3.2 Attori del sistema

Di seguito sono descritti i quattro tipi di attori che sono riferiti nei casi d’uso nellasezione successiva:

• Utente non autenticato: indica un utente non ancora riconosciuto dal sistema;

• Utente base autenticato: indica un utente che ha effettuato l’accesso da unaccount base (non amministratore);

• Utente amministratore autenticato: è riferito ad un utente che ha accedutoal sistema come amministratore;

• Utente autenticato: indica indifferentemente uno dei due precedenti utenti;

3.3 Casi d’uso

Per descrivere dettagliatamente l’interazione dell’utente con il sistema ho definito deicasi d’uso. I casi d’uso (in inglese Use Case) sono descrizioni testuali degli scenari diutilizzo di un sistema, che descrivono quindi l’insieme di funzionalità che esso offre cosìcome sono percepiti e utilizzati dagli attori che interagiscono col sistema stesso.

UC-1: Accesso all’applicazione (login)Attori Principali: Utente non autenticato.

Precondizioni: L’utente si trova sulla pagina di login del programma.

Descrizione: Vengono visualizzati i campi username e password da compilareed un pulsante per confermare i dati inseriti.

Scenario principale:

1. L’utente inserisce le proprie credenziali come specificato nei sotto-casi (UC-1.1, UC-1.2);

2. L’utente preme il pulsante di accesso;

3. L’utente è rediretto alla pagina di benvenuto.

Postcondizioni: L’utente è stato riconosciuto dal sistema e visualizza la paginadi benvenuto dell’applicazione.

Estensioni:

3a. Visualizzazione di un messaggio d’errore nel caso non sia stato possibileaccedere (UC-5).

Page 22: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

12 CAPITOLO 3. ANALISI DEI REQUISITI

UC-1.1: Inserimento dell’usernameAttori Principali: Utente non autenticato.

Precondizioni: L’utente si trova sulla pagina di login del programma.

Descrizione: Per completare l’accesso è necessario inserire il nome utente nel-l’apposito campo.

Scenario principale:

1. L’utente seleziona la casella di testo per l’inserimento del nome utente;

2. L’utente digita il proprio username.

Postcondizioni: L’utente ha inserito l’username nel form di login.

UC-1.2: Inserimento della passwordAttori Principali: Utente non autenticato.

Precondizioni: L’utente si trova sulla pagina di login del programma.

Descrizione: Per poter effettuare l’accesso è necessario inserire la password delproprio account nell’apposito campo.

Scenario principale:

1. L’utente seleziona la casella di testo per l’inserimento della password;

2. L’utente digita la propria password.

Postcondizioni: L’utente ha inserito la password nel form di login.

UC-2: LogoutAttori Principali: Utente autenticato.

Precondizioni: L’utente ha effettuato l’accesso alla piattaforma e si trova in unaqualsiasi pagina dell’applicazione.

Descrizione: L’utente desidera effettuare il logout dall’applicazione e terminarela propria sessione.

Scenario principale:

1. L’utente clicca sul pulsante Logout, posizionato sulla barra di navigazione;

2. L’utente viene reindirizzato alla schermata di login.

Postcondizioni: L’utente non è più autenticato e visualizza la schermata di login.

Page 23: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

3.3. CASI D’USO 13

UC-3: Visualizzazione delle prenotazioni effettuate in unagiornataAttori Principali: Utente amministratore autenticato.

Precondizioni: L’utente a cliccato sul link del menù per accedere alla paginaGestione prenotazioni.

Descrizione: L’utente vuole visualizzare quanti e quali piatti siano stati prenotatinella giornata scelta. È anche possibile visualizzare il nome degli utenti che hannoeffettuato la prenotazione.

Scenario principale:

1. L’utente seleziona nel calendario la giornata per la quale vuole visualizzarela lista di prenotazioni;

2. L’utente attende il caricamento dei dati;

3. L’utente sceglie il pasto per il quale vuole visualizzare le prenotazioni (UC-3.1,UC-3.2);

4. Viene visualizzato l’elenco dei piatti prenotati.

Postcondizioni: L’utente visualizza la lista di piatti prenotati, con indicato ilnumero di prenotazioni per ogni piatto.

Estensioni:

4a. L’utente filtra i piatti per tipo (UC-4).

UC-3.1: Visualizzazione delle prenotazioni per pranzoAttori Principali: Utente amministratore autenticato.

Precondizioni: L’utente sta visualizzando la lista di prenotazioni effettuate percena.

Descrizione: L’utente vuole visualizzare la lista di piatti prenotati per pranzo.

Scenario principale:

1. L’utente seleziona la scheda Pranzo nella parte alta del pannello.

Postcondizioni: Il sistema visualizza la lista di piatti prenotati a pranzo diquella giornata.

Page 24: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

14 CAPITOLO 3. ANALISI DEI REQUISITI

UC-3.2: Visualizzazione delle prenotazioni per cenaAttori Principali: Utente amministratore autenticato.

Precondizioni: L’utente sta visualizzando la lista di prenotazioni effettuate perpranzo.

Descrizione: L’utente vuole visualizzare la lista di piatti prenotati per cena.

Scenario principale:

1. L’utente seleziona la scheda Cena nella parte alta del pannello.

Postcondizioni: Il sistema visualizza la lista di piatti prenotati a cena di quellagiornata.

UC-3.3: Visualizzazione della lista di piatti prenotatiAttori Principali: Utente amministratore autenticato.

Precondizioni: L’utente sta visualizzando la lista di utenti prenotati per pranzoo per cena di una giornata.

Descrizione: L’utente vuole visualizzare la lista di tutti i piatti prenotati perquel pasto, con il numero di prenotazioni per ciascun piatto.

Scenario principale:

1. L’utente seleziona la scheda Vista pasti nella parte alta del pannello;

2. Viene mostrata una lista contenente i nomi di tutti i piatti prenotati.

Postcondizioni: Il sistema visualizza la lista di piatti prenotati per il pastoselezionato ed il numero di prenotazioni.

Page 25: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

3.3. CASI D’USO 15

UC-3.4: Visualizzazione della lista di utenti prenotati perun piattoAttori Principali: Utente amministratore autenticato.

Precondizioni: L’utente sta visualizzando la lista di prenotazioni effettuate perpranzo o per cena.

Descrizione: L’utente vuole visualizzare i nomi degli utenti che hanno prenotatoun certo piatto assieme all’orario scelto per la prenotazione.

Scenario principale:

1. L’utente clicca sul piatto scelto;

2. Viene visualizzata la lista di utenti che hanno effettuato la prenotazioneaffiancati dall’orario.

Postcondizioni: Il sistema visualizza il nome del piatto, il numero di prenotazionee l’elenco di utenti prenotati. Gli altri piatti nella lista restano invariati.

UC-3.5: Visualizzazione della lista di utenti prenotatiAttori Principali: Utente amministratore autenticato.

Precondizioni: L’utente sta visualizzando la lista di piatti prenotati per pranzoo per cena di una giornata.

Descrizione: L’utente vuole visualizzare la lista di tutti gli utenti che hannoeffettuato una prenotazione per quel pasto.

Scenario principale:

1. L’utente seleziona la scheda Vista utenti nella parte alta del pannello;

2. Viene mostrata una lista contenente i nomi di tutti gli utenti prenotati.

Postcondizioni: Il sistema visualizza la lista di utenti prenotati per il pastoselezionato.

Page 26: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

16 CAPITOLO 3. ANALISI DEI REQUISITI

UC-4: Filtraggio dei piatti visualizzati per tipoAttori Principali: Utente amministratore autenticato.

Precondizioni: L’utente sta visualizzando una lista di piatti.

Descrizione: È possibile filtrare i piatti visualizzati per tipo, ovvero selezionaresolo i primi piatti, oppure i secondi, ecc.

Scenario principale:

1. L’utente preme il pulsante corrispondente al filtro desiderato (vedere sottocasi).

Postcondizioni: Il sistema ha applicato il filtro selezionato.

Specializzazioni:

• UC-4.1: Filtraggio per primi piatti;

• UC-4.2: Filtraggio per secondi piatti;

• UC-4.3: Filtraggio per contorni;

• UC-4.4: Filtraggio per dessert.

UC-4.1: Filtraggio per primi piattiAttori Principali: Utente amministratore autenticato.

Precondizioni: L’utente sta visualizzando una lista di piatti.

Descrizione: L’utente desidera visualizzare solamente i primi piatti presentinella lista.

Scenario principale:

1. L’utente preme il pulsante Primi posto sulla barra sopra la lista.

Postcondizioni: Il sistema aggiorna la lista mostrando solo i primi piatti.

Generalizzazioni:

• UC-4: Filtraggio dei piatti visualizzati per tipo.

Page 27: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

3.3. CASI D’USO 17

UC-4.2: Filtraggio per secondi piattiAttori Principali: Utente amministratore autenticato.

Precondizioni: L’utente sta visualizzando una lista di piatti.

Descrizione: L’utente desidera visualizzare solamente i secondi piatti presentinella lista.

Scenario principale:

1. L’utente preme il pulsante Secondi posto sulla barra sopra la lista.

Postcondizioni: Il sistema aggiorna la lista mostrando solo i secondi piatti.

Generalizzazioni:

• UC-4: Filtraggio dei piatti visualizzati per tipo.

UC-4.3: Filtraggio per contorniAttori Principali: Utente amministratore autenticato.

Precondizioni: L’utente sta visualizzando una lista di piatti.

Descrizione: L’utente desidera visualizzare solamente i contorni presenti nellalista.

Scenario principale:

1. L’utente preme il pulsante Contorni posto sulla barra sopra la lista.

Postcondizioni: Il sistema aggiorna la lista mostrando solo i contorni.

Generalizzazioni:

• UC-4: Filtraggio dei piatti visualizzati per tipo.

Page 28: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

18 CAPITOLO 3. ANALISI DEI REQUISITI

UC-4.4: Filtraggio per dessertAttori Principali: Utente amministratore autenticato.

Precondizioni: L’utente sta visualizzando una lista di piatti.

Descrizione: L’utente desidera visualizzare solamente i dessert presenti nellalista.

Scenario principale:

1. L’utente preme il pulsante Dessert posto sulla barra sopra la lista.

Postcondizioni: Il sistema aggiorna la lista mostrando solo i dessert.

Generalizzazioni:

• UC-4: Filtraggio dei piatti visualizzati per tipo.

UC-4.5: Rimozione del filtro per tipoAttori Principali: Utente amministratore autenticato.

Precondizioni: L’utente sta visualizzando una lista di piatti filtrati.

Descrizione: L’utente desidera visualizzare tutti i piatti e rimuovere il filtro.

Scenario principale:

1. L’utente preme il pulsante Tutti posto sulla barra sopra la lista.

Postcondizioni: Il sistema aggiorna la lista mostrando tutti i piatti nella lista.

UC-5: Visualizzazione di un messaggio erroreAttori Principali: Utente autenticato.

Precondizioni: L’utente si trova sulla pagina di scelta del menù.

Descrizione: Nel caso vi siano problemi nell’inviare o ricevere dati verso il back-end viene visualizzato un messaggio d’errore per avvisare l’utente. Questo puòessere dovuto ad un problema di connessione oppure ad un errore segnalato dalserver.

Scenario principale:

1. Viene mostrato il messaggio d’errore che avvisa l’utente dell’impossibilità dicompletare l’operazione.

Postcondizioni: Il sistema mostra il messaggio d’errore.

Page 29: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

3.3. CASI D’USO 19

UC-5.1: Rimozione di un messaggio erroreAttori Principali: Utente autenticato.

Precondizioni: Il sistema sta mostrando un messaggio d’errore.

Descrizione: L’utente vuole eliminare il messaggio d’errore visualizzato.

Scenario principale:

1. L’utente preme il pulsante Ok del messaggio.

Postcondizioni: Il messaggio d’errore non è più visualizzato.

UC-6: Aggiunta di una prenotazioneAttori Principali: Utente amministratore autenticato.

Precondizioni: L’amministratore sta visualizzando l’elenco di utenti prenotatiad un pasto (pranzo o cena).

Descrizione: L’amministratore desidera inserire una prenotazione per conto diun utente per lo stesso pasto che sta visualizzando.

Scenario principale:

1. L’amministratore preme il pulsante di aggiunta posto sulla barra sopra lalista;

2. Attende il caricamento dei dati del form;

3. L’amministratore compila il form come specificato nei sotto-casi (UC-6.3 -UC-6.9);

4. L’amministratore conferma la prenotazione premendo su Aggiungi ;

5. Attende l’elaborazione della richiesta;

6. La lista viene aggiornata mostrando la nuova prenotazione.

Postcondizioni: È stata aggiunta una nuova prenotazione.

Estensioni:

3a. Visualizzazione di un messaggio d’errore se è impossibile scaricare i dati delform (UC-5);

4a. L’utente non conferma l’inserimento della prenotazione (UC-6.2);

5a. Visualizzazione di un messaggio d’errore di compilazione del form (UC-6.1);

6a. Visualizzazione di un messaggio errore di aggiunta della prenotazione (UC-5).

Page 30: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

20 CAPITOLO 3. ANALISI DEI REQUISITI

UC-6.1: Visualizzazione messaggio d’errore di compilazione

Attori Principali: Utente amministratore autenticato.

Precondizioni: L’amministratore sta aggiungendo una prenotazione per unutente.

Descrizione: Uno o più campi del form non sono stati compilati correttamente,quindi viene segnalato l’errore sotto i campi non corretti.

Scenario principale:

1. Viene visualizzato il messaggio d’errore sul campo non corretto.

Postcondizioni: Sotto i campi errati del form compare un errore che invital’utente a correggere l’inserimento.

UC-6.2: Annullamento dell’aggiunta della prenotazioneAttori Principali: Utente amministratore autenticato.

Precondizioni: L’amministratore sta aggiungendo una prenotazione per unutente.

Descrizione: Nel caso l’utente non desideri inserire la prenotazione può chiudereil form e annullare l’inserimento.

Scenario principale:

1. L’utente preme il pulsante Annulla;

2. Il form sparisce e l’utente ritorna all’elenco di utenti prenotati.

Postcondizioni: L’utente visualizza l’elenco di utenti prenotati che è rimastoinvariato.

Page 31: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

3.3. CASI D’USO 21

UC-6.3: Selezione del nome dell’utenteAttori Principali: Utente amministratore autenticato.

Precondizioni: L’amministratore sta aggiungendo una prenotazione per unutente attraverso la compilazione del form.

Descrizione: È necessario inserire il nome dell’utente per il quale effettuare laprenotazione, scegliendolo fra l’elenco di utenti del sistema.

Scenario principale:

1. L’utente seleziona la casella per l’inserimento del nome;

2. Una tendina mostra l’elenco di tutti gli utenti possibili;

3. L’utente seleziona una delle opzioni, eventualmente digitando il nome percercarlo.

Postcondizioni: L’utente ha inserito il nome dell’utente della prenotazione daaggiungere.

UC-6.4: Selezione del primo piattoAttori Principali: Utente amministratore autenticato.

Precondizioni: L’amministratore sta aggiungendo una prenotazione per unutente attraverso la compilazione del form.

Descrizione: È necessario inserire almeno un piatto per effettuare la prenotazione.È possibile sceglierne uno per categoria (primo, secondo, ecc).

Scenario principale:

1. L’utente seleziona il primo piatto che desidera fra quelli elencati, oppureseleziona Nessuno.

Postcondizioni: L’utente ha selezionato il primo piatto da prenotare.

Page 32: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

22 CAPITOLO 3. ANALISI DEI REQUISITI

UC-6.5: Selezione del secondo piattoAttori Principali: Utente amministratore autenticato.

Precondizioni: L’amministratore sta aggiungendo una prenotazione per unutente attraverso la compilazione del form.

Descrizione: È necessario inserire almeno un piatto per effettuare la prenotazione.È possibile sceglierne uno per categoria (primo, secondo, ecc).

Scenario principale:

1. L’utente seleziona il secondo piatto che desidera fra quelli elencati, oppureseleziona Nessuno.

Postcondizioni: L’utente ha selezionato il secondo piatto da prenotare.

UC-6.6: Selezione del contornoAttori Principali: Utente amministratore autenticato.

Precondizioni: L’amministratore sta aggiungendo una prenotazione per unutente attraverso la compilazione del form.

Descrizione: È necessario inserire almeno un piatto per effettuare la prenotazione.È possibile sceglierne uno per categoria (primo, secondo, ecc).

Scenario principale:

1. L’utente seleziona il contorno che desidera fra quelli elencati, oppure selezionaNessuno.

Postcondizioni: L’utente ha selezionato il contorno da prenotare.

UC-6.7: Selezione del dessertAttori Principali: Utente amministratore autenticato.

Precondizioni: L’amministratore sta aggiungendo una prenotazione per unutente attraverso la compilazione del form.

Descrizione: È necessario inserire almeno un piatto per effettuare la prenotazione.È possibile sceglierne uno per categoria (primo, secondo, ecc).

Scenario principale:

1. L’utente seleziona il dessert che desidera fra quelli elencati, oppure selezionaNessuno.

Postcondizioni: L’utente ha selezionato il dessert da prenotare.

Page 33: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

3.3. CASI D’USO 23

UC-6.8: Selezione dell’ora della prenotazioneAttori Principali: Utente amministratore autenticato.

Precondizioni: L’amministratore sta aggiungendo una prenotazione per unutente attraverso la compilazione del form.

Descrizione: Per agevolare la preparazione dei piatti ogni utente deve specificarel’ora nella quale ha intenzione di consumare il pasto, entro un range valido. Ilcampo è precompilato con un valore di default.

Scenario principale:

1. L’utente digita l’orario nella casella dedicata oppure lascia il valore preim-postato.

Postcondizioni: L’utente ha inserito l’orario della prenotazione.

UC-6.9: Scelta di un pranzo a saccoAttori Principali: Utente amministratore autenticato.

Precondizioni: L’amministratore sta aggiungendo una prenotazione per unutente attraverso la compilazione del form.

Descrizione: È disponibile un’opzione per prenotare un pranzo al sacco. Inquesto caso non è però possibile selezionare il piatto e l’orario, e i campi inquestione verranno disabilitati.

Scenario principale:

1. L’utente spunta il checkbox Pranzo al sacco.

Postcondizioni: L’utente ha specificato di voler prenotare un pranzo a sacco.

Page 34: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

24 CAPITOLO 3. ANALISI DEI REQUISITI

UC-7: Eliminazione di una prenotazioneAttori Principali: Utente amministratore autenticato.

Precondizioni: L’amministratore sta visualizzando l’elenco di utenti prenotatiad un pasto (pranzo o cena) che contiene almeno una prenotazione.

Descrizione: L’amministratore desidera eliminare l’intera prenotazione di unutente per lo stesso giorno e pasto che sta visualizzando.

Scenario principale:

1. L’amministratore seleziona il pulsante di eliminazione dal riquadro dellaprenotazione che vuole rimuovere;

2. Viene visualizzato un messaggio di conferma;

3. L’amministratore conferma la rimozione premendo sul pulsante Conferma;

4. Attende l’elaborazione della richiesta;

5. La lista viene aggiornata.

Postcondizioni: L’utente ha eliminato la prenotazione di un utente.

Estensioni:

3a. L’utente non conferma l’eliminazione della prenotazione (UC-7.1);

5a. Visualizzazione di un messaggio errore di rimozione della prenotazione(UC-5).

UC-7.1: Annullamento dell’eliminazione di una prenotazio-neAttori Principali: Utente amministratore autenticato.

Precondizioni: L’amministratore visualizza la richiesta di conferma per elimina-re una prenotazione.

Descrizione: Nel caso l’utente non desideri eliminare la prenotazione può an-nullare l’inserimento, utile nel caso si sia accidentalmente premuto il pulsante dieliminazione.

Scenario principale:

1. L’utente preme il pulsante Annulla;

2. Il messaggio sparisce e l’utente ritorna all’elenco di utenti prenotati.

Postcondizioni: L’utente visualizza l’elenco di utenti prenotati che è rimastoinvariato.

Page 35: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

3.3. CASI D’USO 25

UC-8: Ricerca di un utente prenotatoAttori Principali: Utente amministratore autenticato.

Precondizioni: L’amministratore sta visualizzando l’elenco di utenti prenotatiad un pasto (pranzo o cena).

Descrizione: L’amministratore desidera cercare per nome un utente prenotatonel pasto che sta visualizzando.

Scenario principale:

1. L’utente seleziona la casella di ricerca posta sulla barra degli strumenti soprala lista di utenti;

2. Digita il nome che vuole cercare;

3. La casella di espande in una tendina che mostra tutti i nomi degli utentiche contengono i caratteri inseriti;

4. L’utente seleziona con le frecce o con il mouse l’utente desiderato e premeInvio;

5. La lista si aggiorna mostrando l’utente cercato.

Postcondizioni: L’utente visualizza una lista composta solamente dall’utentericercato.

Page 36: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

26 CAPITOLO 3. ANALISI DEI REQUISITI

UC-9: Visualizzazione del menù di una giornataAttori Principali: Utente amministratore autenticato.

Precondizioni: L’utente ha cliccato sul link della pagina Gestione menù.

Descrizione: L’utente vuole visualizzare la lista di piatti disponibile nel menùdella giornata.

Scenario principale:

1. L’utente clicca sul giorno per il quale vuole visualizzare il menù e vienereindirizzato alla pagina del menù;

2. L’utente attende il caricamento dei dati;

3. L’utente seleziona quale pasto desidera visualizzare (UC-9.1, UC-9.2);

4. L’utente visualizza l’elenco dei piatti inseriti nel menù giornaliero insieme atutti quelli non selezionati.

Postcondizioni: Il sistema visualizza la lista di tutti i piatti disponibili nelsistema evidenziando fra di essi quelli già inseriti nel menù.

Estensioni:

2a. Visualizzazione di un messaggio d’errore (UC-5);

4a. L’utente filtra i piatti in base al tipo (UC-4).

UC-9.1: Visualizzazione del menù del pranzoAttori Principali: Utente amministratore autenticato.

Precondizioni: L’utente sta visualizzando la lista di piatti nel menù per cena.

Descrizione: L’utente vuole visualizzare la lista dei piatti disponibile a pranzonel menù della giornata.

Scenario principale:

1. L’utente seleziona la scheda Pranzo nella parte alta del pannello.

Postcondizioni: Il sistema visualizza la lista dei piatti disponibili per pranzoevidenziando fra di essi quelli già inseriti nel menù.

Page 37: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

3.3. CASI D’USO 27

UC-9.2: Visualizzazione del menù della cenaAttori Principali: Utente amministratore autenticato.

Precondizioni: L’utente sta visualizzando la lista di piatti nel menù per il pranzodella giornata.

Descrizione: L’utente vuole visualizzare la lista dei piatti disponibile a cena nelmenù della giornata.

Scenario principale:

1. L’utente seleziona la scheda Cena nella parte alta del pannello.

Postcondizioni: Il sistema visualizza la lista dei piatti disponibili per cenaevidenziando fra di essi quelli già inseriti nel menù.

UC-10: Modifica del menù di una giornataAttori Principali: Utente amministratore autenticato.

Precondizioni: L’utente sta visualizzando la lista di piatti nel menù del giornoa pranzo oppure a cena.

Descrizione: L’utente amministratore vuole scegliere o modificare il menù darendere disponibile una giornata, specificando un menù per il pranzo oppure perla cena.

Scenario principale:

1. L’utente sceglie i pasti che desidera selezionandoli o deselezionandoli con unclick;

2. Preme il pulsante Conferma e salva;

3. L’utente visualizza il messaggio di conferma dell’avvenuto salvataggio.

Postcondizioni: Il sistema ha salvato il menù per quel giorno.

Estensioni:

3a. L’utente visualizza un errore (UC-5).

Page 38: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

28 CAPITOLO 3. ANALISI DEI REQUISITI

UC-11: Eliminazione del menù di una giornataAttori Principali: Utente amministratore autenticato.

Precondizioni: L’utente sta visualizzando il menù di una giornata.

Descrizione: L’utente amministratore vuole eliminare il menù precedentementeaggiunto. Una volta fatto non sarà più possibile aggiungere prenotazioni per quelgiorno.

Scenario principale:

1. L’utente preme il pulsante Elimina il menù posizionato sotto la lista deipiatti;

2. L’utente attende che tutti i piatti precedentemente selezionati siano desele-zionati.

Postcondizioni: Il sistema ha eliminato il menù di quel giorno.

Estensioni:

2a. L’utente visualizza un errore (UC-5).

UC-12: Visualizzazione dei piatti inseriti nel sistemaAttori Principali: Utente amministratore autenticato.

Precondizioni: L’utente ha cliccato sul link del menù per accedere alla paginaGestione piatti.

Descrizione: L’utente vuole visualizzare la lista di tutti i piatti che sono salvatinel sistema.

Scenario principale:

1. L’utente attende il caricamento dei piatti;

2. L’utente visualizza la lista di piatti.

Postcondizioni: Il sistema visualizza la lista di piatti inseriti nel sistema.

Estensioni:

2a. L’utente filtra i piatti per tipo (UC-4);

2b. Visualizzazione di un messaggio d’errore (UC-5).

Page 39: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

3.3. CASI D’USO 29

UC-13: Ricerca di un piatto nel sistemaAttori Principali: Utente amministratore autenticato.

Precondizioni: L’utente sta visualizzando la lista di piatti nella pagina Gestionepiatti eventualmente con dei filtri applicati.

Descrizione: L’utente vuole cercare e visualizzare un piatto fra quelli visualizzatinella lista di piatti.

Scenario principale:

1. L’utente seleziona la casella di ricerca posta nella barra sopra la lista;

2. L’utente digita il nome del piatto;

3. Seleziona dalla tendina uno dei piatti visualizzati;

4. L’utente visualizza il piatto cercato, se presente.

Postcondizioni: Il sistema visualizza una lista contenente il solo piatto cercato,altrimenti una lista vuota.

Page 40: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

30 CAPITOLO 3. ANALISI DEI REQUISITI

UC-14: Aggiunta di un piattoAttori Principali: Utente amministratore autenticato.

Precondizioni: L’utente sta visualizzando la lista di piatti nella pagina Gestionepiatti.

Descrizione: L’utente vuole aggiungere un nuovo piatto alla lista.

Scenario principale:

1. L’utente seleziona il pulsante di aggiunta posto nella barra sopra la lista;

2. Viene visualizzato un pannello modale con il form di inserimento;

3. L’utente compila il form come specificato nei sotto-casi d’uso (UC-14.1,UC-14.2, UC-14.3);

4. L’utente preme il pulsante Aggiungi ;

5. Il form si chiude e la lista viene aggiornata.

Postcondizioni: Il sistema ha correttamente aggiunto il nuovo piatto.

Estensioni:

4a. L’utente vuole chiudere il form senza salvare i dati inseriti (UC-14.5);

5a. Visualizzazione di un errore di compilazione del form (UC-14.4);

5b. Visualizzazione di un messaggio d’errore se l’aggiunta non è andata a buonfine (UC-5).

UC-14.1: Inserimento del nome del piattoAttori Principali: Utente amministratore autenticato.

Precondizioni: L’utente sta visualizzando il form per l’aggiunta di un piatto.

Descrizione: È necessario inserire il nome del piatto nel form di aggiunta di unnuovo piatto.

Scenario principale:

1. L’utente seleziona la casella del Nome del piatto;

2. Digita il nome del piatto.

Postcondizioni: L’utente ha inserito il nome del piatto.

Page 41: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

3.3. CASI D’USO 31

UC-14.2: Selezione della tipologia del piattoAttori Principali: Utente amministratore autenticato.

Precondizioni: L’utente sta visualizzando il form per l’aggiunta di un piatto.

Descrizione: È necessario inserire il tipo del piatto fra primo, secondo, ecc.

Scenario principale:

1. L’utente seleziona il Tipo del piatto (vedere sotto-casi).

Postcondizioni: L’utente scelto il tipo del piatto fra quelli proposti.

Specializzazioni:

• UC-14.2.1: Selezione della tipologia primo;

• UC-14.2.2: Selezione della tipologia secondo;

• UC-14.2.3: Selezione della tipologia contorno;

• UC-14.2.4: Selezione della tipologia dessert.

UC-14.2.1: Selezione della tipologia primoAttori Principali: Utente amministratore autenticato.

Precondizioni: L’utente sta visualizzando il form per l’aggiunta di un piatto.

Descrizione: L’utente vuole assegnare al piatto la tipologia primo.

Scenario principale:

1. L’utente spunta il radio button corrispondente a Primo.

Postcondizioni: L’utente ha assegnato al piatto la tipologia primo.

Generalizzazioni:

• UC-14.2: Selezione della tipologia del piatto.

Page 42: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

32 CAPITOLO 3. ANALISI DEI REQUISITI

UC-14.2.2: Selezione della tipologia secondoAttori Principali: Utente amministratore autenticato.

Precondizioni: L’utente sta visualizzando il form per l’aggiunta di un piatto.

Descrizione: L’utente vuole assegnare al piatto la tipologia secondo.

Scenario principale:

1. L’utente spunta il radio button corrispondente a Secondo.

Postcondizioni: L’utente ha assegnato al piatto la tipologia secondo.

Generalizzazioni:

• UC-14.2: Selezione della tipologia del piatto.

UC-14.2.3: Selezione della tipologia contornoAttori Principali: Utente amministratore autenticato.

Precondizioni: L’utente sta visualizzando il form per l’aggiunta di un piatto.

Descrizione: L’utente vuole assegnare al piatto la tipologia contorno.

Scenario principale:

1. L’utente spunta il radio button corrispondente a Contorno.

Postcondizioni: L’utente ha assegnato al piatto la tipologia contorno.

Generalizzazioni:

• UC-14.2: Selezione della tipologia del piatto.

UC-14.2.4: Selezione della tipologia dessertAttori Principali: Utente amministratore autenticato.

Precondizioni: L’utente sta visualizzando il form per l’aggiunta di un piatto.

Descrizione: L’utente vuole assegnare al piatto la tipologia dessert.

Scenario principale:

1. L’utente spunta il radio button corrispondente a Dessert.

Postcondizioni: L’utente ha assegnato al piatto la tipologia dessert.

Generalizzazioni:

• UC-14.2: Selezione della tipologia del piatto.

Page 43: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

3.3. CASI D’USO 33

UC-14.3: Inserimento della descrizione del piattoAttori Principali: Utente amministratore autenticato.

Precondizioni: L’utente sta visualizzando il form per l’aggiunta di un piatto.

Descrizione: L’utente vuole inserire una descrizione del piatto, ad esempio perspecificare gli ingredienti o per segnalare allergeni. È anche possibile lasciare ilcampo vuoto.

Scenario principale:

1. L’utente seleziona la casella di testo Descrizione;

2. Digita la descrizione del piatto (o la lascia vuota).

Postcondizioni: L’utente ha inserito la descrizione del piatto.

UC-14.4: Visualizzazione di un errore di compilazione delformAttori Principali: Utente amministratore autenticato.

Precondizioni: L’utente sta visualizzando il form per l’aggiunta di un piatto.

Descrizione: Se uno o più campi del form non sono stati compilati oppurecontengono caratteri non ammessi verrà mostrato un messaggio d’errore.

Scenario principale:

1. Viene mostrato il messaggio sotto i campi non corretti, specificando le causedell’errore.

Postcondizioni: Il sistema mostra un messaggio d’errore che impedisce l’aggiuntadi dati non validi.

Page 44: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

34 CAPITOLO 3. ANALISI DEI REQUISITI

UC-14.5: Annullamento dell’inserimento e chiusura del form

Attori Principali: Utente amministratore autenticato.

Precondizioni: L’utente sta visualizzando il form per l’aggiunta di un piatto.

Descrizione: L’utente vuole chiudere il form, ad esempio perché l’ha apertoaccidentalmente oppure perché non vuole aggiungere il piatto.

Scenario principale:

1. L’utente preme il pulsante Annulla oppure un qualunque punto al di fuoridel pannello modale;

2. La finestra si chiude e riporta alla pagina Gestione piatti.

Postcondizioni: L’utente si trova sulla pagina Gestione piatti.

UC-15: Eliminazione di un piattoAttori Principali: Utente amministratore autenticato.

Precondizioni: L’utente sta visualizzando la lista di piatti nella pagina Gestionepiatti e almeno un piatto è visualizzato.

Descrizione: L’utente vuole rimuovere un piatto dalla lista.

Scenario principale:

1. L’utente preme il pulsante di eliminazione posizionato sotto il nome delpiatto da eliminare;

2. Viene visualizzata una richiesta di conferma;

3. L’utente preme Conferma;

4. L’utente attende l’elaborazione della sua richiesta;

5. La lista viene aggiornata.

Postcondizioni: È stato correttamente eliminato un piatto.

Estensioni:

3a. L’utente annulla l’eliminazione (UC-15.1);

5a. Visualizzazione di un messaggio d’errore nel caso non sia possibile completarela cancellazione (UC-5).

Page 45: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

3.3. CASI D’USO 35

UC-15.1: Annullamento della richiesta di eliminazione di unpiattoAttori Principali: Utente amministratore autenticato.

Precondizioni: L’utente visualizza il messaggio di conferma della rimozione diun piatto.

Descrizione: L’utente vuole annullare l’operazione, ad esempio perché effettuataaccidentalmente.

Scenario principale:

1. L’utente preme il pulsante Annulla.

2. Il messaggio viene chiuso e non viene eliminato alcun elemento.

Postcondizioni: L’utente si trova sulla pagina Gestione piatti e la lista restainvariata.

UC-16: Scaricamento del report delle prenotazioni mensileAttori Principali: Utente amministratore autenticato.

Precondizioni: L’utente amministratore si trova sulla pagina di benvenuto.

Descrizione: È possibile scaricare un foglio elettronico contenente la tabella deipiatti prenotati in ciascun mese con il relativo numero di prenotazioni.

Scenario principale:

1. L’utente clicca sul link del menù Gestione prenotazioni o in alternativaGestione menù;

2. Seleziona dal calendario il mese per il quale desidera scaricare il report;

3. Preme il pulsante Scarica report posizionato sotto al calendario;

4. L’utente attende l’elaborazione della richiesta;

5. Il browser avvia il download del file in formato xlsx.

Postcondizioni: L’utente ha scaricato il foglio elettronico contenente informa-zioni sulle prenotazioni del mese selezionato.

Estensioni:

5a. Visualizzazione di un messaggio d’errore nel caso non sia possibile soddisfarela richiesta (UC-5).

Page 46: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

36 CAPITOLO 3. ANALISI DEI REQUISITI

3.3.1 Casi d’uso per l’utente base

In questa sezione sono descritti i casi d’uso che riguardano solo gli utenti base (nonamministratori). La visualizzazione del messaggio di errore è implementata allo stessomodo di quella già descritta per l’amministratore, quindi i casi d’uso seguenti siriferiranno comunque all’UC-5.

UC-17: Visualizzazione della prenotazione effettuata in ungiornoAttori Principali: Utente base autenticato.

Precondizioni: L’utente si trova sulla Homepage.

Descrizione: L’utente base può selezionare un giorno per visualizzare le pre-notazioni già effettuate per i pasti di quella giornata, oppure in caso contrarioaggiungerne una (vedi UC-18).

Scenario principale:

1. L’utente clicca sul link per accedere alla pagina Prenotazione;

2. Viene visualizzata la pagina con il calendario;

3. L’utente clicca la data che desidera visualizzare;

4. L’utente è rediretto sulla pagina di prenotazione di quel giorno;

5. L’utente attende il caricamento dei dati;

6. Visualizza la prenotazione effettuata per pranzo e per cena.

Postcondizioni: Il sistema mostra le prenotazioni effettuate in quella giornata.

Estensioni:

6a. Visualizzazione di un messaggio d’errore se è impossibile scaricare i dati delform (UC-5);

6b. Non è stata effettuata nessuna prenotazione (UC-17.1).

Page 47: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

3.3. CASI D’USO 37

UC-17.1: Visualizzazione messaggio di assenza di prenota-zioniAttori Principali: Utente base autenticato.

Precondizioni: L’utente si trova sulla pagina di prenotazione di una giornataper la quale non ha ancora prenotato nè il pranzo nè la cena.

Descrizione: Nel caso non vi siano prenotazioni per il pasto di una giornata, unmessaggio lo segnalerà all’utente.

Scenario principale:

1. Viene visualizzato il messaggio che specifica l’assenza di prenotazioni perquel giorno.

Postcondizioni: Il sistema visualizza un messaggio riguardo all’assenza diprenotazioni. La lista di prenotazioni non è visualizzata.

Page 48: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

38 CAPITOLO 3. ANALISI DEI REQUISITI

UC-18: Aggiunta di una prenotazione da un account utente

Attori Principali: Utente base autenticato.

Precondizioni: L’utente si trova sulla pagina Prenotazione per una certa giornata.

Descrizione: L’utente desidera inserire una prenotazione per pranzo o per cenaper la giornata che sta visualizzando.

Scenario principale:

1. L’utente preme il pulsante di aggiunta posto sopra l’eventuale prenotazionevisualizzata;

2. Attende il caricamento dei dati del form;

3. L’utente compila il form come specificato nei sotto-casi (UC-18.3 - UC-18.9);

4. L’utente conferma la prenotazione premendo sul tasto Aggiungi ;

5. Attende l’elaborazione della richiesta;

6. Il sistema visualizza la pagina precedente con la nuova prenotazione effet-tuata.

Postcondizioni: L’utente ha aggiunto una nuova prenotazione.

Estensioni:

2a. Visualizzazione di un messaggio che avvisa l’impossibilità di prenotare(UC-18.10);

3a. Visualizzazione di un messaggio d’errore se è impossibile scaricare i dati delform (UC-5);

4a. L’utente non conferma l’inserimento della prenotazione (UC-18.2);

5a. Visualizzazione di un messaggio d’errore di compilazione del form (UC-18.1);

6a. Visualizzazione di un messaggio errore di aggiunta della prenotazione (UC-5).

Page 49: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

3.3. CASI D’USO 39

UC-18.1: Visualizzazione messaggio d’errore di compilazio-ne del formAttori Principali: Utente base autenticato.

Precondizioni: L’utente sta aggiungendo una prenotazione e ha confermato idati inseriti nel form.

Descrizione: Uno o più campi del form non sono stati compilati correttamente,quindi viene segnalato l’errore sotto i campi non corretti.

Scenario principale:

1. Viene visualizzato il messaggio d’errore sul campo non corretto.

Postcondizioni: Sotto i campi errati del form compare un errore che invital’utente a correggere l’inserimento.

UC-18.2: Annullamento dell’aggiunta della prenotazioneAttori Principali: Utente amministratore autenticato.

Precondizioni: L’amministratore sta aggiungendo una prenotazione per unutente.

Descrizione: Nel caso l’utente non desideri inserire la prenotazione può chiudereil form e annullare l’inserimento.

Scenario principale:

1. L’utente preme il pulsante Annulla;

2. Il form sparisce e l’utente ritorna alla pagina Prenotazione.

Postcondizioni: L’utente visualizza le prenotazioni effettuate ma nessuna nuovaprenotazione è stata aggiunta.

Page 50: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

40 CAPITOLO 3. ANALISI DEI REQUISITI

UC-18.3: Selezione del pasto da prenotareAttori Principali: Utente base autenticato.

Precondizioni: L’utente sta aggiungendo una prenotazione attraverso la compi-lazione del form.

Descrizione: È necessario specificare se la prenotazione da effettuare riguarda ilpranzo o la cena.

Scenario principale:

1. L’utente seleziona il pasto desiderato premendo il pulsante Pranzo oppureCena;

2. L’utente attende il caricamento del menù per quel pasto.

Postcondizioni: L’utente ha indicato il pasto da prenotare.

UC-18.4: Selezione del primo piattoAttori Principali: Utente base autenticato.

Precondizioni: L’utente sta aggiungendo una prenotazione per se stesso attra-verso la compilazione del form.

Descrizione: È necessario inserire almeno un piatto per effettuare la prenotazio-ne. È possibile sceglierne uno per categoria (primo, secondo, ecc).

Scenario principale:

1. L’utente seleziona il primo piatto che desidera fra quelli elencati, oppureseleziona Nessuno.

Postcondizioni: L’utente ha selezionato il primo piatto da prenotare.

Page 51: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

3.3. CASI D’USO 41

UC-18.5: Selezione del secondo piattoAttori Principali: Utente base autenticato.

Precondizioni: L’utente sta aggiungendo una prenotazione attraverso la compi-lazione del form.

Descrizione: È necessario inserire almeno un piatto per effettuare la prenotazio-ne. È possibile sceglierne uno per categoria (primo, secondo, ecc).

Scenario principale:

1. L’utente seleziona il secondo piatto che desidera fra quelli elencati, oppureseleziona Nessuno.

Postcondizioni: L’utente ha selezionato il secondo piatto da prenotare.

UC-18.6: Selezione del contornoAttori Principali: Utente base autenticato.

Precondizioni: L’utente base sta aggiungendo una prenotazione attraverso lacompilazione del form.

Descrizione: È necessario inserire almeno un piatto per effettuare la prenotazione.È possibile sceglierne uno per categoria (primo, secondo, ecc).

Scenario principale:

1. L’utente seleziona il contorno che desidera fra quelli elencati, oppure selezionaNessuno.

Postcondizioni: L’utente ha selezionato il contorno da prenotare.

UC-18.7: Selezione del dessertAttori Principali: Utente base autenticato.

Precondizioni: L’utente sta aggiungendo una prenotazione attraverso la compi-lazione del form.

Descrizione: È necessario inserire almeno un piatto per effettuare la prenotazio-ne. È possibile sceglierne uno per categoria (primo, secondo, ecc).

Scenario principale:

1. L’utente seleziona il dessert che desidera fra quelli elencati, oppure selezionaNessuno.

Postcondizioni: L’utente ha selezionato il dessert da prenotare.

Page 52: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

42 CAPITOLO 3. ANALISI DEI REQUISITI

UC-18.8: Selezione dell’ora della prenotazioneAttori Principali: Utente base autenticato.

Precondizioni: L’utente sta aggiungendo una prenotazione attraverso la compi-lazione del form.

Descrizione: Per agevolare la preparazione dei piatti ogni utente deve specificarel’ora nella quale ha intenzione di consumare il pasto, entro un range valido. Ilcampo è precompilato con un valore di default.

Scenario principale:

1. L’utente digita l’orario nella casella dedicata oppure lascia il valore preim-postato.

Postcondizioni: L’utente ha inserito l’orario della prenotazione.

UC-18.9: Scelta di un pranzo a saccoAttori Principali: Utente base autenticato.

Precondizioni: L’utente sta aggiungendo una prenotazione attraverso la compi-lazione del form.

Descrizione: È disponibile un’opzione per prenotare un pranzo al sacco. In que-sto caso non è però possibile selezionare il piatto e l’orario, e i campi in questioneverranno disabilitati.

Scenario principale:

1. L’utente spunta il checkbox corrispondente a Pranzo al sacco.

Postcondizioni: L’utente ha specificato di voler prenotare un pranzo a sacco.

Page 53: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

3.3. CASI D’USO 43

UC-18.10: Visualizzazione messaggio di chiusura delle pre-notazioniAttori Principali: Utente base autenticato.

Precondizioni: L’utente base ha cercato di cliccare il pulsante di aggiunta diuna prenotazione.

Descrizione: L’aggiunta di prenotazioni giornaliere per gli utenti base è possibilesolo fino ad un certo numero di ore dal pasto, al fine di semplificare le operazionidi preparazione.

Scenario principale:

1. Il sistema visualizza un messaggio che segnala l’impossibilità di prenotareun pasto.

Postcondizioni: Il sistema visualizza un messaggio per avvisare l’utente.

UC-19: Eliminazione di una prenotazione da un accountutenteAttori Principali: Utente base autenticato.

Precondizioni: L’utente si trova sulla pagina Prenotazione per una certa gior-nata e ha effettuato la prenotazione per almeno uno dei due pasti.

Descrizione: L’utente desidera rimuovere una prenotazione mostrata nella pagi-na, per pranzo o per cena.

Scenario principale:

1. L’utente preme il pulsante di eliminazione posto sotto la prenotazione chevuole rimuovere;

2. Viene visualizzata una richiesta di conferma della rimozione;

3. L’utente conferma la sua scelta;

4. Il sistema elabora la richiesta chiedendo all’utente di attendere;

5. Viene aggiornata la pagina nella quale la prenotazione non è più presente.

Postcondizioni: L’utente ha rimosso una prenotazione.

Estensioni:

3a. L’utente non conferma la rimozione (UC-19.1);

5a. Visualizzazione di un messaggio errore nel completare l’eliminazione dellaprenotazione (UC-5).

Page 54: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

44 CAPITOLO 3. ANALISI DEI REQUISITI

UC-19.1: Annullamento della richiesta di eliminazione di unpiattoAttori Principali: Utente base autenticato.

Precondizioni: L’utente visualizza la richiesta di conferma della rimozione dellaprenotazione.

Descrizione: L’utente vuole annullare l’operazione, ad esempio perché effettuataaccidentalmente.

Scenario principale:

1. L’utente preme il pulsante Annulla sulla parte bassa del pannello modale.

2. Il messaggio viene chiuso e non viene eliminato alcun elemento.

Postcondizioni: L’utente si trova sulla pagina Prenotazione e l’elenco di preno-tazioni è rimasto invariato.

Page 55: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

3.4. TRACCIAMENTO DEI REQUISITI 45

3.4 Tracciamento dei requisitiA seguito delle conversazioni avute con il proponente e con il tutor aziendale durante losvolgimento dello stage, è stato possibile classificare le richieste in un elenco di requisitiriportati nelle tabelle di seguito. Essi includono sia requisiti riguardanti il prodotto darealizzare, che requisiti riguardanti le modalità di sviluppo e il raggiungimento degliobiettivi previsti nel percorso formativo. Per poterli distinguere in modo preciso èstata usata la classificazione qui riportata:

R[Importanza][Tipologia]-[Codice]

Ad ogni parametro corrispondono i seguenti valori:

• Importanza: può assumere i seguenti valori:

O : indica un requisito obbligatorio;

D : indica un requisito desiderabile;

F : indica un requisito facoltativo (opzionale).

• Tipologia: può assumere i seguenti valori:

F : requisito funzionale: rappresenta le funzionalità che il prodotto deve fornire;

Q : indica un requisito qualitativo. Rappresenta gli elementi per aumentare illivello di qualità del prodotto finale;

P : requisito prestazionale: rappresenta un valore misurabile delle performanceraggiunte dal prodotto terminato;

V : requisito di vincolo: rappresenta le limitazioni che il prodotto deve rispettare.

• Codice: codice numerico che identifica il requisito; è univoco ed indicato in formagerarchica, da sinistra verso destra, nel formato X.Y.Z.

Nelle tabelle 3.1, 3.2, 3.3 e 3.4 sono riassunti i requisiti e il loro tracciamento con i casid’uso delineati in fase di analisi.

Tabella 3.1: Tabella di tracciamento dei requisiti funzionali

Requisito Descrizione Use Case

ROF-1 L’utente deve poter accedere all’applicazione web UC-1

ROF-2 L’utente deve poter effettuare il logout dallapiattaforma

UC-2

RFF-3 L’utente base deve poter inserire una prenotazione UC-18

RFF-3.1 L’utente base deve poter visualizzare tutti i piattidisponibili, compresi i pasti alternativi

UC-18.4,

UC-18.5,

UC-18.6,

UC-18.7

RFF-3.2 L’utente base deve poter selezionare la prenotazioneper pranzo o per cena

UC-18.3

Page 56: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

46 CAPITOLO 3. ANALISI DEI REQUISITI

Tabella 3.1: Tabella di tracciamento dei requisiti funzionali (continuazione)

Requisito Descrizione Use Case

RFF-3.3 L’utente base deve poter selezionare il giorno dellaprenotazione tramite un calendario cliccabile

UC-17,

UC-18

RFF-3.4 L’utente base deve poter esprimere una preferenza diorario della prenotazione

UC-18.8

RFF-3.5 L’utente base deve poter scegliere l’opzione "pranzoa sacco"

UC-18.9

RFF-3.6 La procedura di inserimento della prenotazione diun utente base deve poter essere interrotta da uncerto orario in avanti della giornata stessa dellaprenotazione

UC-18.10

RFF-3.7 Il sistema deve rilevare la mancata prenotazionedel pasto e suggerire all’utente di procedere allaprenotazione

UC-17.1

ROF-4 L’amministratore deve poter visualizzare le prenota-zioni

UC-3

ROF-4.1 L’amministratore deve poter visualizzare le prenota-zioni per pranzo

UC-3.1

ROF-4.2 L’amministratore deve poter visualizzare le prenota-zioni per cena

UC-3.2

ROF-4.3 L’amministratore deve poter visualizzare le prenota-zioni suddivise per pasti

UC-3.3

ROF-4.4 L’amministratore deve poter visualizzare il numerodi prenotazioni per ogni piatto

UC-3.3

RDF-4.5 L’amministratore deve poter visualizzare i nomi degliutenti prenotati per ogni piatto

UC-3.4

RDF-4.6 L’amministratore deve poter visualizzare gli orari diprenotazione per ogni utente prenotato

UC-3.4

ROF-4.7 L’amministratore deve poter visualizzare le prenota-zioni divise per persone

UC-3.5

ROF-5 L’amministratore deve poter inserire una prenotazionea nome di un utente

UC-6

ROF-5.1 L’amministratore deve poter scegliere il nomedell’utente della prenotazione da una lista

UC-6.3

RDF-5.2 L’amministratore deve poter esprimere una preferenzadi orario nella prenotazione

UC-6.8

RDF-5.3 L’amministratore deve poter scegliere l’opzione"pranzo a sacco"

UC-6.9

Page 57: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

3.4. TRACCIAMENTO DEI REQUISITI 47

Tabella 3.1: Tabella di tracciamento dei requisiti funzionali (continuazione)

Requisito Descrizione Use Case

ROF-5.4 Il sistema deve controllare la validità dei campi dellaprenotazione e mostrare errori appropriati

UC-6.1

ROF-6 L’amministratore deve poter eliminare una prenota-zione

UC-7

RDF-7 L’amministratore deve poter cercare la prenotazionedi un utente nella lista

UC-8

RDF-8 Ogni lista di piatti deve essere filtrabile per tipo UC-4

RDF-8.1 Deve essere possibile filtrare i piatti per primi UC-4.1

RDF-8.2 Deve essere possibile filtrare i piatti per secondi UC-4.2

RDF-8.3 Deve essere possibile filtrare i piatti per contorni UC-4.3

RDF-8.4 Deve essere possibile filtrare i piatti per dessert UC-4.4

RDF-8.5 Deve essere possibile rimuovere il filtro UC-4.5

ROF-9 L’amministratore deve poter visualizzare tutti i piattidisponibili nel sistema, compresi i pasti alternativi

UC-12

ROF-10 L’amministratore deve poter aggiungere un piatto alsistema

UC-14

ROF-10.1 L’amministratore deve poter dare un nome al piatto UC-14.1

ROF-10.2 L’amministratore deve poter assegnare un tipo alpiatto

UC-14.2

ROF-10.3 L’amministratore deve poter inserire una lista diingredienti del piatto

UC-14.3

ROF-10.4 il sistema deve controllare la validità delle informazio-ni inserite e mostrare errori appropriati

UC-14.4

ROF-11 l’amministratore deve poter eliminare un piattoinserito nel sistema

UC-15

RDF-12 L’amministratore deve poter cercare un piatto fraquelli presenti nella lista

UC-13

ROF-13 L’amministratore deve poter modificare il menu delgiorno selezionando i piatti da rendere disponibili

UC-10

ROF-13.1 L’amministratore deve poter modificare il menu delgiorno a pranzo selezionando i piatti da renderedisponibili

UC-10,

UC-9.1

ROF-13.2 L’amministratore deve poter modificare il menudel giorno a cena selezionando i piatti da renderedisponibili

UC-10,

UC-9.2

Page 58: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

48 CAPITOLO 3. ANALISI DEI REQUISITI

Tabella 3.1: Tabella di tracciamento dei requisiti funzionali (continuazione)

Requisito Descrizione Use Case

ROF-13.3 L’amministratore deve poter inserire nel menù unalista di primi piatti

UC-10

ROF-13.4 L’amministratore deve poter inserire nel menù unalista di secondi piatti

UC-10

ROF-13.5 L’amministratore deve poter inserire nel menù unalista di contorni

UC-10

ROF-13.6 L’amministratore deve poter inserire nel menù unalista di dessert

UC-10

ROF-14 L’amministratore deve poter eliminare l’intero menùdi una giornata

UC-11

ROF-15 Il sistema deve segnalare errori opportuni in caso didifficoltà di collegamento al server

UC-5

RDF-15.1 I messaggi di errore devono essere poco intrusivi epoter essere rimossi

UC-5.1

RDF-16 L’amministratore deve poter scaricare dei report men-sili che contengano l’elenco dei piatti prenotati con ilrelativo numero di prenotazioni

UC-16

Tabella 3.2: Tabella di tracciamento dei requisiti qualitativi

Requisito Descrizione Use Case

ROQ-1 Il sistema deve garantire la sicurezza nellatrasmissione dei dati

-

RDQ-1.1 Il sistema deve usare il sistema di autenticazione deidati tramite token

-

RDQ-2 L’applicazione deve essere fruibile con ogni browserrecente disponibile

-

RFQ-3 L’applicazione va testata in un contesto di realeutilizzo

-

Page 59: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

3.4. TRACCIAMENTO DEI REQUISITI 49

Tabella 3.3: Tabella di tracciamento dei requisiti prestazionali

Requisito Descrizione Use Case

ROP-1 L’accesso al sito da un deve avvenire senza difficol-tà prestazionali su un dispositivo mobile dotato diconnessione a internet attiva

-

ROP-1.1 Il sito deve essere utilizzabile senza difficoltàprestazionali su un browser di un dispositivo Android

-

ROP-1.2 Il sito deve essere utilizzabile senza difficoltàprestazionali su un browser di un dispositivo iOS

-

Tabella 3.4: Tabella di tracciamento dei requisiti di vincolo

Requisito Descrizione Use Case

ROV-1 L’applicazione va sviluppata con la libreria JavaScriptReact.js

-

RDV-2 L’applicazione va sviluppata utilizzando la libreriaBootstrap

-

ROV-3 Il frontend si deve appoggiare ad un mock di serverrealizzato con JSON Server

-

ROV-4 L’applicazione deve fare utilizzo di un databaseesterno per effettuare l’autenticazione

-

RDV-5 Deve essere possibile l’autenticazione tramite creden-ziali degli studenti

-

ROV-6 Il report mensile scaricabile dovrebbe essere pre-feribilmente in formato xlsx o alternativamentepdf

-

ROV-7 Fornire una relazione sulle differenze riscontrate fral’utilizzo di React.js e Angular

-

Si noti che i requisiti ROV-4, RDV-5 non riguardano il livello front-end dell’applicazio-ne.

Page 60: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React
Page 61: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

Capitolo 4

Progettazione e codifica

Nel presente capitolo sono descritti gli strumenti utilizzati durante lo sviluppo e le scelteprogettuali messe in opera nella versione finale dell’applicazione. È inoltre fornita unapanoramica generale sul funzionamento di React e della libreria Redux.

4.1 Tecnologie e strumenti

Nella seguente sezione sono descritti gli strumenti di sviluppo utilizzati durante ilpercorso formativo.

4.1.1 Ambiente di sviluppo

Lo sviluppo è stato interamente effettuato sul sistema operativo Ubuntu[g] 17.10.Inoltre, non essendo stati posti vincoli sulle versioni da utilizzare, ho fatto uso delleultime versioni disponibili per ogni pacchetto o strumento. La versione di React.jsadoperata è la 16.4.2.

4.1.1.1 IDE

Per la scrittura del codice l’azienda ospitante mi ha lasciato libertà di scelta e houtilizzato l’IDE[g] Visual Studio Code, che offre una grande varietà di utili estensioniscaricabili gratuitamente dallo store integrato.

4.1.1.2 Strumenti per la documentazione

Per la redazione della documentazione ho utilizzato l’editor LATEX TexStudio[g] 2.11.2 el’editor per il linguaggio Markdown[g] Typhora[g] 0.9.56. Per rappresentare le relazionifra componenti ho utilizzato PlantUML[g], facilmente utilizzabile installando il pluginapposito per Visual Studio Code.

4.1.1.3 Versionamento

Per il versionamento[g] del codice e delle modifiche alla documentazione ho utilizzatouna repository privata creata sulla piattaforma GitHub[g].

51

Page 62: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

52 CAPITOLO 4. PROGETTAZIONE E CODIFICA

4.1.2 Strumenti di supporto allo sviluppo

JSON Server

Questo pacchetto permette di configurare rapidamente un finto server, creato conNode.js[g], che risponde a richieste HTTP con dati nel formato JSON[g]. All’interno diun file è possibile specificare un numero a piacere di endpoint[g] e le rispettive risposte.

Eslint

Si tratta del plugin per l’IDE con funzione di linter[g] utile a mantenere una buonaleggibilità e qualità del codice scritto. È stato configurato con le regole della guida distile AirBnb appositamente adattate alla sintassi di React e JSX[g]1.

Jsx-a11y (plugin eslint)

Si tratta di un’estensione del set di regole di eslint che forniscono suggerimenti esegnalano errori riguardanti l’accessibilità del sito web. È installabile con il pacchettoeslint-plugin-jsx-a11y.

4.1.3 Linguaggio utilizzato

Per lo sviluppo dell’applicazione in React.js ho utilizzato il linguaggio JavaScript.Come alternativa, sarebbe stato possibile utilizzare TypeScript[g]. Tuttavia è molto piùsemplice reperire online guide ed esempi di progetti React sviluppati in JavaScript enon avendo esperienza pregressa di sviluppo con React.js, questo aspetto rappresentavaun considerevole vantaggio nel lavoro da svolgere.La stessa documentazione ufficiale di React e di altri pacchetti utilizzati presupponel’utilizzo di JavaScript.Inoltre ho utilizzato estensivamente la notazione e le funzionalità introdotte nellaversione ES7 di JavaScript, che quindi deve essere supportato dal browser.

4.1.4 Principali dipendenze

React.js è una libreria con poche funzionalità. Al fine di sviluppare l’applicazione misono appoggiato all’ampia collezione di pacchetti installabili tramite npm[g], che hannosemplificato lo sviluppo.Di seguito viene fornita una descrizione per i principali pacchetti necessari per ilfunzionamento dell’applicazione realizzata.

Redux.js

Si tratta di una libreria di state management creata appositamente per React.js.Permette l’utilizzo di uno Store globale che contiene idealmente l’intero stato dell’ap-plicazione. Tramite l’utilizzo dei collegamenti ufficiali con React offerti dal pacchettoreact-redux viene data la possibilità di utilizzare lo Store come un modello di datie collegarlo ai componenti (le view) con un meccanismo analogo a quello del designpattern Observer. È stata utilizzata la versione 4.0.0.

1https://github.com/airbnb/javascript/tree/master/react

Page 63: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

4.1. TECNOLOGIE E STRUMENTI 53

React-router

Questo pacchetto permette di effettuare routing client side caricando componentidinamicamente in base all’indirizzo della pagina.

Reselect

Una delle best practice in React consigliata dalla documentazione ufficiale è utilizzare imemoized selector. Un selector o selettore è una funzione che recupera i dati per uncomponente. L’utilizzo di questa libreria permette di creare selector che memorizzanol’output precedente e rieffettuano la chiamata vera e propria solo se uno dei parametridella funzione è cambiato. Altrimenti utilizzano la precedente versione, migliorando leperformance.

Jsonwebtoken

Per garantire un accesso sicuro all’applicazione, su suggerimento del tutor aziendale,abbiamo dedicato del tempo alla ricerca di un metodo adatto a tale scopo. Abbiamoscelto di utilizzare un approccio tramite token di accesso: nel momento in cui unutente accede al servizio, il server invia un token codificato che contiene le informazionidell’utente. Ogni richiesta successiva dell’utente verso il server deve includere il tokeninviatogli, altrimenti il server segnalerà un errore.La libreria Jsonwebtoken fornisce un’implementazione dello standard JWT[g] cheriguarda la codifica e la decodifica di token.

Redux-persist

Tale libreria offre un semplice meccanismo per far persistere i dati dal Redux Store nelSession Storage[g] o nel Local Storage. È stata utilizzata per salvare il token di accessonel Session Storage per garantire il recupero delle informazioni dell’utente autenticatodopo un refresh della pagina.

Redux-thunk

Un middleware[g] per definire action creators asincrone con effetti collaterali utilizzandoRedux.

Validator.js

Questa libreria è stata utilizzata per scrivere funzioni di validazione dei form dell’ap-plicazione. Fornisce una serie di utilità per controllare vari parametri spesso utili nelcontrollo dell’input dei form, quali verifica della lunghezza del testo, controllo dellavalidità degli indirizzi email, supporto a espressioni regolari[g]ed altro.

React-bootstrap

Dispone di una collezione di componenti per React.js che utilizzano le classi e lo stiledi Bootstrap[g] v3.

4.1.5 Creazione di un server fittizioDurante le prime settimane di stage il back-end dell’applicazione non era ancora attivo.Per verificare il corretto funzionamento delle pagine e per scrivere i primi test, su

Page 64: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

54 CAPITOLO 4. PROGETTAZIONE E CODIFICA

suggerimento del tutor aziendale, ho avviato e configurato un finto server utilizzando lefunzionalità di JSON Server. L’obiettivo di questo server era inviare una risposta allerichieste HTTP effettuate dall’applicazione. I file di configurazione sono situati nellacartella src/server della cartella del progetto ed esso è avviabile tramite il comandonpm run server.Ad ogni modo l’applicazione si interfaccia ora con il reale server, ospitato dal serveraziendale e raggiungibile in VPN[g], quindi il mock[g] creato con JSON server non èstato più aggiornato.

Page 65: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

4.2. FUNZIONAMENTO DI REDUX E REACT.JS 55

import React from ’react’;

export class Component extends React.Component {constructor(props) {

super(props)this.state = {

nomeutente = "nome"field = this.props.fieldValue

}}

render() { // specifica l’HTML a cui corrisponde il componentreturn (

<div><ChildComponent

data={this.state.nomeutente}num="1"

/></div>

)}

}

Codice 4.1: Esempio di componente in React.js

4.2 Funzionamento di Redux e React.js

4.2.1 Struttura a componenti

React.js si basa sul concetto di componenti (o component), che rappresentano i tassellicon i quali è costruita una pagina web. Essi sono classi o funzioni JavaScript checontrollano l’aspetto e definiscono il comportamento di un certo frammento di codiceHTML.Un semplice esempio di componente è riportato nel frammento di codice 4.1.Nel metodo render() è definito il codice HTML che viene visualizzato sulla paginaogni volta che il componente viene caricato.Nell’esempio il componente Component ha uno stato interno che viene inizializzato adogni caricamento come indicato nel costruttore.Nello stato interno di un componente possono essere mantenute informazioni di ognitipo. Ad esempio nella compilazione dei form, this.state è il luogo nel quale sonosolitamente mantenuti i valori inseriti dall’utente in attesa del submit.Spesso alcuni campi mantenuti nello stato interno di un componente devono essere resinoti a componenti figli, ovvero componenti annidati all’interno di un altro componente.Il campo data rappresenta un esempio di passaggio della proprietà nomeutente alcomponente figlio ChildComponent. Le proprietà data e num sono chiamati props esaranno accessibili in ogni metodo del componente figlio come this.props.data ethis.props.num.React quindi si basa sul passaggio di props lungo la gerarchia di componenti che

Page 66: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

56 CAPITOLO 4. PROGETTAZIONE E CODIFICA

Figura 4.1: Raffigurazione del passaggio di props e invocazione di callback nell’albero dicomponenti di React.js [25]

formano un albero gerarchico. È anche possibile passare ai componenti figli dellecallback, ovvero dei metodi che in questo modo possono essere invocati da esso epossono alterare lo stato interno del componente padre (figura 4.1).

4.2.2 Redux

Nello stato interno dei componenti viene mantenuto lo stato dell’applicazione, cheinclude informazioni inserite dall’utente e lo stato dell’interfaccia grafica (ad esempioun campo dati che indica se un pannello è espanso oppure no).Se diversi componenti non relazionati fra loro hanno bisogno di accedere alle stesseinformazioni e soprattutto vogliono modificarle può essere scomodo spezzettare lo statofra vari componenti, perché porterebbe a definire un numero elevato di funzioni dicallback che può diventare difficile da mantenere.Per seguire un approccio più ordinato ho scelto di utilizzare la libreria Redux.Essa offre un contenitore globale dello stato per applicazioni JavaScript, che pur nonessendo specifica per React, permette una semplice integrazione dei due, grazie alpacchetto react-redux2.Il contenitore nel quale Redux mantiene lo stato dell’applicazione in forma di alberosi chiama Store. Da questo punto del documento in poi il termine Store sarà sempreutilizzato riferendosi allo store proprio di Redux (anche definito Redux Store).Inoltre l’utilizzo di React con Redux, al quale mi riferirò con React-Redux, fornisce unmodo semplice di separare la responsabilità del recupero dei dati (tramite chiamateHTTP) dalla responsabilità di visualizzarli nell’interfaccia.La chiave del funzionamento di React-Redux è l’iscrizione dei componenti a porzioni diRedux Store. Quando un valore del Redux Store è modificato, tutti i componenti iscrittial campo dati alterato sono notificati automaticamente ed aggiornati. La libreria

2https://github.com/reduxjs/react-redux

Page 67: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

4.2. FUNZIONAMENTO DI REDUX E REACT.JS 57

export const fetchDishesSuccess = json => {type: actionTypes.FETCH_DISHES_SUCCESS,payload: json

}

Codice 4.2: Una funzione action creator

fornisce quindi quindi un meccanismo di notifica che implementa il design patternObserver.Siccome l’iscrizione dei componenti con react-redux è effettuata esportando compo-nenti decorati dalla funzione connect(), per indicare un componente iscritto si parlaspesso di componente connesso allo Store. Inoltre secondo la notazione proposta daRedux un componente connesso viene chiamato container.

4.2.2.1 Azioni

Uno dei principi sul quale si fonda Redux è l’immutabilità dello Store: esso è in solalettura e non viene mai modificato direttamente. Quando è necessario mutare lo Store,ad esempio in seguito al click di un pulsante, deve essere effettuato il dispatch diun’azione. Un’azione è un oggetto JavaScript che specifica come lo stato deve esserecambiato e contiene il campo type per identificare il valore da cambiare e il campopayload che contiene il valore da sostituire. Tutte le azioni definite nell’applicazionesono create da funzioni chiamate action creator, tutte definite all’interno della cartellasrc/redux/actions, raggruppate in cartelle a seconda della pagina dei componentiche le utilizzano. Una di esse è riportata a titolo di esempio nel frammento di codice4.2.

4.2.2.2 Reducer

Ogni azione di cui viene effettuato il dispatch viene processata da un reducer. Si trattadi una funzione pura che riceve in input due parametri: lo stato contenuto nel ReduxStore e un’azione.Il compito del reducer è computare il nuovo stato con le modifiche descritte dalle azioni.Il reducer non deve modificare lo stato direttamente ed è importante che rispetti ilprincipio dell’immutabilità. Infatti i componenti iscritti al Redux Store, grazie allalibreria react-redux, per capire se è necessario effettuare un aggiornamento dei valorivisualizzati, controllano il cambiamento del riferimento della radice dell’albero dellostato (letteralmente effettuano uno shallow comparison). Per cui se il reducer effet-tuasse dei side effect per modificare lo stato esistente, si romperebbe il ciclo di notificae nessun componente sarebbe aggiornato.Del resto, anche React.js richiede l’immutabilità dello stato, nel senso che esso nondeve mai essere modificato direttamente, ma sempre tramite il metodo this.setStatedisponibile in ogni componente, che sostituisce lo stato piuttosto che modificarlo.I reducer possono essere composti per una migliore modularità. Nell’applicazionesviluppata essi sono definiti all’interno della cartella src/redux/reducers e sono rag-gruppati come specificato nel blocco di codice 4.3.

La figura 4.2 schematizza il funzionamento di React-Redux appena descritto.

Page 68: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

58 CAPITOLO 4. PROGETTAZIONE E CODIFICA

reducers/authentication/....contiene i reducer per i dati della pagina di accesso

authentication.reducer.jsisAuthenticated.reducer.jsmessages.reducer.jsui.reducer.jsuser.reducer.js

dishes/......contiene i reducer per i dati della pagina "Gestione piatti"dishes.reducer.jsdata.reducer.jsmessages.reducer.jsui.reducer.js

menus/data.reducer.jsmenus.reducer.jsmessages.reducer.jsui.reducer.js

reservations/data.reducer.jsmessages.reducer.jsreservations.reducer.jsui.reducer.js

reducer.js ........................................ root Redux reducer

Codice 4.3: Struttura della cartella nella quale sono definiti i reducer

Figura 4.2: Ciclo di interazione React-Redux [22]

Page 69: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

4.2. FUNZIONAMENTO DI REDUX E REACT.JS 59

4.2.2.3 Struttura dell’applicazione

Di seguito (codice 4.4) riporto l’organizzazione della cartella del progetto, commen-tando il contenuto delle cartelle principali, che per ragioni di spazio non è riportatointegralmente.I componenti utilizzati nelle pagine sono raggruppati in due cartelle: components econtainers, che contengono rispettivamente i componenti non connessi (iscritti) alRedux Store e quelli connessi.

Page 70: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

60 CAPITOLO 4. PROGETTAZIONE E CODIFICA

/index.jsApp.jsRoot.js............................componente radice dell’applicazionevalidation/............................validatori per i campi dei form

...css/..............................fogli di stile globali e css di Bootstrap

...test/......................................................file di test

...components/

Headers.jsAlert.jsReport.jsPanel.jsSmallSpinner.jsTabs.js...

containers/Navbar.jsAuth.jsWelcome.jsselectors/.........................cartella con i memoized selector

......

redux/............................definizione delle azioni e dei reducerHttp.js................................wrapper delle funzioni fetchactions/

reservations/...

dishes/...

authentication/...

menus/...

reducers/...........contiene i reducer con la struttura nel blocco 4.3...

...server/............................................file di JSONServer

...

Codice 4.4: Organizzazione della cartella del progetto

Page 71: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

4.3. PROGETTAZIONE 61

4.3 Progettazione

Parallelamente allo studio delle tecnologie da applicare nel progetto è stato necessarioprendere decisioni in merito ai seguenti punti:

• Gli endpoint da utilizzare nell’applicazione;

• La sicurezza dell’accesso alla piattaforma;

• L’organizzazione dei componenti;

• La struttura da utilizzare nel Redux Store.

4.3.1 Elenco di endpoint

L’applicazione utilizza i seguenti endpoint per la comunicazione con il back-end, raggrup-pati per pagina che ne fa uso. La parte comune degli indirizzi è definita all’interno del filesrc/redux/actions/baseURLs.js. Nell’elenco che segue i parametri nell’URL dellechiamate sono indicati inserendo un : prima del nome. Ad esempio url/base/:paramindica che param è un parametro variabile.

Login

• GET /authentication/api/login: utilizza il meccanismo basic authentica-tion[g] per inviare le credenziali nell’header della chiamata HTTP;

Gestione piatti

• GET /dish/api/dishes: ritorna un array di piatti contenente tutte le pietanzeinserite nel sistema;

• POST /dish/api/dishes: aggiunge un piatto. Nel body della richiesta sonoinserite le informazione del piatto da aggiungere. In caso di successo, il serverrisponde re-inviando il body della richiesta con in aggiunta il campo id del piattoinserito, che viene generato automaticamente dal server;

• DELETE /dish/api/dishes/:id: elimina il piatto con l’id specificato. La rispo-sta inviata dal server è un booleano, valorizzato a seconda che la cancellazionesia andata a buon fine o meno.

Gestione menù

• GET /menu/api/menuplan?day=aaaa-mm-gg: ritorna un oggetto contenente gliarray di piatti che sono inseriti nel menù del giorno specificato nel parametro diricerca sia per pranzo che per cena;

• POST /menu/api/menuplan: aggiunge il menù del giorno. Nel body della richiestasono inserite tutte le informazione dei piatti da aggiungere, divisi in due array,uno per pranzo e uno per cena, ed il giorno nel quale aggiungere il menù. In casodi successo, il server risponde re-inviando il body della richiesta con in aggiuntail campo id del menù inserito;

Page 72: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

62 CAPITOLO 4. PROGETTAZIONE E CODIFICA

• PUT /menu/api/menuplan: sovrascrive il menù del giorno. Il formato dellarichiesta è identico a quello specificato per la POST. L’unica differenza è cheviene ignorata la risposta del server, dato che, in questo caso, l’id del menù è giàconosciuto;

• DELETE /menu/api/menuplan/:id: elimina l’intero menù con l’id specificato.La risposta inviata dal server è un valore booleano.

Gestione prenotazioniLe chiamate a prenotazioni fanno uso di parametri di ricerca day, che specifica il giornodi cui ottenere le prenotazioni, in formato ISO-8601, e moment che specifica il pastodella giornata, che può essere pranzo o cena.

• GET /reservation/api/reservations/meals?day=aaaa-mm-gg&moment=lunc-h|dinner: ritorna l’array di piatti prenotati nel giorno specificato nel parametrodi ricerca per pranzo oppure per cena. Ogni piatto prenotato contiene un arraydi utenti che l’hanno prenotato e per ciascuno l’ora specificata nella prenotazione;

• GET /reservation/api/reservations/users?day=aaaa-mm-gg&moment=lunc-h|dinner: ritorna le prenotazioni con modalità analoghe alla precedente, maordinate per utente, visualizzate nella scheda "Vista utenti";

• POST /reservation/api/reservations: aggiunge una prenotazione. Il bodydella richiesta contiene data, ora, id dell’utente, momento (pranzo, cena) edelenco di piatti scelti. In caso di successo, il server risponde re-inviando il bodydella richiesta con in aggiunta il campo id della prenotazione inserita;

• GET /authentication/api/public/users: ottiene l’array contenente tutti gliutenti del sistema. È necessaria per selezionare il nome di un utente durantel’aggiunta di una prenotazione;

• DELETE /reservation/api/reservations/:id: elimina la prenotazione conl’id specificato. Il server risponde con un valore booleano.

Download del report

• GET /reservation/api/report/download?month=mm&year=aaaa: scarica il fo-glio di calcolo contenente il resoconto delle prenotazioni effettuate nel mese edanno specificato.

4.3.1.1 Gestione degli errori

Per segnalare il successo o il fallimento delle richieste HTTP, l’applicazione utilizza icodici di stato inseriti nelle risposte.In aggiunta, per distinguere certe situazioni nella risposta del server è stato inserito unparametro scope.Ci siamo accordati sulla seguente convenzione riguardo ai codici di stato:

• 200: segnala che l’operazione è andata a buon fine e nessun passo addizionale èrichiesto;

• 401/403/404: segnala un errore nel portare a termine la richiesta. Viene inseguito mostrato un messaggio d’errore all’utente;

Page 73: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

4.3. PROGETTAZIONE 63

• 404, scope="db": segnala che il database non contiene elementi da ritornare.È il caso in cui sia richiesto un array di oggetti ma non ne siano ancora statiinseriti. In questo caso non viene mostrato un messaggio d’errore, ma è ritornatoalla funzione chiamante un array o un oggetto vuoto.

In caso di errore, il server può definire il messaggio da visualizzare all’utente, in mododa fornire indicazioni più precise sulla ragione del fallimento. Per fare questo il serverpuò inserire nel body della risposta un campo message contenente il messaggio. Incaso esso non sia presente verrà visualizzato un errore generico generato dal front-enddell’applicazione.

4.3.2 Gestione dell’accesso

Per garantire che solamente gli utenti autorizzati possano interrogare il server, d’ac-cordo con il tutor aziendale e con lo stagista Samuele Bisello che si è occupato delback-end dell’applicazione, abbiamo deciso di gestire la sessione dell’utente con untoken. Per far questo abbiamo scelto di utilizzare lo standard JWT. Si tratta di unopen standard[g] che descrive un metodo di trasferimento sicuro di informazioni fradue parti.Il back-end espone un microservizio di autenticazione (figura 4.3) che al momento dellogin viene interrogato dal client. Questo microservizio accede al database di utenti everifica la correttezza delle credenziali inserite. Se sono corrette risponde con un token,ovvero una stringa codificata che contiene le informazioni dell’account dell’utente,ovvero il suo nome e il tipo di account (admin oppure user se è un utente base).Ogni microservizio, a parte quello di autenticazione, effettua un controllo del token cheè inserito nel campo Authorization dell’header della richiesta, secondo lo schema bea-rer authorization[g] standard. Nel caso il token non sia corretto il server segnala l’errore.

L’immagine 4.4 evidenzia le tre parti di cui è costituito un token JWT scambiato fra ilserver e l’applicazione. Ogni sezione è separata da un punto:

• Header: specifica l’algoritmo di codifica e altri informazioni utili alla decodifica;

• Payload: contiene i dati dell’utente;

• Firma: è la firma, effettuata con l’algoritmo specificato nell’header, per verifi-carne la validità e l’integrità.

Le informazioni trasmesse nel token non sono criptate, e per questo non contengonomai nessuna informazione sensibile come la password dell’account.

4.3.2.1 Persistenza della sessione

Il token viene salvato nel Session Storage, ovvero il database chiave/valore nel quale unsito web può salvare informazioni nel browser dell’utente, utilizzabile come alternativaai cookies [24].Questa informazione, come verrà detto più avanti, è infatti salvata nel Redux Store,che tuttavia, ad un ricaricamento della pagina, viene completamente svuotato. Quindisalvare il token nel Session Storage permette di preservare la sessione dopo il refresh.Dal token possono essere poi estratte le altre informazioni dell’account che non servequindi mantenere.

Page 74: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

64 CAPITOLO 4. PROGETTAZIONE E CODIFICA

Figura 4.3: Schema del funzionamento del token con i microservizi

Page 75: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

4.3. PROGETTAZIONE 65

Figura 4.4: Le tre parti di un JWT token

La persistenza del token nel Session Storage è effettuata tramite le funzionalità dellalibreria redux-persist.Questa libreria permette di aggiungere le funzionalità di persistenza ad uno o piùreducer in modo che ogni volta essi debbano effettuare un cambiamento al Redux Storelo riflettano anche sul Session Storage. Inoltre quando lo Store viene svuotato con unricaricamento della pagina vengono automaticamente ripristinati i campi salvati sulloStorage.È possibile configurare la libreria per salvare solo determinate porzioni dello Store,specificando come i dati devono essere trasformati quando vengono salvati sul SessionStorage (operazione di persistence) e quando vengono ripristinati da esso (operazionechiamata rehydration). Queste operazioni sono definite per il reducer principale, nelfile src/redux/reducers/reducer.js.

Page 76: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

66 CAPITOLO 4. PROGETTAZIONE E CODIFICA

4.3.3 Struttura del Redux Store

La struttura dello stato dell’applicazione conservato nello Store di Redux è mostratonella figura 4.5.Il nodo principale ha quattro figli, uno per ogni pagina pagina dell’applicazione (inodi dall’alto verso il basso corrispondono a Gestione prenotazioni, Gestione menù,Gestione piatti e Login).Le informazioni necessarie ad ogni pagina sono state suddivise in tre categorie,rappresentate dai rispettivi nodi:

• data: contiene i dati ottenuti dal server che l’applicazione deve mostrare, chesono quasi sempre liste di oggetti;

• ui : contiene campi dati che riguardano lo stato dell’interfaccia grafica, come ilfiltro applicato dall’utente o il testo inserito nella casella di ricerca. Quando ilcampo loading è true viene visualizzato uno spinner che segnala il caricamentodei dati della pagina;

• messages: qui sono inseriti tutti i testi dei messaggi di errore, delle pagine o deiform, e anche eventuali messaggi che segnalano il completamento di un’operazione.

Tutti i nodi di secondo e terzo livello (rappresentati in viola nell’immagine) sono alteratida uno specifico reducer, in linea con il principio di composizione di reducer consigliatodalla documentazione di Redux.Il nodo _persist è inserito automaticamente dalla libreria redux-persist. Il nodofiglio rehydrated viene impostato a true quando l’operazione di rehydration (ovveroripristino) dal Session Storage è completata, mentre version è un numero di versioneche incrementa ad ogni ciclo di persistenza.

4.3.3.1 Dati dei form

I dati temporanei che l’utente amministratore inserisce compilando i form di aggiunta diun piatto o di una prenotazione non sono mantenuti nel Redux Store, ma nello stato inter-no dei componenti che visualizzano i form, che sono DishForm e AddReservationForm,e si trovano rispettivamente dentro la cartella src/containers/dishes e src/contain-ers/reservations.Anche utilizzando Redux, non vi è infatti l’obbligo di usare solo lo Store per salvare lostato dell’applicazione. Alcune informazioni provvisorie o che non sono di interesse pernessun altro componente possono essere conservate direttamente nel componente chene fa uso.

Page 77: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

4.3. PROGETTAZIONE 67

Figura 4.5: Albero dello stato dell’applicazione salvato nel Redux Store

Page 78: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

68 CAPITOLO 4. PROGETTAZIONE E CODIFICA

Figura 4.6: Esempio di alcuni componenti all’interno del componente ResPage

4.3.4 Componenti

4.3.4.1 Struttura di una pagina

Ogni pagina dell’applicazione è costituita da un aggregato di componenti e containerannidati uno dentro l’altro.Il componente di più alto livello è Root che è il componente utilizzato all’interno diindex.js che è il file dal quale comincia la costruzione di ogni pagina.Lo scopo di Root è definire i componenti wrapper che servono per il funzionamentodi Redux e redux-persist. All’interno di questi due componenti è inserito App cheè la radice di tutta l’applicazione e contiene la dichiarazione delle Route, ovvero icomponenti di react-router che servono per specificare quali componenti caricarea seconda dell’indirizzo della pagina. In figura 4.6 è mostrata la pagina Gestioneprenotazioni nella quale sono stati riquadrati i componenti principali.

In questo caso, parlando di componenti intendo anche componenti connessi allo Store,ovvero container. Ad esempio ViewTabs (in figura) è un container specifico per cambiaremodalità di visualizzazione delle prenotazioni nella pagina Gestione prenotazioni. Ilcontainer MomentTabs, che non è mostrato in figura, gestisce invece i due tab a destra(per passare da pranzo a cena). Entrambi utilizzano il componente Tabs come templatee lo collegano ai rispettivi valori del Redux Store. Come si vede dal blocco 4.5 l’unicocompito del container è collegare le props del componente Tabs ai corretti valoridello Store tramite la funzione mapStateToProps. La funzione mapDispatchToPropsfornisce a Tabs la prop onSelect, tramite cui viene effettuato il dispatch della giustaazione che modifica il valore state.reservations.ui.view contenuto nel Redux Store.Invece l’intero aspetto presentazionale è gestito dal componente Tabs, che contiene ilcodice HTML da visualizzare e non dipende in alcun modo da Redux.

Page 79: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

4.3. PROGETTAZIONE 69

import { connect } from ’react-redux’import { VIEWS } from ’../costants’import { changeSelectedView } from ’./path/reservations.actions’import Tabs from ’../../components/Tabs’

const mapStateToProps = state => ({tabs: VIEWS,activeKey: state.reservations.ui.view,

})

const mapDispatchToProps = dispatch => ({onSelect: view => dispatch(changeSelectedView(view))

})

export default connect(mapStateToProps, mapDispatchToProps)(Tabs)

Codice 4.5: Definizione del container ViewTabs

Analogamente Toolbar è il componente che mostra la barra degli strumenti presente inogni pagina. Esso è poi "specializzato" e connesso allo Store tramite appositi container.

4.3.4.2 Il componente Auth

Tutte le pagine dell’applicazione, ad eccezione di quella di accesso, richiedono il controllodelle credenziali dell’utente prima di visualizzare i componenti. Altrimenti basterebbedigitare l’indirizzo corretto per visualizzare qualunque pagina, senza nemmeno accederecon il proprio account.Tale controllo è responsabilità del componente Auth (src/containers/Auth.js).Questo componente, che è connesso a Redux, esporta la funzione nel blocco 4.6.Il componente RequireRoleBase è connesso ai campi isAuthenticated e role delRedux Store. Il secondo rappresenta il livello di privilegio dell’utente autenticatoe può essere admin oppure user e viene fornito a RequireRoleBase con il nomecurrentUserRole.La funzione Auth riceve in input un componente (wrappedComponent) e un insiemedi proprietà, fra le quali il campo requiredRole che può contenere la stringa user oadmin a seconda che si voglia mostrare quel componente solo all’utente base, oppuresolo all’amministratore.Il metodo ensureAuth verifica che currentUserRole coincida con requiredRole ein quel caso il campo state.redirect viene impostato a null e la funzione rendercarica i componenti contenuti nella prop children. Questo campo speciale è il modocon cui in React un componente può accedere ai componenti figli annidati al suo interno(che in questo caso si tratta di WrappedComponent).Nel caso currentUserRole sia diverso da requiredRole l’utente è rediretto su unapagina che segnala l’impossibilità di accedere a quella pagina. Se invece l’utente non èautenticato esso viene rimandato alla pagina di login.Il meccanismo appena descritto rientra nello schema di funzionamento del patternHigher-Order Component (HOC)[g], che si può vedere come il design pattern Decorator

Page 80: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

70 CAPITOLO 4. PROGETTAZIONE E CODIFICA

import React, { Component } from ’react’import { connect } from ’react-redux’import { Redirect } from ’react-router-dom’import ... // altre importazioni non rilevanti

class RequireRoleBase extends Component {this.state = { redirect: null }

ensureAuth(props) {// imposta il campo ’state.redirect’ se l’utente// non è autenticato o se non ha il ruolo richiesto

}

render() {const { redirect } = this.stateconst { children, isRehydrated } = this.propsif(!redirect) {

return (<div>

<Loader loading=!isRehydrated />{children}

</div>)

}return (

<div><Loader loading=!isRehydrated /><Redirect to=redirect />

</div>)

}}

// non sono riportate le funzioni di connessione allo Store

const Auth = (wrappedComponent, requireRoleProps) => props => (<RequireRoleConnected ...requireRoleProps>

<WrappedComponent ...props /></RequireRoleConnected>

)

export default Auth

Codice 4.6: Il componente Auth

Page 81: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

4.3. PROGETTAZIONE 71

per React.js3. Il diagramma in figura 4.7 mostra la relazione fra le classi coinvolte.

Figura 4.7: Diagramma delle classi che descrive la struttura di Auth

Il componente Auth è utilizzato nel componente base dell’applicazione, ovvero App, epotenzia i componenti corrispondenti ad ogni pagina dell’applicazione (tranne quelladi login), inserendo le funzionalità di controllo dei privilegi di accesso e assicurandoche ogni categoria di account visualizzi solo le pagine previste.

4.3.4.3 Gestione delle chiamate HTTP

Per effettuare richieste HTTP ho scelto di utilizzare le fetch API[g], ovvero l’interfacciaper l’ottenimento di risorse definita nello standard di JavaScript. Questa è supportatada tutti i browser più moderni [8], con l’eccezione di Internet Explorer[g], per il quale

3Ulteriori dettagli sono disponibili nella documentazione ufficiale di React, al link https://reactjs.org/docs/higher-order-components.html

Page 82: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

72 CAPITOLO 4. PROGETTAZIONE E CODIFICA

il proponente non richiedeva il supporto.La fetch richiede l’indirizzo della risorsa da prelevare, la specifica del tipo di richiestada effettuare (POST, PUT, ecc) e ritorna una promessa[g] che si risolverà in un oggettodi tipo Response, o in alternativa sarà rigettata e la richiesta fallirà.Tutte le chiamate HTTP effettuate dall’applicazione, con l’eccezione della richiestadi download del report mensile, sono incorporate in funzioni action creator di Redux.Queste funzioni, invece che ritornare immediatamente una normale azione, avvianole operazioni di interrogazione del server tramite la fetch, e una volta completateeffettuano il dispatch di un’azione appropriata. Ad esempio se la richiesta è andataa buon fine aggiornano i dati con quelli prelevati dal server, o se la richiesta è fallitaimpostano un messaggio d’errore da mostrare all’utente.È possibile definire questi action creator asincroni utilizzando un middleware, ovverouna funzione che intercetta le azioni di cui è stato effettuato il dispatch e invece chemandarle subito al reducer ne ritarda l’effetto per completare altre operazioni, comeeffettuare altri dispatch se certe condizioni sono verificate, scrivere un log delle azioni ascopo di debug[g] o effettuare interrogazioni verso un server attendendo risposta. Perdare una definizione precisa di Redux middleware, esso è una funzione che permette didefinire action creator che ritornano una funzione invece di un’azione [20]. La figura4.8 riporta il ciclo di aggiornamento di un componente iscritto ad un valore del ReduxStore. Il middleware in figura intercetta il dispatch delle azioni ed effettua dei sideeffect, come il recupero di dati remoti per poi effettuare il dispatch di altre azioni,eventualmente anche asincrone.

Per lo sviluppo dell’applicazione ho utilizzato il middleware Redux-Thunk4, che è ilpiù semplice middleware per Redux. Vi sono tuttavia altre soluzioni che impongonomaggiori vincoli sulle modalità di utilizzo del middleware ma che, soprattutto nellosviluppo di un’applicazione complessa, possono portare ad un miglior risultato conminor sforzo, e che sono da considerarsi una alternativa a Redux-Thunk. Alcuni di essisono nominati nell’appendice in §A.5.2. Il vantaggio di Redux-Thunk sta senz’altronell’immediatezza di utilizzo.

La classe HttpAl fine di semplificare l’utilizzo della fetch, ed avere la possibilità di aggiungereagevolmente parametri di ricerca, campi nell’header della richiesta e gestire in modouniforme gli errori senza dover ripetere sezioni di codice, ho creato un’interfaccia cheracchiude tutti i metodi utilizzati per effettuare chiamate HTTP. Nel dettaglio laclasse Http, definita in src/redux/Http.js, espone un metodo statico per ogni tipodi richiesta utilizzata e aggiunge utilità per la gestione degli errori e per rigettareautomaticamente la risposta nel caso questa impieghi più di cinque secondi, in modo daevitare attese infinite per l’utente. Nel diagramma UML[g] in figura 4.9 sono indicati imetodi pubblici della classe. Essi hanno come parametri anche la funzione dispatch diRedux e tre funzioni callback da invocare quando la richiesta viene avviata (onStart),quando termina e ha successo (onSuccess) oppure quando fallisce (onFail).

4https://github.com/reduxjs/redux-thunk

Page 83: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

4.3. PROGETTAZIONE 73

Figura 4.8: Ciclo di aggiornamento di un componente con un Redux middleware [7]

Figura 4.9: Metodi statici della classe Http

Page 84: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

74 CAPITOLO 4. PROGETTAZIONE E CODIFICA

Figura 4.10: La pagina di selezione del giorno con il componente react-calendar

4.3.4.4 Considerazioni sull’accessibilità

Uno degli aspetti tenuti in considerazione sviluppando l’applicazione è stato l’utilizzocorretto degli elementi HTML e dei loro attributi per garantire un esperienza dinavigazione il più inclusiva possibile.Tuttavia vi sono alcuni aspetti a riguardo che vanno evidenziati. In diversi casiho utilizzato componenti React "già pronti", ad esempio quelli della libreria React-Bootstrap. Questi sono risultati ben realizzati e rispettano le direttive W3C[g] perl’accessibilità.In altri casi però i componenti utilizzati non fanno un uso corretto di certi attributi. Adesempio il componente react-select5, utilizzato nelle caselle di ricerca delle paginee nel form di aggiunta di una prenotazione, sebbene risulti navigabile ed utilizzabilemolto bene da tastiera, inserisce l’attributo type all’interno di elementi label. Questoviene ovviamente segnalato come un errore dai validatori di pagine web.Inoltre il proponente del progetto ha esplicitamente chiesto che la selezione delledate per visualizzare o effettuare una prenotazione avvenisse tramite una paginadi calendario cliccabile. Dopo un po’ di ricerca ho potuto constatare la mancanzadi un componente calendario davvero conforme alle mie necessità. Tuttavia, nonessendo la ricerca di calendari un’attività chiave del mio percorso di stage ho decisodi utilizzare React-calendar6, mostrato in figura 4.10. Un calendario come quello infigura non è del tutto accessibile ad ogni categoria di utenti: un utente non vedentedovrebbe navigarlo tutto tramite tab fino ad arrivare sul giorno desiderato, che èdecisamente scomodo. Inoltre mancano completamente gli attributi ARIA[g] sullefrecce per cambiare mese o anno, rendendo difficile comprenderne il significato senzapoterlo dedurre dalla loro posizione.Una soluzione accessibile in questo caso, sarebbe stata utilizzare un semplice input oin alternativa un date-picker a scomparsa.

5https://react-select.com/home6http://projects.wojtekmaj.pl/react-calendar/

Page 85: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

4.3. PROGETTAZIONE 75

4.3.5 ResponsivenessPer la realizzazione dell’interfaccia sono state sfruttate in gran parte funzionalità diBootstrap 3, che implementa tutti i componenti in modo da renderli adattabili allamaggior parte degli schermi. La parte accessibile all’amministratore è ottimizzata perl’utilizzo con schermi che abbiano almeno le dimensione di un tablet. Non ho adottatoparticolari accortezze per favorire l’esperienza di navigazione tramite smartphone,pertanto essa non risulta perfetta.Nel caso delle liste di piatti o di prenotazioni ho utilizzato i flexbox, che si adattanobene alla visualizzazione su ogni dispositivo.La navigazione su tutte le pagine è stata verificata tramite il simulatore integrato nelbrowser Chromium, emulando le dimensioni di uno smartphone e di un tablet.

4.3.6 CompatibilitàL’applicazione è stata testata e funziona correttamente sulle ultime versioni dei seguentibrowser, tutti installati sul sistema operativo Ubuntu 17.10 :

• Chromium 67.0.3396.99 ;

• Firefox 61.0.1 ;

• Google Chrome 69.0.3497.81 ;

• Opera 55.0.2994.56.

Come già specificato, non è garantito il funzionamento con il browser Internet Explorer.

Page 86: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React
Page 87: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

Capitolo 5

Verifica e validazione

In questo capitolo sono descritti gli strumenti utilizzati per testare il prodotto ed è riportatoil piano dei test effettuati.

5.1 Pacchetti utilizzati

Jest

È una delle librerie di testing JavaScript più comunemente utilizzata. Tutte le suite ditest sono state scritte con Jest.

Redux-mock-store

Questo pacchetto permette di definire un mock del Redux Store. Ne ho fatto uso pertestare il corretto funzionamento delle azioni asincrone, ovvero quelle responsabili dieffettuare richieste HTTP verso il server.

Redux-teskit

Contiene altri strumenti per verificare il corretto funzionamento di Redux. L’houtilizzato soprattutto per testare che le azioni avessero il corretto effetto sullo statomantenuto nello Store.

Seamless immutable

Offre diverse funzionalità per testare l’immutabilità degli oggetti, e fra queste lafunzione Immutable. Se un oggetto decorato da questa funzione viene modificatodirettamente provoca il lancio di un’eccezione ed il fallimento del test.

Enzyme

È un utilità di testing per React che semplifica la scrittura di test per i componenti diReact, utile per verificarne il comportamento emulando l’emissione di certi eventi delbrowser.

77

Page 88: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

78 CAPITOLO 5. VERIFICA E VALIDAZIONE

Total Validator

È uno strumento per la validazione del codice HTML, che controlla la conformità allostandard HTML scelto e alle linee guida WCAG[g].

5.2 Validazione delle pagine HTMLTutte le pagine dell’applicazione sono state validate con Total Validator.Come già specificato alla fine del capitolo precedente, non è possibile correggere gli errorieffettuati nei componenti che appartengono a librerie esterne, come Bootstrap. Questierrori riguardano soprattutto attributi non consentiti all’interno di certi elementi.Ad eccezione di questi il validatore non segnala errori di struttura o di accessibilità.

5.3 TestFra i requisiti obbligatori del piano di lavoro vi era la stesura di un piano di test per leparti critiche dell’applicazione. L’azienda desiderava infatti conoscere gli strumentimaggiormente utilizzati per effettuare il testing di progetti in React e Redux.Considerando che il Redux Store è il nucleo dell’applicazione sviluppata, abbiamodeciso di dare la priorità alla scrittura di suite di test di unità complete per i reducer eper le azioni in modo da avere la certezza che i dati da visualizzare fossero sempremanipolati correttamente.Non c’è stato tempo sufficiente per effettuare anche dei test di integrazione e di sistema,che possono essere scritti utilizzando rispettivamente enzyme ed il framework di testinge browser automation Selenium1. Con la prima libreria ho solamente predispostoqualche test per il componente Toolbar, che gestisce la barra degli strumenti postasopra ogni lista di elementi.Sono stati preparati test di due categorie: quelli sui reducer e sulle azioni asincrone diRedux.I test effettuati sui reducer verificano che il dispatch di ogni azione definita nell’appli-cazione sia processata correttamente dai reducer e alteri lo stato come previsto, senzaeffettuare effetti collaterali e preservando l’immutabilità. Essi sono tutti raccolti nellacartella src/test/reducers.I test riguardanti le azioni asincrone sono definiti nei file all’interno di src/test/Httpe verificano che le funzioni intercettate dal middleware si comportino come previsto a se-conda della risposta ottenuta dalle richieste verso il server ed effettuino il dispatch delleazioni corrette con i parametri giusti. Per emulare il comportamento della funzione fetch,ho predisposto un suo mock all’interno del file src/test/Http/MockResponse.js.

5.3.1 TracciamentoDurante la seconda metà dello stage ho stilato una lista di test da effettuare perassicurarsi che non vi fossero errori nell’interazione con il Redux Store. Tutti questitest sono stati implementati e risultano superati.Le tabelle 5.1 e 5.2 e 5.3 riportano la descrizione di ciascun test effettuato sui redu-cer, sulle azioni asincrone, sui componenti ed il relativo esito. Ogni test di unità èidentificabile da un codice univoco nel formato

TU[Tipo]-[Numero]1https://www.seleniumhq.org/projects/webdriver/

Page 89: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

5.3. TEST 79

dove Numero è un numero progressivo e Tipo è formato da una o due lettere maiuscolecon il seguente significato:

• R[X ]: i test verificano che i reducer ritornino il nuovo stato in maniera corretta.Il parametro X è una lettera che identifica il reducer testato:

– D: il reducer per il nodo dishes del Redux Store;

– M: il reducer per il nodo menus del Redux Store;

– R: il reducer per il nodo reservations del Redux Store;

– A: il reducer per il nodo authentication del Redux Store.

• A[X ]: i test controllano che le azioni asincrone effettuino il dispatch delle azionicorrette e gestiscano gli scenari di errore. Il parametro X può assumere glistessi valori descritti nel punto precedente, con l’unica differenza che la lettera siriferisce alle azioni asincrone definite per ogni pagina, piuttosto che ai reducer ;

• C: test sui componenti con enzyme.

In totale ho predisposto 11 suite di test per un totale di 111 test.

Tabella 5.1: Tabella di tracciamento dei test sui reducer

Codice Descrizione Esito

TURD-1 Il dispatch di un’azione non riconosciuta non apportacambiamenti allo stato

Superato

TURD-2 Le azioni rappresentative di un errore impostano ilmessaggio correttamente

Superato

TURD-3 È possibile eliminare gli errori e i messaggi di successocorrettamente

Superato

TURD-4 L’avvio dell’inserimento di un nuovo piatto imposta ilcampo per visualizzare l’animazione di caricamento sulform

Superato

TURD-5 Il reducer aggiunge correttamente un piatto e nascondel’animazione di caricamento

Superato

TURD-6 Il reducer imposta il campo di errore se l’aggiunta falliscee ferma l’animazione di caricamento

Superato

TURD-7 Ferma l’animazione di caricamento dopo l’eliminazionecorretta di un piatto

Superato

TURD-8 Il piatto viene rimosso correttamente in base al campoid

Superato

TURD-9 Il fallimento dell’eliminazione mostra un messaggio dierrore e ferma il caricamento

Superato

TURD-10 L’azione di filtraggio imposta correttamente il filtro Superato

TURD-11 L’azione di ricerca imposta correttamente la keywordcercata

Superato

Page 90: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

80 CAPITOLO 5. VERIFICA E VALIDAZIONE

Tabella 5.1: Tabella di tracciamento dei test sui reducer (continuazione)

Codice Descrizione Esito

TURD-12 L’apertura del pannello di aggiunta piatto impostacorrettamente il valore booleano

Superato

TURD-13 Il pannello di aggiunta piatto è nascosto correttamente Superato

TURD-14 Non viene visualizzato un errore nel form se il campoerror è null

Superato

TURD-15 Viene visualizzato il messaggio di errore nel form se èimpostato un messaggio come stringa

Superato

TURD-16 Il messaggio di errore nel form è eliminabile dall’utente Superato

TURM-17 Il campo checked di un piatto nel menù può esserecambiato

Superato

TURM-18 Al caricamento dei dati del menù viene impostato ilcampo loading

Superato

TURM-19 I dati del menù vengono impostati correttamente dopoil reperimento

Superato

TURM-20 Nell’impostare i piatti del menù del giorno i duplicatisono rimossi

Superato

TURM-21 Imposta un errore nel caso di fallimento del reperimentodei dati del menù e ferma l’animazione di caricamento

Superato

TURM-22 Imposta correttamente l’animazione di caricamentodopo il dispatch dell’azione di POST o PUT del menù

Superato

TURM-23 Visualizza un messaggio di successo dopo POST delmenù andata a buon fine

Superato

TURM-24 Visualizza un messaggio di successo dopo PUT del menùandata a buon fine

Superato

TURM-25 Visualizza un messaggio di errore dopo POST del menùfallita

Superato

TURM-26 Visualizza un messaggio di errore dopo PUT del menùfallita

Superato

TURM-27 Resetta tutti i campi checked dopo una richiesta dicancellazione del menù andata a buon fine

Superato

TURM-28 Visualizza un messaggio di errore dopo una richiesta dicancellazione del menù fallita e ferma l’animazione dicaricamento

Superato

TURM-29 Elimina correttamente tutti i messaggi di errore e disuccesso presenti

Superato

TURM-30 Modifica correttamente il campo relativo al momentodel pasto (pranzo o cena)

Superato

Page 91: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

5.3. TEST 81

Tabella 5.1: Tabella di tracciamento dei test sui reducer (continuazione)

Codice Descrizione Esito

TURR-31 Avvia l’animazione di caricamento al fetch delleprenotazioni

Superato

TURR-32 Ferma l’animazione di caricamento e imposta i piattidopo una richiesta andata a buon fine

Superato

TURR-33 Imposta un array vuoto se la richiesta delle prenotazionifallisce

Superato

TURR-34 Se la richiesta va a buon fine mentre era visualizzato unerrore esso viene eliminato e l’animazione di caricamentoscompare

Superato

TURR-35 Rimuove correttamente una prenotazione in base al suoid

Superato

TURR-36 Non cancella nessuna prenotazione se non trovacorrispondenza dell’id

Superato

TURR-37 Non modifica la lista di prenotazioni se la cancellazionefallisce e mostra l’errore

Superato

TURR-38 Aggiunge correttamente una prenotazione Superato

TURR-39 Mostra l’animazione di caricamento quando inizial’operazione di aggiunta di una prenotazione

Superato

TURR-40 Elimina tutti i messaggi di errore mostrati nella paginadelle prenotazioni

Superato

TURR-41 Mostra il pannello modale di aggiunta di unaprenotazione

Superato

TURR-42 Nasconde il pannello di aggiunta delle prenotazioni Superato

TURR-43 Avvia l’animazione di caricamento nel pannello diaggiunta di una prenotazione

Superato

TURR-44 Carica correttamente la lista di utenti nel form diaggiunta e ferma il caricamento

Superato

TURR-45 Carica correttamente la lista di piatti del giorno nelform di aggiunta e ferma il caricamento

Superato

TURR-46 Mostra un errore se fallisce il caricamento della lista diutenti e ferma il caricamento

Superato

TURR-47 Mostra un errore se fallisce il caricamento della lista dipiatti del giorno e resetta i dati

Superato

TURR-48 Modifica correttamente il campo relativo alla modalitàdi visualizzazione della lista di prenotazioni (tab)

Superato

TURR-49 Modifica correttamente il campo relativo al momentodel pasto (pranzo o cena) della pagina delle prenotazioni

Superato

Page 92: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

82 CAPITOLO 5. VERIFICA E VALIDAZIONE

Tabella 5.1: Tabella di tracciamento dei test sui reducer (continuazione)

Codice Descrizione Esito

TURR-50 Imposta correttamente il filtro di visualizzazione delleprenotazioni

Superato

TURR-51 Imposta il campo di ricerca con l’id della prenotazioneinserita dall’utente

Superato

TURR-52 Mostra un messaggio di errore nel form di aggiunta diuna prenotazione

Superato

TURR-53 Cancella il messaggio di errore nel form di aggiunta diuna prenotazione

Superato

TURR-54 Sovrascrive l’errore esistente nel form di aggiunta di unaprenotazione mostrandone un altro

Superato

TURA-55 Avvia il caricamento attendendo risposta alla richiestadi login

Superato

TURA-56 Imposta un errore generico al fallimento della richiestadi login

Superato

TURA-57 Imposta un messaggio di errore inviato dal server alfallimento della richiesta di login

Superato

TURA-58 Imposta il campo user nello Store al successo del login Superato

TURA-59 Rimuove i messaggi di errore e di successo correttamente Superato

Tabella 5.2: Tabella di tracciamento dei test delle azioni asincrone effettuati

Codice Descrizione Esito

TUAA-1 L’azione login avvia il caricamento della pagina e inseguito imposta l’utente corretto

Superato

TUAA-2 L’azione login fallisce, imposta un utente vuoto evisualizza un errore inviato dal server

Superato

TUAA-3 L’azione login fallisce, imposta un utente vuoto evisualizza un errore generico

Superato

TUAA-4 L’azione logout imposta un utente vuoto ed elimina iltoken di accesso

Superato

TUAD-5 L’azione getDishes imposta l’elenco di piatti Superato

TUAD-6 L’azione getDishes fallisce e imposta un errore inviatodal server

Superato

TUAD-7 L’azione getDishes fallisce e imposta un errore generico Superato

TUAD-8 L’azione getDishes fallisce in caso di reject dellapromessa ritornata dalla fetch

Superato

Page 93: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

5.3. TEST 83

Tabella 5.2: Tabella di tracciamento dei test delle azioni asincrone (continuazione)

Codice Descrizione Esito

TUAD-9 L’azione getDishes gestisce correttamente il caso in cuiil server segnala la mancanza di oggetti da ritornare

Superato

TUAD-10 L’azione postDish aggiunge un piatto e utilizzacorrettamente la riposta del server per ottenere l’id

Superato

TUAD-11 L’azione postDish fallisce e imposta un errore specificodal server

Superato

TUAD-12 L’azione postDish fallisce e imposta un errore generico Superato

TUAD-13 L’azione postDish fallisce in caso di reject dellapromessa ritornata dal server

Superato

TUAD-14 L’azione postDish fallisce se la richiesta impiega più di5 secondi per completare l’operazione

Superato

TUAM-15 L’azione getAllData ottiene l’elenco di tutti i piatti eil menù del giorno correttamente

Superato

TUAM-16 L’azione getAllData gestisce correttamente il caso incui l’elenco dei piatti sia vuoto (status = 404 e scope =db) ma non l’elenco di piatti nel menù

Superato

TUAM-17 L’azione getAllData gestisce correttamente il caso incui il menù del giorno sia vuoto (status = 404 e scope= db) e mostra solo l’elenco dei piatti

Superato

TUAM-18 L’azione getAllData gestisce correttamente il caso incui il menù del giorno e l’elenco dei piatti sia vuoto

Superato

TUAM-19 L’azione putMenus effettua la POST di un nuovo menùe utilizza la risposta del server per ottenere l’id

Superato

TUAM-20 L’azione putMenus effettua la PUT sovrascrivendo ilmenù già esistente ignorando la risposta del server

Superato

TUAM-21 L’azione getAllData fallisce ed imposta correttamenteil campo d’errore con il messaggio ritornato dal server

Superato

TUAM-22 L’azione getAllData fallisce per il reject della promessaed imposta correttamente il campo d’errore con unmessaggio predefinito

Superato

TUAM-23 L’azione getAllData fallisce ed imposta correttamenteil campo d’errore con un messaggio generico se il servernon ne fornisce uno nella risposta

Superato

TUAM-24 L’azione putMenus fallisce ed imposta correttamente ilcampo d’errore con il messaggio ritornato dal server

Superato

TUAM-25 L’azione putMenus fallisce in caso la risposta impieghitroppo tempo ad arrivare ed imposta correttamente ilcampo d’errore con il messaggio predefinito

Superato

Page 94: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

84 CAPITOLO 5. VERIFICA E VALIDAZIONE

Tabella 5.2: Tabella di tracciamento dei test delle azioni asincrone (continuazione)

Codice Descrizione Esito

TUAM-26 L’azione putMenus fallisce ed imposta correttamente ilcampo d’errore con il messaggio generico se il server nonne ha fornito uno

Superato

TUAM-27 L’azione deleteMenu elimina correttamente il menù conl’id specificato

Superato

TUAR-28 L’azione getReservations ha successo ed impostacorrettamente l’elenco di prenotazioni ricevuto

Superato

TUAR-29 L’azione getReservations ha successo ed imposta cor-rettamente un array di prenotazioni vuoto se il serverritorna status = 404 e scope = db

Superato

TUAR-30 L’azione getReservations fallisce ed imposta ilmessaggio d’errore inserito nella risposta dal server

Superato

TUAR-31 L’azione getReservations fallisce ed imposta un mes-saggio di errore generico se il server non inserisce unmessaggio personalizzato

Superato

TUAR-32 L’azione deleteReservation ha successo ed eliminacorrettamente la prenotazione con l’id indicato

Superato

TUAR-33 L’azione deleteReservation fallisce e mostra un mes-saggio di errore generico se il server non ne ha inseritouno

Superato

TUAR-34 L’azione deleteReservation fallisce e mostra ilmessaggio di errore inserito dal server nella risposta

Superato

TUAR-35 L’azione deleteReservation fallisce se la risposta ri-chiede troppo tempo (timeout) e imposta un messaggiod’errore appropriato

Superato

TUAR-36 L’azione getUserList ottiene un elenco di utenti e loimposta correttamente

Superato

TUAR-37 L’azione getUserList imposta il campo payload anull se il server segnala l’assenza di utenti da ritornare

Superato

TUAR-38 L’azione getUserList fallisce e mostra il messaggio dierrore inserito nella risposta

Superato

TUAR-39 L’azione getDayMenu fallisce e mostra il messaggio dierrore inserito nella risposta

Superato

TUAR-40 L’azione postReservation aggiunge una nuova preno-tazione

Superato

TUAR-41 L’azione postReservation fallisce e imposta ilmessaggio d’errore dal server

Superato

Page 95: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

5.3. TEST 85

Tabella 5.2: Tabella di tracciamento dei test delle azioni asincrone (continuazione)

Codice Descrizione Esito

TUAR-42 L’azione postReservation fallisce a causa della sca-denza del timeout e imposta il messaggio d’erroreappropriato

Superato

Tabella 5.3: Tabella di tracciamento dei test sui componenti

Codice Descrizione Esito

TUC-1 Il componente Toolbar mostra un gruppo di pulsanti radiocon i titoli specificati

Superato

TUC-2 Il componente Toolbar chiama la funzione corretta quantoil pulsante di aggiunta è premuto

Superato

TUC-3 Il componente Toolbar, una volta caricato, mostra labarra di ricerca

Superato

Page 96: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React
Page 97: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

Capitolo 6

Descrizione delle pagine

In questo capitolo sono riportate le immagini delle pagine dell’applicazione accessibili conl’account di amministrazione, evidenziando le funzioni del prodotto e riportando eventualiconsiderazioni sulle scelte effettuate.

6.1 LoginUna volta lanciata l’applicazione viene mostrata una pagina che spiega all’utente dovesi trova e lo invita ad autenticarsi. Nell’immagine 6.1 è mostrato il form di accesso.Non è stata prevista una pagina di registrazione in quanto il sistema dovrebbe alla fineessere integrato con gli account già esistenti degli studenti del collegio.

Figura 6.1: Form della pagina di accesso all’applicazione

87

Page 98: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

88 CAPITOLO 6. DESCRIZIONE DELLE PAGINE

Figura 6.2: Homepage dell’applicazione per la sezione di amministrazione

6.2 HomepageQuesta pagina, in figura 6.2, non offre funzionalità, ma è la prima che l’amministratorevisualizza dopo aver effettuato l’accesso. In alto è presente la barra di navigazione, chedisabilita il link alla pagina corrente e lo evidenzia in colore giallo. Essa contiene ancheun link nascosto per saltare al contenuto della pagina, utile agli utenti che naviganotramite screen reader.Considerando che non sono presenti pagine di secondo livello, accessibili dalle pagineprincipali, ho scelto di non inserire una barra delle breadcrumb. Il link attivo nellabarra del menù adempie allo scopo di indicare all’utente dove si trova.

6.3 Gestione prenotazioniQuesta pagina permette all’amministratore di controllare il numero di prenotazioni diogni piatto e può aggiungere prenotazioni a nome degli utenti. Le funzionalità sonodivise fra due pannelli chiamati Vista pasti e Vista utenti.

6.3.1 Selezione del giornoUna volta cliccato sul link per la pagina Gestione prenotazioni viene visualizzato ilcalendario in figura 6.3. Dopo aver selezionato il giorno viene visualizzata la paginadelle prenotazioni sulla scheda Vista pasti.Nella parte bassa del calendario è presente il pulsante per avviare il download delreport mensile relativo al mese selezionato.

Page 99: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

6.3. GESTIONE PRENOTAZIONI 89

Figura 6.3: Calendario per la selezione del giorno

6.3.2 Scheda Vista pasti

La figura 6.4 mostra la pagina da cui il personale della mensa può visualizzare i piattiprenotati nella giornata selezionata e quindi può conoscere quanti piatti preparare. Alclick su un blocco di un piatto, questo si espanderà mostrando anche l’elenco di studentiche lo hanno prenotato e l’orario indicativo al quale lo studente pensa di presentarsiper il pasto. Questi dati sono visualizzati in una tabella nella quale sono utilizzati gliattributi headers su ogni cella e scope su entrambe le colonne dell’header. Questiattributi permettono agli strumenti di lettura dello schermo di associare correttamenteciascun valore nelle righe all’intestazione della colonna.Inoltre per rendere ogni blocco un elemento interattivo è stato correttamente impostatol’attributo role.

6.3.3 Scheda Vista utenti

Da questa scheda, in figura 6.5, è possibile vedere la lista di utenti che hanno prenotatoalmeno un piatto nella giornata scelta. Tramite i due tab in alto a destra è possibilecambiare visualizzazione fra pranzo e cena della stessa giornata.Scopo di questa sezione è rimuovere le prenotazioni degli utenti ed aggiungerne di nuove.Questa funzionalità è fornita con l’intenzione di dare la possibilità agli amministratori diintervenire nel caso un utente non riesca a prenotare oppure a disdire una prenotazioneeffettuata.Per migliorare l’accessibilità dei pulsanti di eliminazione di una prenotazione, a ciascunoè assegnato dinamicamente un title che identifica esplicitamente la prenotazione chesi sta eliminando (vedi figura 6.6).

6.3.4 Form di aggiunta di una prenotazioneCompilando il form in figura 6.7 e confermando i dati, l’amministratore aggiunge unaprenotazione per l’utente selezionato. Nella figura il modulo è stato confermato senzaaver specificato il nome dell’utente, selezionabile da un elenco a tendina, e quindi èsegnalato l’errore.

Page 100: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

90 CAPITOLO 6. DESCRIZIONE DELLE PAGINE

Figura 6.4: Elenco di piatti prenotati della scheda Vista pasti

Figura 6.5: Elenco di utenti prenotati della scheda Vista utenti

Page 101: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

6.3. GESTIONE PRENOTAZIONI 91

Figura 6.6: Utilizzo dell’attributo title per evidenziare la funzione del pulsante

Figura 6.7: Form di aggiunta di una prenotazione nella scheda Vista utenti

Page 102: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

92 CAPITOLO 6. DESCRIZIONE DELLE PAGINE

Figura 6.8: Pagina di gestione del menù

6.4 Gestione dei menù

La pagina in figura 6.8 permette all’amministratore di visualizzare il menù scelto peruna giornata e di modificarlo. Anche in questa pagina sono presenti i tab Pranzo/Cenache rendono possibile definire un menù differente nei due pasti della stessa giornata.Per selezionare i piatti da inserire nel menù è sufficiente selezionare o deselezionaretramite click i corrispondenti blocchi.Prima di accedere a questa schermata è richiesto selezionare la giornata tramite lostesso calendario utilizzato per accedere alla pagina Gestione prenotazioni.I piatti che è possibile aggiungere al menù sono tutti quelli disponibili nel sistema,visualizzabili nella pagina Gestione piatti, descritta in seguito.Ogni piatto del menù è visualizzato all’interno di <div> cliccabili, per i quali è sta-to usato l’attributo role="checkbox" allo scopo di dichiarare che quegli elementihanno funzione di un <input> di tipo checkbox. È inoltre impostato l’attributoaria-checked che assume valore true o false a seconda che il piatto sia selezionato omeno.Nel caso l’amministratore non voglia permettere la prenotazione può usare il pulsanteper eliminare il menù.

6.5 Gestione dei piatti

Dalla pagina Gestione piatti (in figura 6.9) è possibile visualizzare, aggiungere edeliminare i piatti inseriti nel database del sistema.In tutte le pagine che mostrano un elenco di piatti è anche possibile filtrarli per tipo,ovvero visualizzare solo i primi, i secondi, ecc. Questo è possibile selezionando ilpulsante corrispondente alla categoria desiderata nella barra degli strumenti postasopra le liste.

Page 103: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

6.5. GESTIONE DEI PIATTI 93

Figura 6.9: Elenco di piatti e casella di ricerca

6.5.1 Form di aggiunta di un piattoLa figura 6.10 mostra il form compilabile per aggiungere un piatto. I primi due campisono obbligatori, mentre la descrizione si può omettere: in questo caso al suo postoviene inserita la stringa "Nessuna descrizione".

Figura 6.10: Pannello modale per l’aggiunta di un piatto

Page 104: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React
Page 105: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

Capitolo 7

Conclusioni

7.1 Consuntivo finale delle oreL’attività di stage prevede l’impiego di 300 - 320 ore lavorative dello studente, per 11crediti formativi universitari. Lo stage effettuato è iniziato il giorno 18 Giugno 2018 el’ultimo giorno di permanenza in azienda è stato il 27 Agosto 2018. Il numero di ore dilavoro effettivamente svolte ammonta a circa 319, comprendendo l’attività di ricerca,sviluppo e redazione della relazione richiesta. Le ore lavorative sono state effettuateprevalentemente presso l’azienda, ma sono incluse nel conteggio finale anche ore dilavoro effettuate in orari non lavorativi.

7.2 Raggiungimento degli obiettiviTutti i requisiti obbligatori e alcuni di quelli opzionali indicati nella sezione 3.4, relativial prodotto da realizzare, sono stati soddisfatti. Fra gli obiettivi dell’intero periodo distage tutti quelli obbligatori sono stati completati, ma non vi è stato il tempo sufficienteper svolgere quelli desiderabili e facoltativi (D01 e F01 in §2.2.2).La tabella 7.1 riporta l’elenco di requisiti non soddisfatti, ovvero i requisiti funzionalifacoltativi concernenti la parte dell’applicazione per gli utenti base, che non è statarealizzata, ed un requisito qualitativo. Questo si riferisce al collaudo dell’applicazionepresso la struttura del proponente: dato che ho realizzato solamente l’interfaccia perla sezione accessibile all’amministratore non c’è stato modo di farla provare al collegio.

Rispetto a quanto pianificato, ho speso una quantità considerevole di tempo per capirequali librerie supplementari adoperare assieme a React.js, vista l’enorme quantità dipacchetti creati dalla comunità di sviluppatori che supportano questa libreria.Parallelamente allo studio delle tecnologie ho dovuto testarle da un punto di vistapratico, per capirne le caratteristiche ed il funzionamento. Talvolta, infatti la documen-tazione dei pacchetti non è sufficiente a questo scopo e costringe a dedurre informazionida comunità online come StackOverflow oppure dalle discussioni nate sulle pagine degliissue GitHub. Questo è vero soprattutto per quelle librerie con meno visibilità, nonper quelle più utilizzate (come React e Redux).

95

Page 106: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

96 CAPITOLO 7. CONCLUSIONI

Tabella 7.1: Requisiti facoltativi non soddisfatti

Requisito Descrizione Use Case

RFF-3 L’utente base deve poter inserire una prenotazione UC-18

RFF-3.1 L’utente base deve poter visualizzare tutti i piattidisponibili, compresi i pasti alternativi

UC-18.4,

UC-18.5,

UC-18.6,

UC-18.7

RFF-3.2 L’utente base deve poter selezionare la prenotazioneper pranzo o per cena

UC-18.3

RFF-3.3 L’utente base deve poter selezionare il giorno dellaprenotazione tramite un calendario cliccabile

UC-17,

UC-18

RFF-3.4 L’utente base deve poter esprimere una preferenza diorario della prenotazione

UC-18.8

RFF-3.5 L’utente base deve poter scegliere l’opzione "pranzoa sacco"

UC-18.9

RFF-3.6 La procedura di inserimento della prenotazione diun utente base deve poter essere interrotta da uncerto orario in avanti della giornata stessa dellaprenotazione

UC-18.10

RFF-3.7 Il sistema deve rilevare la mancata prenotazionedel pasto e suggerire all’utente di procedere allaprenotazione

UC-17.1

RFQ-3 L’applicazione va testata in un contesto di realeutilizzo

-

Page 107: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

7.3. CONSIDERAZIONI PERSONALI 97

7.3 Considerazioni personali

7.3.1 Tecnologie appreseIl tirocinio mi ha permesso di acquisire un’ottima panoramica su due delle maggiorilibrerie per la costruzione di interfacce di applicazioni web. Lo studio di Angular èstato affrontato ad un livello più teorico rispetto al lavoro compiuto su React.js, ma adogni modo mi è stato possibile comprenderne le differenze e redigere una soddisfacenterelazione giudicata ottima dal tutor aziendale.Queste tecnologie sono molto recenti (React è stato rilasciato nel 2013 e la versione 2di Angular nel 2015) e la documentazione online, escludendo quella ufficiale, consistesoprattutto di articoli scritti da blog tecnologici come codeacademy.com o medium.com.Inoltre la maggior parte delle informazioni riguardano il come far funzionare questetecnologie, nell’ottica di doverle imparare, ma è molto difficile reperire informazioni sulloro funzionamento interno e sulla loro architettura. Inoltre mancano completamentearticoli accademici che discutano su questi argomenti.

7.3.2 Corsi propedeuticiIl lavoro di stage ha riguardato tecnologie non trattate durante il percorso di laureatriennale. Tuttavia ritengo che alcuni corsi seguiti siano stati di particolare aiuto percompletare il progetto:

• Tecnologie Web: il corso ha introdotto tutti gli aspetti riguardanti la creazione edil mantenimento di un sito web. Oltre a fornire una panoramica sulle principalitecnologie e linguaggi utilizzati nel mondo del web, mi ha permesso di capirequali caratteristiche valorizzare per progettare un sito di qualità;

• Ingegneria del Software: nel mio caso il progetto previsto da questo corso èstato utile sotto due aspetti: quello tecnologico, in quanto mi ha portato adacquisire familiarità con il linguaggio JavaScript, altrimenti a me sconosciuto, emetodologico, in quanto mi ha insegnato un metodo di lavoro ordinato e rigoroso.

Ho elencato i due corsi che trattavano argomenti più affini al tema affrontato durantelo stage, perché le competenze lì acquisite mi hanno aiutato in modo diretto, manaturalmente non sarebbe stato possibile affrontare questi corsi senza aver posto lebasi con i corsi del primo e secondo anno di studi.

Page 108: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React
Page 109: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

Appendice A

Un confronto fra React.js eAngular

Questo capitolo contiene la relazione redatta per l’azienda Sync Lab. Rispetto alla versioneconsegnata al tutor aziendale, ho apportato piccole modifiche alla formattazione deglielementi, con l’obiettivo di aderire alle convenzioni stilistiche utilizzate per il presentedocumento. I contenuti invece sono rimasti immutati.

A.1 IntroduzioneQuesta relazione mira ad evidenziare le principali differenze fra il framework Angularv6.1.1 e la libreria JavaScript React.js v16.4.2. Essi sono fra gli strumenti oggimaggiormente utilizzati per la creazione di interfacce per Single Page Application.React.js ha una storia più recente di Angular. La prima release di React è statapubblicata a Marzo 2013, mentre la primissima versione di Angular (Angular 1.x, anchedetto Angular.js) risale ad Ottobre 2010. Nel 2015 fu rilasciato Angular 2.0.0, unanuova versione di Angular.js completamente riscritto per l’utilizzo con TypeScript edincompatibile con la precedente versione.Da quel momento in poi con Angular si intende qualunque versione del frameworkdalla versione 2 in poi, mentre con Angular.js si identifica la vecchia versione 1.x.Entrambi sono supportati da importanti corporazioni: Angular è mantenuto principal-mente da Google, mentre React.js è mantenuto da Facebook.Nel presente documento le parole Angular e React.js si riferiscono alle versioni indicatenelle prime righe del documento. Inoltre per brevità userò la parola React comesinonimo di React.js.

99

Page 110: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

100 APPENDICE A. UN CONFRONTO FRA REACT.JS E ANGULAR

Figura A.1: Download settimanali di React.js e Angular da npm nel periodo da Luglio 2016a Luglio 2018 [6]

A.2 Statistiche di utilizzoReact ha avuto fin dal rilascio una crescita notevole, visto che offriva un’alternativaal già conosciuto Angular.js, che però non soddisfaceva interamente la comunità disviluppatori. Con l’uscita di Angular 2 questo ha ripreso popolarità e risulta la sceltapiù comune per lo sviluppo front-end nelle aziende.Secondo i dati di BuiltWith.com Angular.js è utilizzato nel 19,56% dei 10.000 maggiorisiti web per traffico [1]. React.js si aggira attorno all’11,72% [18] mentre Angular 2 esuccessive versioni è riportato fermo a solamente lo 0,03% [2].Nelle figure A.1 e A.2 è riportato l’andamento dei download, rispettivamente settimanalie mensili, dei pacchetti npm di Angular e React. Nel caso di Angular ho incluso sia@angular/cli che scarica il client di supporto ad Angular con vari comandi persemplificare la generazione di file, che @angular/core che contiene solo le funzionalitàbase del framework (escluso il modulo router e RxJS). Ad ogni modo il downloaddel primo pacchetto comporta lo scaricamento anche del secondo. Entrambi questipacchetti si riferiscono ad Angular 2 e versioni successive. Ho riportato anche i dati delpacchetto angular che si riferisce ad Angular.js, fermo alla versione 1.7.3. Ovviamentei download di quest’ultimo sono decisamente minori, ma esso mantiene ancora quotedi mercato non trascurabili visto che molte applicazioni realizzate con questa versionenon sono mai state aggiornate alla versione 2 e devono comunque essere mantenute.Queste statistiche non permettono però di capire quale sia effettivamente più utilizzatofra i due. Il numero di download è infatti da considerarsi più un indice di popolaritàche di utilizzo.Nella figura A.3 è riportato l’esito del sondaggio globale State of the Developer Nation,condotto dal programma di ricerca sullo sviluppo software Developer Economics1,riguardo alla scelta di framework JavaScript nello sviluppo front-end.I 5833 sviluppatori partecipanti al sondaggio sono stati anche classificati sulla base dellinguaggio che maggiormente utilizzano in ambito lavorativo.Dal grafico in figura A.3 emerge che la maggior parte degli sviluppatori web votantiutilizzano Angular piuttosto che React. È anche possibile notare che l’utilizzo diAngular 1.x è ancora molto alto.

1https://www.developereconomics.com/

Page 111: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

A.2. STATISTICHE DI UTILIZZO 101

Figura A.2: Download mensili di React.js e Angular da npm nel periodo da Luglio 2016 aLuglio 2018 [6]

Figura A.3: Utilizzo di framework e librerie JavaScript fra sviluppatori raggruppati perlinguaggio di utilizzo primario [23]

Page 112: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

102 APPENDICE A. UN CONFRONTO FRA REACT.JS E ANGULAR

Figura A.4: Interazione fra componenti e servizi in Angular [21]

@Injectable ({providedIn: ’app-mycomponent’, // iniettato in app-mycomponent

})export class Service {

constructor() { }

fetchData() : DataType {return fetch(...).then(...).catch(...) // recupero di dati

}}

Codice A.1: Dichiarazione di un servizio di Angular

A.3 Architettura a componentiAngular e React si basano sul concetto di Component, che rappresentano i tasselli coni quali è costruita una pagina web. Si tratta di blocchi di codice HTML potenziati confunzioni JavaScript o TypeScript che implementano una certa funzionalità.Vi sono due differenze concettuali su come React e Angular organizzano il lavoro.Angular distingue i servizi dai componenti. La documentazione ufficiale definisce unservizio come un’insieme di funzionalità di cui un’applicazione necessita. Il componentedovrebbe solamente abilitare la presentazione dei contenuti e l’interazione con l’utente,ma dovrebbe delegare il come farlo ad uno o più servizi [12].Quindi seguendo l’approccio a servizi di Angular, rappresentato nella figura A.4sottostante, ogni componente che necessiti di dati esterni dovrà essere dotato diun servizio che in qualche modo glieli fornisca (sia tramite richieste remote oppureattingendo da una cache locale).La dichiarazione di un servizio è effettuata specificando nei metadati di @Injectableil nome del componente nel quale sarà iniettato (blocco A.1).Al componente che lo utilizza basta inserire un parametro di tipo Service nel costrut-tore. Di come e quando istanziare il servizio se ne occupa il framework.Il frammento di codice A.2 mostra come sia possibile iniettare il servizio in uncomponente.

Page 113: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

A.3. ARCHITETTURA A COMPONENTI 103

@Component({selector: ’app-mycomponent’, // nome del componente nel templatetemplateUrl: ’./mycomponent.component.html’,styleUrls: [ ’./mycomponent.component.css’ ]

})export class MyComponent implements OnInit {

constructor(private service: Service) { }

ngOnInit() {this.getData()

}

getData() : void {this.service.fetchData()

}}

Codice A.2: Dependency injection di un servizio in un componente Angular

In React.js non esiste tale distinzione: tutto è un componente. La creazione di classiper separare elementi presentazionali da moduli di recupero di dati è totalmente adiscrezione del programmatore. Questa è una delle ragioni per le quali moltissimeapplicazioni in React utilizzano anche Redux o altre librerie di gestione dello stato,che tratterò in seguito.Quindi, mentre in Angular vi è un preciso modo di separare la logica di presentazionedal reperimento dei dati da visualizzare, in React non vi è un meccanismo pronto pertale obiettivo: i dati di cui un componente necessita gli devono essere forniti da altricomponenti oppure da store globali, nel caso in cui si faccia uso di librerie di statemanagement, fra le quali Redux.Un componente in React estende la classe Component ed è dichiarato come indicatonel blocco A.3.Mentre in Angular ad un componente corrisponde sempre del codice HTML, in Reactnon è così. Un componente potrebbe funzionare da semplice wrapper, per esempioeffettuando dei controlli prima di mostrare altri componenti, ed in generale decorandolidi funzionalità. In effetti un componente di React non è altro che una classe/funzioneJavaScript, con un metodo render() che definisce il codice HTML da visualizzare.In Angular invece, l’obiettivo ben definito di un componente rende necessario avereun corrispettivo frammento di pagina HTML da mostrare nel browser. Per il restoesistono i servizi.Come si nota dai due esempi A.2 e A.3, mentre in Angular il template HTML corri-spondente ad un componente si trova in un file separato, specificato nei metadati delcomponente (nel campo templateUrl), in React esso viene accorpato alla classe delcomponente. Precisamente viene definito all’interno del metodo render(). Questo èpossibile grazie a JSX, un’estensione del linguaggio JavaScript che permette di includereframmenti di HTML all’interno di codice JavaScript [11]. Il grado di separazione fraHTML e JavaScript è un’altra differenza fra il framework e la libreria.

Page 114: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

104 APPENDICE A. UN CONFRONTO FRA REACT.JS E ANGULAR

import React from ’react’;

export class Component extends React.Component {this.state = {

// inizializzazione dei campi dello stato del componente}

render() { // specifica l’HTML a cui corrisponde il componentereturn (

<div><OtherComponent />

</div>)

}}

Codice A.3: Un componente in React.js

A.3.1 Condivisione di dati fra componenti in ReactIn una applicazione React lo stato dell’applicazione è mantenuto da uno o più compo-nenti. React implementa un one way data binding nel quale il flusso dei dati scendeseguendo la gerarchia di componenti. Nei casi in cui serva l’interazione dell’utente coni componenti è però spesso necessario avere un modo di far fluire i dati nella direzioneopposta, quindi dalla view con la quale l’utente interagisce, verso lo stato internodell’applicazione. Ad esempio ad un click dell’utente, si potrebbe dover modificareun certo dato contenuto nello stato. Utilizzando solamente React questo si può farecon un meccanismo di callback : ogni componente che contiene stato (detto stateful)può esporre dei metodi per modificare il suo stato interno. Può dunque passare questimetodi ai componenti figli. Questo avviene tramite il passaggio di props, ovvero diproprietà, che possono essere un qualunque tipo di oggetto JavaScript, incluse quindifunzioni. Come rappresentato nella figura A.5, un componente che voglia modificare lostato di un componente più alto nella gerarchia deve invocare su di esso uno di questimetodi. In questo modo è il componente che contiene lo stato a fornire ai figli i datida visualizzare e le funzioni da invocare quando sia necessario effettuare un’operazionesui dati. I componenti figli, in questo caso, sono chiamati componenti controllati, inquanto non hanno uno stato e la loro apparenza nella vista è completamente definitadallo stato dei componenti sopra di loro.

Page 115: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

A.3. ARCHITETTURA A COMPONENTI 105

Figura A.5: Esecuzione di callback verso un componente genitore in React.js [25]

Figura A.6: Passaggio di props in React.js [25]

Page 116: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

106 APPENDICE A. UN CONFRONTO FRA REACT.JS E ANGULAR

A.4 Potenzialità diverseEssendo Angular un framework e React una semplice libreria essi hanno una grado dicompletezza ben differente. Per la precisione Angular è un framework MVC-MVVM(Model View Controller - Model View View-Model) e offre un insieme di strumentida utilizzare assieme per far fronte ad ogni esigenza di uno sviluppatore. React è unalibreria con poche funzionalità rispetto al primo. Di conseguenza per effettuare unconfronto significativo assumerò che l’utilizzo di React sia complementato da un certonumero di librerie che lo rendano paragonabile ad Angular.I principali strumenti che mancano a React.js e che invece sono forniti in Angular,sono [9]:

• Gestione dello stato;

• Routing client-side;

• Gestione di richieste Http;

• Css scoping.

Di seguito sarà discusso ciascuno dei quattro punti, spiegando quali soluzioni sianoadoperabili con React.

A.4.1 Gestione dello statoUn’applicazione web dovrà mostrare dei dati all’utente, che solitamente sono reperitida un server remoto. Una volta che questi dati sono stati ottenuti, l’applicazione devesalvarli da qualche parte per poterli visualizzare. Mantenere uno stato locale puòessere utile ad esempio per effettuare operazioni di ricerca o di filtraggio degli elementivisualizzati senza alcun intervento del server. Per gestione dello stato intendo quindi ilproblema di dove e come mantenere questi dati per poterli presentare e manipolare.Vi sono varie librerie di state management che possono essere utilizzate in Angular,fra le quali NGRX2 (una specie di adattamento ad Angular di Redux) e la più recenteNGXS3. Queste librerie implementano un popolare paradigma nel quale l’intero statodell’applicazione viene mantenuto all’interno di un unico oggetto globale chiamatostore.

Cos’è e quando serve uno store?Tutte le librerie di state management definiscono Store l’oggetto o la collezione dioggetti che contengono tutti i dati dell’applicazione. Quindi lo Store potrebbe conteneresia i dati reperiti da un server, che informazioni sullo stato dell’interfaccia grafica.In genere queste librerie forniscono meccanismi di iscrizione dei componenti a certeparti dello store. Qualora qualche dato nello store fosse modificato, ad esempio inseguito ad una sincronizzazione con il server oppure ad un evento scatenato dall’utente,tutti i componenti iscritti a quel dato saranno automaticamente notificati e aggiornati.Quindi si tratta di una implementazione del design pattern Observer.Non è detto che ci sia bisogno di utilizzare uno store, ovvero di uno o più oggettidedicati al mantenimento dei dati. È anche possibile far in modo che ogni elementoche abbia necessità dei dati effettui la propria richiesta al server e una volta ottenuti liutilizzi come previsto.

2https://github.com/ngrx/platform3https://github.com/ngxs/store

Page 117: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

A.4. POTENZIALITÀ DIVERSE 107

Il grosso vantaggio di uno store, tralasciando considerazioni progettuali sulla scelta dicentralizzare il modello dei dati del client, si percepisce quando diversi componenti diun’applicazione web hanno bisogno di accedere ad uno stesso dato. In questa situazionerifare la stessa richiesta da diversi componenti può diventare inutile visto che quel datoera già stato prelevato in precedenza. Un’altra situazione nel quale può tornare utilecentralizzare lo stato è quando più attori (come il server e l’utente client) possonomodificare i dati concorrentemente, ed in tal caso avere diverse istanze di essi puòdiventare difficile da gestire [3].

Tuttavia, particolarmente in Angular, non vi è necessità di utilizzare una delle succitatelibrerie. Angular, a differenza di React, propone l’utilizzo dei servizi. Come giàdetto, un servizio è un oggetto che mette a disposizione tutte le funzionalità di cui uncomponente necessita. Uno dei problemi che l’utilizzo di uno store risolve elegantementeè la necessità di fornire gli stessi dati a più componenti. Tuttavia Angular fornisceun avanzato meccanismo di dependency injection[g] che, tramite l’utilizzo di servizi,risolve questo problema [3]. Infatti:

• è possibile creare servizi ed effettuarne l’injection in specifici componenti;

• i servizi di Angular possono mantenere localmente dei dati e condividerli in piùcomponenti nei quali sono iniettati;

• ogni servizio iniettato in una data gerarchia di componenti è un singleton. Ovverotutta la gerarchia condividerà la stessa istanza del servizio [5].

Quindi un servizio di Angular può all’occorrenza agire come un piccolo store, diventandola sola sorgente di quel dato per tutti i componenti che lo richiedono.React, invece, non beneficia del meccanismo di dependency injection di Angular. Lacondivisione di dati fra componenti avviene attraverso un passaggio di proprietà lungo lagerarchia di componenti, come spiegato nella sezione precedente. Può diventare quindidesiderabile avere uno stato esterno ad ogni componente che sia l’unica sorgente di datidell’intera applicazione. L’implementazione del pattern Observer fra i componenti e lostore, offerta nativamente in queste librerie, fa in modo che i componenti rispecchinoin ogni momento i dati contenuti nello store.Come si vede nella figura A.7, l’utilizzo di una libreria come Redux, delega il ReduxStore a contenere l’intero stato dell’applicazione. Tramite il pattern Observer i com-ponenti connessi (ovvero iscritti) allo Store sono automaticamente notificati di ognicambiamento ad esso. L’utilizzo di questa libreria è molto popolare visto che elimina lanecessità di fornire funzioni callback ai componenti figli ai fini di far fluire informazioninel senso opposto alla gerarchia. Più informazioni sull’interazione fra React e Reduxsono fornite nella prossima sezione (A.5).

A.4.2 RoutingIl routing in una web application permette il caricamento di componenti diversi aseconda dell’URL della pagina. Permette l’emulazione del cambio pagina al click su unlink, pur senza effettuare un ricaricamento della pagina, ed abilita l’utente a salvarel’indirizzo delle pagine nei preferiti ed a utilizzare i pulsanti di navigazione del browser.React non fornisce alcuna soluzione nativa per questo obiettivo. Angular inveceinclude il pacchetto @angular-router all’interno del framework. Per l’utilizzo in React

Page 118: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

108 APPENDICE A. UN CONFRONTO FRA REACT.JS E ANGULAR

Figura A.7: Flusso dei dati in React con e senza Redux [25]

sono disponibili diversi pacchetti, fra i quali React-mini-router4, React-router5 eUniversal-router6 che non è specifico per React.

A.4.3 Gestione di richieste Http

Nel caso l’applicazione web richieda di reperire dati remoti è necessario effettuarechiamate Http. Angular suggerisce l’utilizzo della reactive programming[g] e del tipoObservable, disponibile nella libreria RxJS7, già inclusa nel framework. Per Reactinvece è necessario installare una delle decine di librerie esistenti. Se si vuole utilizzarel’approccio simile ad Angular con React e Redux esiste redux-observable8. Oppure èpossibile utilizzare Redux con librerie come axios9 o fetch, che fa parte dello standardJavaScript ed è supportata da tutti i browser più recenti10.

A.4.4 Scoping del foglio di stile

Angular permette di definire fra i metadata di un componente anche il foglio di stile dautilizzare per esso. Questo può essere fatto come si vede alla quarta linea del bloccodi codice A.4: nei metadati di un componente è possibile associare il suo foglio distile. Il css associato ad un componente è specifico per esso e quindi non influisce suitemplate di tutti gli altri componenti. Questa soluzione ha il vantaggio di evitare effetti

4https://github.com/larrymyers/react-mini-router5https://reacttraining.com/react-router/6https://www.kriasoft.com/universal-router/7https://rxjs-dev.firebaseapp.com/8https://redux-observable.js.org/9https://github.com/axios/axios

10https://developer.mozilla.org/it/docs/Web/API/Fetch_API

Page 119: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

A.4. POTENZIALITÀ DIVERSE 109

@Component({selector: ’my-component’,templateUrl: ’./mycomponent.component.html’,styleUrls: [ ’./mycomponent.component.css’ ]

})export class MyComponent implements OnInit {

...}

Codice A.4: Dichiarazione di un foglio di stile privato in Angular

indesiderati dovuti alla ripetizione di nomi di classi che possono creare interferenze fradi esse.In React, per far uso di una soluzione simile, è necessario installare il pacchettoreact-css-modules11, tramite il quale è possibile assegnare ad ogni componente unospecifico foglio di stile, sfruttando il pattern Decorator. Al caricamento del componentead ogni tag HTML saranno associati nomi di classi univoci che garantiscono la noninterferenza con gli altri fogli di stile.

11https://github.com/gajus/react-css-modules

Page 120: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

110 APPENDICE A. UN CONFRONTO FRA REACT.JS E ANGULAR

const typicalAction = {type: ’REMOVE_OBJECT’, // dichiara cosa vuole fare l’azionepayload: id // parametri necessari per completare l’azione

}

Codice A.5: Una action di Redux

A.5 React, Redux e la gestione dello stato

A.5.1 Cos’è Redux?

React e Redux sono due librerie separate e mantenute da team differenti che nondevono necessariamente essere utilizzate assieme.Redux è una libreria che offre un container per lo stato di applicazioni JavaScript. Si èispirato a Flux, uno schema architetturale sviluppato da Facebook specificatamenteper l’utilizzo con React.Redux si basa su tre principi [19]:

• Singola sorgente di dati: tutto lo stato dell’applicazione è contenuto all’internodi un oggetto in un unico store (Flux invece prevedeva store multipli);

• Lo store è in sola lettura: non è possibile modificare direttamente lo stato in essocontenuto. L’unico modo di farlo è emettere un’azione e farla processare ad unreducer ;

• I cambiamenti allo store sono effettuati con funzioni pure: un reducer non effettuaside effect, ma restituisce il nuovo stato in un nuovo oggetto.

L’utilizzo di React con Redux si basa sulla possibilità di iscrivere i componenti Reactalle porzioni di Redux Store di cui hanno bisogno. È anche possibile utilizzare Reduxcon un approccio simile a quello di Angular utilizzando RxJS per gestire le chiamateHttp facendo uso del middleware redux-observable.Inoltre, quando è utilizzata una libreria come Redux, è spesso necessario spendere unpo’ di tempo a progettare l’organizzazione dello store o degli store dell’applicazione.Soprattutto nel caso in cui lo store sia singolo è utile, dove possibile, organizzare i datievitando strutture troppo annidate e mantenendo uno stato normalizzato. Uno statomal organizzato può provocare inutili re-rendering dei componenti iscritti allo store erenderne inefficiente l’aggiornamento [14].Maggiori informazioni su questo aspetto sono disponibili sul sito ufficiale di Redux12.

A.5.2 React e Redux

Con React-Redux tutto lo stato dell’applicazione, i dati da visualizzare e lo statodell’interfaccia, può essere salvato all’interno del Redux Store. L’unico modo di appor-tare modifiche a questo oggetto è effettuare il dispatch di actions che contengono le"istruzioni" di cosa cambiare e di come farlo. Un’azione non è altro che un oggetto chenormalmente ha la struttura visualizzata nel codice A.5.

12https://redux.js.org/recipes/structuringreducers/normalizingstateshape

Page 121: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

A.5. REACT, REDUX E LA GESTIONE DELLO STATO 111

Figura A.8: Ciclo di aggiornamento con React-Redux dall’emissione di un evento dalla vistaall’aggiornamento del componente [10]

Quando un’azione viene inviata tramite dispatch allo store questa viene processata daun reducer. Il reducer è una funzione pura che dato lo stato precedente e l’azione dacompiere ritorna lo stato successivo (non modifica lo stato precedente, ma fa una deepcopy dell’oggetto, lo altera e lo restituisce).Il meccanismo ad azioni può essere sfruttato anche per popolare lo store con i dati, chespesso sono inviati da un server, e quindi devono essere ottenuti tramite chiamate REST,che sono asincrone. Quindi in questo caso le azioni dovrebbero attendere che i datiarrivino. Il reducer non può sapere di questa attesa e si aspetta un risultato immediato.È possibile gestire tale asincronia utilizzando un middleware, che è semplicemente unafunzione che attende il completamento di un’azione asincrona prima di effettuare ildispatch dell’azione appropriata verso il reducer. Questo permette di attendere rispostadal server e poi effettuare il dispatch corretto in caso di successo, oppure di errore. PerReact esistono vari middleware che svolgono questo compito. Uno molto utilizzato emolto semplice è redux-thunk13. Ve ne sono altri più complessi come redux-saga14 eredux-promise-middleware15 che seguono un approccio più strutturato. La figuraA.8 riporta lo schema di azione generale in React-Redux, a partire dall’emissione di unevento dalla view, fino all’aggiornamento del componente con i dati dello store.Una volta definite delle azioni asincrone che utilizzano un middleware esse vannorese disponibili al componente perché le possa chiamare (ad esempio al caricamento

13https://github.com/reduxjs/redux-thunk14https://github.com/redux-saga/redux-saga15https://github.com/pburtchaell/redux-promise-middleware

Page 122: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

112 APPENDICE A. UN CONFRONTO FRA REACT.JS E ANGULAR

import { connect } from ’react-redux’import { someAction } from ’./actions’import MyComponent from ’./MyComponent’

const mapStateToProps = state => ({prop1: state.prop1,prop2: state.prop2,

});

const mapDispatchToProps = dispatch => ({fun: () => dispatch(someAction())

});

export connect(mapStateToProps, mapDispatchToProps)(MyComponent);

Codice A.6: Dichiarazione di un componente connesso in React

del componente nella pagina). Per fare questo la libreria react-redux16 mette adisposizione la funzione connect().Tale funzione decora (utilizzando il design pattern Decorator) un componente iniettandoin esso delle proprietà. Serve però indicare a Redux come trasporre il suo store inproprietà, fornendo solo quello che serve ad un componente. Per questa ragione sidefiniscono i seguenti due metodi (i nomi sono arbitrari, ma convenzionalmente sonosempre questi):

• mapStateToProps: definisce come lo stato di Redux deve essere trasformato nelleproprietà che sono passate al componente. In questo metodo è possibile accederea tutto lo stato, ma difficilmente ogni sua parte sarà utile ad un componente,che avrà bisogno solo di un preciso sottoinsieme.

• mapDispatchToProps: nella sua implementazione base rende disponibile la fun-zione dispatch al componente, permettendogli di operare azioni sullo stato,che altrimenti non sarebbe accessibile. È però usanza comune definire anchein questo caso proprietà che corrispondono ad azioni (quindi a funzioni), inmodo da dichiarare chiaramente di quali azioni è possibile fare il dispatch in ognicomponente.

In genere questi componenti connessi allo store di Redux sono chiamati containerperché potendovi accedere acquisiscono la capacità di ottenere dati e modificarli.Un esempio di container che decora il componente MyComponent è mostrato nel bloccoA.6.Nell’esempio la connect rende disponibile al componente MyComponent le proprietàprop1, prop2 e fun che è una funzione, per esempio da invocare all’avvenire di qualcheevento. Si noti che MyComponent, nell’esempio riportato, non è consapevole della fontedi nessuna delle tre proprietà che il container recupera dallo store. Questa è la manieracon cui in React-Redux è possibile separare componenti puramente presentazionali

16https://github.com/reduxjs/react-redux

Page 123: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

A.6. ROUTING: REACT ROUTER E ANGULAR ROUTER 113

(component) dal meccanismo di ottenimento dei dati da visualizzare (del quale sioccupa il container).

A.6 Routing: React router e Angular routerIn una Single Page Application non ci sono veri e propri cambi di pagina così comenon si effettuano ricaricamenti di pagine. Inoltre sarebbe impossibile utilizzare unlink tradizionale perché non si potrebbe specificare una pagina di destinazione in <ahref=""> in quanto una web app in Angular o React è una composizione di componenti,e non esiste il concetto di pagina. Il routing client-side serve quindi a simulare lanavigazione in pagine diverse permettendo di sostituire un componente con un altrocomponente, senza effettivamente cambiare pagina o effettuare redirezioni. Il routingabilita inoltre l’utente a salvare tra i preferiti una specifica pagina dell’applicazione ead utilizzare i pulsanti avanti/indietro del browser nell’applicazione.React.js non possiede meccanismi di routing integrati. Al contrario Angular integra ilsuo router tramite il pacchetto @angular/router. Come già accennato, vi sono variesoluzioni che assolvono allo stesso compito per React, ma la più utilizzata e una dellemeglio documentate è React-router.L’unica significativa differenza riguarda il funzionamento interno dei due pacchetti,non tanto l’agio di utilizzo dal punto di vista di uno sviluppatore.Angular router usa routing statico. Ovvero le route sono dichiarate in un file che vienecaricato durante l’inizializzazione dell’applicazione, prima che qualunque componentesia caricato e mostrato.Invece in React-router (dalla versione 4 in poi) il routing avviene direttamente du-rante il caricamento dei componenti delle varie pagine, non staticamente all’avviodell’applicazione. Questo perché ogni pezzo di react-router è un component, che decidecosa mostrare quando esso viene caricato nell’applicazione. In questo caso si parla dirouting dinamico [16].Per fare un esempio pratico, in React-router ogni route viene definita da un com-ponente Route. Per una route definita come <Route path="/path" component=-{Component}>, essa mostra il componente Component solo se l’indirizzo del browser è/path. Altrimenti non mostra nulla.React-router quindi segue l’approccio dichiarativo di React.js, nel quale ogni cosa è uncomponente. Angular router invece usa un approccio più tradizionale. Ad ogni modosono disponibili pacchetti per effettuare il routing statico anche con React.

Page 124: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

114 APPENDICE A. UN CONFRONTO FRA REACT.JS E ANGULAR

/* File "heroes.component.html" */

<input type="text" [(ngModel)]="data.property">

Codice A.7: Esempio di doppio binding dei dati in Angular

@Component({selector: ’app-heroes’,templateUrl: ’./heroes.component.html’,styleUrls: [’./heroes.component.css’]

})class HeroesComponent implements OnInit {

data: Type = {id: 1,property: ’some value’

};

constructor() { }

ngOnInit() { }}

Codice A.8: Componente Angular per il template nel blocco A.7

A.7 Data bindingUn’evidente differenza fra Angular e React è il modo di collegare il modello dei datialle viste. React è spiccatamente one way data binding, ovvero fornisce un meccanismoper far fluire i dati dal modello (lo stato interno ai componenti oppure uno store) versole viste. Angular invece rende possibile anche il two way data binding fra modello evista.ngModel è la direttiva Angular che permette di collegare un certo elemento direttamentecon la sorgente del dato. I frammenti di codice A.7 e A.8 mostrano come sia possibilecollegare un input testuale al modello di dati in Angular. Il primo blocco rappresentail template HTML, mentre il secondo contiene il codice TypeScript del componente.Ogni modifica apportata nell’elemento input si riflette sul campo dati data.propertygrazie al two way data binding.In React.js invece questo comportamento va implementato con una funzione callback,come nel frammento di codice A.9.Anche in questo caso modificando il testo nella casella di input viene alterato il valorestate.value contenuto nello stato interno del componente.

Page 125: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

A.8. DOM E VIRTUAL DOM 115

class Component extends React.Component {this.state = {

value: ’’}

handleChange(e) { // callbackconst { value } = e.target // recupera il valore inseritothis.setState({ // aggiorna lo stato locale

value,})

}

render() {return (

<inputtype="text"onChange={e => { this.handleChange(e) }

/>)

}}

Codice A.9: Funzione di callback in React

A.8 DOM e Virtual DOMOgni applicazione web ha bisogno di effettuare grandi quantità di operazioni di manipo-lazione del DOM[g] (Document Object Model). Queste operazioni sono però molto piùlente della maggior parte delle operazioni JavaScript, diventando potenzialmente uncollo di bottiglia ogni qual volta sia necessario aggiornare gli elementi della pagina web.React e Angular si differenziano nel modo con cui effettuano questi aggiornamenti.React crea una copia del DOM della pagina e la mantiene in memoria. Questa copiaviene denominata Virtual DOM. Quando React rileva un cambiamento, dovuto allamodifica dello stato dell’applicazione, ogni singolo elemento nel DOM virtuale vieneaggiornato. Siccome il DOM virtuale è una copia dell’albero di elementi che costituisceil DOM reale, l’aggiornamento avviene tramite semplici operazioni JavaScript chesono molto più rapide di operazioni sul DOM reale. Una volta aggiornato il DOMvirtuale React lo compara con uno snapshot del DOM precedente al cambiamento. Inquesto modo determina quali elementi sono cambiati. A questo punto effettua le piùcostose operazioni di manipolazione del DOM solo sugli elementi realmente modificati,migliorando le performance rispetto ad un aggiornamento completo della pagina [17].Angular, invece non utilizza il DOM virtuale e aggiorna direttamente il DOM, com-parando i nuovi dati con i metadati contenuti dai componenti piuttosto che con unacopia del DOM [13].Ad ogni modo le differenze di performance legate al rendering delle pagine sono gene-ralmente trascurabili, e raramente queste differenze implementative sono una buonaragione per scegliere l’uno oppure l’altro.

Page 126: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

116 APPENDICE A. UN CONFRONTO FRA REACT.JS E ANGULAR

A.9 Ciclo di sviluppo e mantenimentoPer gli sviluppatori è importante conoscere la stabilità del framework per avere certezzache il loro lavoro non sarà reso inutile da un aggiornamento dello stesso che richiedauna parziale o completa riscrittura del codice. Di seguito inserisco informazioni sulciclo di aggiornamenti dei due soggetti del confronto. Tali informazioni sono riportatedai rispettivi canali ufficiali per la documentazione [4, 15].Angular è mantenuto dal team di sviluppo di Google. Una versione di Angular èidentificata dal formato x.y.z che ha il seguente significato:

• x: major release che contiene nuove funzionalità e può rimuoverne di esisten-ti. È previsto possa dover essere fatta della manutenzione al codice dopol’aggiornamento;

• y: minor release che può introdurre nuove funzionalità, e mantiene completacompatibilità con quelle esistenti. Non è previsto nessun adattamento alle nuoveaggiunte, ma potrebbe essere necessario imparare ad utilizzare nuove API;

• z: patch: aggiornamento di sicurezza senza rischi associati. Corregge bug e non ènecessario alcuno sforzo di adattamento.

Frequenza

• 1 major release ogni 6 mesi;

• 1-3 minor release ogni major release (quindi in circa 6 mesi);

• 1 patch release circa ogni settimana.

Angular: Supporto e Deprecation policyAll’uscita di una nuova major release, la versione precedente entra nella fase LTS, nellaquale saranno fornite solo patch di aggiornamento per correggere bug e per la sicurezza.Il supporto LTS ha la durata di 12 mesi. Quindi ogni versione resta supportata eaggiornata per circa 18 mesi (6 attiva + 12 LTS).Ogni funzionalità deprecata è listata nei changelog di ogni versione. Viene semprefornito supporto proponendo soluzioni consigliate per aggiornare il codice rimuovendole funzionalità deprecate. Ogni funzionalità deprecata viene supportata almeno nelledue major release successive.React segue lo stesso schema di nomenclatura per la versione, ma non ha una frequenzadi aggiornamento definita come Angular. Gli aggiornamenti hanno in media una cadenzamensile, ma vengono rilasciati anche più in fretta se necessario per correggere bug.Anche in questo caso solo le major release possono introdurre cambiamenti radicalirimuovendo o deprecando funzionalità, che restano comunque supportate fino almenoalla versione successiva. La documentazione non aggiunge dettagli più precisi su questoaspetto.

Page 127: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

A.10. STRUMENTI DI CONTROLLO STATICO DELL’ACCESSIBILITÀ 117

A.10 Strumenti di controllo statico dell’accessibilitàNello sviluppo di una applicazione web si dovrebbero fornire adeguati strumenti dinavigazione a tutti gli utenti, incluse persone che utilizzano screen reader o altre peri-feriche di input/output. Fornire un’esperienza accessibile a tutti è possibile utilizzandocorrettamente elementi semantici e attributi durante la creazione dei template HTML.Dato che in Angular il template HTML è posizionato in un file con estensione .html, èpossibile installare una delle varie estensioni per IDE che segnalano errori o warning diaccessibilità e suggeriscono possibili correzioni.Per React i codice HTML è posto all’interno del codice JavaScript (grazie a JSX),quindi si sente maggiormente la necessità di estensioni create ad hoc per JSX. Una dellepiù utilizzate è react-a11y. Questo pacchetto, installabile tramite npm17, permette diaggiungere una serie di regole per il linter e offre un controllo statico del codice deicomponenti scongiurando il rischio di ricadere in errori comuni.La documentazione di React contiene inoltre una sezione dedicata al suggerimento dibest practice per garantire una buona accessibilità18.

17https://www.npmjs.com/package/eslint-plugin-jsx-a11y18https://reactjs.org/docs/accessibility.html

Page 128: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

118 APPENDICE A. UN CONFRONTO FRA REACT.JS E ANGULAR

A.11 Conclusioni

Con il presente documento ho evidenziato alcuni fra i principali aspetti nei qualiAngular 6 e React.js 16 differiscono.Il percorso di stage da me intrapreso prevedeva lo sviluppo di un’interfaccia in React.jsper apprendere le basi di utilizzo della libreria e in seguito l’autoformazione su Angular,prevalentemente seguendo il tutorial ufficiale disponibile sul sito19.È naturale che il livello di dettaglio con il quale è stato effettuato il confronto mi hapermesso di evidenziare solamente le caratteristiche più superficiali. Un’analisi piùapprofondita richiederebbe più del tempo che avevo a disposizione, e sarebbe fattibilesolo possedendo una considerevole esperienza di sviluppo con entrambe le piattaforme.Nel documento ho evitato di riportare differenze triviali come quelle legate solamentealla sintassi, in quanto non ritenevo fossero di interesse data la natura del compitoassegnatomi.Alcune differenze che ho riportato si fondano su modi comuni di utilizzare i duestrumenti. Ad esempio React e Redux sono spesso adoperati assieme, pertanto neho evidenziato il meccanismo d’azione, comparandolo al service pattern di Angular.Tuttavia essendo React.js una libreria minimale con pochissime funzionalità sarebbepossibile anche utilizzarlo in una maniera più fedele possibile a quella di Angular, adesempio con architettura a microservizi20.React.js è infatti estremamente flessibile e non offre vie pronte da percorrere perraggiungere un obiettivo, rendendo possibile (e necessario) attingere da centinaiadi soluzioni create dalla sua ampia comunità di sviluppatori, oppure costruirne unapropria.Angular invece è un prodotto più maturo e completo. Offre tutto quello che serve enon è necessario inventarsi nulla. È pur sempre possibile installare e utilizzare pacchettiesterni a quelli forniti dal framework. Si è comunque obbligati a sottostare ai vincolidi utilizzo di dependency injection, servizi e componenti che hanno meccanismi difunzionamento e compiti ben definiti.In entrambi i casi articoli, tutorial e documentazione disponibili online offrono tutta laconoscenza per imparare ad utilizzarli correttamente.Soprattutto nel caso di React, talvolta capita di utilizzare pacchetti sviluppati da utentiterzi, che non sempre documentano efficacemente il loro funzionamento e costringono aricercare spiegazioni fra forum o issue GitHub. Inoltre è consigliabile evitare pacchettipoco documentati o mantenuti da poche persone, in quanto non offrono un livellodi affidabilità sufficiente a garantirne il corretto funzionamento nel tempo all’internodi un’applicazione business. Questo non può succedere utilizzando le funzionalitàdi Angular, in quanto tutto è documentato sul sito ufficiale e il supporto delle suefunzionalità è garantito.

A.11.1 Curva di apprendimento

È opinione generale che React.js sia molto più rapido da padroneggiare rispetto adAngular. La differenza riguardo a questo aspetto è evidente completando i tutorialproposti sui rispettivi siti ufficiali.Imparare ad utilizzare Angular infatti significa conoscere e saper utilizzare un’intera

19https://angular.io/tutorial20Un esempio di pacchetto per questo è create react microservice: https://immoweltgroup.

gitbooks.io/create-react-microservice/

Page 129: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

A.11. CONCLUSIONI 119

suite di strumenti offerta dal framework che copre ogni possibile necessità. Imparare adutilizzare React.js (senza altre librerie) vuol dire nient’altro che imparare ad assemblarecomponenti in una pagina e inserire callback per modificare lo stato interno. Conseguen-temente il processo sarà molto più rapido. Tuttavia per sviluppare un’applicazione realesarà necessario utilizzare diversi pacchetti esterni di cui bisogna capire il funzionamento,scontrandosi potenzialmente con documentazioni poco esaustive che rallentano i tempidi apprendimento o nel peggiore dei casi costringono a trovare un’altra soluzione.Concluderei dicendo che React è senz’altro molto conveniente nel caso si voglianosviluppare rapidamente prototipi, eliminando l’onere di definire tutta la struttura diservizi, componenti e direttive che Angular richiede.Per applicazioni più mature e complesse, React, all’interno del giusto ecosistema di pac-chetti, è equivalente ad Angular. La scelta dell’uno oppure dell’altro sarà probabilmentelegata all’entità del lavoro da svolgere in relazione alla competenza del team di sviluppo.

Page 130: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React
Page 131: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

Glossario

Application Programming Interface In informatica con il termine ApplicationProgramming Interface (API) (ing. interfaccia di programmazione di un’appli-cazione) si indica ogni insieme di procedure disponibili al programmatore, disolito raggruppate a formare un set di strumenti specifici per l’espletamento diun determinato compito all’interno di un certo programma. La finalità è ottenereun’astrazione, di solito tra l’hardware e il programmatore o tra software a bassoe quello ad alto livello semplificando così il lavoro di programmazione. 71, 116

Back-end In ingegneria del software il back-end è il livello di un applicazione che sioccupa di accedere e recuperare i dati, i quali poi saranno inviati al front-end,che si occupa invece di presentarli all’utente dell’applicazione. 3, 6, 18, 53

Basic authentication Si tratta del metodo più semplice per trasmettere credenziali,ovvero un nome utente ed una password, all’interno dell’header di chiamateHTTP. In questo schema di autenticazione il campo Authorization dell’headerdella richiesta contiene la parola Basic seguita da uno spazio e poi dalla stringausername:password codificata in Base64. Non è prevista alcuna protezione delleinformazioni trasmesse. 61

Bearer authorization Uno schema di autenticazione nel quale nel campo Authori-zation dell’header di una chiamata HTTP è inserita la parola Bearer, seguita dauno spazio e poi da un token di autorizzazione. Questo token permette al serverdi riconoscere chi ha effettuato la richiesta, bloccando richieste non autorizzate.63

Bootstrap Una libreria di componenti per front-end per costruire pagine web respon-sive e accessibili. 53, 78

Debug In informatica è l’attività di individuazione e successiva correzione delle causedi uno o più comportamenti inattesi di un software (anche definiti bug). 72

Dependency Injection Un design pattern architetturale che riguarda il modo concui soddisfare le dipendenze di un oggetto, ovvero come fornirgli istanze di altrioggetti dal quale esso dipende. 107

Design pattern Consiste in una soluzione progettuale generale ad un problemaricorrente. Nell’Ingegneria del software i design pattern affrontano problemidi composizione delle classi e delle relazioni fra oggetti, allo scopo favorire ilri-utilizzo dei moduli di un software. 6, 52, 106

121

Page 132: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

122 GLOSSARIO

Document Object Model (DOM) In informatica indica la rappresentazione didocumenti come alberi di nodi o oggetti. Un esempio di albero DOM è quellogenerato dal browser nell’interpretare un documento HTML. 115

Endpoint Un endpoint di un servizio web è un indirizzo al quale il servizio può esserechiamato da un’applicazione client. 52

Espressione regolare (regex) Si tratta di una sequenza di simboli che identificaun insieme di stringhe. La maggior parte dei linguaggi di programmazione offremetodi per verificare il match di stringhe con espressioni regolari. 53

Front-end In ingegneria del software il front-end è il livello di un applicazione con cuil’utente interagisce, che si occupa di presentare i dati all’utente, ed eventualmentesi interfaccia con il back-end . 3, 6, 49, 100

GitHub Una delle varie piattaforme che permettono il versionamento del codice. 51,95, 118

Higher-Order Component (HOC) Un Higher-Order Component (in italiano Com-ponente di Ordine Superiore) è una tecnica avanzata utilizzabile in React per ilriuso della logica dei componenti. Gli HOC non sono di per se parte delle API diReact, ma sono uno schema progettuale che emerge dalla natura a componentidi React. 69

Integrated Development Environment (IDE) Un IDE (ing. Ambiente di Svilup-po Integrato) è un software che permette la visualizzazione e la compilazione difile di codice di uno o più linguaggi di programmazione. Solitamente include moltistrumenti per agevolare lo sviluppo, come debugger ed estensioni per supportarel’evidenziazione delle keyword del codice dei diversi linguaggi. 51, 117

Internet Explorer È il browser sviluppato da Microsoft preinstallato su tutte leversioni del sistema operativo Windows. Da Windows 10 è stato soppiantato dalpiù moderno Microsoft Edge. 71

JavaScript Object Notation (JSON) Un semplice formato per lo scambio di dati,facilmente leggibile e interpretabile, basato sulla notazione utilizzata per ladefinizione di un oggetto JavaScript. 52

Json Web Token (JWT) I JWT token sono uno standard industriale aperto de-scritto nella proposta RFC 7519, che concerne lo scambio di informazioni in modosicuro fra due parti. 53, 63

JSX Un’estensione del linguaggio JavaScript che introduce nuove regole sintatticheper agevolare lo sviluppo. 52, 103

Linter Un linter è un’estensione per IDE che effettua un controllo statico del codicescritto nell’editor che aiuta lo sviluppatore a mantenere una consistenza e unamigliore leggibilità del codice scritto. Inoltre spesso segnala probabili errori efornisce suggerimenti sulle best practice del linguaggio di sviluppo. 52

Page 133: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

GLOSSARIO 123

Markdown Semplice linguaggio di markup solitamente utilizzato nella redazione difile Readme per le repository . 51

Middleware Vi sono diverse definizioni di middleware a seconda del contesto diutilizzo. Un Redux middleware permette di intercettare le azioni di cui è statoeffettuato il dispatch prima che raggiungano il reducer dello store, per tracciarlein un log, eseguire richieste asincrone, gestire errori ed effettuare il dispatch dinuove azioni. 53, 78, 110

Mock object In ambito informatico un mock indica un oggetto simulato che emulale funzionalità di un oggetto reale, ma in modo controllato. È spesso utilizzatoper testare il comportamento di un oggetto, fornendogli un mock, ovvero unaversione finta di un altro. 54, 77

MongoDB Un database non relazionale gratuito e open source. 3

Node.js È un software multi-piattaforma open source che esegue JavaScript latoserver. 52

Node Packet Manager (npm) npm, acronimo di Node Packet Manager, è il gestoredi pacchetti per Node.js. Raccoglie più di 700.000 pacchetti software open source,sviluppati dalla comunità di sviluppatori, che forniscono strumenti da utilizzareper migliorare lo sviluppo di applicazioni JavaScript. 52, 100

Open standard Uno standard aperto è uno standard con specifica liberamente di-sponibile al pubblico. Ad esempio lo standard HTML, regolato dal W3C è unostandard aperto. 63

PlantUML È uno strumento per disegnare diagrammi UML utilizzando un approcciowhat you see is what you mean. 51

Promessa In informatica una promise (promessa), talvolta chiamata future si riferiscea oggetti che funzionano da proxy per un risultato che è inizialmente sconosciuto,finché la computazione non è terminata. 72

Reactive programming Reactive programming (ing. programmazione reattiva) è unparadigma di programmazione asincrona fondato sull’utilizzo di flussi di dati(stream) e sulla propagazione del cambiamento. 108

Session Storage Si tratta di uno dei due Web Storage utilizzabili in tutti i browserconformi alla specifica HTML5, con la quale è stato introdotto. È un databasechiave/valore che permette ai siti web di salvare dati sotto forma di stringhesul browser dell’utente, fornendo un’alternativa più sicura all’utilizzo dei cookies.L’unica differenza con Local Storage è che i dati salvati sono mantenuti solo finoalla chiusura della scheda del browser della pagina, quindi si perdono con lachiusura della sessione di navigazione dell’utente. 53

Single Page Application (SPA) Si tratta di un’applicazione web oppure un sitoweb che interagisce con l’utente riscrivendo dinamicamente la pagina correntepiuttosto che caricando nuove pagine da un server. Questo approccio evital’interruzione dell’esperienza utente dovuta al cambio pagina ed offre un’esperienzapiù simile a quella di un’applicazione desktop. 5, 99

Page 134: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

124 GLOSSARIO

Spring Un framework open source che fornisce soluzioni per gestire la complessità diapplicazioni enterprise, offrendo strumenti per dependency injection, gestione ditransazioni, collegamento ai database più utilizzati e altro. 3

TexStudio Un IWE (Integrated Writing Environment) per creare documenti LATEX,open source e disponibile per tutti i principali sistemi operativi. 51

TypeScript Un linguaggio superset di JavaScript che, a differenza di quest’ultimo,supporta la dichiarazione dei tipi delle variabili, l’utilizzo delle interfacce, i metodidi classe privati e altri costrutti più tipici dei linguaggi di programmazioneorientati agli oggetti (Java, C++, ecc.). 52, 99

Typhora Un editor gratuito per il linguaggio di markup Markdown scaricabile per iprincipali sistemi operativi. 51

Ubuntu Ubuntu è un popolare sistema operativo con kernel Linux rilasciato sottolicenza GPL e mantenuto dall’azienda britannica Canonical Ltd. 51

Unified Modeling Language (UML) In Ingegneria del software Unified ModelingLanguage (ing. Linguaggio di Modellazione Unificato) è un linguaggio di model-lazione e specifica basato sul paradigma object-oriented. L’UML svolge un’im-portantissima funzione di "lingua franca" nella comunità della progettazionee programmazione a oggetti. Gran parte della letteratura di settore usa talelinguaggio per descrivere soluzioni analitiche e progettuali in modo sintetico ecomprensibile a un vasto pubblico. 72

Versionamento In informatica, con questo termine, si indica l’attività di tracciamentodelle modifiche apportate ad un insieme di file o documenti, per poterle ricondurrealla persona che le ha effettuate e per poterle annullare in caso siano dannose(effettuando un rollback). 51

Virtual Private Network (VPN) È una rete di comunicazione privata e protetta,utilizzata per la comunicazione fra due nodi che utilizzano come tecnologia ditrasporto un protocollo pubblico e condiviso, come la rete internet. Ad esempiopuò essere utilizzata per collegarsi da remoto, tramite rete internet, ad un serveraziendale. 54

W3C IlWorld Wide Web Consortium (scritto W3C) è un’organizzazione internazionalecon l’obiettivo di sviluppare le potenzialità del World Wide Web. Fra i sui compitivi è la standardizzazione dei linguaggi di markup e dei protocolli di comunicazione.74

WAI-ARIA WAI-ARIA (Accessible Rich Internet Applications) è una raccolta dispecifiche, stilata dal W3C, che standardizza metodi e procedure e suggeriscebest practice per rendere il web accessibile anche a persone con disabilità. 74

Web Content Accessibility Guidelines (WCAG) Sono una serie di linee guidaper l’accessibilità dei siti web pubblicate da WAI (Web Accessibility Initiative),che fa parte del consorzio W3C. Queste linee guida permettono di creare e divalutare contenuti web accessibili ad ogni categoria di persone. 78

Page 135: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

Bibliografia

Siti web consultati[7] Devin Eldreth. Redux Primer: Data Flow. Feb. 2017. url: http://www.deldreth.

com/posts/2017- 02- 26_redux- primer- 1.html#data- flow (visitato il11/09/2018) (cit. a p. 73).

[8] Fetch API. url: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API#Browser_compatibility (visitato il 11/09/2018) (cit. a p. 71).

[20] Redux Thunk: Motivation. url: https://github.com/reduxjs/redux-thunk#motivation (visitato il 11/09/2018) (cit. a p. 72).

[22] Radium Sharma. ABC of Redux. Mar. 2018. url: https : / / dev . to /radiumsharma06/abc-of-redux-5461 (visitato il 10/09/2018) (cit. a p. 58).

[24] Web Storage API. url: https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API (visitato il 11/09/2018) (cit. a p. 63).

Siti web consultati per il confronto[1] Angular JS Usage Statistics. url: https : / / trends . builtwith . com /

javascript/Angular-JS (visitato il 11/09/2018) (cit. a p. 100).

[2] Angular JS v2 Usage Statistics. url: https : / / trends . builtwith . com /javascript/Angular-JS-v2 (visitato il 11/09/2018) (cit. a p. 100).

[3] Angular Service Layers: Redux, RxJs and Ngrx Store - When to Use a Sto-re And Why? Giu. 2018. url: https : / / blog . angular - university . io /angular-2-redux-ngrx-rxjs/#thissituationiswhenastoreshines (visitatoil 11/09/2018) (cit. a p. 107).

[4] Angular versioning and releases. url: https://angular.io/guide/releases(visitato il 10/09/2018) (cit. a p. 116).

[5] Dependency Injection in Action. url: https://angular.io/guide/dependency-injection-in-action#limit-service-scope-to-a-component-subtree(visitato il 11/09/2018) (cit. a p. 107).

[6] Download statistics for packages react, @angular/core, @angular/cli, angular.url: https : / / npm - stat . com / charts . html ? package = react & package =%5C%40angular%5C%2Fcore&package=%5C%40angular%5C%2Fcli&package=

125

Page 136: Sviluppo di un'interfaccia web e analisi delle differenze fra Angular e React

126 BIBLIOGRAFIA

angular&from=2016-07-01&to=2018-07-31 (visitato il 11/09/2018) (cit. allepp. 100, 101).

[9] Dan Halverson. React and Angular: A Contrast. A cura di medium.com. Giu.2017. url: https://medium.com/dailyjs/react-and-angular-a-contrast-b19210c3fe89 (visitato il 11/09/2018) (cit. a p. 106).

[10] Danny Huang. What’s Redux and how to use it? Redux Series I. Set. 2017. url:https://kuanhsuh.github.io/2017/09/28/What-s-Redux-and-how-to-use-it (visitato il 11/09/2018) (cit. a p. 111).

[11] Introducing JSX. url: https://reactjs.org/docs/introducing-jsx.html(visitato il 11/09/2018) (cit. a p. 103).

[12] Introduction to services and dependency injection. url: https://angular.io/guide/architecture-services (visitato il 10/09/2018) (cit. a p. 102).

[13] Max K. (NgWizard). The mechanics of DOM updates in Angular. 2017. url:https://blog.angularindepth.com/the-mechanics-of-dom-updates-in-angular-3b2970d5c03d (visitato il 11/09/2018) (cit. a p. 115).

[14] Normalizing State Shape. url: https : / / redux . js . org / recipes /structuringreducers/normalizingstateshape (visitato il 11/09/2018) (cit. ap. 110).

[15] React releases. url: https://github.com/facebook/react/releases (visitatoil 11/09/2018) (cit. a p. 116).

[16] React Router guides: Philosophy. 2017. url: https://reacttraining.com/react - router / core / guides / philosophy / dynamic - routing (visitato il11/09/2018) (cit. a p. 113).

[17] React: The Virtual DOM. url: https://www.codecademy.com/articles/react-virtual-dom (visitato il 11/09/2018) (cit. a p. 115).

[18] React Usage Statistics. url: https://trends.builtwith.com/javascript/React (visitato il 11/09/2018) (cit. a p. 100).

[19] Redux: Three Principles. url: https : / / redux . js . org / introduction /threeprinciples (visitato il 11/09/2018) (cit. a p. 110).

[21] Cory Rylan. Normalizing State Shape. Nov. 2017. url: https://coryrylan.com/blog/angular-observable-data-services#overview (visitato il 11/09/2018)(cit. a p. 102).

[23] State of the Developer Nation Q1 2017. Apr. 2017. url: http://www.mwc.gr/presentations/2017/konstantinou.pdf (visitato il 11/09/2018) (cit. ap. 101).

[25] Brad Westfall. Leveling Up with React: Redux. Mar. 2016. url: https://css-tricks.com/learning-react-redux (visitato il 11/09/2018) (cit. alle pp. 56,105, 108).