javascript - systemjs.config.js angular 5
¿Cuál es la necesidad de SystemJS en Angular2? (1)
Soy un principiante completo en Angular y Angular2. Estoy confundido acerca de cómo se estructura el flujo de trabajo. He estado mirando el proyecto de muestra que está presente en el sitio de Angular2.
Corríjame si me equivoco, pero lo que sé hasta ahora es que todo el mecanografiado se transpila en javascript por el compilador de mecanografía. Entonces el javascript compilado es en realidad lo que se ejecuta en el navegador.
Ahora si estoy importando los archivos javascript en mecanografiado usando declaraciones de importación ES6 como las siguientes:
import { NgModule } from ''@angular/core'';
¿Por qué nuevamente necesito usar SystemJS para cargarlos?
map: {
// our app is within the app folder
app: ''app'',
// angular bundles
''@angular/core'': ''npm:@angular/core/bundles/core.umd.js'',
Quiero decir, ¿no es eso contraproducente? Mirando el javascript transpilado de los archivos ts, muestra que todas las declaraciones de importación se convierten en declaraciones require (). Primero, cómo funciona require () en un archivo ES5 js, y segundo, si ese es el caso, qué está haciendo SystemJS.
Esto realmente me confunde. Cualquier ayuda será apreciada.
Cuando
tsc
compila el mecanografiado en JavaScript, terminas con un montón de archivos js en tu sistema local.
De alguna manera necesitan ser cargados en un navegador.
Dado que los navegadores aún no admiten la carga del módulo ES6 nativo, tiene dos opciones: ponerlos todos en su archivo
index.html
en el orden correcto de dependencias, o puede usar un cargador para hacerlo todo por usted.
Usted especifica la raíz para todos los módulos, y luego ese cargador carga y ejecuta todos los archivos en el orden correcto de las dependencias.
Hay muchos cargadores: requirejs, webpack, systemjs y otros.
En su caso particular es systemjs.
Mirando el javascript transpilado de los archivos ts, muestra que todas las declaraciones de importación se convierten en declaraciones require ().
Sí, esta es una forma para que
SystemJs
cargue paquetes.
Utiliza
require()
y
exports
sintaxis porque esa es la sintaxis de
CommonJS
para cargar paquetes y usted especificó este tipo en su
tsconfig.json
:
{
"compilerOptions": {
"target": "es5",
"module": "commonjs",
Si pusiera el
module:''es6''
, vería que en sus archivos javascript compilados se conservan las declaraciones de importación y exportación.
Sin embargo, como se mencionó anteriormente, aún no puede usar esta sintaxis ya que los navegadores no la admiten de forma nativa.
Si pusiera el
module:''amd''
, vería una sintaxis diferente que usa
define()
.
Supongo que se prefiere el cargador systemjs en el tutorial de inicio
angular2
, ya que en realidad puede cargar todos los tipos de módulos compatibles con
tsc
.
Sin embargo, si desea cargar módulos como módulos
es6
, debe colocar el
module: ''system''
en su
tsconfig.json
.
Es un sistema de módulos diseñado para cumplir con el estándar de
es6 modules
y se utiliza hasta que haya un soporte completo de
es6 modules
en los navegadores.
Cómo funciona la configuración
En su
index.html
agrega el siguiente script:
<script>
System.import(''app'').catch(function (err) {
console.error(err);
});
</script>
que se ejecuta cuando se carga
index.html
.
El método de
import(''app'')
le
systemjs
a
systemjs
que cargue el módulo de
app
que está asignado a la carpeta de la
app
en la estructura de directorios de su proyecto según lo especificado por la configuración en
systemjs.config.js
:
map: {
// our app is within the app folder
app: ''app'',
SystemJs busca el archivo
main.js
en esa carpeta.
Cuando se encuentra
app/main.js
y se carga en un navegador, dentro de su código se encuentra la llamada de
require
:
var app_module_1 = require(''./app.module'');
y systemjs luego obtiene el archivo
app.module.js
del sistema local.
Este a su vez tiene sus propias dependencias, como:
var core_1 = require(''@angular/core'');
Y el ciclo se repite: cargar, buscar dependencias, cargarlas y ejecutarlas.
Y esta es la forma en que el
systemjs
resuelve, carga y ejecuta todas las dependencias en un navegador.
Por qué se requieren las asignaciones a las bibliotecas core @angular
En el archivo
systemjs.config.ts
hay una asignación a los módulos centrales
@angular
:
map: {
...
// angular bundles
''@angular/core'': ''npm:@angular/core/bundles/core.umd.js'',
''@angular/common'': ''npm:@angular/common/bundles/common.umd.js'',
Lo primero que hay que entender aquí es que estos son
mapeos
, no dependencias.
Significa que si ninguno de sus archivos importa
@angular/core
, no se cargará en un navegador.
Sin embargo, puede ver que este módulo en particular se importa dentro de
app/app.module.ts
:
import { NgModule } from ''@angular/core'';
Ahora, por qué las asignaciones están ahí.
Suponga que
systemjs
cargó su
app/app.module.js
en el navegador.
Analiza su contenido y encuentra lo siguiente:
var core_1 = require(''@angular/core'');
Ahora
systemjs
entiende que necesita resolver y cargar
@angular/core
.
Primero pasa por el proceso de verificación de
mappings
, como se especifica en los documentos:
La opción de mapa es similar a las rutas, pero actúa muy temprano en el proceso de normalización. Le permite asignar un alias de módulo a una ubicación o paquete.
Lo llamaría una resolución de un módulo con nombre.
Entonces, encuentra la asignación y sustituye
@angular/core
con
node_modules/@angular/core
y aquí es donde se colocan los archivos reales.
Creo que
systemjs
intenta imitar el enfoque utilizado en
node.js
donde puede especificar un módulo sin identificadores de ruta relativos
[''/'', ''../'', or ''./'']
, simplemente como esto
require(''bar.js'')
y
node.js
:
entonces Node.js comienza en el directorio principal del módulo actual y agrega / node_modules e intenta cargar el módulo desde esa ubicación.
Si lo desea, puede evitar el uso de asignaciones con nombre e importar utilizando una ruta relativa como esta:
import {NgModule} from ''../node_modules/@angular/core'';
Sin embargo, esto debe hacerse en todas las referencias a
@angular.core
en el proyecto y en los archivos lib, incluido
@angular
, que no es una buena solución para decir lo menos.