javascript - w3org - www w3 org tr html52

¿Diferencia entre System.import() y import()?

Question

En webpack 1 docs es una declaración de que en webpack 2 usará System.import() para dinámica requiere:

Afortunadamente, hay una especificación de "cargador" de la API de JavaScript que se escribe para manejar el caso de uso dinámico: System.load (o System.import ). Esta API será el equivalente nativo a las variaciones anteriores require .

Y durante ese tiempo, en toda la web hubo examples del uso de este System.import() .

Antes de lanzar el paquete web 2 , los autores deciden cambiar System.import() para import() :

agregue import() como construcción de división de código. Se debe utilizar en lugar de System.import cuando sea posible. System.import quedará obsoleto en la versión webpack 2 (eliminada en webpack 3) ya que su comportamiento es incorrecto de acuerdo con la especificación .

Este import() se basa en la tc39/proposal-dynamic-import , y puede leer más por qué hicieron este cambio here .

¿Alguien puede explicar la diferencia entre System.import() y import() ?

A pesar del nombre diferente, el uso se ve igual:

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

Pero en weback 2, el documento es: "El comportamiento de System.import() es incorrecto según la especificación", por lo que sugiere que hay una diferencia entre System.import() e import() .

Answer 1

La parte importante de tu primera cita es

especificación siendo escrita

Cuando Webpack 1 implementó System.import , la especificación seguía evolucionando. Si es un hecho todavía lo es. Webpack 1 implementó System.import porque eso era lo que se estaba lanzando como la API potencial en ese momento.

Webpack 2 implementa import() porque es una nueva propuesta para estandarizar un enfoque sintáctico en lugar de uno basado en bibliotecas.

Answer 2

Esto es lo que está buscando: tc39 Propuesta de importación

Una función real

Los borradores de la colección de ideas de Loader han tenido en varias ocasiones funciones reales (no solo formas sintácticas similares a funciones) llamadas System.import () o System.loader.import () o similares, que cumplen los mismos casos de uso.

El mayor problema aquí, como se señaló anteriormente por los editores de las especificaciones, es cómo interpretar el argumento del especificador para estas funciones. Dado que estas son solo funciones, que son las mismas en todo el Reino y no varían según el script o el módulo, la función debe interpretar su argumento de la misma manera sin importar desde dónde se llame. (A menos que se implemente algo realmente extraño, como la inspección de la pila). Por lo tanto, es probable que esto ocurra en problemas similares como el problema de la URL de base de documentos para la función importModule anterior, donde los especificadores de módulos relativos se convierten en una granja de errores y no coinciden con las declaraciones de importación cercanas.