113 votes

Comment Angular se construit et fonctionne

Vous souhaitez simplement apprendre comment Angular se construit et fonctionne en coulisses ?

Voici ce que j'ai compris jusqu'à présent. Je veux savoir si j'ai manqué quelque chose.

Comment Angular se construit

Après avoir codé nos applications Angular à l'aide de TypeScript, nous utilisons la commande Angular CLI pour construire l'application.

ng build La commande compile l'application dans un répertoire de sortie et les artefacts de construction seront stockés dans le répertoire de sortie. dist/ répertoire.

Processus interne

1. Angular CLI utilise Webpack pour construire et regrouper tout le code JavaScript et CSS.

2. A son tour, Webpack appelle les chargeurs TypeScript qui récupèrent toutes les .ts dans le projet Angular et les transpose ensuite en JavaScript, c'est-à-dire en un fichier .js que les navigateurs peuvent comprendre.

Ce site Le post dit qu'Angular a deux compilateurs :

  • Voir le compilateur

  • Compilateur de modules

Questions sur les constructions

Quelle est la séquence d'appel du processus de construction ?

Angular CLI fait d'abord appel au compilateur intégré d'Angular écrit en TypeScript => puis fait appel au transpilateur TypeScript => puis fait appel à Webpack pour regrouper et stocker dans le fichier dist/ répertoire.

Comment fonctionne Angular

Une fois la construction achevée, tous les composants, services, modules, etc. de notre application sont transposés dans l'application. JavaScript .js qui est utilisé pour exécuter l'application Angular dans le navigateur.

Déclarations en Docs Angular

  1. Lorsque vous effectuez un bootstrap avec le AppComponent (dans main.ts), Angular recherche une classe <app-root> dans le index.html le trouve, instancie une instance de AppComponent et le rend à l'intérieur de l'interface utilisateur. <app-root> étiquette.

  2. Angular crée, met à jour et détruit les composants au fur et à mesure que l'utilisateur se déplace dans l'application.

Questions sur les courses

Bien que main.ts est utilisé dans l'énoncé ci-dessus pour expliquer le processus d'amorçage, l'application Angular n'est-elle pas amorcée ou démarrée en utilisant JavaScript ? .js des fichiers ?

Toutes les déclarations ci-dessus ne sont-elles pas exécutées en utilisant JavaScript ? .js des fichiers ?

Quelqu'un sait-il comment toutes les pièces s'assemblent en profondeur ?

120voto

Pace Points 10393

(Quand je dis Angular, je veux dire Angular 2+ et je dirai explicitement angular-js si je mentionne angular 1).

Prélude : C'est confus

Angular, et probablement plus précisément angular-cli, a fusionné un certain nombre d'outils tendance en Javascript qui sont impliqués dans le processus de construction. Cela conduit à un peu de confusion.

Pour ajouter à la confusion, le terme compile était souvent utilisé dans angular-js pour désigner le processus consistant à prendre le pseudo-html du modèle et à le transformer en éléments DOM. C'est une partie de ce que fait le compilateur, mais une des plus petites parties.

Tout d'abord, il n'est pas nécessaire d'utiliser TypeScript, angular-cli ou Webpack pour exécuter Angular. Pour répondre à votre question. Nous devrions examiner une question simple : "Qu'est-ce qu'Angular ?"

Angulaire : Que fait-il ?

Cette section peut être controversée, nous le verrons. Le service offert par Angular consiste essentiellement en un mécanisme d'injection de dépendances qui fonctionne en Javascript, HTML et CSS. Vous écrivez tous les petits morceaux individuellement et dans chaque petit morceau vous suivez les règles d'Angular pour référencer les autres morceaux. Angular tisse ensuite l'ensemble d'une manière ou d'une autre.

Pour être (légèrement) plus précis :

  • Les modèles permettent de connecter le HTML au composant Javascript. Cela permet à l'utilisateur d'entrer dans le DOM lui-même (par exemple, en cliquant sur un bouton) pour alimenter le composant Javascript et permet également aux variables du composant Javascript de contrôler la structure et les valeurs du DOM.
  • Les classes Javascript (y compris les composants Javascript) doivent pouvoir accéder aux instances d'autres classes Javascript dont elles dépendent (par exemple, injection de dépendance classique). Un BookListComponent a besoin d'une instance d'un BookListService qui peut avoir besoin d'une instance d'un BookListPolicy ou quelque chose comme ça. Chacune de ces classes a une durée de vie différente (par exemple, les services sont généralement des singletons, les composants ne sont généralement pas des singletons) et Angular doit gérer toutes ces durées de vie, la création des composants et le câblage des dépendances.
  • Les règles CSS devaient être chargées de telle sorte qu'elles ne s'appliquent qu'à un sous-ensemble du DOM (le style d'un composant est local à ce composant).

