Dans une application angulaire, j'ai vu que cela @Componentavait des propriétés moduleId. Qu'est-ce que ça veut dire?

Et quand elle module.idn'est définie nulle part, l'application fonctionne toujours. Comment cela peut-il encore fonctionner?

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

La version bêta d'Angular (depuis la vesion 2-alpha.51) prend en charge les actifs relatifs pour les composants, comme templateUrl et styleUrls dans le @Componentdécorateur.

module.idfonctionne lors de l'utilisation de CommonJS. Vous n'avez pas à vous soucier de son fonctionnement.

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

Source du billet de Justin Schwartzenberger , merci à @Pradeep Jain

Mise à jour du 16 septembre 2016:

Si vous utilisez Webpack pour le regroupement, vous n'avez pas besoin module.idde décorateur. Gestion automatique des plugins Webpack (ajoutez-le) module.iddans le bundle final

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

Toute mention de moduleId a été supprimée. Livre de recettes "Chemins relatifs des composants" supprimé

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

Nous vous encourageons fortement à n'écrire que des 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 }), ni ne devriez-vous.

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

Définition:

moduleId?: string

moduleIdparamètre à l'intérieur de l' @Componentannotation prend une stringvaleur qui est;

" L'ID du module du module qui contient le composant. "

Utilisation CommonJS: module.id,

Utilisation de SystemJS: __moduleName

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

L'ID du module du module qui contient le composant. Nécessaire pour pouvoir résoudre les URL relatives des modèles et des 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.

réf (ancienne): 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 par rapport au fichier de classe de composant simplement en définissant la propriété moduleId des métadonnées @Component

réf: https://angular.io/docs/ts/latest/cookbook/component-relative-paths.html

Structure des dossiers:

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:

{
  "compilerOptions": {
    "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 typescript error, juste declarela variable dans votre fichier.

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

UPDATE - December 08, 2016

Le modulemot-clé est disponible sur node. Donc, si vous installez @types/node, dans votre projet, vous aurez moduleautomatiquement des mots clés disponibles dans vos fichiers dactylographiés sans en avoir besoin declare.

npm install -D @types/node

Selon votre configuration, vous devrez peut- être l'inclure dans votre tsconfig.jsonfichier pour obtenir l' outillage :

//tsconfig.json
{
   ...
   "compilerOptions": {
       "types" : ["node"]
   }
   ...
}

// some-component.ts
// now, no need to declare module
@Component({
   moduleId: module.id,    // now it works without annoying Typescript
   ...
})

Bonne chance

En plus des excellentes explications de echonaxet Nishchit Dhananije tiens à ajouter que je déteste vraiment la population de composants avec module.id. Surtout, 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.iddans les métadonnées de votre composant.

Depuis les documents :

Les applications compilées par JiT qui utilisent le SystemJSchargeur et les URL relatives aux composants doivent définir la @Component.moduleIdpropriété sur module.id. L'objet module n'est pas défini lors de l'exécution d'une application compilée AoT. L'application échoue avec une erreur de référence nulle, sauf si vous attribuez une valeur de module globale dans le fichier index.html comme ceci:

<script>window.module = 'aot';</script>

Je pense qu'avoir cette ligne dans la version de production du index.htmlfichier n'est absolument pas acceptable!

Par conséquent, l'objectif est d'avoir une compilation JiT (juste à temps) pour le développement et une prise en charge AoT pour la production avec la définition de métadonnées de composant suivante: (sans moduleId: module.idligne)

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

En même temps, je voudrais placer des styles, comme my.component.csset des fichiers de modèle, comme par my.component.html rapport au composantmy.component.ts chemins de fichiers des .

Pour y parvenir, la solution que j'utilise est d'héberger un serveur web (lite-server ou browser-sync) pendant la phase de développement à partir de plusieurs sources d'annuaire!

bs-config.json:

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

Veuillez prendre une réponse à cette réponse pour moi des détails.

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

Selon Angular doc, vous ne devez pas utiliser @Component ({moduleId: module.id})

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

Voici le texte pertinent de cette page:

Toute mention de moduleId a été supprimée. Suppression du livre de recettes "Chemins relatifs des composants" (2017-03-13)

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

Nous vous encourageons fortement à n'écrire que des 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 }), ni ne devriez-vous.

On dirait que si vous utilisez "module": "es6" dans tsconfig.json, vous n'avez pas besoin de l'utiliser :)

Cette valeur moduleId est utilisée par les processus de réflexion angulaire et le composant metadata_resolver pour évaluer le chemin d'accès complet du composant avant la construction du composant.

L'ajout moduleId: module.idcorrige plusieurs problèmes pouvant survenir lors de la création d'applications natives angulaires et d'applications Web angulaires. Il est préférable de l'utiliser.

Il permet également au composant de rechercher des fichiers dans le répertoire courant au lieu du dossier supérieur