Angular.js: DEMANDE DE COMMENTAIRES : `angular.component()` - nom du contrôleur de directive par défaut

c) les programmeurs sont tentés d'utiliser isolate:false et d'accéder directement aux contrôleurs ancêtres.

@drpicox - Je suis tenté de dire que nous interdisons isolate: false pour les composants créés à l'aide de cet assistant.

Je suis d'accord, après avoir considéré ceci:

• isolate: true lorsque restrict vaut 'E' : pour moi, ce sont vraiment des composants, où la notation $ctrl a tout son sens
• isolate: false quand restrict vaut 'A' : pour moi ce sont des _decorators_, une sorte d'enhancer des composants existants, dans ce cas $ctrl entre en collision donc la nomenclature actuelle ça va

Mais je considère que le deuxième cas est plutôt à faire avec des directives, les _décorateurs_ ne sont pas fréquents, généralement de bas niveau, et ne conviennent pas aux juniors.

C'est donc probablement une bonne idée d'interdire isolate: false .

Dans une autre piste de réflexion, à propos des _décorateurs_, une fonction pour obtenir le contrôleur du composant 'E' de l'entité actuelle devrait être une bonne idée, spécialement pour écrire des _décorateurs_ génériques pour traiter n'importe quel composant actuel (nécessite de savoir à l'avance quel contrôleur est et vous ne pouvez pas utiliser une sorte d'interface de ce que vous recherchez).

J'aime $cmp , mais trouvez $comp encore mieux, parce que c'est plus clair.

J'aime $cmp , mais trouvez $comp encore mieux, parce que c'est plus clair.

J'aime $comp . Chaque fois que je vois $cmp , je pense "comparer".

suggestion différente : pourquoi ne pas avoir le nom du composant comme nom d'instance de contrôleur ?
ex: profil utilisateur -> scope.userProfile

@tabanliviu C'est comme ça que ça se passe actuellement sur master mais @petebacondarwin a mentionné dans ce même numéro, dans le premier message, pourquoi un nom commun est préférable.

@mgol :+1: Je pense que j'ai passé sous silence quand j'ai lu le ticket. Ce changement devrait-il être davantage considéré comme un problème lié à ngUpgrade ? Je pense que dans le contexte d'angular 1.x, l'implémentation actuelle est une bonne solution. Peut-être exposer cela comme une fonction de paramètres qui prend le nom du composant et génère le nom du contrôleur ? de cette façon, il sert le modèle actuel et un futur chemin de migration.

L'heure du garage à vélos.

+1 pour $ctrl.

Ctrl a beaucoup de culture préexistante dans la documentation Angular 1 et des exemples comme suffixe "contrôleur". Essayez de googler "angular ctrl" pour faire bonne mesure.

Le choix actuel de le dériver du nom du composant est assez désagréable, car ils ont en effet tendance à être assez longs dans les applications réelles.

:+1: pour $ctrl , $vm par défaut ressemble plus à une déclaration sur la façon dont les contrôleurs doivent être utilisés.

+1 pour $ctrl .

Nous avons débattu de cela assez longuement au sein de l'équipe ng-forward et avons décidé que ctrl était un terme moins chargé que vm .

Je vote pour $ctrl et je serais très heureux si cela encourage les gens à ne plus appeler leurs manettes vm :P

Oh, je voudrais aussi ajouter que

cela peut être confondu avec les éléments d'entrée ConTRoL

Non. Pas vraiment.

$ctrl

Je pense que ce serait plus compréhensible et intuitif pour tout le monde.

+1 $ctrl

Autres suggestions :

1. $as - comme contrôleur as
2. $at - comme @ - alors que dans le script du café, il fait référence à 'ce' contexte
3. $class - bien que 5 caractères, il est proche de la notation de classe de composant ng2.
4. $prox - puisque conceptuellement, l'instance Ctrl est un proxy vers une couche de services
5. $ctx - raccourci pour le contexte
   Merci.

