Une brève analyse de la différence entre jQuery et AngularJS

J'ai étudié Angularjs récemment. Le plus grand sentiment est qu'il est complètement différent du précédent jQuery et des divers concepts de conception de bibliothèques basés sur jQuery. Si vous ne pouvez pas vous en rendre compte et avec les programmeurs qui ont déjà développé jQuery, allez apprendre Angularjs. directement si c'est le cas, il est possible qu'après l'avoir étudié pendant longtemps, vous ne sachiez toujours pas à quoi peut servir cette chose, comment l'utiliser, comment la combiner avec l'interface utilisateur, etc. J'ai trouvé un article. à ce sujet sur stackoverflow, et c'était assez enrichissant après l'avoir lu. Sur cette base, traduisez-le en chinois afin que tout le monde puisse en tirer des leçons ensemble.

Question originale : si je suis habitué à utiliser jQuery pour développer des applications client, comment puis-je démarrer avec Angularjs ? Pouvez-vous décrire les changements de paradigme requis ? Les questions suivantes peuvent vous aider à répondre :

1. Quelles sont les différences lors de la conception d'applications Web clientes ?

2. Quelles technologies dois-je arrêter d'utiliser et quelles technologies dois-je utiliser en remplacement ?

3. Y a-t-il des éléments ou des restrictions à prendre en compte du côté du serveur ?

Réponse :

1. Ne concevez pas d'abord votre page, puis ne la modifiez pas via la manipulation du DOM

Dans jQuery, vous concevez d'abord une page, puis modifiez dynamiquement son contenu. En effet, jQuery est conçu pour étendre, augmenter et modifier considérablement le contenu selon ce principe, mais dans angulairejs, vous devez d'abord concevoir votre structure dans votre esprit. ,

Dès le début, vous devez abandonner "J'ai un élément DOM et je veux qu'il fasse quelque chose" et le remplacer par "Quelle tâche dois-je accomplir, puis concevoir votre application, et enfin concevoir votre vue Afficher couche".

2. N'utilisez pas angulairejs pour étendre jQuery

Par conséquent, n'ayez pas l'idée de laisser jQuery faire certaines choses, puis d'ajouter les fonctions d'angularjs pour lui permettre de gérer le modèle et le contrôleur. Par conséquent, je ne recommande généralement pas aux novices en développement AngularJS d'utiliser jQuery en même temps, du moins pas jusqu'à ce qu'ils se soient adaptés au modèle de développement AngularJS. Mais lorsque vous commencerez vraiment à vous adapter à la méthode AngularJS, vous constaterez que c'est très. tentant.

J'ai vu de nombreux développeurs encapsuler des plug-ins jQuery avec 150 à 200 lignes de code à l'aide des rappels angulaires et des méthodes $apply. Cette méthode rend le code extrêmement compliqué, mais en fait, ils laissent ces plug-ins s'exécuter. Le problème est que dans la plupart des cas, les plug-ins jQuery peuvent être réécrits dans angularjs et ne peuvent utiliser qu'une très petite quantité de code. En même temps, cette réécriture rend le code intuitif et facile à comprendre, ce qui est évidemment mieux que de le faire. Code jQuery directement.

Donc au final, lorsque vous rencontrez un problème, vous devez d'abord penser en termes d'angularjs. Si vous ne trouvez pas de solution, vous pouvez demander de l'aide à la communauté. Si personne ne peut vous proposer une solution simple, alors. réfléchissez-y. Utilisez jQuery, ne laissez pas jQuery devenir votre béquille, sinon vous ne maîtriserez jamais AngularJS.

3. Pensez centré sur l'architecture

Tout d'abord, vous devez savoir que les applications monopage sont des applications Web. Ce ne sont pas des sites Web multipages traditionnels, nous devons donc penser en même temps en tant que développeur serveur et client. comment diviser nos applications en parties indépendantes, extensibles et testables.

Alors, comment pouvons-nous utiliser la pensée AngularJS pour travailler ensuite ? Voici quelques directives de base après l'avoir comparé avec jQuery :

Ce qui suit est la couche d'affichage d'une application :

Dans jQuery, nous modifions dynamiquement cette vue. Nous utilisons ul pour définir un menu déroulant

Copier le code Le code est le suivant :

                                                                                                                                    
Dans jQuery, nous utilisons ce menu déroulant en utilisant la logique suivante

Copier le code

Le code est le suivant :

