Dal tutorial angolare di base, sembra che tutto ciò che fa è recuperare un JSON da un'API e visualizzarlo. Inoltre, c'è la sua doppia magia vincolante.
Ma perché dovrei usarlo invece di una soluzione di back-end (come Rails) che costruisce la vista nel back-end e la serve all'utente, con già tutto in atto? Quali sono i casi d'uso?
Risposte:
TLDR;
Angular ti aiuta a gestire la complessità insita nelle interfacce utente avanzate. Con l'aumentare della complessità dell'interfaccia utente, il modello tradizionale di generazione di pagine sul server diventa molto più complesso. Angular consente di scomporre l'interfaccia utente in blocchi gestibili e di separare l'interfaccia utente dall'implementazione. Ciò rende la generazione di pagine lato server molto più semplice, ma Angular diventa davvero una realtà quando si passa a applicazioni pure basate su JavaScript. Un buon esempio di tale applicazione è Trello .
La lunga storia
Angular non è realmente mirato a siti che puoi comodamente implementare generando tutto sul server e inviandolo. Inoltre, sebbene si tratti di un approccio perfettamente valido che funziona per molti siti e applicazioni su Internet, diventa sempre più complesso (quindi difficile) mantenere attivo tale approccio mentre si tenta di aumentare il livello di interattività nel proprio sito.
In definitiva, il modo in cui risolvi questo problema è spingendo sempre più la tua interfaccia utente nel lato Javascript dell'equazione. Angular ti consente di suddividere l'interfaccia utente in componenti, offrendoti una chiara separazione tra aspetto e funzionamento. È quindi possibile creare pagine abbastanza semplici sul server e il front-end JS viene utilizzato per creare un'interfaccia utente ricca che effettua chiamate separate al server per i dati di cui hanno bisogno.
Arriva un punto, tuttavia, in cui tutto ciò che vuoi fare è server una pagina stub che carica un'applicazione completamente basata su JavaScript. Probabilmente l'esempio più noto del tipo di caso d'uso in cui Angular brilla davvero è Trello (usa Backbone, non Angular, ma è lo stesso caso d'uso). Esiste un sito http://builtwith.angularjs.org/ che contiene più siti di esempio che utilizzano Angular.
Quindi la risposta breve? Angular semplifica la creazione di interfacce utente ricche e altamente interattive, consentendo di scomporre l'interfaccia utente in componenti e, infine, passare completamente a JavaScript.
Si tratta di creare interfacce utente più reattive. La doppia rilegatura, l'iniezione delle dipendenze e così via consente di creare pagine dinamiche abbastanza facilmente. Puoi scrivere direttive in angolare che ti danno un modo dichiarativo per costruire una vista.
Ad esempio, in un progetto attuale abbiamo una vista che utilizza diverse centinaia di righe di codice JavaScript per rendere l'esperienza utente reattiva. Anche così la pagina è un po 'buggy e molto difficile da mantenere. Abbiamo iniziato a cercare un'opzione migliore e abbiamo guardato backbone.js e knockout.js. Alla fine abbiamo provato Angular. Siamo riusciti a creare una pagina molto più reattiva e gestibile con poche righe di codice. Andato era tutto il codice di manipolazione DOM. Sono finite tutte le creazioni di visualizzazione di backend ingombranti che dovevano essere recuperate e inserite nei posti giusti. Andato era tutto il codice che era stato scritto per mantenere il modello e la vista sincronizzati. Con quell'esperienza la decisione di trasferirsi in Angolare è diventata più semplice e finora non ce ne siamo pentiti.
Angular è per lo sviluppo di applicazioni a pagina singola, aiuta a fornire uno scheletro solido per la tua app. È anche buono con i moduli, non così buono con complesse interfacce utente affollate con molti dati. All'inizio l'associazione di dati bidirezionale è "magica", ma è necessario essere consapevoli del fatto che i framework più recenti (incluso Angular 2 stesso) si allontanano dall'associazione di dati bidirezionale per un approccio più semplice di flusso di dati / flusso di eventi (che dice che la storia sarebbe troppo lunga qui).
Devo anche avvertirti che Angular non ha un modo preciso di fare le cose e talvolta offre troppi modi per scuoiare un gatto, il che può rendere più ripida la curva di apprendimento. Inoltre, se desideri ridimensionare un'app angolare, dovrai comprenderne la meccanica interna e il possibile impatto sulle prestazioni. Una volta che lo fai, e una volta stabiliti modelli di progettazione solidi coerenti, il cielo è il limite. Ma devi dedicare del tempo ad esso.
Detto questo, la tua domanda sembra riguardare più quali sono i casi d'uso delle ZPS piuttosto che gli stessi angolari.
I casi d'uso delle applicazioni a pagina singola sono per avere app Web con UI / UX robuste e una migliore sensazione generale dell'applicazione. Non dovendo ricaricare la tua pagina risparmi sui tempi di rendering e sulla larghezza di banda. Separate anche i dati e la presentazione, il che è fantastico. La tua richiesta diventa: