navigationend - Cómo Angular construye y corre

router events subscribe angular 4

Question

¿Solo quieres aprender cómo Angular construye y corre detrás de escena?

A continuación se muestra lo que entendí hasta ahora. Quiero saber si me perdí algo.

Cómo se construye Angular

Después de codificar nuestras aplicaciones angulares usando TypeScript , usamos el comando Angular CLI para construir la aplicación.

ng build comando ng build compila la aplicación en un directorio de salida y los artefactos de compilación se almacenarán en el directorio dist/ .

Proceso interno

1. Angular CLI ejecuta Webpack para compilar y agrupar todo el código JavaScript y CSS .

2. A su vez, Webpack llama a los cargadores TypeScript que .ts todos los archivos .ts del proyecto angular y luego los transpira a JavaScript es decir, a un archivo .js , que los navegadores pueden entender.

This publicación dice que Angular tiene dos compiladores:

• Ver compilador

• Compilador del módulo

Preguntas sobre compilaciones

¿Cuál es la secuencia de llamar al proceso de construcción?

CLI angular Primero llama al compilador incorporado angular escrito en Typecript => luego llama al Transpiler Filescript => luego llama al paquete web para agruparlo y almacenarlo en el directorio dist/ .

Cómo funciona Angular

Cuando se completa la compilación, todos los componentes, servicios, módulos, etc. de nuestra aplicación se trasladan a archivos Javascript .js que se utilizan para ejecutar la aplicación angular en el navegador.

Declaraciones en documentos angulares

1. Cuando AppComponent con la clase AppComponent (en main.ts), Angular busca un <app-root> en index.html , lo encuentra, crea una instancia de AppComponent y lo muestra dentro de la etiqueta <app-root> .

2. Angular crea, actualiza y destruye componentes a medida que el usuario se mueve a través de la aplicación.

Preguntas sobre carreras

Aunque main.ts se usa en la Declaración anterior para explicar el proceso de arranque, ¿la aplicación angular no se arranca o comienza a usar archivos Javascript .js ?

¿No se hacen todas las declaraciones anteriores en tiempo de ejecución usando archivos Javascript .js ?

¿Alguien sabe cómo todas las partes encajan en profundidad?

Answer 1

Entonces, si el proceso de arranque ocurre con el archivo Javascript, ¿por qué Angular Docs usa el archivo Type.ts main.ts para explicar el proceso de arranque?

Esto es parte de la versión .js transformada de main.ts emitida por ng build que aún no está uglified y minified. ¿Cómo espera que un principiante comprenda este código? ¿No se ve muy complicado?

Object(__WEBPACK_IMPORTED_MODULE_1__angular_platform_browser_dynamic__["a" /* platformBrowserDynamic */])().bootstrapModule(__WEBPACK_IMPORTED_MODULE_2__app_app_module__["a" /* AppModule */])
.catch(function (err) { return console.log(err); });

y con ng build --prod --build-optimizer que uglifica y minimiza su código para optimizarlo, los paquetes generados son compactos y están en formato bit-ilegible.

