La différence entre le Système.import() et d'importation()?

Dans webpack 1 docs de l'état que dans webpack 2 utilisera System.import() dynamique exiger:

Heureusement, il existe une API JavaScript “loader” de la spécification à l'
écrites pour gérer la dynamique de cas d'utilisation: System.load (ou
System.import). Cette API sera le natif équivalent à la ci-dessus
require variations.

Et pendant ce temps, tout autour du web, a été exemples de l'utilisation de ce System.import().

Avant de relâcher webpack 2, les auteurs décident de changer de System.import() à import():

ajouter import() que le Code de Fractionnement de construire. Il doit être utilisé au lieu de
System.import lorsque cela est possible. System.import sera obsolète dans
webpack de version 2 (supprimé dans webpack 3) comme c'est le comportement est incorrect
selon la spécification.

Ce import() est basé sur tc39/proposition-dynamique-import cahier des charges, et vous pouvez en lire plus pourquoi ils ont fait ce changement ici.

Quelqu'un peut m'expliquer la différence entre System.import() et import()?

Malgré un nom différent, l'utilisation semble le même:

import(modulePath)
  .then(module => module.default())
  .catch(/* ... */);

System.import(modulePath)
  .then(module => module.default())
  .catch(/* ... */);

Mais dans weback 2 doc est: "System.import() comportement est incorrect, selon la spécification" - de sorte qu'il suggère qu'il ya de différence entre System.import() et import().

  • Si je lis les liens que vous avez fournis à droite, une différence très importante est que import() est conscient du script ou d'un module qui l'invoque, tandis que System.import() ne l'est pas. Si je suis en droit, cela signifie que import('../foo'), c'est à dire la résolution relative à l'actuelle module, est possible. Et puis je me suis peut être mal trompe, corrigez-moi.
  • Il ressemble à la différence provient de cette github question
InformationsquelleAutor Everettss | 2017-02-12
  1. 4

    La partie importante de votre première citation est

    spécification écrite

    Quand Webpack 1 mis en œuvre System.import, la spécification est encore en évolution. Si fait, il l'est toujours. Webpack 1 mis en œuvre System.import parce que ce qui a été jeté autour comme le potentiel de l'API à l'époque.

    Webpack 2 met en œuvre import() parce que c'est une nouvelle proposition de normaliser une approche syntaxique plutôt de la bibliothèque de l'.

    • Ce n'est pas d'expliquer quelle est la différence pratique entre les deux, le cas échéant.
    InformationsquelleAutor loganfsmyth
  2. 2

    Voici ce que vous cherchez: tc39 Proposition pour l'Importation

    Une fonction réelle

    Projets de Chargeur d'idées de collecte ont, à diverses reprises eu des fonctions réelles (et pas seulement de la fonction-comme des formes syntaxiques) du Système nommé.import() ou d'un Système.loader.import() ou similaire, qui accomplissent le même cas d'utilisation.

    Le plus gros problème ici, comme indiqué précédemment par le spec éditeurs, est de savoir comment interpréter le spécificateur argument de ces fonctions. Depuis ce sont juste des fonctions, qui sont les mêmes dans l'ensemble du Royaume et ne pas varier d'un script ou d'un module, la fonction doit interpréter son argument le même quel que soit l'endroit où il est appelé. (À moins que quelque chose de vraiment bizarre comme pile d'inspection est mis en œuvre.) Si cela heurte à des problèmes similaires, comme le document de base de l'URL problème pour le importModule fonction ci-dessus, où relative module de spécificateurs de devenir un bug de la ferme et de l'incompatibilité de tout à proximité des déclarations d'importation.

    InformationsquelleAutor Michael Ryan Soileau