navigationend - Cómo Angular construye y corre
router events subscribe angular 4 (4)
¿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
-
Cuando
AppComponent
con la claseAppComponent
(en main.ts), Angular busca un<app-root>
enindex.html
, lo encuentra, crea una instancia de AppComponent y lo muestra dentro de la etiqueta<app-root>
. -
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?
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.
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.
(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 sumain.js
que llama al métodobootstrap
. 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.
¿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.