javascript - systemjs.config.js angular 5

¿Cuál es la necesidad de SystemJS en Angular2?

Question

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.

Answer 1

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.