AngularJS è solo per applicazioni a pagina singola (SPA)?

Stiamo esaminando le opzioni per creare il front-end di un’applicazione che stiamo creando e stiamo cercando di valutare uno strumento che funzionerà per noi e offrirci la migliore piattaforma per andare avanti.

Questo è un progetto Node.js. Il nostro piano iniziale era di usare Express e seguire questa strada, ma abbiamo deciso che prima di iniziare questa fase sarebbe meglio rivedere ciò che è là fuori. La nostra applicazione ha diverse aree che non riteniamo adatti per il modello a pagina singola in quanto sono correlati da una prospettiva applicativa, ma non da una vista.

Abbiamo visto alcuni dei framework che potremmo utilizzare per creare il client come Backbone.js , Meteor , ecc. E anche AngularJS.

Questa potrebbe essere una domanda abbastanza ovvia, ma non possiamo decifrare se AngularJS è puramente per applicazioni a pagina singola o può essere utilizzato per applicazioni multipagina come Express per esempio.


AGGIORNAMENTO 17 luglio 2013 Solo per tenere le persone al corrente, aggiornerò questa domanda durante il processo. Per ora buildmo tutto insieme e vedremo quanto bene si compie. Abbiamo contattato alcune persone che sono più qualificate con AngularJS di noi e abbiamo posto la domanda riguardante la suddivisione di applicazioni più grandi che condividono il contesto, ma potrebbero essere troppo grandi per lavorare su una singola pagina.

Il consenso era che potremmo servire più pagine statiche e creare applicazioni AngularJS che funzionano con solo quelle pagine, creando in modo efficace una raccolta di SPA e collegando queste applicazioni insieme usando il collegamento standard. Ora il nostro caso d’uso è molto specifico in quanto la nostra soluzione ha diverse applicazioni e, come ho detto, proveremo prima la base del codice singolo e ottimizzeremo da lì.

AGGIORNAMENTO 18 giugno 2016 Il progetto è caduto a picco, quindi non siamo mai riusciti a fare troppo. L’abbiamo raccolto di recente, ma non stiamo più usando angular e invece utilizziamo React. Stiamo ancora utilizzando l’architettura delineata nell’aggiornamento precedente, in cui utilizziamo applicazioni espresse e autonome, quindi, ad esempio, abbiamo un percorso /chat in express che serve la nostra app di chat React, abbiamo un’altra rotta /projects che serve l’app per i progetti e così via. Il modo in cui la guardiamo è che ogni app è una radice aggregata in termini di set di funzionalità, deve essere in grado di essere indipendente perché possa essere considerata un’app in sé. Tecnicamente, tutte le informazioni sono là fuori, è solo un’espressione di base e qualunque sia il sapore dell’app client che costruisce la bontà che vuoi usare.

Affatto. Puoi utilizzare Angular per creare una varietà di app. Il routing lato client è solo un piccolo pezzo di questo.

Hai una vasta lista di funzionalità che ti avvantaggeranno al di fuori del routing lato client:

  • rilegatura a due vie
  • template
  • formattazione della valuta
  • pluralizzazione
  • controlli riutilizzabili
  • Manipolazione delle api RESTful
  • Gestione AJAX
  • modularizzazione
  • iniezione di dipendenza

È assurdo pensare che tutto ciò “possa essere usato solo in una singola app”. Certo che no … è come dire “Jquery è solo per progetti con animazioni”.

Se si adatta al tuo progetto, usalo.

