2014-07-03 29 views
5

Sono stato readingaboutes6 module loaders e io proprio non capisco come funziona e spero che qualcuno possa illuminarmi.Come funziona il caricamento del modulo es6

Nei flussi di lavoro pratici link qui sopra hanno un esempio come questo

System.import('app/app').then(function(app) { 
    // app is now the Module object with exports as getters 
}); 

Nessun problema con quello - ho capito. Ma poi vedo cose del genere

var $ = require('jquery'); 

e diventare davvero confuso. Cosa succede se al momento della chiamata questa jquery non è stata ancora trasferita nel browser? Il filo gira? Il browser analizza il tuo script dietro le quinte e lo modifica in un callback come fa RequireJs? Cosa è configurabile? Ci sono dei limiti specifici?

Qualcuno può darmi una carrellata?

+1

La seconda cosa che si vede è "caricamento del modulo CommonJS", non un afaik ES6. In effetti [non funziona (bene) all'interno di require.js] (http://requirejs.org/docs/api.html#cjsmodule) – Bergi

+0

@Bergi funziona bene all'interno di require.js, mentre io non lo preferisco ci sono alcune pagine all'interno del mio progetto corrente che usano requirejs con lo stile commonjs. Requirejs esegue la scansione del tuo script per le espressioni commonjs e lo riscrive su un formato amd, pertanto utilizza ancora i callback. Tuttavia, a meno che non mi sbagli, la proposta es6 NON usa i callback, quindi la mia confusione. –

+0

Sì, e la scansione dello script non funziona bene per tutti tranne i casi più semplici. Puoi collegare la parte della proposta ES6 che intendi? 'System.import' ovviamente usa i callback. – Bergi

risposta

4

Il Loader modulo ES6 recupera l'origine, determina le dipendenze e attende che tali dipendenze siano caricate prima dell'esecuzione del modulo. Quindi nel momento in cui viene eseguita la richiesta, la dipendenza è già lì seduta in attesa di essere eseguita.

Quando si carica CommonJS tramite un caricatore di moduli ES6, ci si basa sull'analisi statica delle istruzioni require dall'origine e sull'esecuzione della sorgente solo dopo aver caricato tali dati.

In questo modo è possibile supportare in modo dinamico CommonJS nel browser. I riferimenti circolari sono trattati in modo identico al modo in cui vengono gestiti nel nodo.

Le espressioni regolari che analizzano il fabbisogno sono in realtà piuttosto affidabili e veloci, tenendo conto dei commenti e dei token circostanti. Vedi https://github.com/systemjs/systemjs/blob/master/lib/extension-cjs.js#L10 per quello usato da SystemJS.

C'è un limite rimanente con questo approccio e questo è CommonJS dinamico e condizionale richiede come if (condition) require('some' + 'name') non vengono rilevati correttamente. Questo è un costo necessario per far sì che CommonJS si comporti come un formato di modulo completamente asincrono nel browser.

+1

Qualche tempo dopo aver scritto questa domanda abbiamo ottenuto [questo fantastico articolo sui moduli es6] (http://www.2ality.com/2014/09/es6-modules-final.html). Contrasta in modo diretto con alcune delle tue affermazioni (ad esempio l'analisi delle espressioni regolari, il funzionamento delle dipendenze circolari e la disponibilità di dinamiche). Sembra anche che un po 'della mia confusione, almeno, sia che i moduli e i caricatori di moduli sono specifiche separate di cui solo il primo è completo. –

+2

Il caricatore di moduli ES6 ha due modi di interpretare i moduli: 1. Moduli ES6 2. Formati del modulo legacy Possiamo costruire il formato del modulo legacy nel caricatore del modulo ES6 tramite un hook chiamato "instantiate". Hai ragione - Il caricamento del modulo ES6 ha anche uno stile di riferimento circolare diverso da CommonJS. Quando si scrive il supporto CommonJS nel caricatore, questo può consentire il supporto di riferimento circolare completo in stile CommonJS. In termini di specifiche, il comportamento della classe del caricatore del modulo si trova nella specifica ES6, ciò che è una specifica separata è l'esatto hook dell'ambiente. – guybedford

Problemi correlati