15 Question: “Penser en AngularJS” si j'ai un fond jQuery? [fermé]

question créée à Fri, Nov 2, 2018 12:00 AM

Supposons que je sois familiarisé avec le développement d'applications côté client dans jQuery , mais j'aimerais maintenant commencer à utiliser AngularJS . Pouvez-vous décrire le changement de paradigme nécessaire? Voici quelques questions qui pourraient vous aider à formuler une réponse:

  • Comment puis-je architecturer et concevoir des applications Web côté client différemment? Quelle est la plus grande différence?
  • Que dois-je arrêter de faire /utiliser? Que devrais-je commencer à faire /utiliser à la place?
  • Existe-t-il des considérations /restrictions côté serveur?

Je ne cherche pas une comparaison détaillée entre jQuery et AngularJS.

    
4520
  1. Pour ceux qui connaissent "ASP.NET MVC" ou "RoR" - il suffit de penser à Angular comme à "client MVC" et c'est tout.
    2015-05-27 21: 29: 18Z
15 réponses                              15                         

1. Ne concevez pas votre page, puis modifiez-la avec les manipulations DOM

Dans jQuery, vous concevez une page, puis vous la rendez dynamique. En effet, jQuery a été conçu pour l’augmentation et s’est incroyablement développé à partir de ce principe simple.

Mais dans AngularJS, vous devez commencer par le bas en pensant à votre architecture. Au lieu de commencer par penser "J'ai ce morceau du DOM et je veux le faire faire X", vous devez commencer par ce que vous voulez accomplir, puis concevoir votre application, puis enfin concevoir votre vue.

2. Ne pas augmenter jQuery avec AngularJS

De même, ne commencez pas par l'idée que jQuery utilise X, Y et Z, je vais donc ajouter AngularJS en plus de cela pour les modèles et les contrôleurs. Ceci est vraiment tentant quand vous débutez, c'est pourquoi je recommande toujours aux nouveaux développeurs AngularJS de ne pas utiliser jQuery du tout, du moins tant qu'ils ne sont pas habitués à faire les choses à la manière angulaire. ".

J'ai vu beaucoup de développeurs ici et sur la liste de diffusion créer ces solutions élaborées avec des plugins jQuery de 150 ou 200 lignes de code qu'ils ont ensuite collés dans AngularJS avec une collection de callbacks et $apply qui sont déroutants et compliqués; mais ils finissent par le faire fonctionner! Le problème est que dans la plupart des cas, le plug-in jQuery pourrait être réécrit dans AngularJS en une fraction du code, où tout devient soudain compréhensible et simple.

La ligne de fond est la suivante: lors de la résolution, commencez par "penser à AngularJS"; si vous ne pouvez pas penser à une solution, demandez à la communauté; si après tout cela, il n’ya pas de solution simple, puis n’hésitez pas à utiliser jQuery. Mais ne laissez pas jQuery devenir une béquille, sinon vous ne maîtriserez jamais AngularJS.

3. Toujours penser en termes d'architecture

Tout d'abord, sachez que les applications à page unique sont des applications . Ce ne sont pas des pages Web. Nous devons donc penser comme un développeur côté serveur en plus de penser comme un développeur côté client. Nous devons réfléchir à la manière de diviser notre application en composants individuels, extensibles et testables.

Alors comment faites-vous cela? Comment "pensez-vous dans AngularJS"? Voici quelques principes généraux, en contraste avec jQuery.

La vue est le "document officiel"

Dans jQuery, nous modifions la vue par programme. Nous pourrions avoir un menu déroulant défini comme un ul comme suit:

 
<ul class="main-menu">
    <li class="active">
        <a href="#/home">Home</a>
    </li>
    <li>
        <a href="#/menu1">Menu 1</a>
        <ul>
            <li><a href="#/sm1">Submenu 1</a></li>
            <li><a href="#/sm2">Submenu 2</a></li>
            <li><a href="#/sm3">Submenu 3</a></li>
        </ul>
    </li>
    <li>
        <a href="#/home">Menu 2</a>
    </li>
</ul>

Dans jQuery, dans notre logique d’application, nous l’activerions avec quelque chose comme:

 
$('.main-menu').dropdownMenu();

Lorsque nous examinons la vue, il n’est pas immédiatement évident qu’il existe une fonctionnalité. Pour les petites applications, c'est bien. Mais pour des applications non triviales, les choses deviennent rapidement confuses et difficiles à maintenir.

Dans AngularJS, cependant, la vue est le compte rendu officiel des fonctionnalités basées sur la vue. Notre déclaration ul ressemblerait à ceci:

 
<ul class="main-menu" dropdown-menu>
    ...
</ul>

Ces deux personnes font la même chose, mais dans la version d’AngularJS, toute personne consultant le modèle sait ce qui est censé se passer. Chaque fois qu'un nouveau membre de l'équipe de développement arrive à bord,elle peut regarder cela et ensuite savoir qu'il existe une directive appelée dropdownMenu qui y est appliquée; elle n'a pas besoin de deviner la bonne réponse ni de passer au crible un code. La vue nous a dit ce qui était censé se passer. Beaucoup plus propre.

Les développeurs qui découvrent AngularJS posent souvent une question du genre: comment trouver tous les liens d’un type spécifique et y ajouter une directive. Le développeur est toujours sidéré lorsque nous répondons: vous ne le faites pas. Mais la raison pour laquelle vous ne le faites pas, c’est que c’est comme à moitié jQuery, à moitié AngularJS, et pas bon. Le problème ici est que le développeur essaie de "faire jQuery" dans le contexte de AngularJS. Cela ne fonctionnera jamais bien. La vue est le compte rendu officiel. En dehors d'une directive (plus de détails ci-dessous), vous ne changez jamais, jamais, jamais le DOM. Et les directives sont appliquées dans la vue , l'intention est donc claire.

N'oubliez pas: ne créez pas, puis annotez. Vous devez architecter, puis concevoir.

Liaison de données

C’est de loin l’une des fonctionnalités les plus impressionnantes d’AngularJS et élimine la nécessité de faire les types de manipulations DOM que j’ai mentionnés dans la section précédente. AngularJS mettra automatiquement à jour votre vue afin que vous n'ayez pas à le faire! Dans jQuery, nous répondons aux événements, puis mettons à jour le contenu. Quelque chose comme:

 
$.ajax({
  url: '/myEndpoint.json',
  success: function ( data, status ) {
    $('ul#log').append('<li>Data Received!</li>');
  }
});

Pour une vue ressemblant à ceci:

 
<ul class="messages" id="log">
</ul>

Outre le mélange des préoccupations, nous avons également les mêmes problèmes de signification que ceux mentionnés précédemment. Mais plus important encore, nous devions référencer et mettre à jour manuellement un nœud DOM. Et si nous voulons supprimer une entrée de journal, nous devons également coder avec le DOM. Comment testons-nous la logique en dehors du DOM? Et si nous voulions changer de présentation?

C'est un peu brouillon et un peu frêle. Mais dans AngularJS, nous pouvons faire ceci:

 
$http( '/myEndpoint.json' ).then( function ( response ) {
    $scope.log.push( { msg: 'Data Received!' } );
});

Et notre vue peut ressembler à ceci:

 
<ul class="messages">
    <li ng-repeat="entry in log">{{ entry.msg }}</li>
</ul>

Mais, d'ailleurs, notre vue pourrait ressembler à ceci:

 
<div class="messages">
    <div class="alert" ng-repeat="entry in log">
        {{ entry.msg }}
    </div>
</div>

Et maintenant, au lieu d’utiliser une liste non ordonnée, nous utilisons des boîtes d’alerte Bootstrap. Et nous n'avons jamais eu à changer le code du contrôleur! Mais plus important encore, peu importe ou comment le journal est mis à jour, la vue changera également. Automatiquement. Neat!

Bien que je ne l'aie pas montré ici, la liaison de données est bidirectionnelle. Ainsi, ces messages de journal pourraient également être édités dans la vue simplement en procédant ainsi: <input ng-model="entry.msg" />. Et il y avait beaucoup de joie.

Couche modèle distincte

Dans jQuery, le DOM est un peu comme le modèle. Mais dans AngularJS, nous avons une couche de modèle distincte que nous pouvons gérer comme bon nous semble, de manière totalement indépendante de la vue. Cela aide pour la liaison de données ci-dessus, maintient la séparation des problèmes et introduit une testabilité beaucoup plus grande. D'autres réponses ont mentionné ce point, je vais donc en rester là.

Séparation des préoccupations

Et tout ce qui précède est lié à ce thème central: gardez vos préoccupations séparées. Votre point de vue sert de registre officiel de ce qui est censé se passer (pour la plupart); votre modèle représente vos données; vous avez une couche de service pour effectuer des tâches réutilisables; vous manipulez le DOM et augmentez votre vue avec des directives; et vous collez tout cela avec les contrôleurs. Cela a également été mentionné dans d'autres réponses, et la seule chose que je voudrais ajouter concerne la testabilité, dont je vais parler dans une autre section ci-dessous.