Il est important de noter qu'Angular n'est pas responsable de la manière dont les fichiers Javascript font référence à d'autres fichiers Javascript (par exemple, la balise import mot-clé). C'est Webpack qui s'en charge.

Que fait le compilateur ?

Maintenant que vous savez ce que fait Angular, nous pouvons parler de ce que fait le compilateur. Je vais éviter d'être trop technique, principalement parce que je suis ignorant. Cependant, dans un système d'injection de dépendances, vous devez généralement exprimer vos dépendances à l'aide d'une sorte de métadonnées (par exemple, comment une classe disant I can be injected , My lifetime is blah ou You can think of me as a Component type of instance ). En Java, Spring a initialement fait cela avec des fichiers XML. Java a ensuite adopté les annotations, qui sont devenues le moyen privilégié d'exprimer les métadonnées. C# utilise des attributs pour exprimer les métadonnées.

Javascript n'a pas un grand mécanisme pour exposer cette métadonnée intégrée. angular-js a fait une tentative et ce n'était pas mal mais il y avait beaucoup de règles qui ne pouvaient pas être facilement vérifiées et étaient un peu confuses. Avec Angular, il existe deux façons de spécifier les métadonnées. Vous pouvez écrire du Javascript pur et spécifier les métadonnées manuellement, un peu comme avec angular-js et continuer à suivre les règles et à écrire du code supplémentaire. Vous pouvez également passer à TypeScript qui, comme par hasard, dispose de décorateurs (ces @ ) qui sont utilisés pour exprimer les métadonnées.

C'est donc ici que nous pouvons enfin passer au compilateur. Le travail du compilateur consiste à prendre ces métadonnées et à créer le système de pièces fonctionnelles qu'est votre application. Vous vous concentrez sur toutes les pièces et toutes les métadonnées et le compilateur construit une grande application interconnectée.

Comment le compilateur s'y prend-il ?

Le compilateur peut travailler de deux façons : en cours d'exécution et en avance sur le temps. À partir de maintenant, je supposerai que vous utilisez TypeScript :

  • Durée d'exécution : Lorsque le compilateur TypeScript s'exécute, il prend toutes les informations relatives aux décorateurs et les insère dans le code Javascript associé aux classes, méthodes et champs décorés. Dans votre index.html vous faites référence à votre main.js qui appelle le bootstrap méthode. Cette méthode est transmise à votre module de premier niveau.

La méthode bootstrap lance le compilateur d'exécution et lui donne une référence à ce module de premier niveau. Le compilateur d'exécution commence alors à explorer ce module, tous les services, composants, etc. référencés par ce module, ainsi que toutes les métadonnées associées, et construit votre application.

  • AOT : Plutôt que de faire tout le travail au moment de l'exécution, Angular a fourni un mécanisme permettant de faire la majeure partie du travail au moment de la construction. Ceci est presque toujours fait en utilisant un plugin webpack (ce doit être l'un des paquets npm les plus populaires et pourtant les moins connus). Il s'exécute après la compilation des typescripts et voit donc essentiellement la même entrée que le compilateur d'exécution. Le compilateur AOT construit votre application comme le compilateur d'exécution, mais l'enregistre ensuite en Javascript.

L'avantage ici n'est pas seulement d'économiser le temps CPU nécessaire à la compilation elle-même, mais aussi de réduire la taille de votre application.

Réponses spécifiques

Angular CLI appelle d'abord le compilateur intégré d'angular écrit en Typescript => puis appelle le transpilateur Typescript => puis appelle la fonction Webpack pour regrouper et stocker dans le répertoire dist/.

