AngularJS best practice - Modelli vs Javascript

Question

Per impostazione predefinita, Angular recupera i modelli HTML dal server quando l'utente naviga verso una rotta. Con questo in mente, immagina questo scenario:

• L'utente carica l'app Angolare. La vista principale ha una pagina secondaria chiamata "Ordine".
• Mentre l'utente sta studiando la vista principale, viene messa in produzione una nuova versione dell'app. La nuova versione ha una completa riscrittura della pagina Ordine con nuovi Javscript e HTML.
• L'utente accede alla pagina Ordine. Il Javascript è già caricato dal browser nel passaggio 1, quindi l'utente è sulla vecchia versione fino a quando l'app non viene ricaricata. Ma il nuovo modello viene prelevato dal server durante la navigazione. Quindi ora il Javascript e il modello sono i nostri di sincronizzazione!

La mia ipotesi è che Javascript/HTML non sia sincronizzato, corretto?

In tal caso, esistono delle best practice relative a questo problema?

Immagino che una soluzione sia la marca Angolare che preleva tutti i modelli sull'inizializzazione dell'app. Ma questa potrebbe essere una penalizzazione delle prestazioni se l'app ha centinaia di visualizzazioni HTML.

Answer 1

Grazie per le buone risposte.

Si è scoperto che questo problema si è risolto per noi. Ogni volta che distribuiamo una nuova versione tutte le sessioni degli utenti vengono eliminate e gli utenti verranno inviati alla pagina di accesso. Questo attiverà un caricamento della pagina e verrà caricato fresco JavaScript/HTML.

Answer 2

Non mi sono mai chiesto questo problema. Una possibile idea sarebbe quella di riutilizzare il modello noto come versioning delle risorse, dove alla nuova release, rinominate tutte le vostre risorse.

Ad esempio, anziché login.html si utilizza login-xyz.html come nome di un modello. xyz potrebbe essere un valore casuale o un checksum del file. Il checksum potrebbe essere un'opzione leggermente migliore perché se la nuova versione è piccola (cioè hai corretto qualche piccolo bug in un file), se l'utente carica qualsiasi pagina tranne quella fissa, non sarà disturbato con una ricarica - tutti gli altri i file avranno gli stessi checksum, funzioneranno senza interruzioni.

In questo modo, quando un'app Anguar obsoleta tenta di recuperare un modello, si ottiene un errore HTTP 404. In aggiunta, potresti scrivere un semplice $http interceptor, che rileverà una risposta 404 e ricaricherà automaticamente la pagina (o offrirà all'utente un'opzione per farlo).

Ci sono moduli che sono in grado di ridenominare le risorse, come ad esempio gulp-rev - ma non ho mai sentito di usarlo per i modelli angolari. Potresti implementare qualcosa del genere da solo, però.

Naturalmente è possibile mantenere sia la versione nuova che quella vecchia dei file per consentire agli utenti di lavorare senza interromperli con un aggiornamento. Dipende da quali sono le tue esigenze. Suppongo che tu stia cercando di evitarlo, comunque.

---

Esempio 404 intercettore (CoffeScript, come ho a portata di mano ora):

m.factory 'notFoundInterceptor', ($q) -> 
    return { 
    responseError: (response) -> 
     if response?.status == 404 
      # Reload, or warn user 
      return $q.defer() 

     # Not a 404, so handle it elsewhere 
     $q.reject response 
    } 

m.config ($httpProvider) -> 
    $httpProvider.interceptors.push 'notFoundInterceptor' 

Answer 3

Ho letto su questo problema molto tempo fa, e una possibilità è di fare delle versioni sulle pagine modificate e file application.js.

Per esempio della versione 1 della vostra applicazione è possibile sul tuo html utilizzo file di qualcosa di simile a:

<script src="js/angular_app_v1.js"></script> 

All'interno tuoi percorsi anche la versione del TemplateURL

templateUrl: 'templates/view_product_v1.html' 

Quindi, quando si tira fuori un la nuova versione non sovrascriverà i template e gli utenti che già lavorano avranno la vecchia versione fino a che non ricaricheranno il browser ma non avranno inconsistenze di versione.

Answer 4

Il controllo delle versioni delle risorse utilizzando i nomi dei file non è più gestibile nemmeno per un'app per le medie.

Sebbene sia un approccio pesante per le risorse Web, è possibile esaminare la negoziazione del contenuto. Qui è dove la chiamata per una risorsa, in genere un'API REST restituisce la versione della risorsa, Content-Type: application/vnd.contentful.delivery.v1+json.. Sul client è possibile verificare che la versione corrisponda a ciò che si aspetta. Quindi, se il client sa solo come caricare v1.1 e le risposte alle risorse con v1.2, l'interfaccia utente saprebbe che non può elaborarlo e dovrebbe ricaricare la pagina.

Un'altra possibilità è caricare tutti i modelli in primo piano nell'interfaccia utente. Ci sono processi di compilazione in Grunt che puoi eseguire come https://github.com/ericclemmons/grunt-angular-templates che unirà tutti i tuoi modelli in un unico file per la consegna e poi li caricherà in $ templateCache in modo che nessuna richiesta arrivi al server.

Answer 5

Se si dispone di una sorta di linguaggio lato server è possibile creare un filtro (.NET, Rails, Java o qualsiasi altra cosa) e passare un numero di versione con le richieste del modello. Se la versione richiesta dal client è precedente a quella distribuita, invierai un errore al client. Il tuo cliente avrebbe guardato per quell'errore (intercettore $ http) e forzato un aggiornamento della pagina per tirare giù il codice javascript più recente. (Forse mostrare prima un avviso all'utente in modo che sappiano cosa sta succedendo).

Answer 6

È possibile precaricare tutti i modelli in $ templateCache e servirli come un file templates.js. Esiste un compito eccezionale per questo https://www.npmjs.com/package/gulp-angular-templatecache. Quindi l'applicazione caricherà tutti i modelli in una singola richiesta insieme agli script dell'applicazione all'avvio, quindi saranno sincronizzati. Leggi http://www.johnpapa.net/angular-and-gulp/ per maggiori informazioni.

Answer 7

Ha sempre senso avere un numero di versione e utilizzarlo durante la sincronizzazione delle risorse. Non è solo una buona pratica per il caso d'uso che hai descritto, ma anche per altre situazioni, come tornare a una versione specifica o avere due versioni live e utilizzabili (ad esempio per consentire ad alcuni utenti di visualizzare l'anteprima della prossima versione)