Angular – Quelles sont les significations de module.id dans le composant?

Dans une application angular, j’ai vu que @Component a la propriété moduleId . Qu’est-ce que ça veut dire?

Et lorsque module.id n’est défini nulle part, l’application fonctionne toujours. Comment ça marche encore?

 @Component({ moduleId: module.id, selector: 'ng-app', templateUrl: 'app.component.html', styleUrls: ['app.component.css'], directives: [AppComponent] }); 

La version bêta de Angular (depuis la version 2-alpha.51) prend en charge les ressources relatives des composants, telles que templateUrl et styleUrls dans le décorateur @Component .

module.id fonctionne avec CommonJS. Vous n’avez pas besoin de vous soucier de son fonctionnement.

Rappelezvous : la définition de moduleId: module.id dans le décorateur @Component est la clé ici. Si vous ne l’avez pas, alors Angular 2 recherchera vos fichiers au niveau racine.

Source du billet de Justin Schwartzenberger , grâce à @Pradeep Jain

Mise à jour du 16 septembre 2016:

Si vous utilisez Webpack pour grouper, vous n’avez pas besoin de module.id dans le décorateur. Webpack plugins gérer automatiquement (append) module.id dans le paquet final

Mise à jour pour (2017-03-13) :

Toute mention de moduleId supprimée. Le livre de recettes “Chemins relatifs au composant” est supprimé

Nous avons ajouté un nouveau plug-in SystemJS (systemjs-angular-loader.js) à notre configuration SystemJS recommandée. Ce plugin convertit dynamicment les chemins relatifs aux composants dans templateUrl et styleUrls en “chemins absolus” pour vous.

Nous vous encourageons fortement à écrire uniquement les chemins relatifs aux composants. C’est la seule forme d’URL abordée dans ces documents. Vous n’avez plus besoin d’écrire @Component({ moduleId: module.id }) , pas plus que vous.

Source: https://angular.io/docs/ts/latest/guide/change-log.html

Définition:

 moduleId?: ssortingng 

moduleId paramètre moduleId dans l’annotation @Component prend une valeur de ssortingng qui est;

L’identifiant du module qui contient le composant.

Usage CommonJS: module.id ,

Utilisation de __moduleName : __moduleName


Raison d’utiliser moduleId :

moduleId est utilisé pour résoudre les chemins relatifs de vos feuilles de style et de vos modèles, comme indiqué dans la documentation.

Identifiant du module contenant le composant. Nécessaire pour pouvoir résoudre les URL relatives pour les modèles et les styles. Dans Dart, cela peut être déterminé automatiquement et n’a pas besoin d’être défini. Dans CommonJS, cela peut toujours être défini sur module.id.

ref (ancien): https://angular.io/docs/js/latest/api/core/index/ComponentMetadata-class.html

nous pouvons spécifier les emplacements des fichiers de modèle et de style relatifs au fichier de classe de composant en définissant simplement la propriété moduleId des métadonnées @Component

ref: https://angular.io/docs/ts/latest/cookbook/component-relative-paths.html


Exemple d’utilisation:

Structure du dossier:

 RootFolder ├── index.html ├── config.js ├── app │ ├── components │ │ ├── my.component.ts │ │ ├── my.component.css │ │ ├── my.component.html 

Sans module.id :

 @Component({ selector: 'my-component', templateUrl: 'app/components/my.component.html', < - Starts from base path styleUrls: ['app/components/my.component.css'] <- Starts from base path }) 

Avec module.id :