Non. Angular CLI appelle Webpack (le vrai service d'Angular CLI est la configuration de webpack. Lorsque vous exécutez ng build ce n'est pas beaucoup plus qu'un proxy pour démarrer Webpack). Webpack appelle d'abord le compilateur Typescript, puis le compilateur Angular (dans l'hypothèse d'un AOT), tout en regroupant votre code en même temps.

Bien que main.ts soit utilisé dans la déclaration ci-dessus pour expliquer le processus d'amorçage. l'application angulaire n'est-elle pas amorcée ou démarrée à l'aide de fichiers Javascript .js ?

Je ne suis pas tout à fait certain de ce que vous demandez ici. main.ts sera transposé en Javascript. Ce Javascript contiendra un appel à bootstrap qui est le point d'entrée dans Angular. Lorsque bootstrap est fait, vous aurez votre application Angular complète en cours d'exécution.

Ce post dit qu'Angular a deux compilateurs :

Voir le compilateur

Compilateur de modules

Pour être honnête, je vais juste clamer mon ignorance ici. Je pense qu'à notre niveau, nous pouvons simplement considérer tout cela comme un grand compilateur.

Quelqu'un sait-il comment toutes les pièces s'assemblent en profondeur ?

J'espère que ce qui précède vous a satisfait.

Don't @ Me : Angular fait plus que de l'injection de dépendances

Bien sûr. Il fait du routage, de la construction de vues, de la détection de changement et toutes sortes d'autres choses. Le compilateur génère en fait du Javascript pour la construction des vues et la détection des changements. J'ai menti quand j'ai dit que c'était juste l'injection de dépendance. Cependant, l'injection de dépendances est au cœur du système et suffit à piloter le reste de la réponse.

Devrions-nous l'appeler un compilateur ?

Il fait probablement beaucoup de parsing et de lexing et génère certainement beaucoup de code en conséquence, on peut donc l'appeler un compilateur pour cette raison.

D'autre part, il ne s'agit pas vraiment de traduire votre code en une représentation simplement différente. Il s'agit plutôt de prendre un tas de morceaux de code différents et de les tisser en morceaux consommables d'un plus grand système. Le processus d'amorçage prend ensuite (après compilation, si nécessaire) ces morceaux et les intègre au noyau d'Angular.

0 votes

Merci pour cette réponse détaillée. Avant d'accepter votre réponse, j'ai un doute sur votre déclaration. The compiler does actually generate Javascript` pour la construction des vues et la détection des changements. ` Ce n'est pas un mensonge. C'est ce que fait le compilateur, non ? Et Angular fait l'injection des dépendances.

1 votes

Oui, désolé. Le mensonge auquel je faisais référence était "A son cœur, le service qu'Angular fournit, est un mécanisme d'injection de dépendance" parce que si Angular fait cela, ce n'est pas tout ce qu'il fait et même pas tout ce que le compilateur fait.

0 votes

Si Angular est abstrait comme un nouveau "langage" avec des fonctionnalités comme les composants, les directives, les services, etc. On peut l'appeler un compilateur. Il compile le langage Angular en js et html bruts.

10voto

Arun Points 260

Permettez-moi de commencer par le début.

Dans mon application, j'ai directement exécuter l'application à partir d' Webpack.

Pour générer et exécuter l'application que nous utilisons webpack, les progrès et webpack-dev-server --inline la commande a été écrit en package.json comme ci-dessous

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

  }

Quand nous courons webpack --progress commande de début de lecture d' webpack.config.js le fichier où il trouver le point d'entrée comme ci-dessous.

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'
        })
    ]
}   

et puis il lu tout Typescript le fichier et de compilation basé sur des règles déclaré dans l' tsconfig.json le fichier et de le convertir est lui respectifs .js fichiers et fichier de carte.

Si elle s'exécute sans erreur de compilation, il créera bundle.js fichier avec des noms comme nous l'avons dit dans l' Webpack section de sortie.

Maintenant laissez-moi vous expliquer pourquoi nous utilisons des chargeurs.

génial-tapuscrit-chargeur, angular2-modèle-chargeur de Nous utiliser ces chargeur pour compiler l' Typescript le fichier sur la base déclarée dans l' tsconfig.json le fichier et angular2-modèle-chargeur de recherche templateUrl et styleUrls déclaration à l'intérieur de l'angle de 2 Composant de métadonnées et remplace les chemins correspondant à exiger la déclaration.

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

Nous utilisons ci-dessus résoudre la section de raconter Webpack convertir Typescript de JavaScript le fichier

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

Les plug-ins est utilisé pour injecter du tiers-cadre ou le fichier. Dans mon code j'utilise cette injecter index.html de dossier de destination.

 devtool: 'source-map',

Ligne ci-dessus est utilisé pour voir le Typescript le fichier dans le navigateur et de débogage, il est principalement utilisé pour le code du développeur.

 loader: 'raw-loader'

Le ci-dessus raw-loader est utilisé pour charger l' .html et .css le fichier et de les combiner avec d' Typescript fichiers.