Je vote pour $this parce que dans ng2 this du contrôleur est le contexte du modèle (et à mon avis component est très bon dans le rôle d'outil de transition entre ng1 et ng2).

+1 pour $ctrl

Je préfère également la propriété $ctrl , car elle représente le contrôleur de composant.

+1 pour $ctrl

+1 pour $ceci

J'irais même avec this et laisserais tomber le $ si ce n'était pas trop difficile à faire. C'est aussi la seule option qui n'est pas abrégée pour autre chose, et je déteste les abréviations. :)

J'opterais pour $ ctrl ou $ cc (étant l'abréviation de contrôleur de composant)

+1 pour $ctrl

Nous pourrions l'appeler juste $troll , il a un peu de $this et la moitié de $controller . Non, je plaisante, ça me va avec $ctrl . :+1:

$ctrl + 1

$vm

Avantages

• moins de nouveaux concepts
• court
• ne représente pas ce qu'est vraiment l'objet (mais les développeurs en transition l'obtiendront... et c'est le but)

Les inconvénients

• ne représente pas ce qu'est vraiment l'objet (mais les développeurs en transition l'obtiendront... et c'est le but)

$ctx - raccourci pour le contexte.

Plus général que $ctrl , moins anonyme que $vm , sans confusion comme $comp ou $this .

J'ai jeté un coup d'œil aux moteurs de modèles (Jade, Handlebars, Moustache.js, Dust.js, Nunjucks, EJS, etc.) et il semble que les noms context , locals ou data sont utilisés pour le nom de variable passé à la méthode de rendu.

Aussi $ctx , pour le contexte, n'a pas la même surcharge cognitive que $ctrl (ou $this ) et, en effet, vous avez dit in Angular 2, where the context is the controller .

@albertosantini - un problème avec $ctx est que le contexte réel est la portée actuelle, qui est également accessible directement par this .

$vc - représente le contrôleur de vue.
j'ai trouvé une référence dans la documentation d'apple

tldr ;

"...La classe UIViewController définit les méthodes et les propriétés de gestion de vos vues, de gestion des événements..."

Je vote fortement pour $this :

<textarea ng-change="$this.handleChange">

_Avantages:_

• Le GROS avantage : Vous n'avez pas besoin de faire de ctrl = this dans votre Controller, pour que les deux entités se ressemblent.
• Tout autre chose que $this donne l'impression qu'Angular introduit encore _"plus de langage propriétaire"_, ce qui est l'une des plaintes les plus courantes à propos d'Angular . Votre contrôleur deviendra pollué comme ça :

  controller: function() {
    var ctrl = this;

    ctrl.items = [];
    ctrl.text = '';
    ctrl.handleSubmit = function () {
        ctrl.items.push({text: ctrl.text});
        ctrl.text = '';
    };
  }

au lieu du plus propre, élégant et indépendant du cadre

  controller: function() {
    this.items = [];
    this.text = '';
    this.handleSubmit = function () {
       this.items.push({text: this.text});
       this.text = '';
    };

• Cette dernière est une pure fonction JavaScript qui peut être réutilisée n'importe où avec ou sans Angular. Le premier aurait l'air hors contexte n'importe où ailleurs.
• Notez comment même le surligneur de syntaxe est votre ami dans ce dernier extrait et comment il vous combat dans le premier. La lisibilité du code est un problème important.
• Cette syntaxe est similaire à React telle qu'elle apparaît sur leur landing page :

<textarea onChange={this.handleChange}>

• Dans React, le contexte DOM et l'instance de contrôleur sont traités exactement comme les mêmes entités , et React en profite même, affirmant que leur approche est plus simple.
• Angular n'est sûrement pas React, mais beaucoup de gens utilisent ou regardent les deux, donc plus de similitude leur semblerait plus amicale, c'est-à-dire moins déroutante pour eux.

@dmitriz Un problème avec $this dans AngularJS, c'est que dans le modèle, le contexte (c'est-à-dire this ) n'est vraiment pas le contrôleur. Il semble que dans React (et Angular 2), ils soient vraiment la même chose et il est donc logique d'utiliser this (ou $this ). Dans Angular 1, ils ne sont pas identiques et donc $this pourrait en fait causer encore plus de confusion.