Injection de dépendance

Pour nous aider à séparer les problèmes, utilisez la injection de dépendance (DI). Si vous venez d'une langue côté serveur (de Java à PHP ) vous connaissez probablement déjà ce concept, mais si vous êtes un client du côté de jQuery , ce concept peut sembler de stupide à superflu à hipster. Mais ce n'est pas. : -)

D'un point de vue général, DI signifie que vous pouvez déclarer des composants très librement, puis à partir de tout autre composant. Il vous suffit de demander une instance de celui-ci et celui-ci sera accordé. Vous n'avez pas à connaître le chargement de la commande, l'emplacement des fichiers ou quoi que ce soit du genre. L’alimentation peut ne pas être immédiatement visible, mais je ne donnerai qu’un exemple (courant): testing.

Supposons que dans notre application, nous avons besoin d'un service qui implémente le stockage côté serveur via un REST API et, en fonction de l'état de l'application, stockage local également. Lorsque nous exécutons des tests sur nos contrôleurs, nous ne voulons pas avoir à communiquer avec le serveur - nous testons le contrôleur , après tout. Nous pouvons simplement ajouter un service factice du même nom que notre composant d'origine, et l'injecteur veillera à ce quenotre contrôleur obtient automatiquement le faux - notre contrôleur ne sait pas et ne doit pas savoir la différence.

En parlant de test ...

4. Développement piloté par les tests - toujours

Cela fait vraiment partie de la section 3 sur l'architecture, mais il est très important que je la pose comme sa propre section de niveau supérieur.

Parmi tous les nombreux plug-ins jQuery que vous avez vus, utilisés ou écrits, combien d'entre eux avaient une suite de tests d'accompagnement? Pas très nombreux car jQuery n’est pas très réceptif à cela. Mais AngularJS est.

Dans jQuery, le seul moyen de tester consiste souvent à créer le composant indépendamment avec un exemple /page de démonstration sur laquelle nos tests peuvent effectuer une manipulation DOM. Nous devons donc développer un composant séparément et puis l'intégrer dans notre application. Comme c'est gênant! La plupart du temps, lors du développement avec jQuery, nous optons pour un développement itératif plutôt que basé sur des tests. Et qui pourrait nous en vouloir?

Mais comme nous séparons les problèmes, nous pouvons effectuer un développement piloté par les tests de manière itérative dans AngularJS! Par exemple, supposons qu'une directive très simple indique dans notre menu quel est notre itinéraire actuel. Nous pouvons déclarer ce que nous voulons dans le cadre de notre candidature:

 
<a href="/hello" when-active>Hello</a>

D'accord, nous pouvons maintenant écrire un test pour la directive when-active inexistante:

 
it( 'should add "active" when the route changes', inject(function() {
    var elm = $compile( '<a href="/hello" when-active>Hello</a>' )( $scope );

    $location.path('/not-matching');
    expect( elm.hasClass('active') ).toBeFalsey();

    $location.path( '/hello' );
    expect( elm.hasClass('active') ).toBeTruthy();
}));

Et lorsque nous effectuons notre test, nous pouvons confirmer qu'il échoue. C’est seulement maintenant que nous devrions créer notre directive:

 
.directive( 'whenActive', function ( $location ) {
    return {
        scope: true,
        link: function ( scope, element, attrs ) {
            scope.$on( '$routeChangeSuccess', function () {
                if ( $location.path() == element.attr( 'href' ) ) {
                    element.addClass( 'active' );
                }
                else {
                    element.removeClass( 'active' );
                }
            });
        }
    };
});

Notre test réussit maintenant et notre menu fonctionne comme demandé. Notre développement est à la fois itératif et piloté par des tests. Wicked-cool.

5. Conceptuellement, les directives ne sont pas dans JQuery

Vous entendrez souvent dire "ne faites que des manipulations DOM dans une directive". C’est une nécessité. Traitez-le avec déférence!

Mais plongeons un peu plus loin ...

Certaines directives ne font que décorer ce qui se trouve déjà dans la vue (pensez à ngClass) et font donc parfois des manipulations DOM immédiatement, puis sont finalement faites. Mais si une directive est comme un "widget" et a un modèle, elle devrait également respecter la séparation des préoccupations. Autrement dit, le modèle aussi devrait rester largement indépendant de son implémentation dans les fonctions de liaison et de contrôleur.

AngularJS est livré avec un ensemble complet d’outils pour rendre cela très facile; avec ngClass nous pouvons mettre à jour dynamiquement la classe; ngModel permet la liaison de données bidirectionnelle; ngShow et ngHide afficher ou masquer un élément par programme; et beaucoup d'autres, y compris ceux que nous écrivons nous-mêmes. En d’autres termes, nous pouvons faire toutes sortes d’expressions sans manipulations DOM. Moins il y a de manipulations du DOM, plus les directives sont faciles à tester, plus elles sont faciles à modifier, plus elles sont faciles à modifier à l'avenir, et plus elles sont réutilisables et distribuables.

Je vois beaucoup de développeurs qui découvrent AngularJS pour la première fois en utilisant des directives pour lancer un tas de jQuery. En d'autres termes, ils pensent "comme je ne peux pas manipuler le DOM dans le contrôleur, je prendrai ce code dans une directive". Bien que cela soit certainement beaucoup mieux, il est souvent toujours faux .

Pensez à l'enregistreur que nous avons programmé à la section 3. Même si nous mettons cela dans une directive, nous voulons toujours le faire de la "manière angulaire". Il encore ne prend aucune manipulation du DOM! Il y a beaucoup de fois où la manipulation du DOM est nécessaire, mais c'est beaucoup plus rare que vous ne le pensez! Avant de manipuler le DOM n'importe où dans votre application, demandez-vous si vous en avez vraiment besoin. Il pourrait y avoir un meilleur moyen.

Voici un exemple rapide illustrant le schéma que je vois le plus souvent. Nous voulons un bouton à bascule. (Remarque: cet exemple est un peu artificiel et discutable pour représenter des cas plus complexes résolus exactement de la même manière.)

 
.directive( 'myDirective', function () {
    return {
        template: '<a class="btn">Toggle me!</a>',
        link: function ( scope, element, attrs ) {
            var on = false;

            $(element).click( function () {
                on = !on;
                $(element).toggleClass('active', on);
            });
        }
    };
});

Il y a quelques défauts avec ceci:

  1. Tout d'abord, jQuery n'a jamais été nécessaire. Nous n'avons rien fait ici qui ait besoin de jQuery!
  2. Deuxièmement, même si nous avons déjà jQuery sur notre page, il n’ya aucune raison de l’utiliser ici; nous pouvons simplement utiliser angular.element et notre composant fonctionnera quand on le déposera dans un projet sans jQuery.
  3. Troisièmement, même en supposant que jQuery soit requis pour que cette directive fonctionne, jqLite (angular.element) utilisera toujours si jQuery est chargé! Nous n'avons donc pas besoin d'utiliser le $ - nous pouvons simplement utiliser le angular.element.
  4. Quatrièmement, le troisième élément étroitement lié au précédent est que les éléments jqLite ne doivent pas nécessairement être enveloppés dans $ - le element qui est passé à la fonction link serait déjà un élément jQuery!
  5. Cinquièmement, comme nous l'avons mentionné dans les sections précédentes, pourquoi mélangeons-nous des éléments de modèle dans notre logique?

Cette directive peut être réécrite (même pour des cas très compliqués!) beaucoup plus simplement comme ceci:

 
.directive( 'myDirective', function () {
    return {
        scope: true,
        template: '<a class="btn" ng-class="{active: on}" ng-click="toggle()">Toggle me!</a>',
        link: function ( scope, element, attrs ) {
            scope.on = false;

            scope.toggle = function () {
                scope.on = !scope.on;
            };
        }
    };
});

Encore une fois, le modèle est dans le modèle, donc vous (ou votre utilisation)rs) peut facilement être remplacé par un modèle qui correspond à tous les styles, et la logique ne doit jamais être touchée. Réutilisation - boum!

Et il y a encore tous ces autres avantages, comme les tests, c'est simple! Quel que soit le contenu du modèle, l'API interne de la directive n'est jamais modifiée. Le refactoring est donc facile. Vous pouvez modifier le modèle autant de fois que vous le souhaitez sans toucher à la directive. Et peu importe ce que vous changez, vos tests passent toujours.

w00t!

Donc, si les directives ne sont pas simplement des collections de fonctions jQuery, que sont-elles? Les directives sont en réalité des extensions de HTML . Si le HTML ne fait pas quelque chose dont vous avez besoin, vous écrivez une directive pour le faire pour vous, puis vous l'utilisez comme si elle faisait partie du HTML.

Autrement dit, si AngularJS ne fait pas quelque chose d’original, songez à la façon dont l’équipe le ferait pour s’adapter parfaitement à ngClick, ngClass, et al.

Résumé

