utilité - jquery vs javascript




“Penser à AngularJS” si j'ai un fond jQuery? (10)

Supposons que je connaisse le développement d'applications côté client dans jQuery , mais j'aimerais maintenant 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 .


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 quels résultats vous voulez, mais pas comment vous y prendre. Plus à ce sujet here . Consultez é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 complet côté client 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 choses intéressantes telles que le MVC, l’ injection de dépendances , la liaison de données, etc.

Il se concentre sur la séparation des problèmes et des tests (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 suivre leur formidable tutoriel . Vous pouvez parcourir les marches en quelques heures. Toutefois, si vous souhaitez maîtriser les concepts en coulisse, ils incluent une myriade 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 d'exploiter leur fabrique de ressources , ce qui crée une abstraction de votre API RESTful côté serveur et facilite les appels côté serveur (obtenir, enregistrer, supprimer, etc.).


1. Ne concevez pas votre page, puis modifiez-la avec DOM 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 simplement ajouter AngularJS 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 sont pas habitués à faire des choses de 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 collent ensuite à AngularJS avec une collection de callbacks et de $apply s confus et compliqués; mais ils finissent par le faire fonctionner! Le problème est que dans la plupart des cas, le plug-in jQuery peut ê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, il n’ya pas de solution simple, 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 d'une page 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 fais-tu 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 à la place:

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

Ces deux-là 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 se joint à elle, elle peut l'examiner et savoir qu'il existe une directive appelée dropdownMenu . 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 rien de 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 procès-verbal 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 , donc l'intention est 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 d'intention signifiante que j'ai mentionnés auparavant. 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 des boîtes d’alerte Bootstrap. Et nous n'avons jamais eu à changer le code du contrôleur! Mais plus important encore, peu importe et 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 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 à 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, 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 constitue le compte rendu 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 problèmes, nous avons recours à l’ injection de dépendance . Si vous venez d'un langage côté serveur (de Java à PHP ), vous connaissez probablement déjà ce concept, mais si vous êtes un client qui utilise 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, ni l'emplacement des fichiers, ni rien de ce 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 axé sur 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 plug-ins jQuery que vous avez vus, utilisés ou écrits, combien d'entre eux avaient une suite de tests d'accompagnement? Pas beaucoup parce que 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, 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 when-active non existante:

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 basé sur des tests. Méchant-cool.

5. Conceptuellement, les directives ne 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 se trouve 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 doit également 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 affichent ou masquent un élément par programmation; et beaucoup d'autres, y compris ceux que nous écrivons nous-mêmes. En d’autres termes, nous pouvons faire toutes sortes d’impressionnants sans manipulation de DOM. Moins il y a de manipulations 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 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 ce soit certainement beaucoup mieux, c'est souvent encore faux .

Pensez à l'enregistreur que nous avons programmé à la section 3. Même si nous l'inscrivons dans une directive, nous voulons toujours le faire de la "manière angulaire". Il ne prend toujours pas de manipulation 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 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:

  1. Tout d'abord, jQuery n'a jamais été nécessaire. Il n'y a rien que nous ayons fait ici qui ait eu besoin de jQuery!
  2. 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.element et notre composant fonctionnera quand on le déposera dans un projet sans jQuery.
  3. Troisièmement, même en supposant que jQuery était requis pour que cette directive fonctionne, jqLite ( angular.element ) utilisera toujours jQuery si elle est chargée! Nous n’avons donc pas besoin d’utiliser le $ - nous pouvons simplement utiliser angular.element .
  4. La quatrième, étroitement liée à la troisième, est que les éléments jqLite ne doivent pas nécessairement être encapsulés dans $ - l' element qui est transmis à la fonction link serait déjà un élément jQuery!
  5. 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 afin que vous (ou vos utilisateurs) puissiez facilement l'échanger contre un modèle qui correspond à tous les styles nécessaires et que la logique n'a jamais dû être modifié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 simple. 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, pensez à la façon dont l’équipe l’accomplirait pour s’intégrer parfaitement à ngClick , ngClass , et al.

Résumé

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à savoir comment résoudre dans jQuery, avant d’atteindre le $ , essayez de réfléchir à la façon de le faire dans les limites d’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 des résultats jQuery demande plus de travail.


jQuery

jQuery effectue des commandes JavaScript ridiculement longues comme getElementByHerpDerpcourt 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, vous n’avez donc pas besoin de <div>tout mettre en place 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.


Impératif → déclaratif

Dans jQuery, les sélecteurs permettent de rechercher DOM éléments DOM , puis de leur lier / enregistrer des gestionnaires d’événements. 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 à des vues plutôt qu'à des é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 étant rarement utilisés, le besoin d'identifiants (et de certains types de classes) est considérablement réduit. Les vues sont liées aux 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 la 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 l’utilisateur voit.

Séparation des préoccupations

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

AngularJS utilise des contrôleurs et des directives (qui peuvent chacun avoir 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://.com/a/14346528/215945

Conception de l'application

Une approche pour concevoir 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 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.
  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. 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 comprenez bien l'héritage JavaScript. Lecture recommandée: Quelles sont les nuances de l'héritage prototypal / prototypique de la portée dans AngularJS?


Ce sont des réponses très bonnes mais 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 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 que vous 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.

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

AngularJS change votre façon de trouver des é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 connecter:
<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 d'AngularJS et jQuery 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!


Écoutez le podcast JavaScript Jabber: Épisode 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 avons très peu pensé à Angular est de savoir comment fournir de nombreuses trappes d'évacuation afin que vous puissiez sortir et trouver un moyen de s'en sortir. Donc, pour nous, la réponse est cette chose appelée "directives". Et avec les directives, vous devenez essentiellement un petit JavaScript jQuery régulier, vous pouvez faire ce que vous voulez.

IGOR : Pensez donc à la directive comme une instruction destinée au compilateur, qui indique à chaque fois que vous rencontrez cet élément ou ce code CSS dans le modèle. dans l'arbre 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?" 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.


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 du 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 gâche avec son architecture.

Lors 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, alors n'essayez pas de les inclure.


En tant que débutant JavaScript * et se concentrant uniquement sur l’architecture de l’application (pas sur le serveur / le client), je recommanderais certainement la ressource suivante (ce qui me surprend n’a pas encore été mentionné): JavaScript Design Patterns , 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 était vraiment bien formulé dans la réponse acceptée. Au lieu de cela, cette réponse renvoie aux bases théoriques qui alimentent AngularJS (et d’autres bibliothèques).

Comme moi, vous vous Ember.js vite compte que 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 (1) le code JavaScript natif et (2) des bibliothèques plus petites 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 s'adresse (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 modèles de prototype, constructeur, singleton et décorateur
  • jQuery / Underscore 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 observable, publier / subscribe

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.


Je trouve cette question intéressante, car ma première exposition sérieuse à la programmation JavaScript a été 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 coulisses).





angularjs