En ce qui concerne le côté JavaScript des choses, il est très courant dans le code ES5 d'aliaser this à autre chose en raison des problèmes de liaison de this lors de l'appel de méthodes libres. Ainsi, les contrôleurs auront toujours quelque chose comme var that = this toute façon, auquel cas on peut aussi bien utiliser var ctrl = this .

Cela étant dit, il n'y a aucune obligation de le faire dans vos contrôleurs si vous ne le souhaitez pas. Il est parfaitement raisonnable à l'OMI d'utiliser this en interne dans un objet, mais de se référer ensuite à un objet par un autre nom lors de son utilisation depuis l'extérieur.

@dmitriz , vous n'avez pas besoin d'avoir le même alias dans le contrôleur et dans la vue (je ne le fais jamais). De plus, j'utilise toujours var self = this dans le contrôleur, pour éviter d'avoir à .bind(this) pour les rappels, etc.
Donc, cela ne devrait pas être un problème, imo.

Concernant les autres options :

• $ctx : Je n'aime pas ça, car (comme @petebacondarwin l'a mentionné), le contrôleur n'est pas le contexte des expressions.
• $this : Je n'aime pas ça, car (dans les expressions angulaires) this est un alias spécial pour la portée actuelle, donc avoir this --> scope et $this --> controller serait encore plus déroutant. (J'aurais aimé ça autrement.)
• $vm : Je n'aime pas ça (pour les raisons déjà évoquées), mais je pourrais y aller si rien ne répond mieux à nos contraintes.
• $cmp : Pas super satisfaisant (car pas précis à 100%), mais assez déclaratif. Pourrait aller avec si rien ne répond mieux à nos contraintes.
• $comp : Je préfère $cmp , parce que c'est plus court (et je ne le trouve pas plus "confusable" avec compare qu'avec $comp ).
• $ctrl : J'aime bien ça. C'est assez court, déclaratif et aussi précis que possible. J'ai toujours suffixé mes contrôleurs avec ctrl et je n'ai jamais été témoin d'une quelconque confusion avec ConTRoL (mais les personnes plus informées insistent sur le fait qu'il y a eu confusion :)). Si nous décidons que la confusion n'est pas un problème, j'irais certainement avec ça, mais je vais bien avec autre chose.
• $troll : Il faut y réfléchir un peu plus. Il a certainement du potentiel :stuck_out_tongue:
• Autres options ( $as , $at , $cc , $prox , $vc ): Je pense qu'ils introduisent de nouveaux concepts et seront plus déroutant qu'utile.

Je vote pour $ctrl , car il _est_ le contrôleur de directive. Simple.

Contre les autres :

• $vm -- Comme déjà indiqué, ce n'est pas une intention d'utilisation requise => soit confusion dans la lecture du modèle/code, soit moins de choix pour le développeur (obligé d'implémenter vm)
• $cmp -- Eh bien, ce n'est pas le composant lui-même mais (seulement) le contrôleur ? Donc vraiment trompeur ?
• $this -- Également déjà mentionné, c'est déroutant. Qu'est-ce que l'instance de contrôleur en fait "ceci" dans la portée ? Sémantiquement, je ne vois pas que cela pourrait être... eh bien... intelligible ?
• $ctx -- En fait identique à $this .

Aussi comme Pascal l'a déjà dit : je ne vois pas de confusion avec les éléments de contrôle. À moins qu'Angular2 n'injecte tous les éléments DOM/input de cette manière (c'est-à-dire $ctrl, $val, $cmbx, etc.), je ne vois pas cela comme un problème.

+1 $ctrl

Dans la même ligne que les commentaires précédents :

