web-dev-qa-db-fra.com

Différences d'utilisation de Component template vs templateUrl

Angular 2 permet d’écrire des modèles multilignes en utilisant des caractères `pour les interroger. Il est également possible de placer un modèle multiligne dans le fichier .html et de le référencer par templateUrl.

Il me semble commode de placer le modèle directement dans le composant, car tout est au même endroit, mais y a-t-il un inconvénient à le faire?

1ère approche:

import {Component} from 'angular2/core';
@Component({
    selector: 'my-app',
    template: `
    <h1>My First Angular 2 multiline template</h1>
    <p>Second line</p> 
    `
})
export class AppComponent { }

vs 2ème approche:

import {Component} from 'angular2/core';
@Component({
    selector: 'my-app',
    templateUrl: 'multi-line.html'
})
export class AppComponent { }

avec multi-line.html:

<h1>My First Angular 2 multiline template</h1>
<p>Second line</p>
angularangular2-template
13
Andris Krauze

En termes de performances de l'application finale, il n'y a pas de réelle différence entre un modèle incorporé et un modèle externe.

Pour le développeur, toutefois, vous devez prendre en compte un certain nombre de différences.

  1. Vous obtenez une meilleure complétion de code et une prise en charge intégrée dans votre éditeur/IDE dans la plupart des cas lorsque le code HTML est dans un fichier .html séparé. (IntelliJ IDEA, au moins, prend en charge HTML pour les modèles et chaînes intégrés)
  2. Il y a un facteur de commodité à avoir le code et le code HTML associé dans le même fichier. Il est plus facile de voir comment les deux sont liés.

Ces deux choses auront la même valeur pour beaucoup de gens, alors il vous suffira de choisir ce que vous préférez et de continuer avec la vie si tout se passait pour le mieux.

Mais cela nous amène aux raisons pour lesquelles vous devriez conserver vos modèles dans vos composants, à mon avis:

  1. Il est difficile d’utiliser l’utilisation des chemins de fichiers relatifs pour les modèles externes tel qu’il est actuellement dans Angular 2.
  2. L'utilisation de chemins non relatifs pour les modèles externes rend vos composants beaucoup moins portables, car vous devez gérer toutes les références de type /where/is/my/template à partir de la racine qui changent en fonction de la profondeur de votre composant.

C'est pourquoi je vous suggère de conserver vos modèles dans vos composants, où ils se trouvent facilement. En outre, si vous constatez que votre modèle en ligne devient volumineux et difficile à manier, cela signifie probablement que vous devez scinder votre composant en plusieurs composants plus petits.

24
Michael Oryl

L'inconvénient est que l'outillage IDE n'est pas aussi performant que mentionné ci-dessus, et l'insertion de gros morceaux de code HTML dans vos composants les rend plus difficiles à lire.

De même, si vous suivez le guide de style angular2, il vous est recommandé d'extraire les modèles do dans un fichier séparé lorsque leur longueur est supérieure à 3 lignes. 

Dans le guide de style angular2:

Do extraire les modèles et les styles dans un fichier séparé, lorsque plus de 3 lignes.

Pourquoi? Les astuces de syntaxe pour les modèles insérés dans les fichiers de code (.js et .ts) sont non pris en charge par certains éditeurs.

Pourquoi? La logique d'un fichier de composant est plus facile à lire si elle n'est pas mélangée avec modèle et styles en ligne.

La source

13
swestner

Vous pouvez passer un littéral de chaîne à template composé de vos composants HTML. De cette façon, vous avez la source HTML dans le même fichier que le code TypeScript.

Avec templateUrl, vous référencez un fichier externe contenant le modèle HTML. De cette façon, vous avez HTML et TypeScript dans des fichiers séparés.

Dans un fichier externe, la prise en charge de l'auto-complétion et de la vérification de la syntaxe est généralement mieux prise en charge, mais elle peut s'avérer fastidieuse car chaque composant est composé de plusieurs fichiers au lieu d'un (il y a aussi des styles). Les fichiers externes doivent être intégrés dans une étape de construction, sinon vous auriez beaucoup de demandes de serveur pour charger tous les fichiers de modèle.

Le guide de style Angular2 suggère de ne pas avoir de modèles en ligne de plus de 3 lignes.

3
Günter Zöchbauer

La plupart des réponses semblent correspondre au support de l'éditeur, mais, bien que cet argument soit vrai, je ne le dirais pas comme un atout majeur pour l'intégration des fichiers html et css dans les fichiers .html et .css.

La principale raison pour laquelle je sépare mes fichiers html et css est qu’elle suit SRP . Il facilite la portabilité du code et sa réutilisation lorsque les versions des modifications angulaires et la syntaxe de la manière dont le TypeScript doit être disposé, votre code html et votre css restent en grande partie identiques.

2
Jdahern

Si vous développez Angular2 + bibliothèque qui est supposé être utilisé dans d'autres projets, l'un des inconvénients de l'insertion de votre modèle HTML dans un fichier séparé peut se produire.

Dans ce cas, les utilisateurs de votre bibliothèque risquent de ne pas pouvoir effectuer la compilation JIT avec succès, sauf s'ils utilisent des chargeurs de gabarits tels que angular2-template-loader ou angular2-rollup ou tout autre fonction. sur le lieur qui doit être correctement configuré, cela peut parfois être délicat. 

Pour éviter cet inconvénient et conserver des modèles dans des fichiers séparés (ce qui, à mon avis, est très pratique), le développeur de la bibliothèque pourrait finir par insérer automatiquement les modèles en utilisant le plugin Gulp comme gulp-inline-ng2-template} _ ou n'importe quel autre. Mais cela impliquerait un niveau de complexité supplémentaire lors de la construction de la version ES2015 de la bibliothèque.

1
Oleksii Trekhleb

Semble travailler maintenant.

@Component({
  selector: 'my-dashboard',
  templateUrl: './dashboard.component.html',
  styleUrls: ['./dashboard.component.css']
})

Extrait de 'tour of heros' https://angular.io/docs/ts/latest/tutorial/toh-pt5.html et adapté pour tester ce problème concret.

[email protected]

0
Nuno Ribeiro