Angular-styleguide: Espacement des noms de composants

Un composant n'est qu'un wrapper de directive sans fonction de compilation ni de liaison. Donc, utilisez simplement la même convention que vous utilisez pour les directives.

Ils ne sont pas les mêmes.. par exemple. les composants ont une portée isolée par défaut, ils utilisent le contrôleurComme par défaut, le contrôleur remplace la fonction de lien et bindToController est vrai par défaut..

Tout ce que vous pouvez faire avec un composant, vous pouvez le réaliser avec une directive, mais la raison pour laquelle le composant existe est de faciliter la transition vers angulaire 2.

Vous pouvez en savoir plus sur les fonctionnalités ici : http://www.codelord.net/2015/12/17/angulars-component-what-is-it-good-for/

Alors, cela sera-t-il ajouté?

Des suggestions ou des conseils à ce sujet?

@samithaf utilisant des séparateurs de points vous limite en ce qui concerne les sélecteurs CSS.

L'utilisation de points ne devrait pas vous limiter (par exemple, vous pouvez les échapper dans les sélecteurs CSS), mais est encombrant et non conventionnel.

Les gens utilisent - pour les composants d'espacement de noms depuis des années et je ne vois aucune raison d'utiliser un autre séparateur.

@mackelito @blowsie @gkalpak J'utilise le modèle suivant dans une application financière à très grande échelle (100K + LOC) et jusqu'à présent, tout va bien. Comme vous pouvez le voir, j'utilise des séparateurs de points pour que tout soit cohérent. Cependant, sauf pour les filtres. Avec les styles, vous pouvez échapper au point.

const loginModule = angular.module('app.core.login', [])
.component('app.core.login', loginComponent)
.service('app.core.login.loginService', loginService);

@samithaf comment ['app.core.login.loginService' , function(loginService) {}] ?

@blowsie exemple d'utilisation du service de connexion comme suit.

class LoginController {
  constructor($q, loginService) {
    this.loginService = loginService;
  }

  /**
   * <strong i="7">@method</strong> $onInit
   * This lifecycle hook will be executed when all controllers on an element have been constructed and after their bindings are initialized
   */
  $onInit() {
    this.loginService.invalidateSession();
  }

}

LoginController.$inject = ['$q', 'nw.core.login.loginService'];

export default LoginController;

C'est très sympa pour les services mais pour les composants c'est vraiment bizarre :

<div><app.core.login></app.core.login></div>

Et c'est incompatible avec le monde qui l'entoure (tout le monde utilise - comme l' a dit

Je suis sûr que l'application @samithaf est agréable avec cela, mais il y a une différence entre une convention de nommage étrange qui fonctionne bien sur un projet et ce qu'elle devrait être définie dans un guide de style global.

Le problème central ici est : l'injecteur AngularJS est plat, nous devons donc penser globalement lorsque nous nommons les composants du module. Il s'agit d'un défaut de conception corrigé dans Angular. Changer une convention de base ( - pour l'espacement des noms) utilisée depuis le début par presque tout le monde n'est pas une solution à mon humble avis.

Hé @MarcLoupias, comme vous l'avez mentionné, puisque le DI angulaire est plat, nous ne pouvons pas faire grand-chose. Mais lors de la définition de noms de modules sans espace de noms, cela peut facilement introduire des effets secondaires. Surtout dans un projet à grande échelle où vous avez plus de 10 équipes Scrum qui travaillent. Même la solution que j'ai trouvée n'est pas conforme à la convention, je ne peux pas penser à un autre bon moyen de résoudre ce problème. Cela aurait été bien si l'équipe Angular espace automatiquement les noms des modules. Mais je ne pense pas que cela se produira pour angulaire 1.X ;)

Mais lors de la définition de noms de modules sans espace de noms, cela peut facilement introduire des effets secondaires.

Oui, lors de la phase d'initialisation de l'injecteur, le comportement de l'injecteur est de remplacer silencieusement le service déjà déclaré dans l'injecteur par le dernier à déclarer.

Surtout dans un projet à grande échelle où vous avez plus de 10 équipes Scrum qui travaillent.

C'est quelque chose comme 50+ développeurs !

Je ne peux pas penser à une autre bonne façon de résoudre ce problème.

Diviser votre entreprise en plusieurs applications ? AngularJS n'est pas vraiment adapté aux projets énormes en raison de ce défaut de conception de l'espace de noms d'injecteur.