Ho lottato con il “come” in un primo momento anche con Angular. Poi un giorno mi è venuto in mente: “È ANCORA javascript”. Ci sono un sacco di esempi sugli angoli interni di Angular (uno dei miei preferiti insieme al libro https://github.com/angular-app/angular-app ). La cosa più importante da ricordare è caricare i file js proprio come faresti in qualsiasi altro progetto. Tutto quello che devi fare è assicurarti che le diverse pagine facciano riferimento all’object angular corretto (controller, vista, ecc.) E che tu sia spento e in esecuzione. Spero che abbia senso, ma la risposta è stata così semplice che l’ho trascurato.

Forse la mia esperienza sarà utile a qualcuno. Abbiamo diviso il nostro progetto logicamente. Una SPA che utilizziamo per i feed, un’altra per lavorare con la mappa, un’altra per la modifica di un profilo utente e così via. Ad esempio, abbiamo tre app: feed, utente e mappa. Lo uso negli URL separati, in questo modo:

 https://host/feed/#/top/ https://host/user/#/edit/1/ https://host/map/favorites/#/add/ 

Ciascuna di queste applicazioni ha i propri mapping di routing locali tra stati nell’applicazione. Penso che sia una buona pratica, perché ogni applicazione funziona solo con il proprio contesto e carica le dipendenze di cui ha realmente bisogno. Inoltre, è molto utile per i processi di debug e integrazione.

In effetti, puoi facilmente creare un mix di app SPA, ad esempio il feed sarà url con l’applicazione angularjs, l’app utente con reactjs e la mappa nell’applicazione backbone.js.

In risposta alla tua domanda:

Angolare non solo per SPA, Angular gioca bene e velocemente per applicazioni SPA, ma nessuno si preoccupa di creare un’applicazione MPA di una varietà di applicazioni SPA. Ma pensando alla tua architettura dell’URL non dimenticare la disponibilità SEO delle tue applicazioni.

Sostengo anche l’idea:

Qual è la differenza tra un progetto e un’app? Un’app è un’applicazione Web che fa qualcosa, ad esempio un sistema Weblog, un database di record pubblici o una semplice app di sondaggio. Un progetto è una raccolta di configurazioni e app per un determinato sito Web. Un progetto può contenere più app. Un’app può trovarsi in più progetti.

Se tutto ciò di cui hai bisogno sono alcune pagine con i dati del client, andrei con Knockout e Javascript Namespacing.

Knockout è ottimo, specialmente se hai bisogno di una retrocompatibilità semplice e di pagine abbastanza dirette. Se si utilizzano componenti di terze parti, i binding personalizzati di Knockout sono semplici e facili da utilizzare.

Il namespace Javascript ti consente di mantenere il tuo codice separato e gestibile.

 var myCo = myCo || {}; myCo.page = { init: function(){ ... }, ... } 

E in un tag script dopo il caricamento degli altri script

  

La chiave è che usi lo strumento che desideri quando ne hai bisogno. Hai bisogno di un databinding? Knockout (o qualunque cosa ti piaccia). Hai bisogno di routing? sammy.js (o qualsiasi altra cosa ti piaccia).

Il codice cliente può essere semplice o complicato come lo vuoi tu. Ho provato ad integrare Angular in un sito molto complicato con un framework proprietario esistente, ed è stato un incubo. L’angular è ottimo se stai iniziando a essere fresco, ma ha una curva di apprendimento e ti blocca in un stream di lavoro molto stretto. Se non lo segui, il tuo codice può diventare davvero aggrovigliato molto velocemente.

Direi che Angular è eccessivo se stai solo cercando di sviluppare una SPA. Certo, se ti senti già a tuo agio nello sviluppo, vai avanti. Ma se sei nuovo al framework e hai solo bisogno di sviluppare una SPA, andrei con qualcosa di più semplice con una serie di vantaggi. Consiglio di guardare Vue.js o Aurelia.io .

Vue.js utilizza l’associazione dati bidirezionale, MVVM, componenti riutilizzabili, semplice e veloce da prelevare, meno codice da scrivere, ecc. Combina alcune delle migliori caratteristiche di Angular e React.

Aurelia.io , in tutta onestà, non ne so molto. Ma ho sbirciato in giro e sembra un’alternativa che valga la pena di guardare, simile a quanto sopra.

link:
https://vuejs.org/
http://aurelia.io/