"Penser en AngularJS" si j'ai une formation en jQuery? [fermé]

Suppose que je suis familier avec le développement d'applications côté client dans jQuery , mais maintenant je voudrais 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 concevoir les applications Web côté client différemment? Quelle est la différence?
  • Que dois-je arrêter faire / utiliser; que dois-je commencer à faire/utiliser à la place?
  • y a-t-il des considérations/restrictions côté serveur?

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

4523
demandé sur EnggForum 2013-02-21 08:09:56
la source

15 ответов

1. Ne dessinez pas votre page, puis changez-la avec DOM manipulations

En jQuery, vous concevez une page, puis vous le rendre dynamique. C'est parce que jQuery a été conçu pour l'augmentation et a grandi incroyablement à partir de cette simple prémisse.

mais à AngularJS, vous devez partir de la base avec votre architecture à l'esprit. Au lieu de commencer par penser "j'ai ce morceau du DOM et je veux faire il do X", vous devez commencer par ce que vous voulez accomplir, puis aller à la conception de votre application, et enfin aller à la conception de votre vue.

2. Ne pas augmenter jQuery avec des AngularJS

de même, ne commencez pas avec l'idée que jQuery fait X, Y, et Z, donc je vais juste ajouter AngularJS en plus de cela pour les modèles et les contrôleurs. C'est vraiment tentant quand vous êtes débutant, c'est pourquoi j'ai toujours recommander que les nouveaux développeurs AngularJS ne pas utiliser jQuery du tout, au moins jusqu'à ce qu'ils s'habituent à faire les 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 dans AngularJS avec une collection de callbacks et $apply s qui sont confus et alambiqués; mais ils finissent par le faire fonctionner! Le problème est que dans la plupart cas que jQuery plugin pourrait être réécrit en AngularJS dans une fraction du code, où tout devient soudain compréhensible et simple.

la ligne de fond est ceci: quand vous solutionnez, d'abord" pensez à AngularJS"; si vous ne pouvez pas penser à une solution, demandez à la communauté; si après tout cela il n'y a pas de solution facile, puis se sentent libres pour atteindre pour le jQuery. Mais ne laissez pas jQuery devenir une béquille ou vous ne maîtriserez jamais AngularJS.

3. Toujours penser en termes d'architecture

d'Abord savoir que single page applications sont applications . Ce sont des pages web et non . 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 façon de diviser notre application en individuel, extensible, testable composant.

alors comment faites-vous cela? Comment "pensez-vous à AngularJS"? Voici quelques principes généraux, contrastés avec jQuery.

La vue est le "dossier officiel"

en jQuery, nous programmatically changer la vue. Nous pourrions avoir un menu déroulant défini comme un ul comme suit:

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

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

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

quand on regarde la vue, il n'est pas évident qu'il y ait des fonctionnalités ici. Pour les petites applications, c'est bien. Mais pour les applications non triviales, les choses deviennent vite confuses et difficiles à maintenir.

Dans AngularJS, cependant, le point de vue est le compte rendu officiel de la vue de base de la fonctionnalité. Notre déclaration ul ressemblerait plutôt à ceci:

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

ces deux-là font la même chose, mais dans la version 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 vient à bord, elle peut regarder cela et puis savoir qu'il ya une directive appelée dropdownMenu d'exploitation sur elle; elle n'a pas besoin d'intuit la bonne réponse ou passer au crible tout code. La vue nous a dit ce qui devait arriver. Beaucoup plus propre.

développeurs nouveau pour AngularJS posent souvent la question: comment puis-je trouver tous les liens d'un type spécifique et ajouter une directive sur eux. Le développeur est toujours sidéré quand nous répondons: vous ne le faites pas. Mais la raison pour laquelle tu ne fais pas ça c'est que c'est à moitié jQuery, à moitié AngularJS, et pas bon. Le problème ici est que le développeur essaie de "faire jQuery" dans le contexte D'AngularJS. Qui ne marchera jamais. Le point de vue est le dossier officiel. En dehors d'une directive (plus sur cela ci-dessous), vous jamais, jamais, jamais changer le DOM. Et les directives sont appliquées dans la vue , l'intention est claire.

rappelez-vous: ne pas concevoir, puis marquer. Vous devez architecte, puis de la conception.

liaison de Données

C'est de loin l'une des caractéristiques les plus impressionnantes D'AngularJS et coupe beaucoup de la nécessité de faire les genres de DOM manipulations que j'ai mentionnées dans le précédent section. AngularJS mettra automatiquement à jour votre vue pour que vous n'ayez pas à le faire! Dans jQuery, nous réagissons aux événements et 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 les préoccupations de mélange, nous avons également les mêmes problèmes de Signification de l'intention que j'ai mentionné avant. Mais plus important encore, nous avons dû manuellement référencer et mettre à jour un noeud DOM. Et si nous voulons supprimer une entrée de journal, nous avons à code contre le DOM pour ça aussi. Comment tester la logique en dehors du DOM? Et si on veut changer la présentation?

c'est un peu bordélique et frêle. Mais à AngularJS, nous pouvons le faire:

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

et notre vue peut ressembler à ceci:

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

mais d'ailleurs, notre point de 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 classée, nous sommes utiliser les boîtes D'alerte Bootstrap. Et nous n'avons jamais eu à changer le code du contrôleur! Mais plus important encore, peu importe ou comment le log est mis à jour, la vue changera aussi. Automatiquement. Soigné!

bien que je ne l'ai pas montré ici, la liaison de données est bidirectionnelle. Donc ces messages de log pourraient aussi être éditables dans la vue juste en faisant ceci: <input ng-model="entry.msg" /> . Et il y eut beaucoup de réjouissances.

Distinct couche modèle

à jQuery, le DOM est un peu comme le modèle. Mais à AngularJS, nous avons une couche modèle séparée que nous pouvons gérer de n'importe quelle manière, complètement indépendamment de la vue. Cela aide pour la liaison de données ci-dessus , maintient la séparation des préoccupations , et introduit beaucoup plus de testabilité. D'autres réponses mentionnaient ce point, alors je vais en rester là.

séparation des préoccupations

et tout ce qui précède sont liés à ce thème dominant: gardez vos préoccupations séparées. Votre vue agit comme un enregistrement officiel de ce qui est supposé se produire (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 faites des manipulations DOM et augmentez votre vue avec des directives; et vous la collez avec des 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 êtes probablement déjà familier avec ce concept, mais si vous êtes un client-côté gars venant de jQuery, ce concept peut sembler n'importe quoi de stupide à superflu à hipster. Mais il n'est pas. :- )