N'utilisez même pas jQuery. Ne l'incluez même pas. Cela vous retiendra. Et lorsque vous arrivez à un problème que vous pensez déjà pouvoir résoudre dans jQuery, avant d’atteindre le $, essayez de réfléchir à la façon de le résoudre dans les limites de AngularJS. Si vous ne savez pas, demandez! 19 fois sur 20, la meilleure façon de le faire ne nécessite pas jQuery et essayer de le résoudre avec les résultats jQuery demande plus de travail.

    
7183
2015-04-17 20: 38: 02Z
  1. Je pense qu'incorporer le travail avec JQuery dans une application angulaire est un cas d'utilisation important en raison de tous les plugins JQuery existants qui ont été écrits. Je ne réécris pas FancyBox dans jQuery pour conserver une application purement angulaire.
    2013-02-26 21: 53: 14Z
  2. @ taudep Je ne pense pas que nous soyons en désaccord autant que vous le pensez. La plupart des plugins jQuery peuvent être réécrits dans AngularJS à moindre coût, et dans ce cas, nous devrions le faire. Pour quelque chose de complexe pour lequel il n'y a pas d'équivalent, alors foncez. Pour citer la section 2: «Le résultat final est le suivant: lors de la résolution, commencez par" penser à AngularJS "; si vous ne pouvez pas penser à une solution, demandez à la communauté; si, après tout, il n’existe pas de solution simple, n'hésitez pas à rechercher le jQuery . Mais ne laissez pas jQuery devenir une béquille, sinon vous ne maîtriserez jamais AngularJS. [emphase ajoutée]
    2013-02-26 22: 39: 08Z
  3. une traduction en chinois de cette bonne réponse, j'espère utile. hanzheng.github.io/tech/angularjs/2013/10/28/…
    2013-10-28 14: 00: 00Z
  4. @ Benno Ce qu'il veut dire par "aucune manipulation du DOM" est que votre code dans la directive ne réalise pas directement des manipulations du DOM. Ce code ne connaît rien du DOM, il ne fait que modifier des variables js dans votre modèle. Oui, le résultat final est que le DOM est modifié, mais c'est qu'en dehors du code que nous écrivons, il existe des liaisons qui réagissent à l'évolution de nos variables, mais à l'intérieur de la directive, nous ne savons rien à ce sujet, ce qui crée une séparation nette entre la manipulation du DOM et logique d'entreprise. Dans votre exemple jQuery, vous modifiez directement le DOM en disant "ajoutez ce texte à cet élément"
    2014-03-02 06: 06: 38Z
  5. @ trusktr Si un développement définit jamais la valeur d'un élément d'entrée à l'aide de jQuery dans une application AngularJS, elle commet une erreur grave . La seule exception à laquelle je puisse penser est un plug-in jQuery existant qui est trop difficile à porter et qui modifie automatiquement une entrée. Dans ce cas, il est absolument essentiel de se connecter à un rappel ou de mettre une montre pour intégrer les modifications à l'application.
    2014-04-01 05: 04: 10Z

Impératif → déclaratif

Dans jQuery, les sélecteurs sont utilisés pour rechercher les éléments DOM . puis liez /enregistrez les gestionnaires d’événements àleur. Lorsqu'un événement se déclenche, ce code (impératif) s'exécute pour mettre à jour /modifier le DOM.

Dans AngularJS, vous souhaitez penser aux vues plutôt qu'aux éléments DOM. Les vues sont du HTML (déclaratif) contenant des directives AngularJS. Les directives configurent les gestionnaires d'événements en coulisse pour nous et nous donnent une liaison de données dynamique. Les sélecteurs sont rarement utilisés, le besoin d'identifiants (et de certains types de classes) est donc grandement réduit. Les vues sont liées à des modèles (via des portées). Les vues sont une projection du modèle. Les événements changent de modèle (c'est-à-dire les données, les propriétés de portée) et les vues projetant ces modèles sont mises à jour "automatiquement".

Dans AngularJS, pensez aux modèles plutôt qu'aux éléments DOM sélectionnés par jQuery qui contiennent vos données. Considérez les vues comme des projections de ces modèles plutôt que d’enregistrer des rappels pour manipuler ce que voit l’utilisateur.

Séparation des préoccupations

jQuery utilise JavaScript non intrusif - le comportement (JavaScript) est séparé de la structure (HTML) .

AngularJS utilise des contrôleurs et des directives (qui peuvent avoir chacun leur propre contrôleur et /ou des fonctions de compilation et de liaison) pour supprimer les comportements de la vue /structure (HTML). Angular propose également des services et des filtres permettant de séparer /organiser votre application.

Voir aussi https://stackoverflow.com/a/14346528/215945

Conception de l'application

Une approche pour la conception d’une application AngularJS:

  1. Pensez à vos modèles. Créez des services ou vos propres objets JavaScript pour ces modèles.
  2. Réfléchissez à la manière dont vous souhaitez présenter vos modèles - vos vues. Créez des modèles HTML pour chaque vue, en utilisant les directives nécessaires pour obtenir la liaison de données dynamique.
  3. Associez un contrôleur à chaque vue (en utilisant ng-view et routing, ou ng-controller). Demandez au contrôleur de rechercher /obtenir uniquement les données de modèle dont la vue a besoin pour faire son travail. Rendez les contrôleurs aussi minces que possible.

Héritage prototypique

Vous pouvez faire beaucoup de choses avec jQuery sans savoir comment fonctionne l'héritage prototypique en JavaScript. Lors du développement d'applications AngularJS, vous éviterez certains pièges courants si vous maîtrisez bien l'héritage JavaScript. Lecture recommandée: Quelles sont les nuances du prototypage de portée /héritage prototypique dans AngularJS?

    
408
2017-05-23 11: 47: 31Z
  1. pouvez-vous pls. expliquer en quoi un élément dom est différent d’une vue?
    2013-02-27 01: 06: 48Z
  2. @ rajkamal, un élément DOM est (évidemment) un élément unique, et dans jQuery, c'est souvent ce que nous sélectionnons /ciblons /manipulons. Une vue angulaire est une collection /un modèle d’éléments DOM associés: vue de menu, vue d’en-tête, vue de pied de page, vue de barre latérale droite, vue de profil, éventuellement plusieurs vues de contenu principales (commutables via la vue ng). En gros, vous voulez diviser votre page en différentes vues. Chaque vue a son propre contrôleur associé. Chaque vue projette une partie de vos modèles.
    2013-02-27 03: 46: 00Z
  3. jQuery est PAS . on et when sont des fonctions d'ordre supérieur, fonctionnant sur les membres d'un objet de collection jQuery.
    2013-07-25 18: 28: 48Z
  4. Quel type de code est donc exécuté dans le rappel pour on? Impératif.
    2013-08-05 17: 10: 06Z
  5. Cet impératif contre déclaratif n’est en réalité qu’une question d’abstractions. En fin de compte, tout le code déclaratif (que faire) est implémenté de manière impérative (comment le faire), que ce soit par le développeur dans un sous-programme à un niveau d'abstraction inférieur, par le framework ou par un compilateur /interprète. Dire que "jQuery est impératif" est en général une déclaration assez étrange, d'autant plus qu'elle fournit en réalité une API beaucoup plus déclarative en ce qui concerne la manipulation "manuelle" du DOM.
    2014-11-08 04: 05: 40Z

AngularJS vs. jQuery

AngularJS et jQuery adoptent des idéologies très différentes. Si vous venez de jQuery, vous trouverez peut-être certaines des différences surprenantes. Angular peut vous mettre en colère.

Ceci est normal, vous devriez pousser à travers. Angular vaut la peine.

La grande différence (TLDR)

jQuery vous fournit une boîte à outils pour sélectionner des bits arbitraires du DOM et y apporter des modifications ad-hoc. Vous pouvez faire à peu près tout ce que vous aimez, pièce par pièce.

AngularJS vous fournit plutôt un compilateur .

Cela signifie qu'AngularJS lit votre DOM entier de haut en bas et le traite comme un code, littéralement comme une instruction destinée au compilateur. Lorsqu'il traverse le DOM, il recherche des directives (directives du compilateur) spécifiques qui indiquent au compilateur AngularJS comment se comporter et quoi faire. Les directives sont de petits objets remplis de JavaScript qui peuvent correspondre à des attributs, des balises, des classes ou même des commentaires.

Lorsque le compilateur angulaire détermine qu’une partie du DOM correspond à une directive particulière, il appelle la fonction de directive, en lui transmettant l’élément DOM, tous les attributs, le champ $actuel (qui est un magasin de variables local) et un autre. bits utiles. Ces attributs peuvent contenir des expressions pouvant être interprétées par la directive et lui indiquant comment effectuer le rendu et quand elle doit se redessiner.

Les directives peuvent à leur tour extraire des composants angulaires supplémentaires tels que des contrôleurs, des services, etc. Ce qui ressort du bas du compilateur est une application Web entièrement formée, câblée et prête à l'emploi.

Cela signifie que Angular est basé sur les modèles . Votre modèle conduit le JavaScript, pas l'inverse. Il s’agit d’un renversement radical des rôles et de l’inverse total du code JavaScript discret que nous écrivons depuis une dizaine d’années. Cela peut prendre un certain temps pour s'y habituer.