• $vm , $as , $at , $cc , $prox , $vc , $ctx ,. .. : introduit de nouveaux concepts inutiles pour les programmeurs
• $this : parce que this existe déjà, cela peut être déroutant pour les programmeurs
• $cmp ou $comp : (mieux d'abord) ça devrait être bien parce que cela concentre les programmeurs sur le modèle de composants, mais ils peuvent ne pas être simples
• $ctrl : c'est juste ce qui est publié dans le scope, le contrôleur, donc ça semble vraiment clair, facile à comprendre et à utiliser

Je vois, merci pour la précision, je ne savais pas this = $scope mais, oui, cela exclut tout.

Alors $ctrl semble être le deuxième meilleur choix, à part $troll c'est-à-dire :)

+1 pour $ctrl : le plus intuitif et le plus générique

@petebacondarwin Merci pour les détails.

Donc +1 pour $ctrl .

Je préfère le déclaratif $ctrl comme nom par défaut.

Pourquoi pas bon ?

@petebacondarwin @PascalPrecht

Pourquoi VM n'est-il pas une bonne représentation ?

(Si vous en avez déjà discuté sur un autre problème, faites simplement un lien vers celui-ci si vous le pouvez)

Parce que AFAIK, les contrôleurs dans Angular sont plus proches des modèles de vue que des contrôleurs classiques de MVC. mais peut-être qu'il me manque quelque chose.

+1 pour $vm

Je suis d'accord avec les points de @QuintyneBrown -

c'est plus court.

mais plus important -

Le guide de style de @johnpapa est très populaire, et beaucoup de gens que je connais s'y réfèrent dans le cadre de leur programme de formation "nouveaux développeurs".

Si nous changeons cela ici, nous devrions considérer l'effet que cela aura sur les nouveaux développeurs (peut-être soumettre un PR au guide de style)

C'est pourquoi j'aime le nom plus court "$vm" (BTW, pourquoi doit-il commencer par $ ? :)

(BTW, pourquoi doit-il commencer par $ ? :)

Les noms définis angulaires commencent par $ lorsqu'ils partagent l'espace de noms avec les définitions du programmeur, cela évite les collisions. Dans ce cas, il est défini par Angular et il est défini à l'intérieur de la portée, où le programmeur peut avoir ses propres définitions. En utilisant $ , nous évitons les collisions de noms et Angular se comporte de manière cohérente avec les attentes des programmeurs.

(@johnpapa) Le but de ce guide de style est de fournir des conseils sur la construction d'applications angulaires en montrant les conventions que j'utilise et, plus important encore, pourquoi je les choisis.

Style Y032 Utilisez une variable de capture pour cela lorsque vous utilisez la syntaxe controllerAs. Choisissez un nom de variable cohérent tel que vm, qui signifie ViewModel.

Donc, peu importe si c'est vm , ctrl ou troll , il suffit que ce soit une variable cohérente.
De plus, comme je l'ai souligné plus tôt, l'idée n'est pas d'ajouter de nouveaux concepts : vm signifie ViewModel , si vous n'utilisez pas View Models ou ne le connaissez pas, vous ne comprendrez pas ce que signifient vm ou ViewModel , ce qui sera source de confusion.

Je ne suis pas fan des noms confus. Je pense que ctrl est source de confusion. C'est le contrôleur ? contrôle (comme le contrôle html) ? et n'est-ce pas pour un composant ?

Je vote pour vm ou comp . vm est couramment utilisé et facile à expliquer. comp est nouveau, mais pas difficile à deviner.

Que diriez-vous $ctlr (ie ConTroLleR) plutôt que de $ctrl ?

+1 $comp

@petebacondarwin Oh la quantité de dyslectiques (comme moi) qui vont nous bombarder de problèmes à ce sujet... :)

@drpicox Merci pour l'explication, je vois vos points et ils sont valables. c'est difficile, mais je peux partager cela au moins d'après mon expérience, je n'ai eu aucun mal à enseigner aux développeurs la convention "vm", et j'ai aidé quelques entreprises à structurer leur application massive de cette façon, ils l'ont obtenu assez rapidement, mais peut-être que je ' Je suis seul dans cette expérience.

Mais je comprends vos points. d'accord avec $

Je suis toujours pour $vm, mais ça me va aussi avec $comp...

@wesleycho de l'équipe Angular UI Bootstrap semble fortement contre vm :
https://github.com/angular/angular.js/issues/10007#issuecomment -166707284

+1 pour $ctrl

@shairez Je partage complètement votre point de vue sur la tenue d'une convention, je suis un architecte indépendant avec des dizaines de projets en retard, la convention vm a beaucoup aidé, mais j'ai encore quelques problèmes. Il s'avère qu'il y a des gens qui résistent à l'utiliser. La résistance devrait probablement être plus faible si cette convention vient d'Angular elle-même, mais je suis sûr que si le nom était $ctrl , ils l'accepteraient tel quel, sans aucune résistance. $ctrl est tout simplement simple.