D'un point de vue général, DI signifie que vous pouvez déclarer des composants très librement et puis de tout autre composant, il suffit de demander une instance de celui-ci et il sera accordé. Vous n'avez pas besoin de connaître l'emplacement des commandes de chargement ou des fichiers, ou quoi que ce soit de ce genre. La puissance peut ne pas être immédiatement visible, mais je vais fournir un seul exemple (commun): test.

disons dans notre application, nous avons besoin d'un service qui met en œuvre stockage Côté Serveur via une API REST et, selon l'état de l'application, stockage local également. Lors de l'exécution de tests sur nos contrôleurs, nous ne voulons pas avoir à communiquer avec le serveur - nous testons le contrôleur , après tout. Nous pouvons juste ajouter un service de simulation du même nom que notre composant d'origine, et l'injecteur veillera à ce que notre contrôleur obtienne le faux automatiquement - notre contrôleur ne sait pas et n'a pas besoin de différence.

en parlant de test...

4. Développement piloté par des essais - toujours

c'est vraiment une partie de la section 3 sur l'architecture, mais c'est tellement important que je la mette comme sa propre section de haut niveau.

parmi les nombreux plugins jQuery que vous avez vus, utilisés ou écrits, combien avaient une suite de test? Pas beaucoup parce que jQuery n'est pas très prête à qui. Mais AngularJS l'est.

dans jQuery, la seule façon de tester est souvent de créer le composant de manière indépendante avec un échantillon/une page Démo contre laquelle nos tests peuvent effectuer des manipulations DOM. Donc, nous devons développer un composant séparément et puis l'intégrer dans notre application. Comment gênant! La plupart du temps, lorsque nous développons avec jQuery, nous optons pour un développement itératif plutôt que basé sur des tests. Et qui pourrait nous blâmer?

mais parce que nous avons la séparation des préoccupations, nous pouvons faire le développement d'essai itérativement dans AngularJS! Par exemple, disons que nous voulons une directive super-simple pour indiquer dans notre menu Quelle est notre route actuelle. Nous pouvons déclarer ce que nous voulons dans la vue de notre application:

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

Ok, maintenant nous pouvons écrire un test pour l'inexistant when-active directive:

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 quand nous faisons notre test, nous pouvons confirmer qu'il échoue. Ce n'est que maintenant que nous devrions créer Notre directive:

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

notre test passe maintenant et notre menu fonctionne comme demandé. Notre développement est à la fois itérative et Test-driven. Wicked cool.

5. Sur le plan conceptuel, les directives sont et non packaged jQuery

Vous entendrez souvent "seulement de manipulation du DOM dans directive." C'est une nécessité. traitez - le avec déférence!

mais plongeons un peu plus profond...

certaines directives décorent simplement ce qui est déjà dans la vue (penser ngClass ) et donc parfois faire la manipulation DOM tout de suite et puis sont essentiellement fait. Mais si une directive est comme un " widget "et a un modèle, elle doit aussi respecter la séparation des préoccupations. Qui est, le le modèle aussi doit rester largement indépendant de son implémentation dans les fonctions de lien et de contrôleur.

AngularJS est livré avec un ensemble complet d'outils pour rendre cela très facile; avec ngClass nous pouvons dynamiquement mettre à jour la classe; ngModel permet la liaison de données bidirectionnelle; ngShow et ngHide montrent ou cachent programmatiquement un élément; et beaucoup plus-y compris ceux que nous écrivons nous - mêmes. En d'autres termes, nous pouvons faire tout genres de awesomeness sans Dom manipulation. Moins il y a de manipulation de DOM, plus les directives sont faciles à tester, plus elles sont faciles à styliser, plus elles sont faciles à changer à l'avenir, et plus elles sont réutilisables et distribuables.

je vois beaucoup de développeurs nouveaux à AngularJS en utilisant des directives comme l'endroit pour jeter un tas de jQuery. En d'autres termes, ils pensent "puisque je ne peux pas faire de manipulation DOM dans le contrôleur, je vais prendre ce code put dans une directive". Bien que ce soit certainement beaucoup mieux, il est souvent encore tort .

pensez à l'enregistreur que nous avons programmé dans la section 3. Même si nous mettons cela dans une directive, nous encore veulent le faire la "voie angulaire". encore ne prend pas toutes les manipulations du DOM! Il y a beaucoup de fois où la manipulation de DOM est nécessaire, mais c'est un lot plus rare que vous le pensez! Avant doing DOM manipulation anywhere dans votre application, demandez-vous si vous en avez vraiment besoin. Il pourrait y avoir une meilleure façon.

