Pratiche per l'organizzazione delle importazioni AMD JavaScript

4

La nostra azienda ha utilizzato le versioni più recenti del framework Dojo, che sono progredite in un formato caricatore basato su AMD. Attualmente sto cercando di trovare dei modi logici per separare i file di livello, prendere un modulo e tutte le sue dipendenze e avvolgerli tutti in singoli file minificati. I miei obiettivi sono generalmente i seguenti:

  • Riduci al minimo il numero di richieste separate effettuate per pagina
  • Se possibile, utilizza la cache in modo da recuperare nuovamente i moduli di grandi dimensioni già utilizzati.

La nostra app è composta da molte centinaia di pagine e finestre di dialogo, molte delle quali hanno una propria logica personalizzata e script correlati.

Sto iniziando a imbattersi in problemi sempre più complessi in termini di trovare il modo giusto per costruire file di livelli per le migliori prestazioni. Proprio di recente, mi sono imbattuto nel seguente tipo di scenario:

A dipende da B, dipende da C, dipende da D ... ecc ... dipende da Z.

A1 dipende da D (che dipende da ... Z)

A2 dipende da L (che dipende da ... Z)

Lo scenario è per lo più solo un esempio: non ho 24 dipendenze in un albero retto. Ma con il nostro metodo precedente di dichiarare semplicemente tutti gli oggetti globalmente sotto uno spazio dei nomi, si tratta semplicemente di minimizzare tutto in un file di livello incluso nelle pagine pertinenti. Così com'è ora, non sono sicuro di cosa guadagnerei facendo di D il suo livello, o A o L. Proprio per evitare di caricare lo stesso codice due volte, lo separeremmo in circa 3 o 4 richieste. Un dato problematico è il modo in cui lo script della pagina emette immediatamente nuove richieste di script per qualsiasi cosa nel suo blocco "require ()" che non ha ancora memorizzato nella cache. Inoltre, è diventato molto complicato solo per comprendere e discutere.

Volevo sapere in che modo le altre persone tendono ad affrontare questo problema, si spera in un modo più semplice; la versione precedente del nostro prodotto presentava alcuni significativi problemi di caricamento in tempo reale, quindi questo non è certamente l'ottimizzazione prematura (potrebbe essere "passato-maturo"). Stiamo iniziando a cambiare le nostre pagine per utilizzare tag script caricati in modo asincrono ora che la maggior parte dei nostri script lo supporta, nel caso sia utile.

    
posta Katana314 17.10.2014 - 22:23
fonte

2 risposte

0

Questa non è davvero una risposta, è solo un commento più lungo

Per trarre ispirazione, ti suggerisco di dare un'occhiata al (1) progetto link che mirava per semplificare la gestione delle dipendenze tra i pacchetti JavaScript (e il loro packaging e minification). Da quando sono nato 2 anni fa si è sistemato in qualche modo e può offrire una soluzione.

Altre buone pratiche di gestione dei moduli che ti suggerisco di guardare (2) sono quelle usate e raccomandate per l'uso insieme a dattiloscritto . Alcune discussioni su vantaggi e svantaggi dell'utilizzo di moduli interni / esterni sono disponibili in link

La compilazione in tempo reale di 1 script minuscolo per pagina ottiene il mio voto, lazy caricando grandi script su richiesta possibile ma piuttosto un'eccezione alla regola.

Questo è il modo in cui tendo ad affrontare il problema

Alcuni interessanti approfondimenti:

risposta data 20.10.2014 - 17:46
fonte
0

(Auto-risposta) Una cosa che ho provato ultimamente e con moderato successo, è creare livelli di avvio separati. Dal momento che possiamo essere certi che ogni particolare blocco di JavaScript eseguirà tutti, o non eseguirà affatto, e deve essere disponibile per qualsiasi definizione / richiesta di lavoro, è un buon posto dove mettere tutti i principali " moduli di libreria "per qualsiasi tipo di utente specifico.

Da lì, ho creato livelli minificati per ogni "script di pagina", escludendo tutti i moduli già scritti in uno degli script di avvio di tipo utente. C'è ancora un sacco di lavoro manuale, e in effetti alcune ristrutturazioni. Per le prestazioni, ho bisogno che la pagina di login per ogni tipo di utente richieda il loro "layer" prima di arrivare alla loro homepage (ogni script ammonta a un megabyte, non a una piccola app). Sembra che si stia adattando alle mie esigenze finora, ma non ha superato alcun test prestazionale effettivo.

    
risposta data 22.10.2014 - 15:54
fonte

Leggi altre domande sui tag