L’utilizzo di Node.js richiede l’importazione / esportazione di ES6

In un progetto a cui sto collaborando, abbiamo due scelte su quale sistema di moduli possiamo usare:

  1. Importare moduli usando require ed esportando usando module.exports ed exports.foo .
  2. Importazione di moduli mediante l’ import ES6 ed esportazione mediante export ES6

Ci sono dei vantaggi in termini di prestazioni nell’usare l’uno sull’altro? C’è qualcos’altro che dovremmo sapere se dovessimo usare i moduli ES6 su quelli Node?

Ci sono dei vantaggi in termini di prestazioni nell’usare l’uno sull’altro?

Tieni presente che non esiste ancora un motore JavaScript che supporti nativamente i moduli ES6. Hai detto a te stesso che stai usando Babel. Babel converte la dichiarazione di import ed export in CommonJS ( require / module.exports ) per impostazione predefinita. Quindi, anche se si utilizza la syntax del modulo ES6, si utilizzerà CommonJS sotto il cofano se si esegue il codice nel nodo.

Esistono differenze tecniche tra i moduli CommonJS e ES6, ad esempio CommonJS consente di caricare i moduli in modo dinamico. ES6 non lo consente, ma esiste un’API in fase di sviluppo .

Poiché i moduli ES6 fanno parte dello standard, li userei.

Ci sono diversi usi / capacità che potresti voler considerare:

richiede:

  • È ansible avere un caricamento dinamico in cui il nome del modulo caricato non è predefinito / statico, o dove si carica un modulo solo se è “veramente richiesto” (a seconda del stream di codice).
  • Il caricamento è sincrono. Ciò significa che se hai più require s, vengono caricate ed elaborate una per una.

Importazioni ES6:

  • È ansible utilizzare le importazioni denominate per caricare in modo selettivo solo i pezzi necessari. Questo può salvare la memoria.
  • L’importazione può essere asincrona (e nel Loader modulo ES6 corrente, infatti, è) e può funzionare un po ‘meglio.

Inoltre, il sistema del modulo Require non è basato su standard. È altamente improbabile che diventi standard ora che esistono i moduli ES6. In futuro ci sarà il supporto nativo per i moduli ES6 in varie implementazioni che saranno vantaggiose in termini di prestazioni.

I principali vantaggi sono sintattici:

  • Sintassi più dichiarativa / compatta
  • I moduli ES6 renderanno fondamentalmente obsoleto UMD (Universal Module Definition), rimuovendo essenzialmente lo scisma tra CommonJS e AMD (server vs browser).

È improbabile che si vedano dei vantaggi in termini di prestazioni con i moduli ES6. Sarà comunque necessaria una libreria aggiuntiva per raggruppare i moduli, anche quando il browser supporta pienamente le funzionalità di ES6.

Ci sono dei vantaggi in termini di prestazioni nell’usare l’uno sull’altro?

La risposta attuale è no, perché nessuno degli attuali motori di browser implementa l’ import/export dallo standard ES6.

Alcuni grafici di confronto http://kangax.github.io/compat-table/es6/ non ne tengono conto, quindi quando vedi quasi tutti i verdi per Chrome, fai attenzione. import parola chiave import di ES6 non è stata presa in considerazione.

In altre parole, gli attuali motori di browser, incluso V8, non possono importare nuovi file JavaScript dal file JavaScript principale tramite qualsiasi direttiva JavaScript.

(Potremmo essere ancora a pochi bug o a distanza di anni, finché V8 non implementerà quello secondo le specifiche ES6).

Questo documento è ciò di cui abbiamo bisogno e questo documento è ciò che dobbiamo obbedire.

E lo standard ES6 diceva che le dipendenze del modulo dovrebbero essere presenti prima di leggere il modulo come nel linguaggio di programmazione C, dove avevamo i file .h (header).

Questa è una struttura buona e ben collaudata, e sono sicuro che gli esperti che hanno creato lo standard ES6 lo avessero in mente.

Questo è ciò che abilita Webpack o altri pacchetti di pacchetti per ottimizzare il pacchetto in alcuni casi speciali e ridurre alcune dipendenze dal pacchetto che non sono necessarie. Ma nei casi in cui abbiamo dipendenze perfette questo non accadrà mai.

Ci vorrà un po ‘di tempo prima che il supporto nativo di import/export venga pubblicato e la parola chiave require non vada da nessuna parte per un lungo periodo.

Cosa è require ?

Questo è il modo node.js per caricare i moduli. ( https://github.com/nodejs/node )

Il nodo utilizza metodi a livello di sistema per leggere i file. Fondamentalmente ti basti su questo quando usi require . require terminerà in alcune chiamate di sistema come uv_fs_open (dipende dal sistema finale, Linux, Mac, Windows) per caricare il file / modulo JavaScript.

Per verificare che ciò sia vero, prova ad utilizzare Babel.js e vedrai che la parola chiave di import verrà convertita in require .

inserisci la descrizione dell'immagine qui

L’uso dei moduli ES6 può essere utile per il “tree shaking”; Ad esempio, abilitando Webpack 2, Rollup (o altri bundler) per identificare i percorsi di codice che non vengono utilizzati / importati e che quindi non si trasformano nel pacchetto risultante. Questo può ridurre significativamente la dimensione del file eliminando il codice che non ti servirà mai, ma con CommonJS è in bundle di default perché Webpack e altri non hanno modo di sapere se è necessario.

Questo viene fatto usando l’analisi statica del percorso del codice.

Ad esempio, utilizzando:

 import { somePart } 'of/a/package'; 

… dà al bundler un suggerimento sul fatto che package.anotherPart non è richiesto (se non è importato, non può essere usato – giusto?), quindi non si preoccuperà di raggrupparlo.

Per abilitare questo per Webpack 2, è necessario assicurarsi che il proprio transpiler non stia sputando i moduli CommonJS. Se stai utilizzando il plug-in es2015 con babel, puoi disabilitarlo nel tuo .babelrc modo:

 { "presets": [ ["es2015", { modules: false }], ] } 

Rollup e altri potrebbero funzionare in modo diverso: guarda i documenti se sei interessato.

Quando si tratta di caricamento asincrono o forse lazy, import () è molto più potente. Vedi quando richiediamo il componente in modo asincrono, quindi lo importiamo solo in modo asincrono come nella variabile const .

 const module = await import('./module.js'); 

O se vuoi usare require() allora,

 const converter = require('./converter'); 

La cosa è import() è in realtà asincrona in natura. Come menzionato da neehar venugopal in ReactConf, puoi usarlo per caricare dynamicmente i componenti.

Inoltre è molto meglio quando si tratta di routing. Questa è l’unica cosa speciale che rende il log di rete scaricare la parte necessaria quando l’utente si connette a un sito Web specifico al suo componente specifico. per esempio. pagina di accesso prima che la dashboard non scarica tutti i componenti della dashboard. Perché è necessario ciò che è corrente, cioè il componente di accesso, che verrà scaricato solo.

NOTA : se si sta sviluppando un progetto node.js, è necessario utilizzare rigorosamente require() poiché il nodo genererà un errore di eccezione come invalid token 'import' se si utilizzerà l’ import . Quindi il nodo non supporta le istruzioni di importazione

Vedi questo per più spazio dove usare le importazioni asincrone – https://www.youtube.com/watch?v=bb6RCrDaxhw

Io personalmente uso l’importazione perché, possiamo importare i metodi richiesti, i membri utilizzando l’importazione.

 import {foo, bar} from "dep"; 

FileName: dep.js

 export foo function(){}; export const bar = 22 

Il merito va a Paul Shan. Maggiori informazioni