À la fin, quand nous courons webpack-dev-server --inline il va créer propre serveur et de démarrage de l'application, comme le chemin mentionné en web-pack.config.js le fichier où nous l'avons mentionné dossier de destination et le point d'entrée.

En Angular 2 point d'entrée de la plupart des applications est - main.ts où nous mentionner le démarrage initial du module par exemple(app.module) ce module contiennent l'intégralité des informations de l'application comme tous directive,du service,des modules,des composants et le routage de la mise en œuvre de l'ensemble de l'application.

Note: Beaucoup de gens avoir de doute que pourquoi index.html seulement du démarrage de l'application, même s'ils n'ont pas mentionné importe où. La réponse est lorsqu' Webpack servir de commande exécute créer propre à servir et, par défaut, il charge d' index.html si vous n'avez pas mentionner toute la page par défaut.

J'espère que l'information donnée aider certaines personnes.

2 votes

J'apprécie que vous ayez essayé d'expliquer, mais ce serait mieux si vous pouviez expliquer de manière séquentielle plus claire. Donc vous n'utilisez pas Angular CLI pour la construction Angular applications et utilisation Webpack directement comment ?

6voto

stom Points 2477

Comment Angular se construit-il ?

El Angular CLI appelle Webpack quand Webpack frappe un .ts il le transmet à TypeScript Compilateur qui possède un transformateur de sortie qui compile Angular modèles

La séquence de construction est donc la suivante :

Angular CLI => Webpack => TypeScript Compilateur => TypeScript Le compilateur appelle le Angular compilateur au moment de la compilation.

Comment fonctionne Angular ?

Angular s'amorce et s'exécute en utilisant Javascript fichier.

En fait, le processus d'amorçage est exécutable et se produit avant l'ouverture du navigateur. Cela nous amène à notre prochaine question.

Donc, si le processus d'amorçage se produit avec Javascript alors pourquoi Angular Docs utilise main.ts Fichier TypeScript pour expliquer le processus d'amorçage ?

Angular Les docteurs parlent juste de la .ts puisque c'est la source.

Voici une réponse brève. J'apprécierais si quelqu'un pouvait répondre en profondeur.

Les crédits vont à @ Toxicable pour avoir répondu à mes questions dans le chat.

5voto

ForestG Points 2574

Il est peut-être tard pour répondre, mais il y a eu récemment une très bonne discussion sur ce sujet, qui part d'un point de vue de débutant et va en profondeur. Au lieu d'essayer de résumer ou de signaler les informations erronées dans ce fil de discussion avec mes mots, je vais simplement mettre un lien vers la vidéo en Kara Erickson : Comment fonctionne Angular ? .

Elle est à la tête de la technologie du cadre Angular, et fait une très bonne présentation :

  • Quelles sont les principales parties du cadre Angular ?
  • comment le compilateur fonctionne-t-il, que produit-il ?
  • qu'est-ce qu'une "définition des composants" ?
  • Qu'est-ce qu'un bootstrap d'application, comment fonctionne-t-il ?

1 votes

Merci pour votre contribution :) J'apprécie.

0 votes

Il se concentre principalement sur les processus d'exécution et n'aborde que brièvement les stratégies/processus de compilation. C'est exactement le contraire de ce dont a besoin l'OP.

1voto

Vikas Points 7185

Donc si le processus d'amorçage se produit avec le fichier Javascript, alors pourquoi Angular Docs utilise le fichier TypeScript main.ts pour expliquer le processus d'amorçage. ?

C'est une partie de la version .js transformée de main.ts émise par ng build qui n'est pas encore uglifié et minifié, comment voulez-vous qu'un débutant comprenne ce code ? n'a-t-il pas l'air beaucoup plus compliqué ?

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); });

et avec ng build --prod --build-optimizer qui uglifie et minifie votre code afin de l'optimiser, les paquets générés sont compacts et sont dans un format illisible par les bits.

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

Alors que le fichier main.ts est lisible par l'homme et lucide, c'est pourquoi angular.io utilise main.ts pour expliquer le processus de démarrage d'une application angulaire. Angular : Pourquoi TypeScript ? en dehors de cela, si vous aviez été l'auteur d'un framework aussi génial, quelle approche auriez-vous utilisée pour rendre votre framework populaire et convivial ? n'auriez-vous pas opté pour une explication claire et concise plutôt qu'une explication compliquée ? Je suis d'accord que la documentation d'angular.io manque d'explications approfondies et qu'elle n'est pas très bonne, mais d'après ce que j'ai vu, ils s'efforcent de l'améliorer.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X