voici un exemple rapide qui montre le modèle que je vois le plus souvent. Nous voulons un toggleable bouton. (Note: Cet exemple est un peu artificiel et un skosh verbose pour représenter des cas plus compliqués qui sont 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 problèmes avec ceci:

  1. tout d'abord, jQuery n'a jamais été nécessaire. Il n'y a rien de ce que nous avons fait ici qui a eu besoin de jQuery du tout!
  2. Deuxièmement, même si nous avons déjà jQuery sur notre page, il n'y a aucune raison de l'utiliser Ici; nous pouvons tout simplement utiliser angular.element et notre composant fonctionnera toujours une fois tombé dans un projet qui n'a pas jQuery.
  3. troisième, même en supposant que était nécessaire pour que cette directive fonctionne, jqLite ( angular.element ) toujours utiliser jQuery si il a été chargé! Nous n'avons donc pas besoin d'utiliser le $ - nous pouvons simplement utiliser angular.element .
  4. quatrième, étroitement lié à la troisième, est que les éléments jqLite ne doivent pas être enveloppés dans $ - le element qui est passé à la fonction link serait déjà un élément jQuery!
  5. et cinquième, que nous avons mentionné dans la précédente sections, pourquoi est-ce qu'on mélange des trucs de gabarits dans notre logique?

cette directive peut être réécrite (même dans des cas très compliqués!) beaucoup plus simplement ainsi:

.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, donc vous (ou vos utilisateurs) pouvez facilement l'échanger pour un qui répond à n'importe quel style nécessaire, et le logique n'a jamais eu à être touché. La réutilisabilité - boom!

et là sont encore tous ces autres avantages, comme le test - il est facile! Peu importe ce qu'il y a dans le modèle, l'API interne de la directive n'est jamais touchée, donc le remaniement est facile. Vous pouvez changer le modèle autant que vous le voulez sans toucher à la directive. Et peu importe ce que tu changes, tes tests sont toujours bons.

w00t!

donc si les directives ne sont pas seulement des collections de fonctions de type jQuery, que sont-elles? Les Directives sont en fait extensions de HTML . Si HTML ne fait pas quelque chose que vous avez besoin qu'il fasse, vous écrivez une directive pour le faire pour vous, et ensuite l'utiliser comme s'il faisait partie de HTML.

autrement dit, Si AngularJS ne fait pas quelque chose hors de la boîte, pensez à la façon dont l'équipe l'accomplirait pour s'intégrer avec ngClick , ngClass , et al.

résumé

N'utilisez même pas jQuery. Ne comprend même pas. Il va vous tenir en arrière. Et quand vous venez à un problème que vous pensez que vous savez comment résoudre en jQuery déjà, avant que vous atteigniez le $ , essayez de penser à la façon de le faire dans les limites de L'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 d'essayer de le résoudre avec jQuery résultats dans plus de travail pour vous.

7185
répondu Josh David Miller 2015-04-17 23:38:02
la source

impératif → déclaratif

En jQuery, sélecteurs sont utilisés pour trouver DOM éléments, puis liez/enregistrer les gestionnaires d'événements. Lorsqu'un événement se déclenche, ce code (impératif) s'exécute pour mettre à jour/changer le DOM.

à AngularJS, vous voulez penser à vues plutôt que des éléments DOM. Les vues sont (déclaratives) HTML qui contiennent des directives AngularJS . Les Directives mettent en place les gestionnaires d'événements en coulisse pour nous et nous donnent la possibilité de créer des bases de données dynamiques. Les sélecteurs sont rarement utilisés, de sorte que le besoin D'IDs (et de certains types de classes) est grandement diminué. Les vues sont liées aux modèles (via des portées). Les vues sont une projection du modèle. Les événements de changement de modèles (qui est, les données, les propriétés de l'étendue), et le point de vue que le projet de ces modèles de mise à jour "automatiquement."

à AngularJS, pensez à des modèles, plutôt que les éléments DOM jQuery-sélectionnés qui contiennent vos données. Pensez vues comme des projections de ces modèles, plutôt que d'enregistrer les callbacks pour manipuler ce que l'utilisateur voit.

séparation des préoccupations

jQuery emploie JavaScript discret - le comportement (JavaScript) est séparé de la structure (HTML).

AngularJS utilise controllers et des directives (dont chacune peut avoir leur propre controller, et/ou compiler et lier les fonctions) pour supprimer le comportement de la vue / structure (HTML). Angular a également services et filtres pour aider à séparer/organiser votre application.

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

dessin ou modèle industriel

Une approche pour la conception d'une application AngularJS:

  1. pensez à vos modèles. Créez des services ou vos propres objets JavaScript pour ces modèles.
  2. Pensez à comment vous voulez présenter vos modèles, vos points de vue. Créez des gabarits HTML pour chaque vue, en utilisant les directives nécessaires pour obtenir la reliure de données dynamique.
  3. attacher un contrôleur à chaque vue (en utilisant ng-view et routing, ou ng-controller). Le contrôleur ne trouve / obtient que les données du modèle dont la vue a besoin pour faire son travail. Rendre les contrôleurs aussi minces que possible.

Prototypes héritage

vous pouvez faire beaucoup avec jQuery sans savoir comment fonctionne JavaScript prototypal inheritance. Lorsque vous développez des applications AngularJS, vous éviterez certains pièges courants si vous avez une bonne compréhension de l'héritage JavaScript. Texte recommandé: quelles sont les nuances de la portée prototypal / prototypical héritage en AngularJS?

408
répondu Mark Rajcok 2017-05-23 14:47:31
la source

AngularJS vs. jQuery

AngularJS et jQuery adoptent des idéologies très différentes. Si vous venez de jQuery vous pouvez trouver certaines des différences surprenantes. Angulaire peut vous mettre en colère.

c'est normal, vous devriez passer. Angulaire en vaut la peine.

La grande différence (TLDR)

jQuery vous donne une boîte à outils pour sélectionner les bits arbitraires du DOM et faire des changements ad-hoc à ils. Tu peux faire à peu près tout ce que tu veux morceau par morceau.

AngularJS vous donne plutôt un compilateur .

cela signifie que AngularJS lit tout votre DOM de haut en bas et le traite comme du code, littéralement comme des instructions au compilateur. Comme il traverse le DOM, il cherche des directives spécifiques 1519220920 " (compilateur) qui indiquent au compilateur AngularJS comment se comporter et quoi faire. faire. Les Directives sont de petits objets remplis de JavaScript qui peuvent correspondre avec des attributs, des tags, des classes ou même des commentaires.

quand le compilateur angulaire détermine qu'un morceau du DOM correspond à une directive particulière, il appelle la fonction directive, lui passant L'élément DOM, les attributs, le $scope courant (qui est un magasin de variables local), et quelques autres bits utiles. Ces attributs peuvent contenir des expressions qui peuvent être interprétées par la Directive, et qui dites comment rendre, et quand il doit se redessiner.

Les Directives

peuvent à leur tour introduire des composants angulaires supplémentaires tels que des contrôleurs, des services, etc. Ce qui ressort du bas du compilateur est une application web entièrement formée, branchée et prête à démarrer.

cela signifie que L'angle est déterminé par un gabarit . Votre modèle pilote le JavaScript, pas l'inverse. Il s'agit d'un renversement radical des rôles, et le contraire du JavaScript discret que nous écrivons depuis une dizaine d'années. Cela peut prendre un certain obtention utilisé to.

si cela sonne comme si cela pouvait être trop prescriptif et limitatif, rien ne pourrait être plus éloigné de la vérité. Parce que AngularJS traite votre HTML comme du code, vous obtenez niveau de granularité HTML dans votre application web . Tout est possible, et la plupart des choses sont étonnamment faciles Une fois que vous faites quelques conceptuels saut.

passons aux choses sérieuses.

tout d'abord, Angular ne remplace pas jQuery

Angular et jQuery font des choses différentes. AngularJS vous donne un ensemble d'outils pour produire des 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, les AngularJS sont équipés de jQuery Lite, ce qui est une réduction, mais tout de même parfaitement utilisable. la version de jQuery.

Misko aime jQuery et ne s'oppose pas à ce que vous l'utilisiez. Cependant, au fur et à mesure que vous avancerez, vous constaterez que vous pouvez faire à peu près tout votre travail en utilisant une combinaison de scope, de templates et de directives, et que vous devriez préférer ce flux de travail lorsque c'est possible parce que votre code sera plus discret, plus configurable et plus angulaire.

si vous utilisez jQuery, vous ne devriez pas en saupoudrer partout. La bonne place pour DOM manipulation à AngularJS est dans une directive. Plus tard.

JavaScript Discret Avec sélecteurs vs. modèles déclaratifs

jQuery est généralement appliqué de manière non-intrusive. 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 bits de la page et écrire des plugins pour modifier ces parties.

le JavaScript est sous contrôle. Le HTML a une existence complètement indépendante. Votre HTML reste sémantique même sans JavaScript. Les attributs Onclick sont de très mauvaises pratiques.

une des premières choses que vous remarquerez à propos D'AngularJS est que les attributs personnalisés sont partout . Votre HTML sera jonché d'attributs ng, qui sont essentiellement des attributs onClick sur les stéroïdes. Ce sont des directives (directives du compilateur), et sont l'une des principales façons dont le modèle est accroché au modèle.

quand vous voyez cela pour la première fois, vous pourriez être tenté D'écrire AngularJS comme JavaScript intrusif de la vieille école (comme je l'ai fait au début). En fait, AngularJS ne respecte pas ces règles. En 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 doit être compilé. AngularJS lit dans toute votre page web et le compile littéralement dans une nouvelle page Web en utilisant son compilateur intégré.

votre modèle doit être déclaratif; son sens doit être clair simplement en le lisant. Nous utilisons les attributs personnalisés avec des noms significatifs. Nous composons de nouveaux éléments HTML, encore une fois avec des noms significatifs. Un concepteur avec un minimum de connaissances HTML et aucune compétence de codage peut lire votre modèle AngularJS et comprendre ce qu'il fait. Il ou elle peut faire des modifications. This est l'angle moyen.

le gabarit est sur le siège conducteur.

l'une des premières questions que je me suis posée en commençant AngularJS et en parcourant les tutoriels est "Où est mon code?" . Je n'ai pas écrit de JavaScript, et pourtant j'ai ce comportement. La réponse est évidente. Parce Qu'AngularJS compile le DOM, AngularJS traite votre HTML comme du code. Pour de nombreux cas simples, il est souvent suffisant écrivez un modèle et laissez AngularJS le compiler dans une application pour vous.

votre modèle Pilote votre application. Il est traité comme un DSL . Vous écrivez des composants AngularJS, et AngularJS s'occupera de les tirer et de les rendre disponibles au bon moment en fonction de la structure de votre modèle. C'est très différent d'une norme MVC , où le modèle est juste pour la sortie.

c'est plus similaire à XSLT que Ruby on Rails par exemple.

il s'agit d'une inversion radicale du contrôle à laquelle il faut s'habituer.

cessez d'essayer de conduire votre application à partir de votre JavaScript. Laissez le modèle piloter l'application, et laissez AngularJS s'occuper du câblage des composants ensemble. C'est aussi l'angle.

Sémantique HTML vs Sémantique des Modèles

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

parce que AngularJS traite votre page HTML comme un modèle. Le modèle n'est pas supposé être sémantique car votre contenu est typiquement stocké dans votre modèle qui provient finalement 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, à la place, votre API et DOM compilé sont sémantiques.

en AngularJS, ce qui signifie vit dans le modèle, le HTML est juste un modèle, pour l'Affichage Seulement.

à ce stade, vous avez probablement toutes sortes de questions concernant SEO et l'accessibilité, et à juste titre. Il y a des questions ici. La plupart des les lecteurs d'écran vont maintenant analyser JavaScript. Les moteurs de recherche peuvent également indexer le contenu AJAXed . Néanmoins, vous voudrez vous assurer que vous utilisez pushstate URLs et vous avez un sitemap décent. Voir ici pour une discussion de la question: https://stackoverflow.com/a/23245379/687677

Separation of concerns (SOC) vs. MVC

la Séparation des préoccupations (SOC) est un modèle qui a grandi au cours de nombreuses années de développement web pour une variété de raisons, y compris le référencement, l'accessibilité et l'incompatibilité de navigateur. Il ressemble à ceci:

  1. HTML - sens sémantique. Le HTML doit être autonome.
  2. css-style, sans CSS la page est encore lisible.
  3. JavaScript Comportement, sans que le script le contenu reste.

encore une fois, AngularJS ne ne pas jouer selon leurs règles. Dans un coup, AngularJS fait disparaître avec une décennie de sagesse reçue et à la place met en œuvre un modèle MVC dans lequel le modèle n'est plus sémantique, pas même un peu.

il ressemble à ceci:

  1. Modèle-vos modèles contiennent vos données sémantiques. Les modèles sont habituellement JSON objets. Les modèles existent comme attributs d'un objet appelé $scope. Vous pouvez également stockez des fonctions utilitaires pratiques sur $scope auxquelles vos modèles peuvent accéder.
  2. Voir - Vos points de vue sont écrites en HTML. La vue n'est généralement pas sémantique parce que vos données vivent dans le modèle.
  3. contrôleur-votre contrôleur est une fonction JavaScript qui branche la vue au modèle. Sa fonction est d'initialiser $champ d'application. Selon votre application, vous pouvez ou non avoir besoin de créer un controller. Vous pouvez avoir beaucoup de contrôleurs sur une page.

MVC et SOC ne sont pas sur des extrémités opposées de la même échelle, ils sont sur des axes complètement différents. Le SOC n'a aucun sens dans un contexte AngularJS. Vous avez oublier et d'avancer.

Si, comme moi, vous avez vécu la guerre des navigateurs, vous pourriez trouver cette idée assez offensive. Oublie ça, ça en vaudra la peine, je te le promets.

Plugins vs. Directives

les Plugins étendent jQuery. Les directives AngularJS étendent les possibilités de votre navigateur.

dans jQuery nous définissons les plugins en ajoutant des fonctions à jQuery.prototype. Nous les accrochons ensuite dans le DOM en sélectionnant les éléments et en appelant le plugin sur le résultat. L'idée est d'étendre les capacités de jQuery.

par exemple, si vous voulez un carrousel sur votre page, vous pouvez définir une liste non ordonnée de figures, peut-être enveloppé dans un élément nav. Vous pouvez ensuite Ecrivez quelques jQuery pour sélectionner la liste sur la page et la restaurer comme une galerie avec des temps morts pour faire l'animation coulissante.

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

la voie AngularJS est d'étendre les capacités de l'apparence natif HTML. vous devez écrire HTML qui ressemble à HTML, étendu avec des attributs et des éléments personnalisés.

si vous voulez un carrousel, il suffit d'utiliser un élément <carousel /> , puis définir une directive pour tirer dans un gabarit, et faire fonctionner cette sucette.

Beaucoup de petites directives vs big plugins avec les commutateurs de configuration

la tendance avec jQuery est d'écrire de grands plugins comme lightbox que nous configurons ensuite en passant dans de nombreuses valeurs et options.

C'est une erreur à AngularJS.

prenons l'exemple d'un dropdown. Lors de l'écriture d'un plugin dropdown vous pourriez être tenté de coder dans les gestionnaires de clic, peut-être une fonction à ajouter dans un chevron qui est soit en haut ou en bas, peut-être changer la classe de l'élément déplié, montrer cacher la menu, tous les trucs utiles.

Jusqu'à ce que vous vouliez faire un petit changement.

dites que vous avez un menu que vous voulez déployer en vol stationnaire. Eh bien maintenant, nous avons un problème. Notre plugin est câblé dans notre gestionnaire de clic pour nous, nous allons avoir besoin d'ajouter une option de configuration pour qu'elle se comporte différemment dans ce cas précis.

à AngularJS nous écrivons des directives plus petites. Notre Directive sur l'abandon serait ridiculement petite. Il pourrait maintenir l'état plié, et fournissent des méthodes pour fold (), unfold () ou toggle (). Ces méthodes ne feraient que mettre à jour $scope.menu.visible qui est un booléen tenant l'état.

maintenant dans notre template nous pouvons télégraphier ceci:

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

besoin d'une mise à jour sur mouseover?

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

le modèle pilote l'application de sorte que nous obtenons le niveau de granularité HTML. Si nous voulons faire des exceptions au cas par cas, le le modèle rend cela facile.

Fermeture vs $scope

les plugins JQuery sont créés dans une fermeture. La vie privée est préservée dans le cadre de cette fermeture. C'est à vous de maintenir votre chaîne scope dans cette fermeture. Vous n'avez vraiment accès qu'à l'ensemble des noeuds DOM passés au plugin par jQuery, plus toutes les variables locales définies dans la fermeture et tous les globals que vous avez définis. Cela signifie que les plugins sont tout à fait autonome. C'est une bonne chose, mais peut devenir restrictif lors de la création d'une application complète. Essayer de passer des données entre des sections d'une page dynamique devient une corvée.

AngularJS a $scope objects. Ce sont des objets spéciaux créés et entretenus par AngularJS dans lequel vous stockez votre modèle. Certaines directives vont engendrer un nouveau $ scope, qui par défaut hérite de son $ wrapping $ scope en utilisant JavaScript prototypical inheritance. 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 grosso modo la structure de la DOM, les éléments ont accès à leur propre scope, et à tous les scopes contenant, de façon transparente, jusqu'au global $scope (ce qui n'est pas la même chose que le global scope).