Si cela semble être trop prescriptif et contraignant, rien ne saurait être plus éloigné de la vérité. Comme AngularJS traite votre code HTML en tant que code, vous obtenez une granularité de niveau HTML dans votre application Web . Tout est possible et la plupart des choses sont étonnamment faciles après quelques sauts conceptuels.

Allons droit au but.

D'abord, Angular ne remplace pas jQuery

Angular et jQuery font des choses différentes. AngularJS vous fournit un ensemble d’outils pour la création d’applications Web. jQuery vous donne principalement des outils pour modifier le DOM. Si jQuery est présent sur votre page, AngularJS l'utilisera automatiquement. Si ce n’est pas le cas, AngularJS est livré avec jQuery Lite, une version simplifiée mais parfaitement utilisable de jQuery.

Misko aime jQuery et ne s'oppose pas à ce que vous l'utilisiez. Cependant, vous constaterez au fur et à mesure de l'avancement de votre travail que vous pourrez effectuer la quasi-totalité de votre travail en utilisant une combinaison de portées, modèles et directives, et vous devriez préférer ce flux de travail dans la mesure du possible car votre code sera plus discret, plus configurable et plus Angulaire.

Si vous utilisez jQuery, vous ne devriez pas le répandre partout. L'endroit correct pour la manipulation du DOM dans AngularJS est dans une directive. Plus sur ces derniers plus tard.

JavaScript discret avec sélecteurs et modèles déclaratifs

jQuery est généralement appliqué de manière discrète. Votre code JavaScript est lié dans l'en-tête (ou le pied de page), et c'est le seul endroit où il est mentionné. Nous utilisons des sélecteurs pour sélectionner des éléments de la page et écrire des plugins pour modifier ces éléments.

Le JavaScript est en contrôle. Le HTML a une existence complètement indépendante. Votre code HTML reste sémantique même sans JavaScript. Les attributs Onclick sont une très mauvaise pratique.

L'une des premières choses que vous remarquerez à propos d'AngularJS, c'est que les attributs personnalisés sont partout . Votre code HTML sera jonché d'attributs ng, qui sont essentiellement des attributs onClick sur des stéroïdes. Il s’agit de directives (directives de compilation) et constituent l’un des principaux moyens par lesquels le modèle est lié au modèle.

Lorsque vous verrez ceci pour la première fois, vous pourriez être tenté d’écrire AngularJS comme du code JavaScript intrusif de vieille école (comme je l’ai fait au début). En fait, AngularJS ne respecte pas ces règles. Dans AngularJS, votre HTML5 est un modèle. Il est compilé par AngularJS pour produire votre page Web.

C’est la première grande différence. Pour jQuery, votre page Web est un DOM à manipuler. Pour AngularJS, votre code HTML est le code à compiler. AngularJS lit l'intégralité de votre page Web et la compile littéralement dans une nouvelle page Web à l'aide de son compilateur intégré.

Votre modèle doit être déclaratif. sa signification devrait être claire simplement parEn le lisant. Nous utilisons des attributs personnalisés avec des noms significatifs. Nous créons de nouveaux éléments HTML, toujours avec des noms évocateurs. Un concepteur avec des connaissances minimales en HTML et aucune compétence en matière de codage peut lire votre modèle AngularJS et comprendre ce qu’il fait. Il ou elle peut faire des modifications. C'est la manière angulaire.

Le modèle est dans le siège du conducteur.

Une des premières questions que je me suis posée lors du démarrage d’AngularJS et de la présentation des didacticiels est "Où est mon code?" . Je n'ai pas écrit de JavaScript et pourtant j'ai tout ce comportement. La réponse est évidente. Comme AngularJS compile le DOM, AngularJS traite votre code HTML en tant que code. Dans de nombreux cas simples, il suffit souvent d’écrire un modèle et de le laisser compiler AngularJS dans une application.

Votre modèle pilote votre application. Il est traité comme une DSL . Vous écrivez des composants AngularJS et AngularJS se chargera de les extraire et de les rendre disponibles au bon moment en fonction de la structure de votre modèle. Ceci est très différent d’un MVC standard modèle, où le modèle est juste pour la sortie.

Il ressemble plus à XSLT à Ruby on Rails , par exemple.

Il s’agit d’une inversion radicale du contrôle qui prend un certain temps pour s’y habituer.

Arrêtez d'essayer de piloter votre application à partir de JavaScript. Laissez le modèle piloter l'application et laissez AngularJS s'occuper du câblage des composants entre eux. C’est aussi la voie angulaire.

HTML sémantique vs modèles sémantiques

Avec jQuery, votre page HTML doit contenir un contenu significatif sémantique. Si le JavaScript est désactivé (par un utilisateur ou un moteur de recherche), votre contenu reste accessible.

Car AngularJS traite votre page HTML en tant que modèle. Le modèle n'est pas censé être sémantique, car votre contenu est généralement stocké dans votre modèle, lequel provient en définitive de votre API. AngularJS compile votre DOM avec le modèle pour produire une page Web sémantique.

Votre source HTML n'est plus sémantique, mais votre API et vos DOM compilés sont sémantiques.

Dans AngularJS, la signification réside dans le modèle, le code HTML n’est qu’un modèle, à afficher uniquement.

À ce stade, vous avez probablement toutes sortes de questions concernant le référencement et l'accessibilité, et à juste titre. alors. Il y a des problèmes en suspens ici. La plupart des lecteurs d'écran vont maintenant analyser JavaScript. Les moteurs de recherche peuvent également indexer le contenu du AJAXed . Néanmoins, vous voulez vous assurer que vous utilisez des URL Pushstate et que vous avez un sitemap décent. Voir ici pour une discussion sur le problème: https://stackoverflow.com/a/23245379/687677

Séparation des préoccupations (SOC) et MVC

La séparation des préoccupations (SOC) est un modèle qui s'est développé au fil de nombreuses années de Web développement pour diverses raisons, notamment le référencement, l'accessibilité et l'incompatibilité des navigateurs. Cela ressemble à ceci:

  1. HTML - Signification sémantique. Le HTML devrait être autonome.
  2. CSS - Styling, sans CSS, la page est toujours lisible.
  3. JavaScript - Comportement, sans le script, le contenu reste.

Encore une fois, AngularJS ne respecte pas ses règles. D'un coup, AngularJS supprime une décennie de sagesse reçue et implante plutôt un modèle MVC dans lequel le modèle n'est plus sémantique, pas même un petit peu.

Cela ressemble à ceci:

  1. Modèle - vos modèles contiennent vos données sémantiques. Les modèles sont généralement des objets JSON . Les modèles existent en tant qu'attributs d'un objet appelé $scope. Vous pouvez également stocker des fonctions utilitaires pratiques sur $scope, auxquelles vos modèles peuvent ensuite accéder.
  2. Vue - Vos vues sont écrites en HTML. La vue n’est généralement pas sémantique, car vos données résident dans le modèle.
  3. Contrôleur - Votre contrôleur est une fonction JavaScript qui relie la vue au modèle. Sa fonction est d’initialiser $scope. En fonction de votre application, vous pouvez ou non avoir besoin de créer un contrôleur. Vous pouvez avoir plusieurs contrôleurs sur une page.

MVC et SOC ne se trouvent pas à des extrémités opposées de la même échelle, mais sur des axes complètement différents. Le SOC n’a aucun sens dans un AngularJS context. Vous devez l'oublier et passer à autre chose.

Si, comme moi, vous avez vécu la guerre des navigateurs, cette idée pourrait vous paraître assez choquante. Je vous le promets, ça en vaudra la peine.

Plugins vs. Directives

Les plugins étendent jQuery. Les directives AngularJS étendent les capacités de votre navigateur.

Dans jQuery, nous définissons les plugins en ajoutant des fonctions à jQuery.prototype. Nous les relions ensuite au DOM en sélectionnant des éléments et en appelant le plug-in sur le résultat. L’idée est d’étendre les capacités de jQuery.

Par exemple, si vous souhaitez un carrousel sur votre page, vous pouvez définir une liste non ordonnée de figures, éventuellement encapsulée dans un élément de navigation. Vous pouvez ensuite écrire du jQuery pour sélectionner la liste sur la page et le transformer en galerie avec des délais d’exécution pour l’animation glissante.

Dans AngularJS, nous définissons des directives. Une directive est une fonction qui retourne un objet JSON. Cet objet indique à AngularJS les éléments du DOM à rechercher et les modifications à apporter. Les directives sont connectées au modèle en utilisant des attributs ou des éléments, ce que vous inventez. L'idée est d'étendre les capacités du HTML avec de nouveaux attributs et éléments.

La méthode AngularJS consiste à étendre les fonctionnalités du code HTML d’apparence native. Vous devez écrire du code HTML au format HTML, étendu avec des attributs et des éléments personnalisés.

Si vous voulez un carrousel, utilisez simplement un élément <carousel />, puis définissez une directive pour extraire un modèle et faire fonctionner ce meunier.

Beaucoup de petites directives par rapport aux gros plugins avec des commutateurs de configuration

