Angular UI Routing e componenti

Angular UI Router ha lentamente integrato il supporto per il routing ai componenti Angular. Questo post discuterà perché questo è utile, e come farlo usando sia Angular UI Router 0.x.x che la versione 1.0.0-beta.x.

Background

Con l’introduzione dei componenti Angular nella versione 1.5, il concetto di un insieme stand alone e riutilizzabile di comportamenti e viste è diventato più facile da definire rispetto a quanto fatto precedentemente nelle direttive. Questi cambiamenti includono: l’astrazione dello scopo, il collegamento ai controller in modo esplicito, la fornitura di ganci per il ciclo di vita nel controller, così come alcune altre cose.

Questo ha permesso una migliore componentizzazione di intere viste e applicazioni. Con questo è arrivata la consapevolezza che una pagina web è un componente composto da componenti.

Detto questo, il routing verso un componente è diventato un comportamento desiderato.

Componenti intelligenti e componenti stupidi

Prima di approfondire l’uso di UI Router per instradare i componenti, il concetto di componenti intelligenti e stupidi dovrebbe essere discusso.

Un componente intelligente è uno che è molto consapevole delle API e dei dati che guidano una vista. Questo significa che nel suo controller, sta tipicamente facendo una chiamata di servizio all’inizializzazione del componente. Sa cosa è richiesto per effettuare la chiamata e la risposta che dovrebbe aspettarsi dall’API.

D’altra parte, ci sono componenti stupidi che sanno cosa fare con un oggetto o un valore passato e di quali interazioni è responsabile. In genere non interagisce con nessun servizio. La maggior parte delle interazioni risultano in un callback ad un componente genitore per passare le informazioni indietro per essere usate
da un componente intelligente o sono relative puramente ai cambiamenti di visualizzazione.

Per il bene della riusabilità, i componenti muti sono tipicamente i più riutilizzabili (pensate a contenitori con intestazioni, barre di navigazione, select box, ecc). I componenti intelligenti sono ottimi per costruire applicazioni complete da un alto livello, ma non sono molto personalizzabili.

Il modo migliore per rendere un componente muto è quello di rimuovere le chiamate API dai controllori e trovare un modo per fornire quei dati attraverso una sorta di binding. Questo è utile se hai già gli stessi dati di cui ha bisogno un componente intelligente, ma non vuoi fare due visite al server per averli.

Scrivere un’applicazione come un componente

Con il passaggio alle applicazioni componentizzate, c’è stato un cambiamento mentale relativo a come vediamo le applicazioni. Intere applicazioni possono essere viste come un componente. Questo ha effettivamente dei casi d’uso pratici. Per esempio, se scriviamo la nostra applicazione come un componente, possiamo prendere un’applicazione web indipendente e potenzialmente metterla in un contenitore web ibrido e farne un’applicazione mobile.

Il modo migliore per scrivere un’applicazione come un componente è quello di sfruttare le viste annidate in UI Router. Questo può essere impegnativo, a volte, ma permette una grande flessibilità nello scambiare i componenti basati
sullo stato dell’applicazione.

Uso dei componenti nella definizione dello stato usando i template

La prima integrazione con i componenti routable è stata, invece di usare una proprietà templateUrl sulla definizione dello stato, usare la proprietà template. Un esempio di questo sarebbe
come segue:

Ovviamente, questo funziona, ma quando ogni singolo stato è dichiarato con un elemento HTML che è semplicemente un singolo elemento HTML senza attributi, inizia a diventare noioso.

Garantito, tutta la logica e la visualizzazione relativa a quel componente è isolata e riutilizzabile. Se, per esempio, decidete di avvolgere myComponent in un template di navigazione, ora potete farlo senza dover generare un nuovo componente da un template se avete impostato lo stesso stato come tale:

Binding to Components

Come facciamo a scrivere un’applicazione completa come un componente muto, quando molti dei nostri percorsi devono fare chiamate di servizio per visualizzare informazioni che un utente vuole visualizzare?

Una possibile risposta a questo è risolvere i dati necessari al funzionamento del componente dalla rotta e poi legarli al componente attraverso i binding del componente. Ci sono due approcci per farlo:

1. Creare un componente intelligente che avvolge un componente stupido. L’unico scopo del componente intelligente è quello di fare una chiamata di servizio e legarsi correttamente al componente muto.
2. Utilizzare la funzionalità di risoluzione fornita nel router UI per risolvere i dati direttamente al componente muto.

Ci sono alcuni ovvi compromessi per entrambe le opzioni. Con un wrapper per componenti intelligenti, hai un componente aggiuntivo da mantenere. Per risolvere il componente usando UI Router, ti stai legando alla capacità del router, ed è anche più difficile gestire la gestione delle eccezioni.

Detto questo, creare componenti instradabili tramite i binding di UI Router è estremamente semplice, e UI Router è abbastanza potente e fornisce grandi funzionalità al punto che, se è nel tuo progetto, probabilmente rimarrà lì fino alla completa riscrittura di un’applicazione.

Per legarsi a un componente nella versione stabile di UI Router (0.x.x), UI Router crea un oggetto $resolve nel contesto che ha usato per compilare il contenuto del ui-view.

Questo può essere usato per legarsi a una dichiarazione del componente nella proprietà template della definizione dello stato.

Questo ci permette di rimuovere la dipendenza UserService dal componente user. Per quei componenti intelligenti che fanno semplicemente una chiamata al servizio e poi visualizzano le informazioni, possiamo effettivamente eliminare anche un intero controller.

Binding to Components – 1.0.0-beta.x

Con il rilascio di [email protected], la proprietà component è stata aggiunta all’oggetto definizione di stato. Questo permette allo sviluppatore di legarsi direttamente a un componente come definito nel modulo angolare. Elimina la necessità di avere un template contenente un singolo elemento, come avevamo visto in passato.

Sono state aggiunte le seguenti proprietà