il est ainsi beaucoup plus facile de transmettre des données et de les stocker à un niveau approprié. Si un dropdown est déployé, seul le dropdown $scope doit le savoir. Si l'utilisateur met à jour leurs préférences, vous pourriez vouloir mettre à jour le $scope global, et tout scopes imbriqués écoutant les préférences de l'utilisateur serait automatiquement alerté.

cela peut sembler compliqué, en fait, une fois que vous vous détendez dedans, c'est comme voler. Vous n'avez pas besoin de créer l'objet $scope, AngularJS instancie et le configure pour vous, correctement et correctement basé sur votre hiérarchie de template. AngularJS le rend alors disponible pour votre composant en utilisant la magie de la dépendance d'injection (plus sur cela plus tard).

changements de DOM Manuel vs. Data Binding

à jQuery vous faites tous vos changements de DOM à la main. Vous construisez de nouveaux éléments DOM de façon programmatique. Si vous avez un tableau JSON et que vous voulez le mettre dans le DOM, vous devez écrire une fonction pour générer le HTML et l'insérer.

dans AngularJS vous pouvez faire cela aussi, mais vous êtes encouragés à faire usage de la liaison de données. Changer de modèle, et parce que le DOM est lié à celui-ci via un modèle que votre DOM mettra automatiquement à jour, aucune intervention requise.