jQuery a tendance à écrire de très gros plugins comme lightbox que nous configurons ensuite en transmettant de nombreuses valeurs et options.

C’est une erreur dans AngularJS.

Prenons l'exemple d'un menu déroulant. Lors de l'écriture d'un plugin déroulant, vous pourriez être tenté de coder dans les gestionnaires de clics, par exemple une fonction à ajouter dans un chevron qui est soit ascendante ou descendante, peut-être changer la classe de l'élément déplié, afficher masquer le menu, tout ce qui est utile.

Jusqu'à ce que vous souhaitiez apporter une petite modification.

Supposons que vous ayez un menu que vous souhaitez déployer en survol. Eh bien maintenant nous avons un problème. Notre plugin a été câblé dans notre gestionnaire de clics pour nous, nous devrons ajouter une option de configuration pour le faire se comporter différemment dans ce cas spécifique.

Dans AngularJS, nous écrivons des directives plus petites. Notre directive concernant le menu déroulant serait ridiculement petite. Cela pourrait maintenir l'état plié et fournir des méthodes pour fold (), unfold () ou toggle (). Ces méthodes mettraient simplement à jour $scope.menu.visible qui est un booléen détenant l'état.

Maintenant, dans notre modèle , nous pouvons vous connecter ceci:

 
<a ng-click="toggle()">Menu</a>
<ul ng-show="menu.visible">
  ...
</ul>

Besoin de mettre à jour votre souris?

 
<a ng-mouseenter="unfold()" ng-mouseleave="fold()">Menu</a>
<ul ng-show="menu.visible">
  ...
</ul>

Le modèle pilote l'application pour obtenir une granularité de niveau HTML. Si nous voulons créer des exceptions au cas par cas, le modèle facilite les choses.

Fermeture vs $scope

Les plugins JQuery sont créés dans une fermeture. La confidentialité est maintenue dans cette fermeture. C'est à vous de maintenir votre chaîne de portées dans cette fermeture. Vous n'avez réellement accès qu'à l'ensemble des nœuds DOM transmis au plug-in par jQuery, plus les variables locales définies dans la fermeture et les éléments globaux que vous avez définis. Cela signifie que les plugins sont assez autonomes. C'est une bonne chose, mais cela peut devenir restrictif lors de la création d'une application complète. Essayer de transmettre des données entre les sections d’une page dynamique devient une corvée.

AngularJS a des objets $scope. Ce sont des objets spéciaux créés et gérés par AngularJS dans lesquels vous stockez votre modèle. Certaines directives génèrent une nouvelle portée $, qui hérite par défaut de sa portée enveloppante $à l'aide de l'héritage prototypique JavaScript. L’objet $scope est accessible dans le contrôleur et la vue.

