Angulaire de l'utilisation de JavaScript en ligne dans les attributs HTML n'est pas "mauvaise pratique"?

Question

Comme je l'ai lu à travers l'angle de tutoriels, j'aime vraiment beaucoup, mais ce n'est pas "ng-click" l'équivalent d'une ligne onClick? Ma compréhension est que le JavaScript de la communauté avait décidé de JavaScript en ligne de gestionnaires d'événements dans votre HTML a été "mauvaise pratique".

<img ng-src="{{img}}" ng-click="setImage(img)">

Il serait bon de savoir pourquoi ce n'est plus considérée comme "incorrect" lors de l'utilisation Angulaire.

Source: http://docs.angularjs.org/tutorial/step_10

Answer 1

Vraiment, tout cela revient au fait que votre code doit être accroché dans votre application logique d'une certaine manière. Les meilleures pratiques pour AngularJS généralement de l'état que vous devriez écrire vos propres modèles--les objets qui représentent votre entreprise domaine--et les attacher à la portée. Imaginez un code comme ceci:

<img ng-src="{{img}}" ng-click="myProfile.setMainImage(img)">

myApp.controller("ProfileController", function($scope, myProfile) {
  $scope.myProfile = myProfile;
});

Le point de vue dit "quand cette image est cliqué, il va appeler setMainImage() sur mon profil." La logique métier est à l'intérieur d' myProfile, où il peut être testé, etc. La vue est juste un crochet.

Dans un plus "traditionnelles" ou "vanille" jQuery de l'installation, vous devriez écrire quelque chose comme:

$("#someId img").on('click', function() {
  var img = $(this).attr('src');
  myProfile.setMainImage(img); // where does myProfile come from here?
                               // how does it update the view?
});

Bien sûr, le code JavaScript de la communauté a déterminé que le fait d'écrire des applications importantes dans ce mode n'est pas vraiment défendable, en partie à cause de la déconnexion entre la vue et le modèle d'objets (comme indiqué par les commentaires dans l'extrait de code), qui est pourquoi nous avons des cadres comme Angulaire en premier lieu.

Donc, nous savons que ce natif de jQuery n'est pas l'idéal, mais nous ne sommes pas encore sûr de l'ensemble de l' ngClick chose. Nous allons le comparer à un autre très populaire framework JavaScript qui fournit une MV* architecture, de la colonne vertébrale. Dans une récente RailsCasts épisode sur AngularJS, quelqu'un a demandé une question très semblable:

Est-ce juste moi, ou AngularJS ressemble tellement une mauvaise idée? Ryan, ne vous méprenez pas, l'épisode était génial, mais je ne suis pas convaincu par le cadre.

Tout ce qui ng-show, ng-repeat, ng-class sont à la recherche comme les vieux de Java JSF, et les cadres similaires. Il applique également les importune JS avec ng-submit et ng-click.

Donc, mon point est: votre point de vue sera facilement devenir encombré et totalement dépendant de lui. L'avantage de d'autres cadres comme l'épine Dorsale, est d'avoir une séparation des préoccupations entre la présentation et le comportement (moins ou pas de dépendances), et structuré de l'application côté client (MVVM).

Ma réponse est applicable ici aussi:

Dans un cadre comme épine Dorsale, vous auriez quelque chose comme le code suivant (pris à partir de la colonne vertébrale site web, moins quelques lignes):

var DocumentView = Backbone.View.extend({

  events: {
    "dblclick"                : "open",
    "click .icon.doc"         : "select",
    "contextmenu .icon.doc"   : "showMenu",
    "click .show_notes"       : "toggleNotes",
    "click .title .lock"      : "editAccessLevel",
    "mouseover .title .date"  : "showTooltip"
  },

  open: function() {
    window.open(this.model.get("viewer_url"));
  },

  select: function() {
    this.model.set({selected: true});
  },

});

Dans cet objet , qui est un point de vue, vous êtes mise en place de gestionnaires d'événements sur divers éléments. Ces gestionnaires d'événement fonctions d'appel sur le point de vue de l'objet de déléguer à des modèles. Vous pouvez également configurer des rappels sur les différents événements du modèle (comme change), qui à son tour appel de fonctions sur le point de vue de l'objet à mettre à jour la vue en conséquence.

Dans Angulaire, le DOM est votre point de vue. Lors de l'utilisation d' ng-click, ng-submit, etc., vous êtes mise en place de gestionnaires d'événements sur ces éléments, qui appellent des fonctions qui doivent déléguer à des objets de modèle. Lors de l'utilisation d' ng-show, ng-repeat, etc. vous configurez des rappels sur le modèle, les événements qui changent la vue.

Le fait que AngularJS) énonce les [crochets et] rappels derrière les coulisses pour vous est sans importance; la seule différence entre cela et quelque chose comme épine Dorsale, c'est que Angulaire vous permet d'écrire votre point de vue de manière déclarative-vous décrire ce que votre vue est--plutôt que de impérativement--décrivant ce que votre vue ne.

Donc, à la fin, <a ng-click="model.set({selected: true})"> ajoute vraiment pas plus que les dépendances

events: {
  'click a': 'select'
},

select: function() {
  this.model.set({selected: true});
}

...mais c'est sûr, c'est un enfer de beaucoup moins de code. ;)

(Note: en fait, l'angle de la version devrait être <a ng-click="select()">, et l' select méthode sur le champ d'application serait comme l' select méthode dans la vue dans l'épine Dorsale exemple.)

Maintenant, peut-être un légitime souci, c'est que vous n'aimez pas le cas des crochets dans votre balisage. Personnellement, je préfèrent largement la nature déclarative de Angulaire des points de vue, où votre balisage explique que le point de vue est et vous avez une liaison bidirectionnelle entre les événements (qu'ils soient générés par les utilisateurs ou tout simplement des changements dans le modèle) et vos points de vue--je trouve que j'écris beaucoup moins de code réutilisable pour raccorder des événements (en particulier les changements dans la vue, marquée par des changements dans les modèles), et je pense que c'est plus facile de raisonner sur la vue en général.