parce que la liaison de données est faite à partir du modèle, en utilisant soit un attribut, soit la syntaxe d'accrochage Bouclé, c'est très facile à faire. Il y a une petite charge cognitive associée à cela, donc vous vous retrouverez à 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.

de même:

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

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

Ajax tout le temps

à jQuery faire un appel Ajax est assez simple, mais c'est encore quelque chose que vous pourriez penser à deux fois. Il y a la complexité accrue à laquelle il faut penser, et un bon morceau de script à maintenir.

dans AngularJS, Ajax est votre solution de go-to par défaut et il se produit tout le temps, presque sans que vous le remarquiez. 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 envelopper un appel Ajax dans un service et créer vous-même un GitHub service, ou un Flickr service, auquel vous pouvez accéder avec une facilité étonnante.

objets de Service vs Helper Fonctions

dans jQuery, si nous voulons accomplir une petite tâche non liée au dom comme tirer un flux D'une API, nous pourrions écrire une petite fonction pour le faire dans notre fermeture. C'est une solution valable, mais que faire si nous voulons accéder à qui alimentent 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 qui contiennent des fonctions et des données. Ils sont toujours des singletons, ce qui veut dire qu'il ne peut y en avoir plus d'un. Si nous voulons accéder à l'API de débordement de la pile, nous pourrions écrire un StackOverflowService qui définit les méthodes pour le faire.

disons que nous avons un panier. Nous pourrions définir un service de magasinage qui maintient notre panier et contient des méthodes pour ajouter et enlever des articles. Parce que le service est un singleton, et est partagé par tous les autres composants, tout objet qui a besoin d'écrire au panier et tirez des données de lui. C'est toujours le même panier.

