Angular - 2-9 Comprendre pleinement le sélecteur de components

Concentrons-nous maintenant sur la dernière propriété du décorateur @Component que nous n'avons pas encore explorée en détail : le selector. On sait déjà qu'il doit être unique pour ne pas écraser accidentellement un élément existant ou un composant fourni par un autre package. Mais il y a une information de plus à connaître : vous n'êtes pas obligé d'utiliser un sélecteur de type élément. Le sélecteur Angular fonctionne en réalité comme un sélecteur CSS.

Aujourd'hui nous utilisons app-server comme nom d'élément, exactement comme on cible un h3 en CSS en tapant simplement h3. Mais on peut aussi cibler le composant par attribut ou par classe, ce qui donne trois écritures possibles :

  • par élément : selector: 'app-server' → on utilise <app-server></app-server> ;
  • par attribut : selector: '[app-server]' → on utilise <div app-server></div> ;
  • par classe : selector: '.app-server' → on utilise <div class="app-server"></div>.

Ce qui n'est PAS supporté

Si on bascule sur la version attribut sans changer le template, l'application casse : Angular se plaint que app-server est un élément inconnu. C'est normal — le sélecteur cherche désormais un attribut, plus un élément. Une fois le template adapté, tout refonctionne. La sélection par ID (#app-server) n'est pas supportée par Angular, et les pseudo-sélecteurs CSS comme :hover non plus. En pratique, pour les composants on s'en tient quasiment toujours au sélecteur d'élément (app-server) ; les sélecteurs par attribut sont plus pertinents pour les directives, que nous étudierons bientôt. Il est tout de même important de savoir que ces alternatives existent : certains cas d'usage avancés justifient un sélecteur différent.

En résumé

Cette leçon explore en profondeur la propriété 'sélecteur' du décorateur @Component d'Angular. Elle explique comment fonctionnent les trois types de sélecteurs supportés (élément, attribut et classe) et montre leurs cas d'usage respectifs. La leçon souligne l'importance de choisir des sélecteurs uniques et présente les limitations des sélecteurs non supportés comme les ID et pseudo-sélecteurs.

Points clés

  • Le sélecteur doit être unique pour éviter de surcharger des éléments existants ou issus d'autres packages
  • Angular supporte trois syntaxes de sélecteur : l'élément (app-servers), l'attribut [app-servers] et la classe (.app-servers), identiques à la syntaxe CSS
  • Les sélecteurs par ID et les pseudo-sélecteurs (hover, active...) ne sont pas supportés par Angular
  • La bonne pratique consiste à utiliser le sélecteur d'élément pour les composants personnalisés plutôt que les sélecteurs de classe ou d'attribut

Questions fréquentes

Quels types de sélecteurs fonctionnent dans Angular ?

Angular supporte trois types de sélecteurs : par élément (app-servers), par attribut ([app-servers]) et par classe (.app-servers). Ces syntaxes correspondent aux sélecteurs CSS standard. Les sélecteurs par ID et pseudo-sélecteurs ne sont pas supportés.

Pourquoi le sélecteur doit-il être unique ?

Un sélecteur unique évite de surcharger accidentellement un élément existant dans le DOM ou un composant provenant d'un autre package tiers utilisé dans le projet. Cela garantit que votre composant Angular est correctement identifié et isolé.

Quel sélecteur faut-il utiliser comme bonne pratique ?

Il est recommandé d'utiliser le sélecteur d'élément (par exemple app-servers) pour les composants. C'est la pratique la plus courante et la plus intuitive pour créer des éléments HTML personnalisés que votre application Angular reconnaît.