Question L'utilisation de Node.js nécessite l'importation / exportation ES6


Dans un projet sur lequel je collabore, nous avons deux choix sur le système de module que nous pouvons utiliser:

  1. Importer des modules en utilisant requireet exportant en utilisant module.exports et exports.foo.
  2. Importation de modules à l'aide de ES6 importet exporter en utilisant ES6 export

Y a-t-il des avantages de performance à utiliser l'un par rapport à l'autre? Y a-t-il autre chose que nous devrions savoir si nous devions utiliser des modules ES6 plutôt que des nœuds?


565
2017-07-11 07:19


origine


Réponses:


Y a-t-il des avantages de performance à utiliser l'un par rapport à l'autre?

Gardez à l'esprit qu'il n'y a pas encore de moteur JavaScript qui supporte nativement les modules ES6. Vous avez dit vous-même que vous utilisez Babel. Babel convertit import et export déclaration à CommonJS (require/module.exports) par défaut de toute façon. Donc même si vous utilisez la syntaxe du module ES6, vous utiliserez CommonJS sous le capot si vous exécutez le code dans Node.

Il existe une différence technique entre les modules CommonJS et ES6, par ex. CommonJS vous permet de charger des modules dynamiquement. ES6 ne le permet pas, mais il y a une API en développement pour ça.

Puisque les modules ES6 font partie de la norme, je les utiliserais.


482
2017-07-12 12:38



Il y a plusieurs utilisations / capacités que vous pourriez vouloir considérer:

Exiger:

  • Vous pouvez avoir un chargement dynamique où le nom du module chargé n'est pas prédéfini / statique ou lorsque vous chargez un module sous condition uniquement si c'est "vraiment nécessaire" (en fonction de certains flux de code).
  • Le chargement est synchrone. Cela signifie que si vous avez plusieurs requires, ils sont chargé et traité un par un.

ES6 Importations:

  • Vous pouvez utiliser les importations nommées pour charger de manière sélective uniquement les pièces dont vous avez besoin. Qui peut économiser de la mémoire.
  • L'importation peut être asynchrone (et dans ES6 Module Loader actuel, il est en fait) et peut effectuer un peu mieux.

En outre, le système de module Require n'est pas basé sur la norme. Il est hautement improbable qu'il devienne standard maintenant que les modules ES6 existent. À l'avenir, il y aura un support natif pour les modules ES6 dans diverses implémentations, ce qui sera avantageux en termes de performances.


101
2017-07-11 08:49



Les principaux avantages sont syntaxiques:

  • Plus de syntaxe déclarative / compacte
  • Les modules ES6 rendront l'UMD (Universal Module Definition) obsolète - supprime essentiellement le schisme entre CommonJS et AMD (serveur vs navigateur).

Il est peu probable que vous voyiez des avantages en termes de performances avec les modules ES6. Vous aurez toujours besoin d'une bibliothèque supplémentaire pour regrouper les modules, même s'il y a un support complet pour les fonctionnalités ES6 dans le navigateur.


32
2017-07-11 08:15



Y a-t-il des avantages de performance à utiliser l'un par rapport à l'autre?

La réponse actuelle est non, car aucun des moteurs de navigateur actuels implémente import/export de la norme ES6.

Quelques tableaux de comparaison http://kangax.github.io/compat-table/es6/ Ne tenez pas compte de cela, alors quand vous voyez presque tous les verts pour Chrome, faites attention. import mot-clé de ES6 n'a pas été pris en compte.

En d'autres termes, les moteurs de navigateur actuels, y compris V8, ne peuvent pas importer nouveau fichier JavaScript du fichier JavaScript principal via n'importe quelle directive JavaScript.