les objets de Service sont des composants AngularJS autonomes que nous pouvons utiliser et réutiliser comme bon nous semble. Ce sont de simples objets JSON contenant des fonctions et des données. Ils sont toujours des singletons, donc si vous stockez des données sur un service à un endroit, vous pouvez obtenir ces données ailleurs simplement en demandant le même service.

Dependency injection (DI) vs. Instatiation - aka dé-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 ceci, il est difficile d'expliquer à quel point c'est un énorme avantage du temps. Rien de tel Qu'AngularJS DI n'existe à l'intérieur de jQuery.

DI signifie qu'au lieu d'écrire votre application et le câblage ensemble, vous définissez plutôt une bibliothèque de composants, chaque identifié par une chaîne de caractères.

dis que j'ai un composant appelé "FlickrService" qui définit les méthodes pour tirer les flux JSON de Flickr. Maintenant, si je veux écrire un controller qui peut accéder à Flickr, j'ai juste besoin de faire référence au 'FlickrService' par son nom quand je déclare le controller. AngularJS s'occupera d'instancier le composant et de le mettre à 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 m'y réfère simplement par son nom comme ceci:

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

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

cela rend le câblage des choses ensemble très facile, et élimine pratiquement toute tendance à la spagettification. Nous avons une liste plate de composants, et AngularJS nous les remet un par un au fur et à mesure que nous en avons besoin.

Modulaire de l'architecture de services

jQuery dit Très peu sur la façon 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 à Flickr par exemple, vous pourriez vouloir créer un module Flickr pour envelopper toutes vos fonctions liées à Flickr. Les Modules peuvent inclure d'autres modules (DI). L'application principale est généralement un module, ce qui doit comprendre tous les autres modules de votre application dépendra.

vous obtenez la réutilisation de code simple, si vous voulez écrire une autre application basée sur Flickr, vous pouvez juste inclure le module Flickr et voila, 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 liste simple 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 (templates, data-binding, $scope, directives, etc.) vous trouverez que vous avez besoin d'un lot moins jQuery que vous pourriez autrement nécessaire.

la principale chose à réaliser est que votre modèle Pilote votre application. Arrêter d'essayer d'écrire des 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.

pensez moins au JavaScript discret, et pensez plutôt en termes D'extensions HTML.

mon petit livre

j'étais tellement excitée AngularJS, j'ai écrit un petit livre que vous pouvez lire en ligne http://nicholasjohnson.com/angular-book / . J'espère que c'est utile.

184
répondu superluminary 2017-05-23 15:26:38
la source

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

impératif vs déclaratif

Avec jQuery dis-le DOM ce qui doit arriver, étape par étape. Avec AngularJS vous décrivez quels résultats vous voulez, mais pas comment le faire. En savoir plus sur ce ici . En outre, consultez le site de Mark Rajcok réponse.

Comment puis-je concevoir les applications Web côté client différemment?

AngularJS est un cadre complet côté client qui utilise le modèle MVC (cochez leur représentation graphique ). Il met fortement l'accent sur la séparation des préoccupations.

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

jQuery est une bibliothèque

AngularJS est un beau cadre côté client, très testable, qui combine des tonnes de choses fraîches telles que MVC, injection de dépendance , liaison de données et beaucoup plus.

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

la meilleure façon de commencer est de passer par leur impressionnant tutoriel . Vous pouvez parcourir les étapes en quelques heures; cependant, si vous voulez maîtriser les concepts dans les coulisses, ils comprennent une myriade de références pour une lecture plus approfondie.

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

vous pouvez l'utiliser sur des applications existantes où vous utilisez déjà du jQuery pur. Cependant, si vous souhaitez profiter pleinement des fonctionnalités AngularJS, vous pouvez envisager de coder le côté serveur en utilisant une approche RESTful .

cela vous permettra de tirer parti de leur resource factory , qui crée une abstraction de votre côté serveur RESTful API et fait des appels côté serveur (get, enregistrer, supprimer, etc.) incroyablement facile.

152
répondu Ulises 2017-05-23 15:02:47
la source

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

AngularJS change la façon dont vous trouver elements

dans jQuery , vous utilisez généralement sélecteurs pour trouver des éléments, puis les filez vers le haut:

$('#id .class').click(doStuff);

dans AngularJS , vous utilisez directives marquer les éléments directement, les raccorder:

<a ng-click="doStuff()">

AngularJS n'a pas besoin (ou ne veut pas) que vous trouviez des éléments utilisant des sélecteurs - la principale différence entre le jqLite D'AngularJS par rapport au jQuery est que jqLite ne supporte pas les sélecteurs .

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

84
répondu Scott Rippey 2014-11-29 11:46:50
la source

jQuery

jQuery rend les commandes JavaScript ridiculement longues comme getElementByHerpDerp plus courtes et cross-browser.

AngularJS

AngularJS vous permet de créer vos propres balises/attributs HTML qui font des choses qui fonctionnent bien avec les applications web dynamiques (depuis HTML a été conçu pour les pages statiques).

Edit:

dire "j'ai une formation de jQuery Comment puis-je penser en AngularJS?" c'est comme dire "j'ai un fond HTML Comment puis-je penser en JavaScript?"Le fait que vous posez la question montre très probablement que vous ne comprenez 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 plutôt que de passer en revue la liste disant "AngularJS utilise des directives tandis que jQuery utilise des sélecteurs CSS pour faire un objet jQuery qui fait ceci et cela etc....". Cette question ne nécessite pas réponse longue.

jQuery est un moyen de faciliter la programmation JavaScript dans le navigateur. Shorter, cross-browser commandes,etc.

AngularJS étend HTML, de sorte que vous n'avez pas à mettre <div> partout juste pour faire une application. Il fait HTML fonctionnent réellement pour des applications plutôt que ce qu'il a été conçu pour, qui est statique, les pages web éducatives. Il le fait de manière détournée en utilisant JavaScript, mais fondamentalement c'est une extension de HTML, Pas JavaScript.

69
répondu Nick Manning 2015-06-09 05:08:25
la source

jQuery: on pense beaucoup à propos de 'l'Interrogation de la DOM " pour les éléments du DOM et de faire quelque chose.

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