Donc, les votes sont en cours et cela ressemble à ceci:

$comp  4
$cmp   2
$ctrl  19
$vm    3
$this  3
$ctx   2
$vc    1

Le favori clair est $ctrl . En plus d'être populaire, il répond aux critères affichés en haut de ce numéro. De plus, il n'introduit aucun concept particulièrement nouveau. La chose à laquelle il est fait référence est vraiment un contrôleur (un contrôleur de composant/directive) dont les développeurs Angular comprennent déjà et tout comme certains développeurs se sont habitués à utiliser vm dans leurs directives, il ne faudra pas longtemps aux développeurs pour coton sur ce défaut.

Génial, c'est $ctrl !

Problème pour 1.4 et inférieur - impossible de nommer un "comme nom" avec $ctrl

Une autre préoccupation que j'aimerais soulever est que dans angular 1.4 et inférieur, nous ne pouvons pas vraiment utiliser "comme noms" commençant par un signe $ .

Il donne l'erreur suivante :
Error: [$controller:ctrlfmt] Badly formed controller string

Certaines entreprises ont du mal à passer aux dernières versions, et cela peut leur prendre plusieurs mois.

Ils veulent toujours suivre les conventions, donc leur processus de mise à niveau sera plus simple à l'avenir.

Pour eux, passer de vm à $ctrl est impossible.

Qu'est-ce que tu penses? Aucune suggestion?

peut-être migrer par phases :
commencez par convertir vm en ctrl
lors de la sortie de la version 1.5, "mettez à niveau" ctrl vers $ctrl

Un autre moyen possible - bien que verbeux - consiste à générer un alias controllerAs au moment de l'exécution, en vérifiant angular.version . quelque chose comme:

 angular
        .module('github')
        .directive('issueThread', issueThread);

    /* <strong i="14">@ngInject</strong> */
    function issueThread () {
        // this can be required as a module if using some module loader
        // or - another way is using global on angular namespace (i know it a bad practice - hwoever just to indicate reuse of this check 
        let prefix = angular.version.minor === 5 ? '$' : '';
        let controllerAs = prefix + 'ctrl';
        // with template strings
        var controllerAs = `${prefix}ctrl`;

        var directive = {
            controller: controller,
            restrict: 'E'
        };
        return directive;

        function controller() {
        }
    }

@orizens Qu'en est-il des modèles ?

@shariez Uhmmm c'est logique, les symboles $ ne sont destinés qu'aux éléments internes angulaires ... peut-être avoir une sorte de compatibilité ascendante dans le prochain mineur est agréable.

@drpicox vous avez un point là :).
Encore une fois, une solution à laquelle je peux penser (hacky one...), est de "remplacer" ctrl par $ctrl dans le modèle dans runtime/build. Cela peut être réalisé facilement si le projet est construit avec es6 et des modules. sinon, c'est une tâche pour gulp/grunt/npm au moment de la construction.

Pourquoi ne pas simplement utiliser controllerAs ?
Ce n'est pas une solution idéale (et en effet, nous devrons peut-être réviser la RegExp qui extrait l'identifiant de la chaîne du contrôleur (le cas échéant), mais l'utilisation controllerAs est à la fois compatible en amont et en aval :)

(Si quelqu'un veut essayer de mettre à jour cet identifiant en extrayant RegExp, c'est juste là .)

@gkalpak c'est un bon point, aller de l'avant en promouvant l'utilisation de la propriété controllerAs est bon car de plus en plus de gens passeront également à l'utilisation de composants dans leurs versions 1.4 et inférieures, je crois.

Mais, je pense que cela pourrait être déroutant si nous commencions à enseigner aux gens à propos $ctrl et dans certains cas cela fonctionne et dans d'autres non.

Donc, une compatibilité ascendante (je ne sais pas comment) est une excellente idée !

@shariez avez-vous (pouvez-vous) créer un nouveau problème pour suivre cela ?