C’est la partie intelligente. Étant donné que la structure de l'héritage $scope suit grossièrement la structure du DOM, les éléments ont accès à leur propre portée et à toutes les portées contenant, de manière transparente, jusqu'à la portée globale $(qui n'est pas identique à la portée globale).

Cela facilite beaucoup le transfert des données et leur stockage à un niveau approprié. Si une liste déroulante est dépliée, seule la portée de la liste déroulante $doit en être informée. Si l'utilisateur met à jour ses préférences, vous voudrez peut-être mettre à jour la portée globale $et toutes les étendues imbriquées écoutant les préférences de l'utilisateur seront automatiquement alertées.

Cela peut sembler compliqué, en fait, une fois que vous vous y attardez, c’est comme voler. Vous n'avez pas besoin de créer l'objet $scope, AngularJS l'instancie et le configure pour vous correctement et correctement en fonction de la hiérarchie de vos modèles. AngularJS le met ensuite à la disposition de votre composant en utilisant la magie de l'injection de dépendance (pour plus d'informations à ce sujet plus tard).

Modifications manuelles du DOM par rapport à la liaison de données

Dans jQuery, vous apportez toutes vos modifications DOM à la main.Vous construisez de nouveaux éléments DOM par programmation. Si vous avez un tableau JSON et que vous voulez le placer dans le DOM, vous devez écrire une fonction pour générer le code HTML et l'insérer.

Dans AngularJS, vous pouvez également le faire, mais vous êtes encouragé à utiliser la liaison de données. Modifiez votre modèle. Etant donné que le DOM est lié à celui-ci via un modèle, votre DOM sera automatiquement mis à jour. Aucune intervention requise.

Étant donné que la liaison de données est effectuée à partir du modèle, à l'aide d'un attribut ou de la syntaxe entre accolades, il est extrêmement facile à effectuer. Il y a peu de surcharge cognitive associée à cela, donc vous vous retrouvez à le faire tout le temps.

 
<input ng-model="user.name" />

Lie l'élément d'entrée à $scope.user.name. La mise à jour de l'entrée met à jour la valeur de votre portée actuelle, et inversement.

De même:

 
<p>
  {{user.name}}
</p>

affichera le nom d'utilisateur dans un paragraphe. C'est une liaison active, donc si la valeur $scope.user.name est mise à jour, le modèle sera également mis à jour.

Ajax tout le temps

Dans jQuery, passer un appel en Ajax est assez simple, mais c’est quand même un sujet de réflexion. Il y a la complexité supplémentaire à penser, et une bonne partie du script à maintenir.

Dans AngularJS, Ajax est votre solution par défaut et elle se produit tout le temps, presque sans que vous vous en rendiez compte. Vous pouvez inclure des modèles avec ng-include. Vous pouvez appliquer un modèle avec la directive personnalisée la plus simple. Vous pouvez insérer un appel Ajax dans un service et créer vous-même un service GitHub , ou un Flickr , auquel vous pouvez accéder avec une facilité déconcertante.

Objets de service et fonctions auxiliaires

Dans jQuery, si nous souhaitons accomplir une petite tâche non liée au domaine, telle que l'extraction d'un flux depuis une API, nous pourrions écrire une petite fonction pour le faire lors de notre fermeture. C'est une solution valable, mais que se passe-t-il si nous voulons accéder à ce flux souvent? Et si nous voulons réutiliser ce code dans une autre application?

AngularJS nous donne des objets de service.

Les services sont des objets simples contenant des fonctions et des données. Ce sont toujours des singletons, ce qui signifie qu'il ne peut jamais y en avoir plus d'un. Supposons que nous voulions accéder à l'API Stack Overflow, nous pourrions écrire un StackOverflowService qui définit des méthodes pour le faire.

Disons que nous avons un panier d'achat. Nous pourrions définir un ShoppingCartService qui gère notre panier et contient des méthodes pour ajouter et supprimer des éléments. Étant donné que le service est un singleton et qu'il est partagé par tous les autres composants, tout objet devant le faire peut écrire dans le panier et en extraire des données. C'est toujours le même panier.

Les objets de service sont des composants AngularJS autonomes que nous pouvons utiliser et réutiliser à notre guise. Ce sont de simples objets JSON contenant des fonctions et des données. Ce sont toujours des singletons. Par conséquent, si vous stockez des données sur un service à un endroit, vous pouvez les extraire ailleurs simplement en demandant le même service.

Injection de dépendances (DI) contre Instatiation - aussi appelée dés-spaghettification

AngularJS gère vos dépendances pour vous. Si vous voulez un objet, il suffit de s'y référer et AngularJS l'obtiendra pour vous.

Jusqu'à ce que vous commenciez à utiliser cela, il est difficile d'expliquer à quel point c'est énorme. AngularJS DI n’existe pas dans jQuery.

DI signifie qu'au lieu d'écrire votre application et de la relier, vous définissez une bibliothèque de composants, chacun étant identifié par une chaîne.

Disons que j’ai un composant appelé 'FlickrService' qui définit des méthodes pour extraire les flux JSON à partir de Flickr. Maintenant, si je veux écrire un contrôleur pouvant accéder à Flickr, il me suffit de faire référence au 'FlickrService' par son nom lorsque je déclare le contrôleur. AngularJS se chargera d’instancier le composant et de le mettre à la disposition de mon contrôleur.

Par exemple, je définis ici un service:

 
myApp.service('FlickrService', function() {
  return {
    getFeed: function() { // do something here }
  }
});

Maintenant, quand je veux utiliser ce service, je le désigne simplement par son nom, comme suit:

 
myApp.controller('myController', ['FlickrService', function(FlickrService) {
  FlickrService.getFeed()
}]);

AngularJS reconnaîtra qu’un objet FlickrService est nécessaire pour instancier le contrôleur et nous en fournira un.

Cela facilite grandement le câblage et élimine pratiquement toute tendance à la spagettification. Nous avons une liste plate de composants et AngularJS nous les transmet un par un au fur et à mesure de nos besoins.

Architecture de service modulaire

jQuery explique très peu de choses sur la manière d’organiser votre code. AngularJS a des opinions.

AngularJS vous donne des modules dans lesquels vous pouvez placer votre code. Si vous écrivez un script qui parle par exemple à Flickr, vous pouvez créer un module Flickr dans lequel toutes vos fonctions associées à Flickr seront intégrées. Les modules peuvent inclure d'autres modules (DI). Votre application principale est généralement un module, et cs devrait inclure tous les autres modules dont dépend votre application.

Vous obtenez une simple réutilisation du code. Si vous souhaitez écrire une autre application basée sur Flickr, vous pouvez simplement inclure le module Flickr et le tour est joué, vous avez accès à toutes les fonctions liées à Flickr dans votre nouvelle application.

Les modules contiennent des composants AngularJS. Lorsque nous incluons un module, tous les composants de ce module deviennent disponibles sous la forme d'une simple liste identifiée par leurs chaînes uniques . Nous pouvons ensuite nous injecter ces composants les uns dans les autres en utilisant le mécanisme d’injection de dépendance d’AngularJS.

Pour résumer

AngularJS et jQuery ne sont pas des ennemis. Il est possible d'utiliser jQuery dans AngularJS très bien. Si vous utilisez bien AngularJS (modèles, liaison de données, $scope, directives, etc.), vous constaterez que vous avez besoin d’un lot inférieur à jQuery par rapport à ce que vous auriez sinon besoin.

La principale chose à réaliser est que votre modèle pilote votre application. Arrêtez d'essayer d'écrire de gros plugins qui font tout. Au lieu de cela, écrivez de petites directives qui font une chose, puis écrivez un modèle simple pour les lier ensemble.

Pensez moins à JavaScript discret qu'au lieu de penser à des extensions HTML.

Mon petit livre

AngularJS me passionnait tellement, j’ai écrit un petit livre à ce sujet, que vous pouvez très bien lire en ligne http://nicholasjohnson.com/angular-book/. J'espère que c'est utile.

    
184
2017-05-23 12: 26: 38Z
  1. L'idée que "la séparation des problèmes" est différente de "MVC (modèle, vue, contrôleur)" est totalement fausse. Le modèle en langues Web des préoccupations distinctes (HTML, CSS et JS) le fait en laissant les gens placer des éléments sur une page Web (le balisage /HTML) sans se soucier de son apparence (style /mise en forme /CSS) ni de ce qu'elle "fait" (Événements DOM /AJAX /JavaScript). MVC sépare également les préoccupations. Chaque "couche" du modèle MVC a un rôle distinct: données, routage /logique ou rendu. Les couches sont couplées par des rappels, des itinéraires et des liaisons de modèles. En théorie, une personne peut se spécialiser dans chaque couche, ce qui est souvent le cas.
    2014-09-22 00: 08: 37Z
  2. En tant que personne ayant une formation stricte en SOC et défenseur de longue date des standards Web remontant à la guerre des navigateurs, j'ai initialement trouvé le non-sémantique, non-validant modèles gênants. Je voulais juste préciser que pour écrire Angular, il faut abandonner le SOC tel qu’il est généralement pratiqué. Cela peut être une transition difficile.
    2014-09-22 18: 02: 09Z
  3. Vous avez raison. SOC est un terme large, mais dans le monde du Web, SOC a (ou a éventuellement eu) une signification très spécifique: HTML sémantique, CSS de présentation et JavaScript pour le comportement. Je fais des hypothèses sur mon public qui ne sont peut-être pas raisonnables, alors je devrais m'excuser également.
    2015-01-02 19: 50: 25Z
  4. Je trouve votre réponse très claire et éclairante. Je suis assez novice ici, donc, si j’ai une extension pour changer une page existante (que je ne contrôle pas), devrais-je alors garder JQuery?
    2015-06-24 15: 33: 45Z
  

Pouvez-vous décrire le changement de paradigme nécessaire?

Impératif vs déclaratif

Avec jQuery , vous indiquez au DOM ce qui doit se passer, étape par étape. Avec AngularJS , décrivez les résultats que vous souhaitez, mais comment vous y prendre. il. Pour en savoir plus sur cette cliquez ici . Découvrez également la réponse de Mark Rajcok.

  

Comment puis-je architecturer et concevoir des applications Web côté client différemment?

AngularJS est un framework client complet qui utilise le MVC modèle (consultez leur représentation graphique ). Il met beaucoup l'accent sur la séparation des préoccupations.

  

Quelle est la plus grande différence? Que devrais-je arrêter de faire /utiliser? que dois-je commencer à faire /utiliser à la place?

jQuery est une bibliothèque

AngularJS est un beau framework côté client, hautement testable, qui associe des tonnes de choses intéressantes telles que MVC, injection de dépendance , liaison de données, etc.

Il se concentre sur la la séparation des préoccupations et le test ( tests unitaires et tests de bout en bout), ce qui facilite le développement piloté par les tests.

La meilleure façon de commencer est de leur didacticiel génial . Vous pouvez parcourir les marches en quelques heures. Toutefois, si vous souhaitez maîtriser les concepts en coulisse, ils incluent une multitude de références pour des lectures plus approfondies.

  

Existe-t-il des considérations /restrictions côté serveur?

Vous pouvez l’utiliser sur des applications existantes sur lesquelles vous utilisez déjà jQuery pur. Toutefois, si vous souhaitez tirer pleinement parti des fonctionnalités d'AngularJS, vous pouvez envisager de coder côté serveur à l'aide d'un . Approche RESTful .

Cela vous permettra de tirer parti de leur fabrique de ressources , qui crée un Abstraction de votre RESTful côté serveur RESTful API et effectue des appels côté serveur (obtenir, enregistrer, supprimer, etc.) incroyablement facile.

    
152
2017-05-23 12: 02: 47Z
  1. Je pense que vous êtes en train de brouiller les pistes en expliquant que jQuery est une "bibliothèque" et que Angular est un "framework" ... pour une chose, je pense il est possible de dire que jQuery est un framework ... c'est une abstraction de la manipulation du DOM et de la gestion des événements. Ce n'est peut-être pas un cadre pour le même genre de chose que Angular, mais c'est le dilemme dans lequel se trouve le questionneur: ils ne connaissent pas vraiment la différence entre Angular et jQuery, et pour tout le questionneur le sait, jQuery est un cadre de travail pour la création de sites Web contenant beaucoup de clients. Donc, discuter de la terminologie ne va pas éclaircir les choses.
    2013-07-25 16: 08: 43Z
  2. Je pense que vous êtes celui qui est en train de devenir confus. Cette question concerne précisément cette stackoverflow.com/questions/7062775 . En outre, cette réponse peut aider à clarifier la différence entre un framework et une bibliothèque: stackoverflow.com/a/148759/620448
    2013-07-25 17: 18: 07Z
  3. Une bibliothèque ne devient pas un "framework" simplement parce que sa collection de fonctions est particulièrement utile ou volumineuse. Un cadre prend des décisions pour vous. Lorsque vous commencez à utiliser AngularJS, vous risquez d’y être associé par sa nature. (Ex: vous ne devriez mettre à jour le DOM que dans les directives, sinon quelque chose gâchera.) En effet, AngularJS est un framework. Lorsque vous utilisez jQuery, vous pouvez facilement mélanger et assortir des outils avec un risque minimal de conflit. C’est parce que jQuery est une bibliothèque et une au moins à moitié décente aussi.
    2014-09-22 00: 17: 38Z
  4. Une bibliothèque est le code que vous appelez. Un framework est un code qui appelle votre code. Par cette définition, Angular est un framework. Vous lui fournissez des composants et Angular veille à ce que vos composants soient instanciés avec les dépendances dont ils ont besoin.
    2014-09-29 15: 38: 38Z

Pour décrire le "changement de paradigme", je pense qu'une réponse courte peut suffire.

AngularJS change la manière dont vous trouvez les éléments

.

Dans jQuery , vous utilisez généralement des sélecteurs pour rechercher des éléments, puis les câbler:
$('#id .class').click(doStuff);

Dans AngularJS , vous utilisez des directives pour marquer les éléments directement, pour les câbler:
<a ng-click="doStuff()">

AngularJS n'a pas besoin (ou ne veut pas) que vous trouviez des éléments à l'aide de sélecteurs - la principale différence entre jqLite et tout autre jQuery d'AngularJS est que jqLite ne prend pas en charge les sélecteurs .

Donc, quand les gens disent "n'incluez pas du tout jQuery", c'est principalement parce qu'ils ne veulent pas que vous utilisiez des sélecteurs; ils veulent que vous appreniez à utiliser des directives à la place. Direct, pas sélectionner!

    
84
2014-11-29 08: 46: 50Z
  1. À titre de limitation de responsabilité, il existe BEAUCOUP de différences plus importantes entre Angular et jQuery. Mais la recherche d'éléments est celle qui nécessite le plus grand changement de mentalité.
    2014-02-21 08: 00: 57Z
  2. pardonnez-moi si je me trompe, mais je pensais qu'un sélecteur était ce que vous utilisez pour trouver l'élément DOM? Vous préférez garder en référence chaque partie de votre nouvelle interface utilisateur, plutôt que de simplement sélectionner le ou les éléments sur lesquels un utilisateur peut cliquer, à la volée à l'aide d'un sélecteur? Cela me semble plus difficile.
    2014-05-21 22: 22: 55Z
  3. @ AlexanderPritchard L'intérêt d'Angular est de ne pas sélectionner depuis votre JavaScript, mais directement depuis votre modèle. C'est une inversion de contrôle qui met le pouvoir entre les mains du concepteur. C'est un principe de conception délibéré. Pour vraiment obtenir Angular, vous devez penser à votre code de cette façon. C'est un changement difficile à faire.
    2014-09-23 18: 43: 58Z
  4. @ superluminary Quelle belle citation! "ne sélectionnez pas; direct!" Sérieusement, je vais l'utiliser.
    2014-09-24 18: 47: 49Z
  5. C'est l'une de mes choses préférées sur AngularJS. Je n'ai pas à craindre que l'équipe UX ne casse mes fonctionnalités ou que je ne casse pas leurs styles. Ils utilisent des classes, j'utilise des directives, point. Je ne manque pas un peu de sélecteurs.
    2014-10-07 22: 04: 35Z

jQuery

jQuery rend les commandes JavaScript ridiculement longues comme getElementByHerpDerp plus courtes et multi-navigateurs.

AngularJS

AngularJS vous permet de créer vos propres balises /attributs HTML fonctionnant correctement avec les applications Web dynamiques (car HTML a été conçu pour les pages statiques).

Modifier:

Dire "J'ai un arrière-plan jQuery, comment puis-je penser dans AngularJS?" est comme dire "j'ai un fond HTML comment puis-je penser en JavaScript?" Le fait que vous posiez la question montre que vous ne comprenez probablement pas les objectifs fondamentaux de ces deux ressources. C'est pourquoi j'ai choisi de répondre à la question en soulignant simplement la différence fondamentale au lieu de parcourir la liste en disant "AngularJS utilise des directives alors que jQuery utilise des sélecteurs CSS pour créer un objet jQuery qui fait ceci ou cela, etc.". . Cette question ne nécessite pas de réponse longue.

jQuery est un moyen de faciliter la programmation de JavaScript dans le navigateur. Commandes plus courtes entre navigateurs, etc.

AngularJS étend le code HTML, vous n’avez donc pas besoin de mettre <div> partout pour créer une application. Il fait en sorte que HTML fonctionne réellement pour les applications plutôt que pour ce pour quoi il a été conçu, à savoir des pages Web statiques et éducatives. Il y parvient de manière détournée en utilisant JavaScript, mais il s’agit fondamentalement d’une extension de HTML, et non de JavaScript.

    
69
2015-06-09 02: 08: 25Z
  1. @ Robert dépend de ce que vous faites. $(".myclass") est extrêmement courant, et plus qu'un peu plus facile dans jQuery que PO-Javascript.
    2015-01-02 14: 48: 16Z

jQuery: vous pensez beaucoup à 'interroger le DOM ' pour les éléments DOM et faire quelque chose .

AngularJS: LE modèle est la vérité et vous pensez toujours de cet ANGLE.

Par exemple, lorsque vous obtenez des données provenant du serveur THE que vous souhaitez afficher sous un format quelconque dans le DOM, dans jQuery, vous devez "1. FIND 'où vous voulez placer ces données dans le DOM, le' 2. UPDATE /APPEND 'en y créant un nouveau noeud ou en définissant simplement son innerHTML . Ensuite, lorsque vous souhaitez mettre à jour cette vue, vous passez à «3. TROUVEZ 'l'emplacement et' 4. METTRE À JOUR'. Ce cycle de recherche et de mise à jour s’effectue dans le même contexte d’obtention et de formatage des données du serveur dans AngularJS.

Avec AngularJS, vous avez votre modèle (les objets JavaScript auxquels vous êtes déjà habitué) et la valeur du modèle vous informe sur le modèle (évidemment) et sur la vue. Une opération sur le modèle se propage automatiquement à la vue. vous n'avez pas à y penser. Vous vous retrouverez dans AngularJS qui ne trouve plus rien dans le DOM.

En d'autres termes, dans jQuery, vous devez penser aux sélecteurs CSS, c’est-à-dire où se trouvent les div ou td qui ont une classe ou un attribut, etc., afin que je puisse obtenir leur code HTML, leur couleur ou leur valeur. , mais dans AngularJS, vous vous retrouverez à penser ainsi: à quel modèle ai-je affaire, je vais définir la valeur du modèle sur true. Vous ne vous souciez pas de savoir si la vue reflétant cette valeur est une case à cocher ou réside dans un élément td (détails auxquels vous auriez souvent eu besoin de penser dans jQuery).

Et avec la manipulation DOM dans AngularJS, vous vous retrouvez en train d'ajouter des directives et des filtres, que vous pouvez considérer comme des extensions HTML valides.

Encore une chose que vous allez expérimenter dans AngularJS: dans jQuery, vous appelez beaucoup les fonctions jQuery, dans AngularJS, AngularJS appelle vos fonctions, donc AngularJS "vous explique comment faire", mais les avantages en valent la peine, Par conséquent, apprendre AngularJS signifie généralement apprendre ce que veut AngularJS ou la façon dont AngularJS exige que vous présentiez vos fonctions et il l'appellera en conséquence. C’est l’une des choses qui fait d’AngularJS un framework plutôt qu’une bibliothèque.

    
61
2014-01-15 19: 08: 09Z

Ce sont des réponses très bonnes mais très longues.

Pour résumer mes expériences:

  1. Les contrôleurs et les fournisseurs (services, usines, etc.) servent à modifier le modèle de données, PAS HTML.
  2. HTML et les directives définissent la mise en page et la liaison au modèle.
  3. Si vous devez partager des données entre des contrôleurs, créez un service ou une fabrique. Ce sont des singletons partagés dans l'application.
  4. Si vous avez besoin d'un widget HTML, créez une directive.
  5. Si vous avez des données et essayez maintenant de mettre à jour le code HTML ... STOP! mettez à jour le modèle et assurez-vous que votre code HTML est lié au modèle.
46
2014-08-11 20: 14: 48Z

jQuery est une bibliothèque de manipulation DOM.

AngularJS est un framework MV *.

En fait, AngularJS est l’un des rares frameworks JavaScript MV * (de nombreux outils JavaScript MVC relèvent toujours de la bibliothèque de catégories).

En tant que cadre, il héberge votre code et prend en charge les décisions concernant les appels à effectuer et à quel moment!

AngularJS lui-même inclut une édition jQuery-lite. Donc, pour une sélection /manipulation de base du DOM, vous n’avez vraiment pas besoin d’inclure la bibliothèque jQuery (elle enregistre de nombreux octets à exécuter sur le réseau.)

AngularJS utilise le concept de "directives" pour la manipulation de DOM et la conception de composants d’UI réutilisables. Vous devez donc l’utiliser chaque fois que vous en avez besoin.Les actions ne sont que des endroits où vous devriez écrire du code jQuery lorsque vous utilisez AngularJS).

AngularJS implique une courbe d’apprentissage (plus que jQuery: -).

- > Pour tous les développeurs issus de jQuery, mon premier conseil serait "d'apprendre le JavaScript en tant que langage de première classe avant de sauter dans un cadre riche comme AngularJS!" J'ai appris le fait ci-dessus à la dure.

Bonne chance.

    
45
2014-01-15 19: 11: 39Z

Ce sont des pommes et des oranges. Vous ne voulez pas les comparer. Ce sont deux choses différentes. AngularJs a déjà jQuery lite intégré, ce qui vous permet d’effectuer une manipulation de base du DOM sans même inclure la version complète de jQuery.

jQuery est entièrement consacré à la manipulation du DOM. Cela résout tout le problème des navigateurs, sinon vous devrez vous en occuper, mais ce n’est pas un cadre qui vous permet de diviser votre application en composants comme AngularJS.

L’un des avantages de AngularJs est qu’il vous permet de séparer /isoler la manipulation DOM dans les directives. Il existe des directives intégrées prêtes à être utilisées telles que ng-click. Vous pouvez créer vos propres directives personnalisées qui contiendront toute votre logique de vue ou votre manipulation DOM afin de ne pas mélanger le code de manipulation DOM dans les contrôleurs ou les services devant prendre en charge la logique métier.

Angular décompose votre application en - Contrôleurs - Prestations de service - Vues - etc.

et il y a encore une chose, c'est la directive. C'est un attribut que vous pouvez attacher à n'importe quel élément du DOM et vous pouvez devenir dingue avec jQuery sans craindre que votre jQuery entre en conflit avec les composants AngularJs ou gâche avec son architecture.

J'ai entendu parler d'une réunion à laquelle j'ai assisté. L'un des fondateurs d'Angular a déclaré qu'ils travaillaient très dur pour séparer les manipulations du DOM. N'essayez donc pas de les inclure.

    
34
2013-08-14 14: 19: 07Z

Écoutez le podcast JavaScript Jabber: l'épisode n ° 32 qui contient les Créateurs originaux de AngularJS: Misko Hevery & Igor Minar. Ils discutent beaucoup de ce que signifie faire à AngularJS à partir d’autres arrière-plans JavaScript, notamment jQuery.

Un des points abordés dans le podcast m'a permis de faire beaucoup de choses en ce qui concerne votre question:

  

MISKO : [...] une des choses à laquelle nous avons très peu pensé à Angular est la suivante: comment fournir beaucoup de trappes d'évacuation afin que vous puissiez sortir et trouver un moyen hors de cela. Donc, pour nous, la réponse est cette chose appelée «directives». Et avec les directives, vous devenez essentiellement un petit JavaScript jQuery classique, vous pouvez faire ce que vous voulez.

     

IGOR : Considérez la directive comme une instruction destinée au compilateur indiquant à chaque fois que vous rencontrez cet élément ou ce code CSS dans le modèle, et que vous conservez ce type de code en charge de l'élément et de tout ce qui se trouve en dessous de cet élément dans l'arbre DOM.

Une transcription de l'intégralité de l'épisode est disponible sur le lien indiqué ci-dessus.

Donc, pour répondre directement à votre question: AngularJS est très avisé et constitue un véritable framework MV *. Cependant, vous pouvez toujours faire toutes les choses vraiment cool que vous connaissez et que vous aimez avec jQuery dans les directives. Ce n'est pas une question de "Comment puis-je faire ce que je faisais dans jQuery?" autant que c’est une question de "Comment puis-je compléter AngularJS avec tout ce que je faisais dans jQuery?"

C'est vraiment deux états d'esprit très différents.

    
31
2014-01-15 19: 02: 25Z
  1. Je ne suis pas sûr d’être tout à fait d’accord que Angular est TRES opinionée. Vous voulez un avis, regardez Ember. Je présenterais Angular comme ayant des opinions en points d'arrêtés - pour beaucoup de ce que je vois, jQuery a trop peu d'avis et Ember en a trop. Les angulaires semblent juste comme il faut.
    2014-02-06 18: 41: 34Z

Je trouve cette question intéressante, car ma première sérieuse exposition à la programmation JavaScript était Node.js et AngularJS. Je n'ai jamais appris jQuery, et je suppose que c'est une bonne chose, car je ne dois rien désapprendre. En fait, j’évite activement les solutions jQuery à mes problèmes et cherche uniquement un «moyen AngularJS» pour les résoudre. Donc, je suppose que ma réponse à cette question se résumerait essentiellement à "pense comme quelqu'un qui n’a jamais appris jQuery" et évite toute tentation d’incorporer jQuery directement (évidemment AngularJS l’utilise dans une certaine mesure en coulisse).

    
30
2014-01-15 19: 12: 45Z

AngularJS et jQuery:

AngularJs et JQuery sont complètement différents à tous les niveaux, à l'exception de la fonctionnalité JQLite, et vous le verrez une fois que vous aurez commencé à apprendre les fonctionnalités de base d'AngularJs (je l'ai expliqué ci-dessous).

AngularJs est un framework côté client qui permet de construire l’application côté client indépendante. JQuery est une bibliothèque côté client jouant autour du DOM.

Principe cool d’AngularJs - Si vous souhaitez que des modifications soient apportées à votre interface utilisateur, pensez du point de vue de la modification des données du modèle. Modifiez vos données et l'interface utilisateur se refera. Vous n'avez pas besoin de jouer à DOM chaque fois, à moins que et jusqu'à ce que cela soit à peine requis et que cela soit également géré via des directives angulaires.

Pour répondre à cette question, je souhaite partager mon expérience de la première application d'entreprise avec AngularJS. Ce sont les fonctionnalités les plus impressionnantes fournies par Angular où nous commençons à modifier notre état d’esprit jQuery et où nous obtenons l’Angle comme un framework et non la bibliothèque.

La liaison de données bidirectionnelle est incroyable: J'ai eu une grille avec toutes les fonctionnalités UPDATE, DELTE, INSERT. J'ai un objet de données qui lie le modèle de la grille en utilisant ng-repeat. Il vous suffit d'écrire une seule ligne de code JavaScript simple pour supprimer et insérer, et c'est tout. La grille est automatiquement mise à jour lorsque le modèle de grille change instantanément. La fonctionnalité de mise à jour est en temps réel, pas de code pour cela. Vous vous sentez incroyable !!!

Les directives réutilisables sont super: Écrivez des directives à un endroit et utilisez-les dans toute l'application. OMG!!! J'ai utilisé ces directives pour la pagination, les expressions rationnelles, les validations, etc. C'est vraiment cool!

Le routage est puissant: C’est à votre implémentation de décider comment vous voulez l’utiliser, mais il faut très peu de lignes de code pour acheminer la requête afin de spécifier le code HTML et le contrôleur (JavaScript)

Les contrôleurs sont excellents: Les contrôleurs prennent en charge leur propre code HTML, mais cette séparation fonctionne bien pour les fonctionnalités courantes. Si vous souhaitez appeler la même fonction en cliquant sur un bouton du HTML principal, écrivez simplement le même nom de fonction dans chaque contrôleur et écrivez le code individuel.

Plugins: Il existe de nombreuses autres fonctionnalités similaires, telles que l'affichage d'une superposition dans votre application. Vous n'avez pas besoin d'écrire de code pour cela, utilisez simplement un plugin de superposition disponible en tant que wc-overlay, et cela s'occupera automatiquement de tout XMLHttpRequest (XHR) demandes.

Idéal pour l'architecture RESTful : En tant que framework complet, AngularJS est idéal pour travailler avec une architecture RESTful. Appeler les API REST CRUD est très simple et

Services : écrivez des codes communs à l'aide de services et moins de code dans les contrôleurs. Les services peuvent être utilisés pour partager des fonctionnalités communes entre les contrôleurs.

Extensibilité : Angular a étendu les directives HTML à l'aide de directives angulaires. Ecrivez des expressions en HTML et évaluez-les au moment de l'exécution. Créez vos propres directives et services et utilisez-les dans un autre projet sans aucun effort supplémentaire.

    
23
2015-05-24 02: 56: 31Z

En tant que débutant en JavaScript * et se concentrant uniquement sur l’architecture de l’application (et non sur les aspects serveur /client), je recommanderais certainement la ressource suivante (dont je suis surpris qu’elle n’ait pas encore été mentionnée): "http://addyosmani.com/resources /essentialjsdesignpatterns /book /"> Modèles de conception JavaScript , de Addy Osmani, en guise d’introduction à différents Modèles de conception JavaScript . Les termes utilisés dans cette réponse proviennent du document lié ci-dessus. Je ne vais pas répéter ce qui était vraiment bien formulé dans la réponse acceptée, mais plutôt renvoyer aux arrière-plans théoriques qui alimentent AngularJS (et d'autres bibliothèques).

Comme moi, vous vous rendrez vite compte que AngularJS (ou Ember.js , Durandal, et autres MV * les frameworks d'ailleurs) est un framework complexe assemblant de nombreux modèles de conception JavaScript.

J'ai également trouvé plus facile de tester (1) code JavaScript natif et (2) de plus petites bibliothèques pour chacun de ces modèles séparément avant de plonger dans un cadre global. Cela m'a permis de mieux comprendre les questions cruciales auxquelles un cadre s'adresse (car vous êtes personnellement confronté au problème).

Par exemple:

  • Programmation JavaScript orientée objet (il s'agit d'un lien de recherche Google). Ce n'est pas une bibliothèque, mais certainement une condition préalable à toute programmation d'application. Il m'a appris les implémentations natives du prototype, constructeur, singleton & motifs de décorateur
  • jQuery / Souligner pour le motif de façade (comme WYSIWYG pour manipuler le DOM)
  • Prototype.js pour le modèle prototype /constructeur /mixin
  • RequireJS / Curl.js pour le modèle de module /AMD
  • KnockoutJS pour le modèle de publication /abonnement observable

NB: Cette liste n’est pas complète, ni "les meilleures bibliothèques"; ce sont juste les bibliothèques que j'ai utilisées. Ces bibliothèques incluent également plus de motifs, ceux mentionnés ne sont que leurs objectifs principaux ou leurs intentions originales. Si vous pensez qu'il manque quelque chose dans cette liste, veuillez le mentionner dans les commentaires et je serai heureux de l'ajouter.

    
20
2014-11-29 08: 54: 35Z

En fait, si vous utilisez AngularJS, vous n’avez plus besoin de jQuery. AngularJS lui-même a la liaison et la directive, ce qui est un très bon "remplacement" pour la plupart des choses que vous pouvez faire avec jQuery.

Je développe généralement des applications mobiles utilisant AngularJS et Cordova . La SEULE chose de jQuery dont j'avais besoin est le sélecteur.

En cherchant sur Google, je vois qu’il existe un module de sélecteur jQuery autonome. C'est Sizzle.

Et j’ai décidé de créer un petit extrait de code qui m’aide à démarrer rapidement un site Web avec AngularJS, doté de la puissance de jQuery Selector (avec Sizzle).

J'ai partagé mon code ici: https://github.com/huytd/Sizzular

    
12
2014-11-22 15: 41: 23Z
source placée ici
D\'autres questions