webpackJsonp([1],{0:function(t,e,n){t.exports=n("cDNt")},"1j/l":function(t,e,n){"use strict";nd(e,"a",function(){return r});var r=Array.isArray||function(t){return t&&"number"==typeof t.length}},"2kLc

Mientras que el archivo main.ts es legible y lúcido, es por eso que angular.io usa main.ts para explicar el proceso de arranque de la aplicación angular. Angular: ¿Por qué TypeScript? aparte de esto, si hubiera sido autor de un marco tan excelente, ¿qué enfoque habría utilizado para que su marco fuera popular y fácil de usar? ¿no irías por una explicación clara y concisa en lugar de una complicada? Estoy de acuerdo en que la documentación de angular.io carece de una explicación en profundidad y no es muy buena, pero hasta ahora he visto que se esfuerzan por mejorarla.

Answer 2

Dejame empezar por el principio.

En mi aplicación, ejecuto directamente la aplicación desde Webpack .

Para compilar y ejecutar la aplicación, usamos el comando webpack --progress y webpack-dev-server --inline que se ha escrito en package.json como se muestra a continuación

"scripts": {
"serve": "webpack-dev-server --inline ",
"build": "webpack --progress"
}

Cuando webpack --progress comando webpack --progress , comienza a leer el archivo webpack.config.js donde encuentra el punto de entrada como se muestra a continuación.

module.exports = {
devtool: ''source-map'',
entry: ''./src/main.ts'',
output: {
path: path.resolve(__dirname, ''dist''),
filename: ''bundle.js''
},
module: {
loaders: [
{
test: //.ts$/,
loaders: [''awesome-typescript-loader'', ''angular2-template-loader''],
exclude: [//.(spec|e2e)/.ts$/]
},
/* Embed files. */
{
test: //.(html|css)$/,
loader: ''raw-loader'',
exclude: //.async/.(html|css)$/
},
/* Async loading. */
{
test: //.async/.(html|css)$/,
loaders: [''file?name=[name].[hash].[ext]'', ''extract'']
},
]
},
resolve: {
extensions: [''.ts'', ''.js'']
},
plugins: [
new HtmlWebpackPlugin({
template: ''./src/index.html''
})
]
} 

y luego lee todos los archivos y compilaciones tsconfig.json basados ​​en las reglas declaradas en el archivo tsconfig.json y luego lo convierte en archivos .js respectivos y es un archivo de mapa.

Si se ejecuta sin ningún error de compilación, creará el archivo bundle.js con los nombres que Webpack en la sección de salida de Webpack .

Ahora déjame explicarte por qué usamos cargadores.

awesome-typescript-loader, angular2-template-loader Usamos estos cargadores para compilar el archivo Typescript en la base declarada en el archivo tsconfig.json y las búsquedas de angular2-template-loader para la declaración templateUrl y styleUrls dentro de los metadatos del componente Angular 2 y reemplaza las rutas con la correspondiente declaración require.

resolve: {
extensions: [''.ts'', ''.js'']
}

Usamos la sección de resolución anterior para indicarle a Webpack que convierta el Webpack a un archivo JavaScript

plugins: [
new HtmlWebpackPlugin({
template: ''./src/index.html''
})
]

La sección de complementos se utiliza para inyectar un marco o archivo de terceros. En mi código, estoy usando esto para inyectar index.html de la carpeta de destino.

 devtool: ''source-map'',

La línea anterior se usa para ver el archivo de Typescript en el navegador y depurarlo principalmente para el código de desarrollador.

 loader: ''raw-loader''

El raw-loader anterior se usa para cargar el archivo .html y .css y agruparlos junto con los archivos de Typescript .

Al final, cuando ejecutamos webpack-dev-server, en línea , creará su propio servidor y arrancará la aplicación como la ruta mencionada en web-pack.config.js archivo web-pack.config.js donde mencionamos la carpeta de destino y el punto de entrada.

En Angular 2, el punto de entrada de la mayoría de las aplicaciones es main.ts donde mencionamos el módulo de arranque inicial, por ejemplo (app.module), este módulo contiene información completa de la aplicación, como todas las directivas, servicios, módulos, componentes e implementación de enrutamiento de toda la aplicación.

Nota: Muchas personas tienen dudas de por qué index.html solo inicia la aplicación, a pesar de que no han mencionado ningún lugar. La respuesta es que cuando el comando Webpack serve se ejecuta crea su propio servicio y, de forma predeterminada, carga index.html si no ha mencionado ninguna página predeterminada.

Espero que la información dada ayude a algunas personas.

Answer 3

(Cuando digo Angular me refiero a Angular 2+ y explícitamente diré angular-js si estoy mencionando angular 1).

Preludio: es confuso

Angular, y probablemente con mayor precisión angular-cli han fusionado varias herramientas de tendencias en Javascript que están involucradas en el proceso de construcción. Sí conduce a un poco de confusión.

Para aumentar la confusión, el término compile menudo se usaba en angular-js para referirse al proceso de tomar el pseudo-html de la plantilla y convertirlo en elementos DOM. Eso es parte de lo que hace el compilador, pero una de las partes más pequeñas.

En primer lugar, no es necesario usar TypeScript, angular-cli o Webpack para ejecutar Angular. Para responder tu pregunta. Deberíamos mirar una pregunta simple: "¿Qué es angular?"

Angular: ¿Qué hace?

Esta sección puede ser controvertida, ya veremos. En esencia, el servicio que proporciona Angular es un mecanismo de inyección de dependencia que funciona en Javascript, HTML y CSS. Escribe todos los pequeños trozos y piezas individualmente y en cada pequeño pedazo sigue las reglas de Angular para hacer referencia a las otras piezas. Angular luego teje todo de alguna manera.

Para ser (ligeramente) más específico:

• Las plantillas permiten que el HTML se conecte al componente Javascript. Esto permite la entrada del usuario en el DOM (por ejemplo, hacer clic en un botón) para alimentar el componente Javascript y también permite que las variables en el componente Javascript controlen la estructura y los valores en el DOM.
• Las clases de Javascript (incluidos los componentes de Javascript) deben poder acceder a las instancias de otras clases de Javascript de las que dependen (por ejemplo, la inyección de dependencia clásica). Un BookListComponent necesita una instancia de un BookListService que podría necesitar una instancia de un BookListPolicy o algo así. Cada una de estas clases tiene vidas diferentes (p. Ej., Los servicios suelen ser singletons, los componentes generalmente no son singletons) y Angular debe gestionar todas esas vidas, la creación de los componentes y el cableado de las dependencias.
• Las reglas CSS debían cargarse de tal manera que solo se aplicaran a un subconjunto del DOM (el estilo de un componente es local para ese componente).

Una cosa posiblemente importante a tener en cuenta es que Angular no es responsable de cómo los archivos Javascript hacen referencia a otros archivos Javascript (por ejemplo, la palabra clave de import ). De eso se encarga Webpack.

¿Qué hace el compilador?

Ahora que sabes lo que hace Angular, podemos hablar sobre lo que hace el compilador. Evitaré ser demasiado técnico principalmente porque soy ignorante. Sin embargo, en un sistema de inyección de dependencias, generalmente tiene que expresar sus dependencias con algún tipo de metadatos (por ejemplo, ¿cómo dice una clase I can be injected My lifetime is blah o You can think of me as a Component type of instance ). En Java, Spring originalmente hizo esto con archivos XML. Posteriormente, Java adoptó anotaciones y se han convertido en la forma preferida de expresar metadatos. C # usa atributos para expresar metadatos.

Javascript no tiene un gran mecanismo para exponer esta metadata incorporada. angular-js hizo un intento y no estuvo mal, pero había muchas reglas que no podían verificarse fácilmente y eran un poco confusas. Con Angular hay dos formas compatibles de especificar los metadatos. Puede escribir Javascript puro y especificar los metadatos manualmente, algo similar a angular-js y simplemente seguir las reglas y escribir código extraplano. Alternativamente, puede cambiar a TypeScript que, como sucede, tiene decoradores (esos símbolos @ ) que se utilizan para expresar metadatos.

Así que aquí es donde finalmente podemos llegar al compilador. El trabajo del compilador es tomar esos metadatos y crear el sistema de piezas de trabajo que es su aplicación. Te enfocas en todas las piezas y todos los metadatos y el compilador construye una gran aplicación interconectada.

¿Cómo lo hace el compilador?

Hay dos formas en que el compilador puede funcionar, tiempo de ejecución y anticipado. De aquí en adelante, supondré que está utilizando TypeScript:

• Tiempo de ejecución: cuando se ejecuta el compilador de mecanografía, toma toda la información del decorador y la inserta en el código Javascript adjunto a las clases, métodos y campos decorados. En su index.html , hace referencia a su main.js que llama al método bootstrap . Ese método pasa su módulo de nivel superior.

El método bootstrap activa el compilador de tiempo de ejecución y le da una referencia a ese módulo de nivel superior. Luego, el compilador de tiempo de ejecución comienza a rastrear ese módulo, todos los servicios, componentes, etc. a los que hace referencia ese módulo y todos los metadatos asociados, y desarrolla su aplicación.

• AOT: en lugar de hacer todo el trabajo en tiempo de ejecución, Angular ha proporcionado un mecanismo para hacer la mayoría del trabajo en tiempo de compilación. Esto casi siempre se realiza utilizando un complemento de paquete web (este debe ser uno de los paquetes npm más populares pero menos conocidos). Se ejecuta después de que la compilación mecanografiada se haya ejecutado, por lo que ve esencialmente la misma entrada que el compilador de tiempo de ejecución. El compilador AOT construye su aplicación al igual que el compilador de tiempo de ejecución, pero luego la vuelve a guardar en Javascript.

La ventaja aquí no es solo que puede ahorrar el tiempo de CPU requerido para la compilación en sí, sino que también le permite reducir el tamaño de su aplicación.

Respuestas especificas

CLI angular Primero llama al compilador integrado angular escrito en Typecript => luego llama al Transcriptor de mecanografiado => luego llama al paquete web para agruparlo y almacenarlo en el directorio dist /.

No. Angular CLI llama a Webpack (el servicio real de Angular CLI es configurar webpack. Cuando ejecuta ng build no es mucho más que un proxy para iniciar Webpack). Webpack primero llama al compilador Typecript, luego al compilador angular (suponiendo AOT), todo mientras agrupa su código al mismo tiempo.

Aunque main.ts se usa en la Declaración anterior para explicar el proceso de arranque, ¿la aplicación angular no se arranca o comienza a usar archivos .js de Javascript?

No estoy completamente seguro de lo que estás preguntando aquí. main.ts se trasladará a Javascript. Ese Javascript contendrá una llamada a bootstrap que es el punto de entrada a Angular. Cuando bootstrap , tendrá su aplicación Angular completa ejecutándose.

Esta publicación dice que Angular tiene dos compiladores:

Ver compilador

Compilador del módulo

Para ser honesto, voy a reclamar ignorancia aquí. Creo que a nuestro nivel podemos pensar en todo como un gran compilador.

¿Alguien sabe cómo todas las partes encajan en profundidad?

Espero que lo anterior haya satisfecho esto.

Don''t @ Me: Angular hace más que la inyección de dependencia

Por supuesto. Realiza enrutamiento, creación de vistas, detección de cambios y todo tipo de otras cosas. El compilador realmente genera Javascript para la creación de vistas y la detección de cambios. Mentí cuando dije que solo era una inyección de dependencia. Sin embargo, la inyección de dependencia está en el núcleo y es suficiente para impulsar el resto de la respuesta.

¿Deberíamos llamarlo un compilador?

Probablemente analiza mucho y lexing, y definitivamente genera mucho código como resultado, por lo que podría llamarlo un compilador.

Por otro lado, en realidad no está traduciendo su código en simplemente una representación diferente. En cambio, está tomando un montón de diferentes piezas de código y entrelazándolas en piezas consumibles de un sistema más grande. El proceso de arranque luego (después de compilar, si es necesario) toma esas piezas y las conecta al núcleo angular.

Answer 4

¿Cómo se construye Angular?

La Angular CLI llama a Webpack , cuando Webpack golpea un archivo .ts lo pasa al compilador TypeScript que tiene un transformador de salida que compila plantillas Angular

Entonces la secuencia de construcción es:

Angular CLI => Webpack => TypeScript Compiler => TypeScript Compiler llama al compilador Angular en tiempo de compilación.

¿Cómo funciona Angular?

Angular y se ejecuta utilizando un archivo Javascript .

En realidad, el proceso de arranque es tiempo de ejecución y ocurre antes de abrir el navegador. Esto nos lleva a nuestra siguiente pregunta.

Entonces, si el proceso de arranque ocurre con el archivo Javascript , ¿por qué Angular Docs usa el archivo main.ts para explicar el proceso de arranque?

Angular documentos Angular solo hablan sobre los archivos .ts , ya que esa es la fuente.

Esta es una breve respuesta. Apreciar si alguien puede responder en profundidad.

Los créditos van a @ Toxicable por responder mis preguntas en el chat.