J'ai créé #13736 qui autorise $ dans l'identifiant, lors de l'utilisation <ctrl> as <identifier> .
Les identifiants autorisés sont toujours différents entre controller: '... as ...' et controllerAs: '...' .

Cela dit, je ne suis pas sûr que la promotion controller: '... as $ctrl' soit un bon moyen de suivre les conventions. Il est beaucoup plus difficile de mettre à jour controller: '... as $ctrl' que controller: '...', controllerAs: '$ctrl' .

Merci @gkalpak - Je suis d'accord que nous devrions probablement encourager l'utilisation de la propriété controllerAs plutôt que le contrôleur comme syntaxe.

Une chose est la suivante : la documentation du composant indique : "Les définitions de composants sont très simples et ne nécessitent pas une grande partie de la complexité derrière la définition de directives générales".
Un autre: le contrôleur dans la directive n'est nécessaire que si vous construisez des directives complexes qui se parlent. Sinon, une fonction de lien est plus que suffisante (par exemple, "utilisez un contrôleur lorsque vous souhaitez exposer une API à d'autres directives. Sinon, utilisez un lien" dans la directive du guide du développeur et, d'après mon expérience, des directives implémentant la même fonctionnalité avec un lien au lieu de contrôleurs utilisés une centaine de fois dans ng-repeat sont beaucoup plus rapides.
Alors...
Je ne trouve pas dans Component (directive "simple") la manière de faire "simple" (fonction lien), seulement la plus lourde (contrôleur).
Est-ce que je manque quelque chose ?
Merci pour l'explication.

@frfancha - l'amélioration des performances est due au fait de ne pas avoir à utiliser le $injector pour instancier le contrôleur, n'est-ce pas ? Peut-être avez-vous des mesures de performance que vous pouvez fournir ?

L'idée de l'assistant de composant est de simplifier (au sens LOC) l'écriture de directives de type de composant (isolate, élément) ; et plus facile à écrire du code qui est plus en phase avec la façon dont les choses sont faites dans Angular 2.

S'il y a un problème de performances dans une application spécifique, il serait assez simple de convertir une directive de composant pour utiliser l'assistant plus général directive .

Je pense que nous devons jeter un coup d'œil aux autres documents de l'API et aux guides du développeur pour nous assurer qu'ils sont cohérents avec le nouvel assistant component() .

@petebacondarwin Au début, nous avons écrit toutes nos directives avec contrôleur, simplement parce que cela a été montré de cette façon dans le premier tutoriel que nous avons suivi.
Ce n'est qu'après avoir constaté qu'il fallait environ 15 secondes pour "ouvrir" une certaine page avec 1000 directives (5 par "lignes" dans ng-repeat x 200), nous avons lu plus sur les directives et compris que les contrôleurs sont inutiles si vous ne le faites pas " parler" entre les directives (en exigeant le contrôleur d'une autre). Après avoir "réécrit" le tout avec des fonctions de lien au lieu de contrôleurs (réécrire est un bien grand mot car il s'agissait simplement d'un copier/coller du code dans le lien au lieu du contrôleur), le temps d'affichage de la page était de 8 secondes.
Notez que ce sont des mesures firefox, à cette époque nous n'utilisions pas Chrome. Maintenant, nous l'utilisons et j'estime que le temps dans Chrome est le tiers de Firefox (et l'utilisation de la mémoire le quatrième (et sans fuite de mémoire, ce qui est formidable, dans Firefox, notre application est connue pour être "lente l'après-midi)).
Nous sommes généralement très satisfaits d'angular (nous avons converti toutes nos applications de saisie de données de l'application Smalltalk windows en WEB API + angular (au cas où ça vous intéresserait de le voir ?? Je suis parfois à Londres).
Mais je suis surpris par le choix du contrôleur pour supporter la "manière simple" de faire la directive

merci @gkalpak !

@petebacondarwin un problème distinct n'est plus pertinent, n'est-ce pas ? (A cause du PR)

Je suis d'accord (comme je l'ai écrit), nous devrions éduquer les gens à utiliser la propriété controllerAs , mais je viens de le mentionner parce que je prédis que les gens s'y heurteront.