$('.main-menu').dropdownMenu(); Revenons sur cette vue. Vous constaterez que sa fonction n'est pas très simple pour les petites applications, ce n'est pas grave, mais pour les grandes applications, cette approche sera déroutante et difficile à maintenir ; Dans Angularjs, cette vue est en fait une fonction basée sur la vue, nous pouvons définir ul comme ceci

Copier le code

Le code est le suivant :

Les deux méthodes font en fait la même chose, mais dans la méthode AngularJS, quiconque voit ce modèle de vue saura quoi faire ensuite. Chaque fois qu'un nouveau membre rejoint l'équipe de développement, il peut regarder ici et constater qu'il existe une instruction appelée dropdownMenu pour faire fonctionner la vue. Il n'a pas besoin de deviner la bonne réponse ou de revoir un autre code, la vue nous dit directement ce qu'elle fait. , c'est plus simple que jQuery.

Certains débutants d'AngularJS posent souvent cette question : Comment puis-je trouver tous les liens d'un certain type et ajouter une directive basée sur celui-ci, mais lorsque nous répondons "Vous ne devriez pas le faire de cette façon, vous êtes à moitié jQuery, à moitié idée d'AngularJS". ", ils seront surpris. 

Le problème est qu'ils essaient de faire quelque chose avec jQuery dans le contexte d'AngularJS, ce qui n'est généralement pas un bon moyen de le faire. Vous n'avez pas besoin de faire de manipulation DOM en dehors de la directive qui est ajoutée. directement à la vue, donc l'intention est déjà évidente. N'oubliez pas qu'il ne faut pas le concevoir d'abord, puis le modifier, mais avoir d'abord une structure, puis le concevoir dans ce cadre.

Liaison de données

C'est de loin la fonctionnalité la plus accrocheuse d'AngularJS. En termes de liaison de données, elle abandonne le mode de fonctionnement du DOM, et tout cela est fait par AngularJS pour mettre à jour automatiquement la vue. écrivons du code pour faire fonctionner le dom. , dans jQuery, nous répondons souvent aux événements et modifions les vues de la manière suivante :

Copier le code

Le code est le suivant :

