web-dev-qa-db-ja.com

System.import（）とimport（）の違いは？

webpack 1 docs is statement では、webpack 2ではSystem.import()を使用して動的に要求します：

幸いなことに、動的なユースケースを処理するために記述されているJavaScript API「ローダー」仕様があります。_System.load_（または_System.import_ ）。このAPIは、上記のrequireバリエーションにネイティブに相当します。

そしてその間、Web全体で 例 このSystem.import()を使用していました。

webpack 2をリリースする前に 、著者はSystem.import()をimport()に変更することにしました：

import()をコード分割構成として追加します。可能であれば、_System.import_の代わりに使用する必要があります。 _System.import_は、webpack 2リリースでは非推奨になります（webpack 3では削除されます）。仕様に従って動作が正しくないためです。

このimport()は tc39/proposal-dynamic-import 仕様に基づいており、この変更を行った理由をさらに読むことができます here 。

誰かがSystem.import()とimport()？の違いを説明できますか？

名前は異なりますが、使用方法は同じです。

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

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

しかし、weback 2のドキュメントでは、「System.import()の動作は仕様に従って正しくありません」-したがって、System.import()とimport()に違いがあることを示唆しています。

javascriptimportwebpackecmascript-6webpack-2
17
Everettss

最初の引用の重要な部分は

書かれている仕様

Webpack 1が_System.import_を実装したとき、仕様はまだ進化していました。実際、それはまだです。 Webpack 1が_System.import_を実装したのは、それが当時の潜在的なAPIとして投げ捨てられていたからです。

Webpack 2はimport()を実装します。これは、ライブラリベースのアプローチではなく構文アプローチを標準化するための新しい提案であるためです。

4
loganfsmyth

探しているものは次のとおりです。 tc39 Import for Proposal

実際の機能

Loaderアイデアコレクションの下書きには、System.import（）またはSystem.loader.import（）などの名前の実際の関数（関数のような構文形式だけでなく）がさまざまな時点であり、同じユースケースを実現します。

ここでの最大の問題は、仕様の編集者が以前に指摘したように、これらの関数への指定子引数の解釈方法です。これらは単なる関数であり、レルム全体で同じであり、スクリプトまたはモジュールごとに変化しないため、関数は、どこから呼び出されても同じように引数を解釈する必要があります。 （スタック検査のような本当に奇妙なものが実装されていない限り）。これにより、上記のimportModule関数のドキュメントベースURLの問題と同様の問題が発生します。

2
Michael Ryan Soileau