par exemple, lorsque vous obtenez des données du serveur que vous avez l'intention d'afficher dans un certain format dans le DOM, en jQuery, vous avez besoin de " 1. Trouvez' où dans le DOM vous voulez placer ces données, le '2. Mettre à jour/ajouter' il en créant un nouveau noeud ou tout simplement paramétrage de son innerHTML . Puis quand vous voulez mettre à jour cette vue, vous alors '3. TROUVER " l'emplacement et '4. La mise à JOUR". Ce cycle de trouver et mettre à jour tout fait dans le même contexte de l'obtention et le formatage des données du serveur est parti en AngularJS.

avec AngularJS vous avez votre modèle (objets JavaScript auxquels vous êtes déjà habitués) et la valeur du modèle vous indique le modèle (évidemment) et la vue, et une opération sur le modèle propage automatiquement à la vue, de sorte que vous n'avez pas à y penser. Vous vous trouverez à AngularJS ne plus trouver des choses dans le DOM.

pour mettre d'une autre manière, en jQuery, vous devez penser aux sélecteurs CSS, c'est-à-dire, où est le div ou td qui a une classe ou un attribut, etc., de sorte que je peux obtenir leur HTML ou la couleur ou la valeur, mais en AngularJS, vous vous trouverez à penser comme ceci: quel modèle je traite, je vais mettre le valeur du modèle à true. Vous ne vous souciez pas de savoir si la vue reflétant cette valeur est une case cochée ou réside dans un élément td (détails auxquels vous auriez souvent dû penser dans jQuery).

et avec DOM manipulation dans AngularJS, vous vous retrouvez à ajouter des directives et des filtres, que vous pouvez considérer comme des extensions HTML valides.

encore une chose que vous expérimenterez à AngularJS: à jQuery vous appelez les fonctions jQuery lot, à AngularJS, AngularJS appellera vos fonctions, donc AngularJS 'vous dire comment faire les choses', mais les avantages en valent la peine, donc apprendre AngularJS signifie habituellement apprendre ce que veut AngularJS ou la façon dont AngularJS exige que vous présentez vos fonctions et il l'appellera en conséquence. C'est une des choses qui fait AngularJS un cadre plutôt qu'une bibliothèque.

61
répondu Samuel 2014-01-15 23:08:09
la source

Ceux qui sont certains très joli, mais les réponses longues.

pour résumer mes expériences:

  1. contrôleurs et fournisseurs (services, usines, etc.) sont pour 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 avez besoin de partager des données entre les contrôleurs, créer un service ou une usine - ce sont des singletons qui sont partagés à travers le application.
  4. si vous avez besoin d'un widget HTML, créez une directive.
  5. si vous avez des données et essayez maintenant de mettre à jour HTML... ARRÊTEZ! mettez à jour le modèle, et assurez-vous que votre HTML est lié au modèle.
46
répondu Dan 2014-08-12 00:14:48
la source

jQuery est une bibliothèque de manipulation DOM.

AngularJS est un MV* cadre.

en fait, AngularJS est l'un des rares cadres JavaScript MV* (de nombreux outils JavaScript MVC relèvent encore de la catégorie Bibliothèque).

étant un cadre, il héberge votre code et prend en charge les décisions sur ce qu'il faut appeler et quand!