$.ajax({ URL : '/myEndpoint.json', Succès : fonction (données, statut) { $('ul#log').append('

Données reçues !

'); > });

Par rapport à une telle vue

Copier le code

Le code est le suivant :

En plus du problème de confusion, nous avons aussi le problème que j'ai évoqué plus tôt sur la façon d'indiquer ses intentions. Mais plus important encore, nous devons référencer et mettre à jour manuellement ce nœud DOM. Si nous voulons supprimer l'un d'entre eux, nous devons faire fonctionner cet élément DOM par programme. Alors, dans ce cas, comment tester le nœud DOM ? voulons-nous changer la méthode d'affichage ?

Le code ci-dessus semble compliqué et fragile, mais dans AngularJS, nous pouvons faire ceci :

Copier le code Le code est le suivant :

$http( '/myEndpoint.json' ).then( function ( réponse ) {

$scope.log.push( { msg : 'Données reçues !' } );

});

Notre vue devrait ressembler à ceci

Copier le code Le code est le suivant :

{{ Entry.msg }}

Dans ce cas, notre point de vue pourrait aussi ressembler à ceci

Copier le code Le code est le suivant :

Maintenant, nous n'utilisons plus ul, mais utilisons la boîte contextuelle de Bootstrap, mais nous n'avons pas besoin de modifier le code dans le contrôleur. Plus important encore, quelle que soit la façon dont les données sont modifiées, la couche de vue changera automatiquement. donc, ce qui est très simple !

Bien que je ne fasse pas de démonstration ici, vous devez savoir que la liaison de données est bidirectionnelle, vous pouvez modifier les données en ajoutant la directive , et il y a bien d'autres endroits passionnants.

Couche de modèle de différence

Dans jQuery, DOM est similaire à un modèle, mais dans AngularJS, nous avons une couche de modèle différente de celle de jQuery afin que nous puissions la gérer comme nous le souhaitons. Cette approche nous aide à effectuer la liaison des données et à maintenir la séparation des préoccupations, et permet une meilleure testabilité.

Séparation des préoccupations

Tout ce qui précède est lié à ce sujet général : concentrez-vous sur la séparation, votre couche de vue affiche les enregistrements, votre couche de modèle représente les données et vous disposez d'une couche de service pour effectuer ces tâches réutilisables. Vous utilisez des directives pour effectuer des opérations DOM, étendre votre vue et la connecter au contrôleur, c'est pourquoi j'ai mentionné ailleurs sur l'amélioration de la testabilité.

Injection de dépendances

Ce qui nous aide à résoudre la séparation des problèmes, c'est l'injection de dépendances (DI). Si vous êtes un développeur côté serveur (Java ou PHP), vous connaissez peut-être déjà ce concept, mais si vous êtes engagé dans le côté client. développement, on pourrait penser que ce concept est peut-être un peu redondant et purement à la mode, mais en fait ce n'est pas le cas.

D'un point de vue général, DI signifie que vous pouvez librement déclarer des composants, puis instancier à partir de ces composants, ce qui est une évidence. Vous n'avez pas besoin de connaître l'ordre de chargement, l'emplacement des fichiers, ce genre de choses, la magie n'est pas immédiatement apparente, mais je vais donner un exemple : les tests.

Nous avons dit que dans l'application, nous avons besoin d'un service qui s'appuie sur l'état de l'application et le stockage local pour effectuer le stockage côté serveur via une API de repos. Lorsque nous testons notre contrôleur, nous n'avons pas besoin de communiquer avec le serveur, après. tout simplement tester le contrôleur. Nous ajoutons simplement un service fictif identique à notre composant d'origine. L'injecteur garantit que notre contrôleur obtient un service factice. Le contrôleur lui-même n'a pas besoin de connaître la différence.

Parlons des tests.

4. Développement piloté par les tests

Cette partie est la troisième partie de l'architecture, mais elle est tellement importante que je dois la mettre à la position la plus importante.

Parmi tous les plugins jQuery que nous avons vus, utilisés et écrits, combien ont un composant de test ? En fait, il n'y en a pas beaucoup car jQuery n'est pas facile à contrôler pendant les tests, mais AngularJS est différent de cela.

Dans jQuery, la seule façon de tester est d'utiliser une page de démonstration pour créer un composant indépendant afin que notre test puisse effectuer des opérations DOM. Ensuite, nous devons développer un composant séparé et l'intégrer dans notre application. Comme c'est gênant ! Dans de nombreux cas, lorsque nous utilisons jQuery pour développer, nous effectuons en réalité beaucoup de développements répétitifs plutôt que de développement piloté par les tests. Pouvez-vous nous en vouloir ?

Mais dans AngularJS, nous pouvons nous concentrer sur les points de séparation, afin de pouvoir effectuer du développement piloté par les tests. Par exemple, nous avons une directive pour décrire notre chemin actuel dans le menu. Nous pouvons le déclarer dans la vue comme ceci :
.

Copier le code Le code est le suivant :

Bonjour

D'accord, maintenant nous pouvons écrire un test pour tester cette instruction inexistante lorsqu'elle est active

Copier le code Le code est le suivant :

it( 'devrait ajouter "actif" lorsque l'itinéraire change', inject(function() {
var elm = $compile( 'Bonjour' )( $scope );

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

$location.path( '/bonjour' );
Attendez-vous( elm.hasClass('active') ).toBeTruthy();
}));

Nous exécutons le scénario de test directement, et vous constaterez qu'il échoue. À ce stade, vous devez créer cette commande, comme suit :

Copier le code Le code est le suivant :

.directive( 'whenActive', fonction ( $location ) {

Retour {

portée : vrai,

lien : fonction (portée, élément, attrs) {

               scope.$on( '$routeChangeSuccess', function () {

Si ( $location.path() == element.attr( 'href' ) ) {

                      element.addClass( 'active' );

                }

                   autre {

                         element.removeClass( 'active' );

                }

            });

>

};

});

Exécutez à nouveau ce cas de test, vous constaterez qu'il a réussi et le menu s'affiche comme demandé. Notre développement est à la fois itératif et testable, ce qui est très cool !

5. Conceptuellement, les directives ne sont pas empaquetées avec jQuery

Vous entendez souvent dire que les opérations DOM ne peuvent être effectuées que dans des instructions. C'est un must et vous devez le prendre au sérieux.

Plongeons-nous,

Certaines directives décorent simplement nos vues (comme ngClass), donc parfois il est acceptable de manipuler directement le dom, mais lorsqu'une directive est similaire à un widget et a son propre modèle, alors elle doit être traitée comme une préoccupation distincte Point, cela signifie que son modèle doit être séparé de la logique d'exécution dans le lien et des autres fonctions du contrôleur.

AngularJS dispose d'un ensemble complet d'outils qui peuvent faciliter cette séparation. En utilisant la directive ngClass, nous pouvons mettre à jour dynamiquement les classes, en utilisant ngBind, nous pouvons effectuer une liaison de données bidirectionnelle, et en utilisant ngShow et ngHide, nous

Vous pouvez afficher et masquer un élément par programmation, y compris de nombreuses instructions que nous avons écrites nous-mêmes. En d'autres termes, nous pouvons effectuer tout le travail sans opérations DOM. Moins il y a d'opérations DOM, plus il est facile de tester les instructions, plus il est facile de spécifier leurs attributs de style, plus il est facile de les modifier à l'avenir, et plus ils sont plus faciles à réutiliser et à distribuer.

J'ai vu de nombreux débutants d'AngularJS utiliser des directives pour encapsuler une grande séquence de code jQuery. En d'autres termes, comme je ne peux pas effectuer d'opérations dom dans le contrôleur, je peux le mettre dans la directive, bien que ce soit bien mieux que. exploitant directement le dom, mais toujours faux.

Regardez notre record ci-dessus, même si nous le mettons dans une directive, nous devons quand même le faire fonctionner de manière angulaire, qui n'effectue pas d'opérations dom ! Il arrive souvent que la manipulation du DOM soit nécessaire, mais cette situation est beaucoup plus rare que vous ne le pensez. Lorsque nous devons effectuer des opérations DOM, nous nous demandons d'abord si nous devons le faire ici. C'est une meilleure façon.

Ce qui suit est un exemple simple pour illustrer un modèle que je vois souvent, où nous avons besoin d'un bouton bascule :

Copier le code Le code est le suivant :

.directive( 'maDirective', function() {
Retour {
Modèle : 'Basculez-moi !',
lien : fonction (portée, élément, attrs) {
var on = false;

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

Dans l'exemple ci-dessus, il y a l'erreur suivante :

1. Tout d'abord, jQuery n'est pas nécessaire, jQuery n'est pas du tout nécessaire pour fonctionner ici !

2. Deuxièmement, même si nous avons introduit jQuery dans la page, mais que nous n'avons aucune raison de l'utiliser, nous pouvons utiliser angulaire.element et nos composants pourront s'exécuter, même si jQuery n'est pas introduit dans ce projet. .

3. Troisièmement, en supposant que jquery soit nécessaire dans nos instructions, nous pouvons utiliser jqLite pour le remplacer.

4. Quatrièmement, et étroitement lié au troisième point, les éléments jqLite n'ont pas besoin d'être enveloppés avec $. L'élément element transmis à la fonction de lien est déjà un objet jQuery ;

5. Cinquièmement, comme nous l'avons déjà dit, pourquoi ne pas mélanger nos modèles et notre logique

La commande ci-dessus peut être réécrite comme suit, la rendant si simple même dans les cas les plus complexes.

Copier le code Le code est le suivant :

.directive( 'maDirective', function() {

Retour {
portée : vrai,
Modèle : 'Basculez-moi !',
lien : fonction (portée, élément, attrs) {
scope.on = false;

scope.toggle = fonction () {
scope.on = !scope.on;
};
>
};
});

L'élément template est dans l'attribut template, vous pouvez facilement remplacer son style, et la logique n'a pas besoin de changer du tout, permettant une réutilisation complète !

Il existe d'autres avantages, tels que la facilité de test et l'API de commande ne changera pas, quel que soit le contenu du modèle, il est donc facile de le refactoriser. Vous pouvez modifier votre modèle autant de fois que vous le souhaitez sans modifier les instructions, et peu importe la manière dont vous le modifiez, vos tests réussiront toujours !

L'instruction n'est donc pas une collection de codes jQuery, tels que des fonctions, etc., mais une extension du code HTML. Si le code HTML ne peut pas réaliser la fonction dont vous avez besoin, vous pouvez écrire une instruction pour l'implémenter, et. puis utilisez-le comme HTML. Utilisez-le.

En d'autres termes, si AngularJS ne fait pas de choses supplémentaires, réfléchissez à la façon dont nous pouvons utiliser les instructions ngClick et ngClass ?

Résumé

N'utilisez pas toujours jquery, n'y faites même pas référence, cela vous arrêtera net lorsque nous reviendrons sur le problème - vous savez comment vous résolvez le problème dans AngularJS à la manière de jquery, mais lorsque vous utilisez des sélecteurs comme $ etc., vous devez réfléchir à la façon dont ils emprisonnent réellement AngularJS. Si vous ne savez pas comment l'implémenter sans jQuery, demandez aux autres et demandez encore et encore. La meilleure façon est de ne pas utiliser jQuery. ne fera qu'augmenter votre travail.