"Penser à AngularJS" si j'ai un fond jQuery?
Supposons que je connaisse 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 devrais-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.
1. Ne concevez pas votre page, puis modifiez-la avec DOM manipulations
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. C'est vraiment tentant lorsque 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 s'y seront pas habitués. les choses de la "voie angulaire".
J'ai vu de nombreux 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 de $applys confus et compliqués; mais ils finissent par le faire fonctionner! Le problème est que dans la plupart des cas où le plugin jQuery pouvait être réécrit dans AngularJS en une fraction du code, où tout devient soudain compréhensible et simple.
La ligne du bas 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 facile, alors n’hésitez pas à utiliser le 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 applications d'une seule page sont des applications . Ce sont pas 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, contrastés avec jQuery.
La vue est le "record officiel"
Dans jQuery, nous changeons la vue par programme. Nous pourrions avoir un menu déroulant défini comme un ul comme ceci:
<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 l'enregistrement 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, quiconque regarde 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 ceci 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 document officiel. En dehors d'une directive (plus de détails ci-dessous), vous ne changez jamais jamais le DOM. Et les directives sont appliquées dans la vue , l'intention est donc claire.
Rappelez-vous: ne concevez pas, puis annotez. Vous devez architecte, 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 le genre de manipulations DOM que j’ai mentionnées 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 qui ressemble à 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 que j'ai 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 on voulait changer la 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 à cet égard, 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 les zones d'alerte Bootstrap. Et nous n'avons jamais eu à changer le code du contrôleur! Mais plus important encore, peu importe où ou comment le journal est mis à jour, la vue changera également. Automatiquement. Soigné!
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 comme suit: <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 séparation des problèmes et introduit une testabilité beaucoup plus grande. D'autres réponses ont mentionné ce point, alors je vais en rester là.
Séparation des préoccupations
Et tout ce qui précède est lié à ce thème primordial: 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 discute dans une autre section ci-dessous.
Injection de dépendance
Pour nous aider avec la séparation des préoccupations est injection de dépendance (DI). Si vous venez d'un langage côté serveur (de Java à PHP ), vous connaissez probablement déjà ce concept, mais si vous êtes client mec venant de jQuery, ce concept peut sembler quelque chose 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 (commun): les tests.
Supposons que dans notre application, nous avons besoin d'un service qui implémente le stockage côté serveur via une API REST et, en fonction de l'état de l'application, un stockage local. 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 fictif du même nom que notre composant d'origine et l'injecteur veillera à ce que notre contrôleur obtienne automatiquement le faux - notre contrôleur ignore et n'a pas besoin de connaître 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 considère comme sa propre section de niveau supérieur.
Parmi tous les nombreux plugins 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 à l'aide duquel 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 préoccupations, 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 la vue de notre application:
<a href="/hello" when-active>Hello</a>
Bon, maintenant nous pouvons écrire un test pour la directive inexistante when-active:
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. Seulement maintenant devrions-nous 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 passe maintenant et notre menu fonctionne comme demandé. Notre développement est à la fois itératif et piloté par des tests. Méchant-cool.
5. Conceptuellement, les directives sont pas empaquetées jQuery
Vous entendrez souvent "ne manipuler le DOM que dans une directive". C'est une nécessité. Traitez-le avec déférence!
Mais plongons un peu plus loin ...
Certaines directives ne font que décorer ce qui est déjà dans la vue (think 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. En d'autres termes, 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 par programme un élément; et beaucoup d'autres, y compris ceux que nous écrivons nous-mêmes. En d'autres termes, nous pouvons faire toutes sortes de génies sans manipulation du DOM. Moins il y a de manipulations dans le DOM, plus les directives sont faciles à tester, plus elles sont faciles à styler, 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 beaucoup 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, c'est souvent toujours faux .
Pensez à l'enregistreur que nous avons programmé à la section 3. Même si nous le mettons dans une directive, nous continuons à vouloir 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 qui montre le motif que je vois le plus souvent. Nous voulons un bouton basculable. (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:
- Tout d'abord, jQuery n'a jamais été nécessaire. Nous n'avons rien fait ici qui ait besoin de jQuery!
- Deuxièmement, même si jQuery est déjà sur notre page, il n’ya aucune raison de l’utiliser ici; nous pouvons simplement utiliser
angular.elementet notre composant fonctionnera quand on le déposera dans un projet sans jQuery. - Troisièmement, même en supposant que jQuery était requis pour que cette directive fonctionne, jqLite (
angular.element) utilisera toujours si jQuery c'était chargé! Donc, nous n'avons pas besoin d'utiliser le$- nous pouvons simplement utiliserangular.element. - La quatrième, étroitement liée à la troisième, est que les éléments jqLite ne doivent pas nécessairement être encapsulés dans
$- laelementqui est déjà transmise à la fonctionlinkêtre un élément jQuery! - Cinquièmement, et que nous 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 contenu du modèle est dans le modèle, de sorte que vous (ou vos utilisateurs) pouvez facilement l’échanger contre un modèle qui correspond à n’importe quel style, et la logique n'a jamais dû être touché. 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’extérieur, imaginez comment l’équipe pourrait le faire pour s’intégrer parfaitement à ngClick, ngClass, et al.
Sommaire
N'utilisez même pas jQuery. Ne l'incluez même pas. Cela vous retiendra. Et quand 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 d’AngularJS. Si vous ne savez pas, demandez! 19 fois sur 20, la meilleure façon de le faire n'a pas besoin de jQuery et essayer de le résoudre avec des résultats jQuery demande plus de travail.
Impératif → déclaratif
Dans jQuery, les sélecteurs sont utilisés pour rechercher les éléments DOM , puis lier/enregistrer les gestionnaires d'événements correspondants. Lorsqu'un événement se déclenche, ce code (impératif) s'exécute pour mettre à jour/modifier le DOM.
Dans AngularJS, vous voulez 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 à 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 d'étendue) 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 l’utilisateur voit.
Séparation des préoccupations
jQuery utilise le comportement JavaScript discret - le comportement (JavaScript) est séparé de la structure (HTML).
AngularJS utilise des contrôleurs et des directives (chacun pouvant avoir son propre contrôleur et/ou des fonctions de compilation et de liaison) pour supprimer le comportement de la vue/structure ( HTML). Angular possède également des services et filtres pour vous aider séparer/organiser votre application.
Voir aussi https://stackoverflow.com/a/14346528/215945
Conception de l'application
Une approche pour concevoir une application AngularJS:
- Pensez à vos modèles. Créez des services ou vos propres objets JavaScript pour ces modèles.
- Réfléchissez à la manière dont vous souhaitez présenter vos modèles - vos points de vue. Créez des modèles HTML pour chaque vue, en utilisant les directives nécessaires pour obtenir une liaison de données dynamique.
- 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. Rendre 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 prototypal 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 de l'héritage prototypique/prototypique dans AngularJS?
AngularJS contre 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 en 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 à donner au compilateur. En traversant le DOM, il recherche des directives spécifiques (directives du compilateur) 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 Angular 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, l’étendue $ actuelle (qui est un magasin de variables locales), et quelques autres 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 il convient de le redessiner.
Les directives peuvent alors extraire à leur tour des composants Angular tels que des contrôleurs, des services, etc. Le compilateur génère une application Web entièrement formée, 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 pourrait ê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 au fond des choses.
Tout 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 saupoudrer de partout. L'endroit correct pour la manipulation du DOM dans AngularJS est dans une directive. Plus sur ces plus tard.
JavaScript discret avec sélecteurs et modèles déclaratifs
jQuery est généralement appliqué discrètement. 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 HTML reste sémantique même sans JavaScript. Les attributs Onclick sont une très mauvaise pratique.
Une des premières choses que vous remarquerez à propos de AngularJS 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. Ce sont des 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 votre page Web entière 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 en 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. Ceci est le chemin Angular.
Le modèle est dans le siège de conduite.
Une des premières questions que je me suis posée lors du démarrage d’AngularJS et de l’exécution 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. C'est traité comme un 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 modèle MVC standard, où le modèle est uniquement destiné à la sortie.
Cela ressemble plus à XSLT à Ruby on Rails par exemple.
Il s’agit d’une inversion radicale du contrôle à laquelle il faut s’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 le chemin Angular.
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.
Parce qu'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 vos API et DOM compilés sont sémantiques.
Dans AngularJS, la signification réside dans le modèle, le HTML n'est qu'un modèle, à afficher uniquement.
À ce stade, vous avez probablement toutes sortes de questions concernant SEO et l'accessibilité, et à juste titre. 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 AJAXed contenu. 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 de la question: https://stackoverflow.com/a/23245379/687677
Séparation des préoccupations (SOC) vs MVC
Séparation des préoccupations (SOC) est un modèle qui s'est développé au cours de nombreuses années de développement Web pour diverses raisons, notamment le référencement, l'accessibilité et l'incompatibilité des navigateurs. Cela ressemble à ceci:
- HTML - Sens sémantique. Le HTML devrait être autonome.
- CSS - Styling, sans CSS, la page est toujours lisible.
- JavaScript - Comportement, sans le script, le contenu reste.
Encore une fois, AngularJS ne respecte pas ses règles. Dans un trait, AngularJS supprime une décennie de sagesse reçue et implémente plutôt un modèle MVC dans lequel le modèle n'est plus sémantique, pas même un peu bit.
Cela ressemble à ceci:
- 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.
- 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.
- 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 contexte AngularJS. 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. Remets-toi dessus, ça en vaudra la peine, je te le promets.
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'attente pour faire de 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, 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 faites en sorte que ce ventouse fonctionne.
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 vouliez faire un petit changement.
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 particulier.
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 câbler ceci:
<a ng-click="toggle()">Menu</a>
<ul ng-show="menu.visible">
...
</ul>
Besoin de mettre à jour sur mouseover?
<a ng-mouseenter="unfold()" ng-mouseleave="fold()">Menu</a>
<ul ng-show="menu.visible">
...
</ul>
Le modèle pilote l'application, nous obtenons donc une granularité au niveau HTML. Si nous voulons créer des exceptions au cas par cas, le modèle facilite les choses.
Fermeture vs portée
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. Parce 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 diffère de 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 souhaiterez peut-être mettre à jour la portée globale $, et toute portée imbriquée écoutant les préférences de l'utilisateur sera automatiquement alertée.
Cela peut sembler compliqué, en fait, une fois que vous vous y êtes assis, 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 le faire aussi, 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.
Comme 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 à faire. Il y a peu de surcharge cognitive associée, 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 mettra à jour la valeur de votre portée actuelle, et inversement.
Également:
<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 vous pouvez y réfléchir à deux fois. Il y a une complexité supplémentaire à prendre en compte et une bonne partie du script à gérer.
Dans AngularJS, Ajax est votre solution de référence par défaut et cela 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 intégrer un appel Ajax dans un service et créer vous-même un service GitHub , ou un service Flickr , auquel vous pouvez accéder avec une facilité étonnante.
Objets de service vs 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? Que faire 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épendance (DI) vs Instatiation - aussi connue sous le nom de 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.
Supposons que je possède un composant appelé 'FlickrService' qui définit des méthodes d'extraction des 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, ici je définis 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 ne dit pas grand chose sur la manière dont vous devriez 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, qui doit inclure tous les autres modules dont dépend votre application.
Vous obtenez une simple réutilisation du code. Si vous voulez é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 vos 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 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 à vous pourriez autrement avoir 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 relier ensemble.
Réfléchissez moins au JavaScript non intrusif, mais pensez plutôt aux extensions HTML.
Mon petit livre
AngularJS me passionnait tellement que j’ai écrit un petit livre que vous pouvez lire en ligne http://nicholasjohnson.com/angular-book/ . J'espère que c'est utile.
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, vous décrivez les résultats que vous souhaitez, mais pas comment vous y prendre. Plus sur ceci ici . Consultez également la réponse de Mark Rajcok.
Comment puis-je concevoir et concevoir différemment les applications Web côté client?
AngularJS est un framework client complet qui utilise le modèle MVC (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 combine des tonnes de trucs sympas comme MVC, injection de dépendance , liaison de données et beaucoup plus.
Il met l'accent sur séparation des préoccupations et sur les tests ( tests unitaires et sur les tests de bout en bout), ce qui facilite le développement piloté par les tests.
La meilleure façon de commencer est de passer 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 une lecture plus approfondie.
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'une approche RESTful .
Cela vous permettra de tirer parti de leur fabrique de ressources , ce qui crée une abstraction de votre serveur RESTful API et effectue des appels côté serveur (obtenir, enregistrer, supprimer, etc.) incroyablement facile.
Pour décrire le "changement de paradigme", je pense qu'une réponse courte peut suffire.
AngularJS change la façon dont vous trouvez des éléments
Dans jQuery, vous utilisez généralement sélecteurs pour rechercher des éléments, puis les câbler:$('#id .class').click(doStuff);
Dans AngularJS, vous utilisez directives pour marquer les éléments directement, pour les relier:<a ng-click="doStuff()">
AngularJS n'a pas besoin (ou veut) que vous trouviez des éléments à l'aide de sélecteurs - la principale différence entre les jqLite d'AngularJS et la version complète jQuery est que jqLite ne le fait pas sélecteurs de support .
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!
jQuery
jQuery fait des commandes JavaScript ridiculement longues telles que getElementByHerpDerp plus courte et multi-navigateur.
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 n'exige pas une réponse longue.
jQuery est un moyen de faciliter la programmation de JavaScript dans le navigateur. Commandes plus courtes, multi-navigateurs, etc.
AngularJS étend HTML, de sorte que vous n'avez pas besoin de mettre <div> partout pour créer une application. Il permet au HTML de fonctionner 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 à l'aide de JavaScript, mais il s'agit fondamentalement d'une extension de HTML, et non de JavaScript.
jQuery: vous pensez beaucoup à 'QUERYing the 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 du serveur 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 créant un nouveau nœud ou en définissant simplement son innerHTML . Ensuite, lorsque vous souhaitez mettre à jour cette vue, vous passez à "3. TROUVEZ 'l'emplacement et' 4. MISE À JOUR'. Ce cycle de recherche et de mise à jour est effectué 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 renseigne sur le modèle (évidemment) et sur la vue, et une opération sur le modèle se propage automatiquement à la vue. Je n'ai pas à y penser. Vous vous retrouverez dans AngularJS ne trouvant plus rien dans les DOM.
En d’autres termes, dans jQuery, vous devez penser aux sélecteurs CSS, c’est-à-dire où se trouve la div ou td qui a une classe ou un attribut, etc., afin que je puisse obtenir leur HTML ou couleur ou valeur, mais dans AngularJS, vous vous retrouverez à penser comme ceci: quel modèle suis-je en train de traiter? 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.
Une dernière chose que vous allez expérimenter dans AngularJS: dans jQuery, vous appelez souvent les fonctions jQuery, dans AngularJS, AngularJS appelle vos fonctions, de sorte qu'AngularJS "vous explique comment faire les choses", mais que les avantages en valent la peine, donc 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.
Ce sont des réponses très gentilles mais longues.
Pour résumer mes expériences:
- Les contrôleurs et les fournisseurs (services, usines, etc.) servent à modifier le modèle de données, PAS HTML.
- HTML et les directives définissent la mise en page et la liaison au modèle.
- Si vous devez partager des données entre contrôleurs, créez un service ou une fabrique. Ce sont des singletons partagés dans l'application.
- Si vous avez besoin d'un widget HTML, créez une directive.
- Si vous avez des données et essayez maintenant de mettre à jour le HTML ... STOP! Mettez à jour le modèle et assurez-vous que votre code HTML est lié au modèle.
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 framework, il héberge votre code et prend en charge les décisions concernant ce qu'il doit appeler et quand!
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 (cela enregistre beaucoup d'octets à exécuter sur le réseau.)
AngularJS a le concept de "Directives" pour la manipulation du DOM et la conception de composants d'interface utilisateur réutilisables. Vous devez donc l'utiliser dès que vous sentez le besoin de faire des choses liées à la manipulation du DOM (les directives ne sont qu'un endroit 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.
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 tels que AngularJS.
Une bonne chose à propos 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 - Services - 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 ne s'embrouille avec son architecture.
Lors d'une réunion à laquelle j'ai assisté, l'un des fondateurs de Angular a déclaré qu'ils travaillaient très dur pour séparer les manipulations du DOM, donc n'essayez pas de les réintégrer.
Écoutez le podcast JavaScript Jabber: Épisode n ° 32 qui présente les créateurs d’AngularJS: Misko Hevery & Igor Minar. Ils parlent beaucoup de ce que c'est que de venir chez AngularJS depuis d'autres arrière-plans JavaScript, notamment jQuery.
Un des points abordés dans le podcast a fait beaucoup de choses pour moi en ce qui concerne votre question:
MISKO: [...] une des choses à laquelle nous pensions très difficilement dans Angular est, comment fournissons-nous beaucoup de trappes d'évacuation afin que vous puissiez sortir et trouver un moyen de sortir 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 donc la directive comme une instruction destinée au compilateur indiquant chaque fois que vous rencontrez cet élément en particulier ou ce code CSS dans le modèle, et vous conservez ce type de code et ce code est responsable de l'élément et de tout ce qui se trouve sous cet élément dans l'arborescence DOM.
Une transcription de l'intégralité de l'épisode est disponible sur le lien fourni 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?" "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.
Je trouve cette question intéressante, car ma première exposition sérieuse à 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, mais 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 coulisses).
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 permettant de construire l’application indépendante côté client. JQuery est une bibliothèque côté client qui tourne autour du DOM.
Principe AngularJs Cool - Si vous souhaitez modifier l’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 sauf si et jusqu'à ce que cela soit à peine requis et que cela soit également géré par le biais de Angular Directives.
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 que Angular fournit où nous commençons à changer notre état d'esprit jQuery et nous obtenons le Angular comme un framework et non la bibliothèque.
La liaison de données bidirectionnelle est incroyable: J'avais 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 les directives à un endroit et utilisez-les dans toute l'application. OMG!!! J'ai utilisé cette directive pour la pagination, les expressions rationnelles, les validations, etc. C'est vraiment cool!
Le routage est puissant: Le choix de votre utilisation dépend de votre implémentation, mais il ne nécessite que très peu de lignes de code pour acheminer la requête en spécifiant HTML et contrôleur (JavaScript)
Les contrôleurs sont géniaux: 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 maître, il vous suffit d'écrire le même nom de fonction dans chaque contrôleur et d'écrire un 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 se chargera automatiquement de toutes les demandes XMLHttpRequest (XHR).
Idéal pour RESTful architecture: En tant que framework complet, AngularJS permet de travailler avec une architecture RESTful. Pour appeler REST _ Les API CRUD est très simple et
Services : écrivez des codes communs en utilisant des 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 angular directives. 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.
En tant que débutant en JavaScript * et en se concentrant uniquement sur l’architecture de l’application (pas sur le serveur/le client), je recommanderais certainement la ressource suivante (dont je suis surpris qu’elle n’ait pas encore été mentionnée): Modèles de conception JavaScript , par Addy Osmani, en guise d’introduction aux différents modèles de conception JavaScript . Les termes utilisés dans cette réponse sont tirés du document lié ci-dessus. Je ne vais pas répéter ce qui a été très bien formulé dans la réponse acceptée. Au lieu de cela, cette réponse renvoie aux arrière-plans théoriques qui alimentent AngularJS (et d'autres bibliothèques).
Comme moi, vous vous rendrez vite compte qu'AngularJS (ou Ember.js , Durandal, et autres frameworks MV *) est un framework complexe assemblant de nombreux modèles de conception JavaScript.
J'ai également trouvé plus facile de tester le code JavaScript natif (1) 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 quelles questions cruciales un cadre aborde (parce que 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 des motifs , constructeur, singleton et décorateur
- jQuery / nderscore pour le motif de façade (comme WYSIWYG pour la manipulation du DOM)
- Prototype.js pour le motif prototype/constructeur/mixin
- RequireJS / Curl.js pour le modèle de module /AMD
- KnockoutJS pour le observable, modèle de publication/abonnement
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 ravi de l'ajouter.
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 googlant, je constate qu’il existe un module de sélecteur jQuery autonome. C'est Sizzle.
Et j'ai décidé de créer un petit fragment de code qui m'aide à démarrer rapidement un site Web en utilisant AngularJS avec la puissance de jQuery Selector (à l'aide de Sizzle).
J'ai partagé mon code ici: https://github.com/huytd/Sizzular