AngularJS lui-même contient une édition jQuery-lite. Ainsi, pour certains de base Sélection/manipulation de DOM, vous n'avez vraiment pas besoin d'inclure la bibliothèque jQuery (elle sauve beaucoup d'octets pour fonctionner sur le réseau.)

AngularJS a le concept de" Directives " pour la manipulation de DOM et la conception de composants D'UI réutilisables, donc vous devriez l'utiliser chaque fois que vous ressentez le besoin de faire des choses liées à la manipulation de DOM (directives sont seulement l'endroit où vous devriez écrire le code jQuery tout en utilisant AngularJS).

AngularJS implique une certaine courbe d'apprentissage (Suite que jQuery :-).

-- > pour tout développeur issu de jQuery background, mon premier conseil serait d ' "apprendre le JavaScript comme un langage de première classe avant de sauter sur un cadre riche comme AngularJS!" J'ai appris le fait ci-dessus à la dure.

bonne chance.

45
répondu Sutikshan Dubey 2014-01-15 23:11:39
la source

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

jQuery parle de manipulation de DOM. Il résout toute la douleur cross browser sinon vous aurez à traiter avec, mais ce n'est pas un cadre qui vous permet de diviser votre application en composants comme AngularJS.

une bonne chose à propos D'AngularJs est qu'il vous permet de séparer/isoler la manipulation DOM dans les directives. Il y a des directives intégrées prêtes à l'emploi telles que ng-click. Vous pouvez créer vos propres directives personnalisées qui contiendront toute la logique de votre vue ou la manipulation de DOM de sorte que vous ne finissiez pas par fusionner le code de manipulation de DOM dans les contrôleurs ou les services qui devraient prendre soin de la logique d'affaires.

répartit L'angle de votre application en - Contrôleur - Service - Vue - 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 de DOM et vous pouvez devenir fou avec jQuery dedans sans se soucier de votre jQuery jamais conflits avec les composants D'AngularJs ou de gâcher son architecture.

j'ai entendu d'une réunion que j'ai assisté, l'un des fondateurs D'Angular dit qu'ils ont travaillé très dur pour séparer la manipulation de DOM donc ne tentez pas de les inclure de retour dans.

34
répondu Jin 2013-08-14 18:19:07
la source

Écouter le podcast de l'émission JavaScript Jabber: l'Épisode n ° 32 que les caractéristiques de l'original des créateurs d'AngularJS: Misko Hevery & Igor Minar. Ils parlent beaucoup de ce que c'est de venir à AngularJS à partir d'autres contextes JavaScript, en particulier jQuery.

L'un des points soulevés dans le podcast a fait beaucoup de choses click for me avec respect à votre question:

MISKO : [...] une des choses que nous avons pensé très difficilement dans Angulaire est, comment pouvons-nous fournir beaucoup de panneaux de survie, de sorte que vous pouvez sortir et essentiellement trouver un moyen de sortir de cette. Donc, pour nous, la réponse est cette chose appelée "Directives". et avec des directives, vous devenez essentiellement un petit JavaScript Jquery régulier, vous pouvez faire ce que vous voulez.

IGOR : pensez donc à la directive comme à l'instruction au compilateur qui le dit à chaque fois que vous rencontrez cet élément ou ce CSS dans le modèle, et vous gardez ce genre de code et ce code est en charge de l'élément et de tout ce qui se trouve en dessous de cet élément dans L'arbre DOM.

une transcription de l'épisode complet est disponible au lien ci-dessus.

donc, pour répondre directement à votre question: AngularJS est-très - opiniâtre et est un vrai cadre MV*. Cependant, vous pouvez toujours le faire tous les trucs vraiment cool que vous connaissez et que vous aimez avec jQuery à l'intérieur des directives. Ce n'est pas une question de "comment faire ce que je faisais à jQuery?"autant que c'est une question de" Comment puis-je compléter AngularJS avec tout ce que je faisais à jQuery?"

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

31
répondu codevinsky 2014-01-15 23:02:25
la source

je trouve cette question intéressante, parce que ma première exposition sérieuse à la programmation JavaScript était noeud.js et AngularJS. Je n'ai jamais appris le jQuery, et je suppose que c'est une bonne chose, parce que je n'ai pas à désapprendre quoi que ce soit. En fait, j'évite activement les solutions jQuery à mes problèmes, et à la place, Je ne cherche qu'une "façon AngularJS" de les résoudre. Donc, je crois que ma réponse à cette question se réduisent, "penser comme quelqu'un qui n'a jamais appris jQuery" et éviter toute tentation d'incorporer jQuery directement (évidemment AngularJS l'utilise dans une certaine mesure dans les coulisses).

30
répondu Evan Zamir 2014-01-15 23:12:45
la source

AngularJS et jQuery:

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

AngularJs est un cadre côté client qui offre de construire l'application côté client indépendante. JQuery est une bibliothèque côté client qui joue autour du DOM.

AngularJs Principe Cool - si vous voulez quelques changements sur votre UI penser à partir de la perspective de changement de données de modèle. Modifiez vos données et L'interface utilisateur se réinterprétera. Vous n'avez pas besoin de jouer autour de DOM à chaque fois à moins et jusqu'à ce qu'il soit à peine nécessaire et qui doit également être traitée par des Directives angulaires.

pour répondre à cette question, je veux partager mon expérience sur la première application d'entreprise avec AngularJS. Ce sont les traits les plus impressionnants qui fournissent angulaire où nous commençons à changer notre état d'esprit jQuery et nous obtenons L'angle comme un cadre et pas la bibliothèque.

les Deux sens de la liaison de données est incroyable: J'avais une grille avec toutes les fonctionnalités mises à jour, DELTE, INSERT. J'ai un objet de données qui lie le modèle de la grille en utilisant ng-repeat. Vous avez seulement besoin d'écrire une seule ligne de code JavaScript simple pour supprimer et insérer et c'est tout. la grille est mise à jour automatiquement lorsque le modèle 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: Ecrivez les directives à un endroit et utilisez-les tout au long de l'application. OMG!!! J'ai utilisé ces directives pour la paging, regex, validations, etc. Il est vraiment cool!

Routage est forte: C'est à votre mise en œuvre de décider comment vous voulez l'utiliser, mais il nécessite très peu de lignes de code pour router la demande de spécifier HTML et controller (JavaScript))

les contrôleurs sont grands: Les contrôleurs prennent soin de leur propre HTML, mais cette séparation fonctionne bien pour les fonctionnalités communes ainsi que. Si vous voulez appeler la même fonction en cliquant sur un bouton sur master HTML, il vous suffit d'écrire le même nom de fonction dans chaque controller et d'écrire du code individuel.

Plugins: Il y a beaucoup d'autres traits semblables comme le fait de montrer une superposition dans votre application. Vous n'avez pas besoin de Ecrire le code pour cela, il suffit d'utiliser un plugin de superposition disponible comme wc-superposition, et cela prendra automatiquement en charge toutes les requêtes XMLHttpRequest (XHR).

idéal pour RESTful architecture: Être un cadre complet rend AngularJS grand de travailler avec une architecture reposante. Appeler repos CRUD APIs est très facile et

Services : Ecrire commun codes utilisant des services et moins de code dans les contrôleurs. Sevices peut être utilisé pour partager des fonctionnalités communes entre les contrôleurs.

extensibilité : Angular a étendu les directives HTML en utilisant des directives angular. Ecrivez des expressions dans html et évaluez-les à l'exécution. Créez vos propres directives et services et utilisez-les dans un autre projet sans aucun effort supplémentaire.

23
répondu Sanjeev Singh 2015-05-24 05:56:31
la source

en tant que débutant de JavaScript MV* et purement axé sur l'architecture de l'application (pas les questions Côté Serveur/client), je recommande certainement la ressource suivante (qui je suis surpris n'a pas été mentionné encore): JavaScript Design Patterns , par Addy Osmani, comme une introduction à la différente JavaScript Design Patterns . 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é formulée vraiment bien dans l'acceptation de réponse. Au lieu de cela, cette réponse renvoie à la milieux théoriques qui Puissance AngularJS (et d'autres bibliothèques).

comme moi, vous vous rendrez vite compte que AngularJS (ou Ember.js , Durandal, & autres MV* frameworks for that matter) est un framework complexe assemblant plusieurs des différents modèles de conception JavaScript.

j'ai trouvé plus facile aussi, de tester (1) code JavaScript natif et (2) 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 les questions cruciales qu'un cadre aborde (parce que vous êtes personnellement confrontés au problème).

par exemple:

NB: cette liste n'est pas complète, ni "les meilleures bibliothèques"; il se trouve qu'il s'agit des bibliothèques que j'ai utilisées. Ces bibliothèques comprennent également plus de Modèles, ceux mentionnés ne sont que leurs principaux axes ou intentions originales. Si vous estimez qu'il manque quelque chose dans cette liste, veuillez le mentionner dans les commentaires, et je serai heureux de l'ajouter.

20
répondu Tyblitz 2014-11-29 11:54:35
la source

en fait, si vous utilisez AngularJS, vous n'avez plus besoin de jQuery. AngularJS lui-même a le caractère contraignant 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 habituellement des applications mobiles en utilisant AngularJS et Cordova . La seule chose de jQuery dont j'ai besoin est le sélecteur.

sur google, je vois qu'il est autonome sélecteur jQuery module. C'est le Grésillement.

et j'ai décidé de faire un petit morceau de code qui m'aide à démarrer rapidement un site Web en utilisant AngularJS avec la puissance de jQuery Selector (en utilisant Sizzle).

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

12
répondu Huy Tran 2014-11-22 18:41:23
la source

Autres questions sur javascript jquery design angularjs