(Nous pouvons être encore juste quelques insectes loin ou des années à venir jusqu'à ce que V8 implémente cela selon la spécification ES6. )

Ce document est ce dont nous avons besoin, et cela document est ce que nous devons obéir.

Et la norme ES6 a déclaré que les dépendances du module devraient être là avant que nous lisions le module comme dans le langage de programmation C, où nous avions (en-têtes) .h des dossiers.

C'est une bonne structure bien testée, et je suis sûr que les experts qui ont créé la norme ES6 l'ont bien compris.

C'est ce qui permet à Webpack ou à d'autres bundlers de paquets d'optimiser le bundle dans certains spécial cas, et de réduire certaines dépendances de l'ensemble qui ne sont pas nécessaires. Mais dans les cas où nous avons des dépendances parfaites, cela n'arrivera jamais.

Il faudra un certain temps jusqu'à import/export le support natif devient opérationnel, et le require mot-clé ne va pas n'importe où pendant une longue période.

Quel est require?

C'est node.js façon de charger les modules. ( https://github.com/nodejs/node )

Node utilise des méthodes au niveau du système pour lire les fichiers. Vous comptez essentiellement sur cela lorsque vous utilisez require. require se terminera par un appel système comme uv_fs_open (dépend du système final, Linux, Mac, Windows) pour charger le fichier / module JavaScript.

Pour vérifier que cela est vrai, essayez d'utiliser Babel.js, et vous verrez que le import mot-clé sera converti en require.

enter image description here


24
2017-11-05 15:48



L'utilisation de modules ES6 peut être utile pour «l'agitation des arbres»; c'est-à-dire en activant Webpack 2, Rollup (ou d'autres bundlers) pour identifier les chemins de code qui ne sont pas utilisés / importés, et par conséquent ne le font pas dans l'ensemble résultant. Cela peut réduire considérablement la taille de son fichier en éliminant le code dont vous n'avez jamais besoin, mais CommonJS est fourni par défaut car Webpack et al n'ont aucun moyen de savoir si c'est nécessaire.

Ceci est fait en utilisant l'analyse statique du chemin du code.

Par exemple, en utilisant:

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

... donne au bundler un indice package.anotherPart n'est pas nécessaire (s'il n'est pas importé, il ne peut pas être utilisé, n'est-ce pas?), il ne sera donc pas dérangé.

Pour activer ceci pour Webpack 2, vous devez vous assurer que votre transpilateur ne crache pas les modules CommonJS. Si vous utilisez le es2015 plug-in avec babel, vous pouvez le désactiver dans votre .babelrc ainsi:

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

Rollup et d'autres peuvent travailler différemment - voir les documents si vous êtes intéressé.


17
2017-10-27 15:45



Quand il s'agit de chargement asynchrone ou paresseux, alors import () est beaucoup plus puissant. Voir quand nous avons besoin d'un composant de manière asynchrone, alors seulement nous l'importons de manière asynchrone comme dans const variable.

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

Ou si vous voulez utiliser require() puis,

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

Chose est import() est en réalité async dans la nature. Comme mentionné par neehar venugopal dans ReactConf, vous pouvez l'utiliser pour charger dynamiquement des composants.

Aussi, c'est beaucoup mieux quand il s'agit de routage. C'est la chose spéciale qui fait que le journal de réseau télécharge la partie nécessaire quand l'utilisateur se connecte au site Web spécifique à son composant spécifique. par exemple. La page de connexion avant le tableau de bord ne télécharge pas tous les composants du tableau de bord. Parce que ce qui est nécessaire actuellement, c'est-à-dire le composant de connexion, qui sera seulement téléchargé.

REMARQUE  - Si vous développez un projet node.js, vous devez utiliser strictement require() comme noeud va lancer une erreur d'exception en tant que invalid token 'import' si vous utiliserez import . Le noeud ne prend donc pas en charge les instructions d'importation

Voir ceci pour plus d'autorisation où utiliser les importations asynchrones - https://www.youtube.com/watch?v=bb6RCrDaxhw


4
2017-11-28 02:37



J'utilise personnellement l'import car, nous pouvons importer les méthodes requises, membres en utilisant l'import.

import {foo, bar} from "dep";

Nom de fichier: dep.js

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

Le crédit va à Paul Shan. Plus d'informations.


3
2017-11-22 07:04