tsconfig.json:

 { "comstackrOptions": { "module": "commonjs", < - need to change this if you want to use module.id property ... 

 @Component({ moduleId: module.id, selector: 'my-component', templateUrl: 'my.component.html', < - relative to the components current path styleUrls: ['my.component.css'] <- relative to the components current path }) 

Si vous obtenez une typescript error , declare simplement la variable dans votre fichier.

 // app.component.ts declare var module: { id: ssortingng; } // @Component({ moduleId: module.id, // now it works without annoying Typescript ... }) 

UPDATE - December 08, 2016

Le mot clé du module est disponible sur le node . Donc, si vous installez @types/node , dans votre projet, vous aurez automatiquement le mot-clé module dans vos fichiers typescripts sans avoir à le declare .

npm install -D @types/node

Selon votre configuration, vous devrez peut- être l’inclure dans votre fichier tsconfig.json pour obtenir les outils suivants :

 //tsconfig.json { ... "comstackrOptions": { "types" : ["node"] } ... } // some-component.ts // now, no need to declare module @Component({ moduleId: module.id, // now it works without annoying Typescript ... }) 

Bonne chance

Selon le document angular, vous ne devriez pas utiliser @Component ({moduleId: module.id})

S’il vous plaît référez: https://angular.io/docs/ts/latest/guide/change-log.html

Voici le texte pertinent de cette page:

Toute mention de moduleId supprimée. Le livre de recettes “Chemins relatifs aux composants” est supprimé (2017-03-13)

Nous avons ajouté un nouveau plug-in SystemJS ( systemjs-angular-loader.js ) à notre configuration SystemJS recommandée. Ce plugin convertit dynamicment les chemins relatifs aux composants dans templateUrl et styleUrls en “chemins absolus” pour vous.

Nous vous encourageons fortement à écrire uniquement les chemins relatifs aux composants. C’est la seule forme d’URL abordée dans ces documents. Vous n’avez plus besoin d’écrire @Component({ moduleId: module.id }) , pas plus que vous.

En plus des excellentes explications fournies par echonax et Nishchit Dhanani je tiens à append que je déteste vraiment la population de composants avec module.id . En particulier, si vous avez un support pour la compilation AoT (Ahead of Time) et pour un projet réaliste, c’est ce que vous devriez viser, il n’y a pas de place pour quelque chose comme module.id dans les métadonnées de vos composants.

De la documentation :

Les applications compilées par JiT qui utilisent le chargeur SystemJS et les URL relatives aux composants doivent définir la propriété @Component.moduleId sur module.id . L’object module n’est pas défini lorsqu’une application compilée avec AoT s’exécute. L’application échoue avec une erreur de référence NULL sauf si vous affectez une valeur de module globale dans le fichier index.html comme ceci:

  

Je pense que cette ligne dans la version de production du fichier index.html n’est absolument pas acceptable!

Par conséquent, le but est d’avoir une compilation de jets (juste à temps) pour le développement et la prise en charge AoT pour la production avec la définition de métadonnées de composant suivante: (sans moduleId: module.id ligne moduleId: module.id )

 @Component({ selector: 'my-component', templateUrl: 'my.component.html', < - relative to the components current path styleUrls: ['my.component.css'] <- relative to the components current path }) 

Dans le même temps, je voudrais placer des styles, comme my.component.css et des fichiers de modèle, comme my.component.html rapport au my.component.ts fichiers du composant my.component.ts .

Pour ce faire, la solution consiste à héberger un serveur Web (lite-server ou browser-sync) pendant la phase de développement à partir de plusieurs sources de répertoires!

bs-config.json :

 { "port": 8000, "server": ["app", "."] } 

S'il vous plaît prendre une prise à cette réponse pour moi des détails.

Le projet exemplaire de démarrage rapide angular 2, qui repose sur cette approche, est hébergé ici .

On dirait que si vous utilisez “module”: “es6” dans tsconfig.json, vous n’avez pas à l’utiliser 🙂

Cette valeur moduleId est utilisée par les processus de reflection angular et le composant metadata_resolver pour évaluer le chemin de composant qualifié complet avant la construction du composant.

L’ajout de moduleId: module.id corrige plusieurs problèmes pouvant survenir lors de la création d’applications angulars natives et d’applications Web angulars. Il est recommandé de l’utiliser.

Il permet également au composant de rechercher des fichiers dans le répertoire en cours plutôt que dans le dossier supérieur.