Frage "Thinking in AngularJS" wenn ich einen jQuery Hintergrund habe? [geschlossen]


Angenommen, ich bin mit der Entwicklung von clientseitigen Anwendungen vertraut jQuery, aber jetzt möchte ich anfangen zu verwenden AngularJS. Können Sie den Paradigmenwechsel beschreiben, der notwendig ist? Hier sind ein paar Fragen, die Ihnen helfen können, eine Antwort zu finden:

  • Wie kann ich clientseitige Webanwendungen anders gestalten und gestalten? Was ist der größte Unterschied?
  • Was soll ich aufhören / benutzen? Was sollte ich stattdessen tun / verwenden?
  • Gibt es serverseitige Überlegungen / Einschränkungen?

Ich suche keinen detaillierten Vergleich zwischen jQuery und AngularJS.


4525
2018-02-21 04:09


Ursprung


Antworten:


1. Entwerfen Sie Ihre Seite nicht und ändern Sie sie dann mit DOM Manipulationen

In jQuery entwerfen Sie eine Seite und machen sie dann dynamisch. Dies liegt daran, dass jQuery für die Augmentation entwickelt wurde und von dieser einfachen Prämisse unglaublich gewachsen ist.

Aber in AngularJS müssen Sie von Grund auf mit Ihrer Architektur beginnen. Statt zu denken: "Ich habe dieses Teil des DOM, und ich möchte es X machen lassen", müssen Sie mit dem beginnen, was Sie erreichen wollen, dann Ihre Anwendung entwerfen und schließlich Ihre Ansicht gestalten.

2. Erweitern Sie jQuery nicht mit AngularJS

Genauso sollten Sie nicht mit der Idee beginnen, dass jQuery X, Y und Z verwendet, also werde ich AngularJS für Modelle und Controller hinzufügen. Das ist Ja wirklich Es ist verlockend, wenn Sie gerade erst anfangen. Deshalb empfehle ich allen neuen AngularJS-Entwicklern, jQuery überhaupt nicht zu benutzen, zumindest nicht, bis sie sich daran gewöhnt haben, Dinge auf dem "Angular Way" zu tun.

Ich habe viele Entwickler hier gesehen und auf der Mailing-Liste diese aufwendigen Lösungen mit jQuery-Plugins von 150 oder 200 Zeilen Code erstellt, die sie dann in AngularJS mit einer Sammlung von Callbacks kleben und $applys, die verwirrend und verschlungen sind; aber sie bringen es schließlich zum Laufen! Das Problem ist, dass die meisten Fälle, in denen das jQuery-Plugin in AngularJS in einem Bruchteil des Codes umgeschrieben werden konnte, wo plötzlich alles verständlich und unkompliziert wird.

Die Quintessenz ist: Bei der Lösung zuerst "denke in AngularJS"; Wenn Sie nicht an eine Lösung denken können, fragen Sie die Gemeinschaft; wenn es nach all dem keine einfache Lösung gibt, dann Fühlen Sie sich frei, für die jQuery zu erreichen. Aber lassen Sie jQuery nicht zur Krücke werden oder Sie werden AngularJS niemals beherrschen.

3. Denken Sie immer in der Architektur

Das weißt du zuerst Einzelseiten-Anwendungen sind Anwendungen. Sie sind nicht Webseiten. Also müssen wir wie ein serverseitiger Entwickler denken in Ergänzung zu denken wie ein Client-Side-Entwickler. Wir müssen darüber nachdenken, wie wir unsere Anwendung in einzelne, erweiterbare, testbare Komponenten aufteilen können.

Also dann Wie machst du das? Wie denkst du "in AngularJS"? Hier sind einige allgemeine Prinzipien, im Gegensatz zu jQuery.

Der Blick ist der "offizielle Rekord"

In jQuery ändern wir die Ansicht programmatisch. Wir könnten ein Dropdown-Menü als a definieren ul so:

<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>

In jQuery, in unserer Anwendungslogik, würden wir es aktivieren mit etwas wie:

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

Wenn wir uns nur die Ansicht ansehen, ist es nicht sofort offensichtlich, dass hier irgendeine Funktionalität vorhanden ist. Für kleine Anwendungen ist das in Ordnung. Aber für nicht-triviale Anwendungen werden Dinge schnell verwirrend und schwer zu pflegen.

In AngularJS ist die Ansicht jedoch die offizielle Aufzeichnung der Ansichtsfunktionalität. Unser ul Erklärung würde stattdessen so aussehen:

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

Diese beiden machen das gleiche, aber in der AngularJS-Version weiß jeder, der die Vorlage betrachtet, was passieren soll. Wann immer ein neues Mitglied des Entwicklungsteams an Bord kommt, kann sie sich dies und dann ansehen kennt dass es eine Direktive gibt dropdownMenu darauf arbeiten; Sie braucht die richtige Antwort nicht zu verstehen oder einen Code zu durchforsten. Die Aussicht sagte uns, was passieren sollte. Viel sauberer.

Entwickler, die AngularJS neu kennen, stellen oft eine Frage wie: Wie finde ich alle Links einer bestimmten Art und füge eine Direktive hinzu? Der Entwickler ist immer verblüfft, wenn wir antworten: Sie nicht. Aber der Grund, warum du das nicht tust, ist, dass es halb-jQuery, halb-AngularJS und nicht gut ist. Das Problem hierbei ist, dass der Entwickler versucht, im Kontext von AngularJS "jQuery" zu machen. Das wird nie gut funktionieren. Die Aussicht ist die offizielle Aufzeichnung. Außerhalb einer Direktive (mehr dazu unten), nie, noch nie ändere das DOM. Und Anweisungen werden angewendet in der Ansicht, so Absicht ist klar.

Denken Sie daran: nicht entwerfen und dann markieren. Sie müssen Architekt und dann entwerfen.

Datenbindung

Dies ist bei weitem eines der großartigsten Features von AngularJS und macht die Notwendigkeit von DOM-Manipulationen, die ich im vorherigen Abschnitt erwähnt habe, überflüssig. AngularJS wird automatisch Ihre Ansicht aktualisieren, so dass Sie nicht müssen! In jQuery reagieren wir auf Ereignisse und aktualisieren dann den Inhalt. Etwas wie:

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

Für eine Ansicht, die wie folgt aussieht:

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

Abgesehen von der Vermischung von Bedenken haben wir auch die gleichen Probleme der Absichtserklärung, die ich bereits erwähnt habe. Aber noch wichtiger: Wir mussten einen DOM-Knoten manuell referenzieren und aktualisieren. Und wenn wir einen Protokolleintrag löschen wollen, müssen wir auch dafür gegen das DOM kodieren. Wie testen wir die Logik außer dem DOM? Und wenn wir die Präsentation ändern wollen?

Das ist ein bisschen unordentlich und ein bisschen schwach. Aber in AngularJS können wir dies tun:

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

Und unsere Sicht kann so aussehen:

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

Aber unsere Sichtweise könnte so aussehen:

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

Und jetzt, anstatt eine ungeordnete Liste zu verwenden, verwenden wir Bootstrap-Alarmfelder. Und wir mussten nie den Controller-Code ändern! Aber noch wichtiger, egal woher oder Wie Das Protokoll wird aktualisiert, die Ansicht ändert sich ebenfalls. Automatisch. Ordentlich!

Obwohl ich es hier nicht gezeigt habe, ist die Datenbindung zweiseitig. So können diese Protokollnachrichten auch in der Ansicht editiert werden, indem Sie einfach Folgendes tun: <input ng-model="entry.msg" />. Und es gab viel Freude.

Eindeutige Modellschicht

In jQuery ähnelt das DOM dem Modell. Aber in AngularJS haben wir eine separate Modellschicht, die wir völlig unabhängig von der Ansicht beliebig verwalten können. Dies hilft, die obige Datenbindung beizubehalten Trennung von Bedenkenund führt eine viel größere Testbarkeit ein. Andere Antworten erwähnten diesen Punkt, also lasse ich es einfach dabei.

Trennung von Bedenken

Und all die oben genannten Themen knüpfen an dieses übergreifende Thema an: Halte deine Sorgen getrennt. Ihre Ansicht dient als offizielle Aufzeichnung dessen, was (größtenteils) geschehen soll; Ihr Modell repräsentiert Ihre Daten; Sie haben eine Serviceschicht, um wiederverwendbare Aufgaben auszuführen. Sie machen DOM-Manipulation und erweitern Ihre Ansicht mit Anweisungen; und Sie kleben alles zusammen mit Controllern. Dies wurde auch in anderen Antworten erwähnt, und das Einzige, was ich hinzufügen möchte, betrifft die Testbarkeit, die ich in einem anderen Abschnitt unten diskutiere.

Abhängigkeitsspritze

Uns bei der Trennung von Anliegen zu helfen ist Abhängigkeitsspritze (DI). Wenn Sie aus einer serverseitigen Sprache kommen (aus Java zu PHP) Sie sind wahrscheinlich mit diesem Konzept bereits vertraut, aber wenn Sie ein Client-Side-Typ von jQuery kommen, kann dieses Konzept von albern zu überflüssig zu Hipster scheinen. Aber es ist nicht. :-)

Aus einer breiten Perspektive bedeutet DI, dass Sie Komponenten sehr frei deklarieren können und dann von jeder anderen Komponente, fragen Sie einfach nach einer Instanz davon und es wird gewährt. Sie müssen nicht über die Ladereihenfolge, die Speicherorte oder Ähnliches Bescheid wissen. Der Strom ist vielleicht nicht sofort sichtbar, aber ich werde nur ein (allgemeines) Beispiel vorstellen: Testen.

Nehmen wir an, in unserer Anwendung benötigen wir einen Dienst, der den serverseitigen Speicher über einen Server implementiert SICH AUSRUHEN API und, je nach Anwendungsstatus, auch lokaler Speicher. Wenn wir Tests auf unseren Controllern durchführen, wollen wir nicht mit dem Server kommunizieren müssen - wir testen die Regler, Letztendlich. Wir können einfach einen Schein-Service mit dem gleichen Namen wie unsere ursprüngliche Komponente hinzufügen, und der Injektor wird sicherstellen, dass unser Controller automatisch den falschen bekommt - unser Controller kennt den Unterschied nicht und braucht ihn nicht zu kennen.

Apropos Testen ...

4. Testgetriebene Entwicklung - immer

Dies ist wirklich Teil von Abschnitt 3 über Architektur, aber es ist so wichtig, dass ich es als einen eigenen Abschnitt auf oberster Ebene veröffentliche.

Von all den vielen jQuery-Plugins, die Sie gesehen, benutzt oder geschrieben haben, wie viele von ihnen hatten eine begleitende Testsuite? Nicht sehr viele, weil jQuery nicht sehr zugänglich ist. Aber AngularJS ist.

In jQuery besteht die einzige Möglichkeit zum Testen häufig darin, die Komponente unabhängig mit einer Beispiel- / Demoseite zu erstellen, mit der unsere Tests DOM-Manipulation durchführen können. Also müssen wir eine Komponente separat entwickeln und dann integrieren Sie es in unsere Anwendung. Wie unbequem! Bei der Entwicklung mit jQuery entscheiden wir uns so oft für eine iterative statt für eine testgetriebene Entwicklung. Und wer könnte uns die Schuld geben?

Da wir jedoch Bedenken trennen, können wir in AngularJS iterativ testgetriebene Entwicklungen durchführen. Nehmen wir zum Beispiel an, wir wollen eine super-einfache Direktive, die in unserem Menü die aktuelle Route anzeigt. Wir können im Hinblick auf unsere Anwendung erklären, was wir wollen:

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

Okay, jetzt können wir einen Test für das Nicht-Existieren schreiben when-active Richtlinie:

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();
}));

Und wenn wir unseren Test durchführen, können wir bestätigen, dass er fehlschlägt. Erst jetzt sollten wir unsere Richtlinie erstellen:

.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' );
                }
            });
        }
    };
});

Unser Test besteht jetzt und Unser Menü führt wie gewünscht aus. Unsere Entwicklung ist beide iterativ und testgesteuert. Verdammt cool.

5. Konzeptionell sind Richtlinien nicht verpackte jQuery

Sie werden oft "nur DOM-Manipulation in einer Direktive" hören. Dies ist eine Notwendigkeit. Behandle es mit Respekt!

Aber lass uns ein wenig tiefer tauchen ...

Einige Direktiven schmücken nur das, was bereits in der Ansicht ist (denke ngClass) und machen daher manchmal DOM-Manipulationen sofort und sind dann grundsätzlich erledigt. Aber wenn eine Direktive wie ein "Widget" ist und eine Vorlage hat, sollte sie es tun ebenfalls Respektieren Sie die Trennung von Anliegen. Das heißt, die Vorlage auch sollte weitgehend unabhängig von seiner Umsetzung in den Link- und Controller-Funktionen bleiben.

AngularJS wird mit einer ganzen Reihe von Tools geliefert, um dies sehr einfach zu machen. mit ngClass wir können die Klasse dynamisch aktualisieren; ngModel ermöglicht Zwei-Wege-Datenbindung; ngShow und ngHide Programmgesteuertes Ein- oder Ausblenden eines Elements; und viele mehr - einschließlich derer, die wir selbst schreiben. Mit anderen Worten, wir können alle Arten von Großartigkeit tun ohne DOM-Manipulation. Je weniger DOM manipuliert wird, desto leichter werden die Direktiven getestet, je einfacher sie zu stylen sind, desto leichter können sie sich in der Zukunft ändern, und desto wiederverwendbarer und verteilbarer sind sie.

Ich sehe viele neue AngularJS-Entwickler, die Direktiven als Ort nutzen, um eine Menge jQuery zu werfen. Mit anderen Worten, sie denken: "Da ich im Controller keine DOM-Manipulation machen kann, nehme ich diesen Code in eine Direktive". Während das ist sicherlich viel besser, es ist oft immer noch falsch.

Denken Sie an den Logger, den wir in Abschnitt 3 programmiert haben. Selbst wenn wir das in eine Direktive schreiben, wir immer noch möchte es den "Winkelweg" machen. Es immer noch nimmt keine DOM-Manipulation! Es gibt viele Male, wenn DOM-Manipulation notwendig ist, aber es ist ein Menge seltener als Sie denken! Vor der DOM-Manipulation irgendwo Fragen Sie sich in Ihrer Bewerbung, ob Sie das wirklich brauchen. Es könnte einen besseren Weg geben.

Hier ist ein kurzes Beispiel, das das Muster zeigt, das ich am häufigsten sehe. Wir wollen eine umschaltbare Schaltfläche. (Anmerkung: Dieses Beispiel ist ein wenig erfunden und ein skosh, um kompliziertere Fälle darzustellen, die auf genau die gleiche Weise gelöst werden.)

.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);
            });
        }
    };
});

Es gibt ein paar Dinge falsch damit:

  1. Erstens war jQuery nie notwendig. Es gibt nichts, was wir hier gemacht haben, das überhaupt jQuery benötigt!
  2. Zweitens, auch wenn wir bereits jQuery auf unserer Seite haben, gibt es keinen Grund, es hier zu verwenden; wir können es einfach benutzen angular.element und unsere Komponente funktioniert immer noch, wenn sie in ein Projekt eingefügt wird, das jQuery nicht enthält.
  3. Drittens, sogar unter der Annahme, dass jQuery war Damit diese Richtlinie funktioniert, muss jqLite (angular.element) werden immer benutze jQuery wenn es geladen wurde! Also brauchen wir nicht die $ - Wir können es einfach benutzen angular.element.
  4. Viertens, eng verwandt mit dem dritten, ist, dass jqLite-Elemente nicht eingepackt werden müssen $ - das element das ist an die weitergegeben link Funktion würde schon sein ein jQuery-Element!
  5. Und fünftens, was wir in den vorherigen Abschnitten erwähnt haben, warum mischen wir Vorlagen in unsere Logik?

Diese Anweisung kann (sogar für sehr komplizierte Fälle!) Viel einfacher umgeschrieben werden:

.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;
            };
        }
    };
});

Auch hier ist das Vorlagenkram in der Vorlage enthalten, so dass Sie (oder Ihre Benutzer) es leicht gegen eine Vorlage austauschen können, die allen Stilrichtungen entspricht Logik musste nie berührt werden. Wiederverwendbarkeit - Boom!

Und es gibt noch all die anderen Vorteile, wie Testen - es ist einfach! Unabhängig davon, was in der Vorlage enthalten ist, wird die interne API der Richtlinie nie berührt, so dass das Refactoring einfach ist. Sie können die Vorlage so oft ändern, wie Sie möchten, ohne die Anweisung zu berühren. Und egal, was Sie ändern, Ihre Tests bestehen immer noch.

w00t!

Also, wenn Direktiven nicht nur Sammlungen von jQuery-ähnlichen Funktionen sind, was sind sie? Richtlinien sind eigentlich Erweiterungen von HTML. Wenn HTML etwas nicht tut, was Sie tun müssen, schreiben Sie eine Anweisung, um es für Sie zu tun, und verwenden Sie es dann, als wäre es Teil von HTML.

Anders gesagt, wenn AngularJS nicht etwas aus der Box macht, denke darüber nach, wie das Team es schaffen würde, damit es richtig zusammenpasst ngClick, ngClass, et al.

Zusammenfassung

Benutze nicht einmal jQuery. Nimm es nicht einmal auf. Es wird dich zurückhalten. Und wenn du zu einem Problem kommst, von dem du denkst, dass du es bereits in jQuery lösen kannst, bevor du nach dem $Versuchen Sie darüber nachzudenken, wie Sie es innerhalb der Grenzen des AngularJS tun können. Wenn du es nicht weißt, frag! In 19 von 20 Fällen benötigt der beste Weg keine jQuery und der Versuch, sie mit jQuery zu lösen, führt zu mehr Arbeit für Sie.


7187
2018-02-21 21:26



Imperativ → deklarativ

In jQuery, Selektoren werden verwendet, um zu finden DOM Elemente und binden / registrieren dann Ereignishandler an sie. Wenn ein Ereignis ausgelöst wird, wird dieser (imperative) Code ausgeführt, um das DOM zu aktualisieren / ändern.

In AngularJS möchten Sie darüber nachdenken Ansichten anstatt DOM-Elemente. Ansichten sind (deklaratives) HTML, das AngularJS enthält Richtlinien. Direktiven richten die Ereignishandler hinter den Kulissen für uns ein und geben uns dynamische Datenbindungen. Selektoren werden selten verwendet, so dass die Notwendigkeit von IDs (und einigen Arten von Klassen) stark verringert wird. Ansichten sind verknüpft mit Modelle (über Bereiche). Ansichten sind eine Projektion des Modells. Ereignisse ändern Modelle (d. H. Daten und Bereichseigenschaften) und die Sichten, die diese Modelle projizieren, werden automatisch aktualisiert.

Denken Sie in AngularJS an Modelle und nicht an von jQuery ausgewählte DOM-Elemente, die Ihre Daten enthalten. Betrachten Sie Ansichten als Projektionen dieser Modelle, anstatt Callbacks zu registrieren, um das zu manipulieren, was der Benutzer sieht.

Trennung von Bedenken

jQuery beschäftigt unaufdringliches JavaScript - Verhalten (JavaScript) ist von der Struktur (HTML) getrennt.

AngularJS verwendet Controller und Direktiven (von denen jede einen eigenen Controller und / oder Funktionen zum Kompilieren und Verknüpfen haben kann), um das Verhalten aus der Ansicht / Struktur (HTML) zu entfernen. Eckig hat auch Dienstleistungen und Filter um zu helfen, Ihre Anwendung zu trennen / zu organisieren.

Siehe auch https://stackoverflow.com/a/14346528/215945

Anwendungsdesign

Ein Ansatz zum Entwerfen einer AngularJS-Anwendung:

  1. Denken Sie an Ihre Modelle. Erstellen Sie Dienste oder eigene JavaScript-Objekte für diese Modelle.
  2. Denken Sie darüber nach, wie Sie Ihre Modelle präsentieren möchten - Ihre Ansichten. Erstellen Sie HTML-Vorlagen für jede Ansicht und verwenden Sie die erforderlichen Anweisungen, um dynamische Datenbindung zu erhalten.
  3. Hängen Sie an jede Ansicht einen Controller an (mit ng-view und routing oder ng-controller). Lassen Sie den Controller nur die Modelldaten suchen / abrufen, die die Ansicht benötigt, um ihre Aufgabe zu erfüllen. Machen Sie Controller so dünn wie möglich.

Prototypische Vererbung

Sie können viel mit jQuery machen, ohne zu wissen, wie die JavaScript-Prototyp-Vererbung funktioniert. Wenn Sie AngularJS-Anwendungen entwickeln, werden Sie einige häufige Fehler vermeiden, wenn Sie die Vererbung von JavaScript gut verstehen. Literatur-Empfehlungen: Was sind die Nuancen des Umfangs prototypischer / prototypischer Vererbung in AngularJS?


408
2018-02-21 04:09



AngularJS vs. jQuery

AngularJS und jQuery übernehmen sehr unterschiedliche Ideologien. Wenn Sie von jQuery kommen, können einige der Unterschiede überraschend sein. Angular kann dich wütend machen.

Das ist normal, du solltest dich durchsetzen. Eckig ist es wert.

Der große Unterschied (TLDR)

jQuery bietet Ihnen ein Toolkit zum Auswählen beliebiger Bits des DOM und zum Durchführen von Ad-hoc-Änderungen an ihnen. Sie können so ziemlich alles tun, was Sie Stück für Stück mögen.

AngularJS gibt Ihnen stattdessen eine Compiler.

Was das bedeutet ist, dass AngularJS Ihr gesamtes DOM von oben nach unten liest und es als Code behandelt, buchstäblich als Anweisungen für den Compiler. Während es das DOM durchläuft, sucht es spezifisch Richtlinien (Compiler-Direktiven), die dem AngularJS-Compiler mitteilen, wie er sich verhalten soll und was zu tun ist. Direktiven sind kleine Objekte voller JavaScript, die mit Attributen, Tags, Klassen oder sogar Kommentaren übereinstimmen können.

Wenn der Angular-Compiler feststellt, dass ein Teil des DOM einer bestimmten Direktive entspricht, ruft er die directive-Funktion auf und übergibt ihr das DOM-Element, alle Attribute, den aktuellen $ -Scope (ein lokaler Variablenspeicher) und einige andere nützliche Bits. Diese Attribute können Ausdrücke enthalten, die von der Direktive interpretiert werden können und die angeben, wie sie zu rendern sind und wann sie sich neu zeichnen sollen.

Anweisungen können dann wiederum zusätzliche Angular-Komponenten wie Controller, Dienste usw. einbeziehen. Was am Ende des Compilers herauskommt, ist eine voll ausgebildete Web-Anwendung, die verdrahtet und betriebsbereit ist.

Dies bedeutet, dass Angular Template-gesteuert ist. Ihre Vorlage steuert das JavaScript, nicht umgekehrt. Dies ist eine radikale Umkehr der Rollen und das komplette Gegenteil des unaufdringlichen JavaScript, das wir in den letzten 10 Jahren geschrieben haben. Dies kann etwas gewöhnungsbedürftig sein.

Wenn das klingt, als wäre es übervorschriftsmäßig und einschränkend, könnte nichts weiter von der Wahrheit entfernt sein. Weil AngularJS Ihren HTML-Code als Code behandelt, erhalten Sie HTML-Level-Granularität in Ihrer Webanwendung. Alles ist möglich, und die meisten Dinge sind überraschend einfach, wenn Sie ein paar konzeptionelle Sprünge machen.

Lassen Sie uns auf das Wesentliche eingehen.

Zunächst ersetzt Angular jQuery nicht

Angular und jQuery machen verschiedene Dinge. AngularJS bietet Ihnen eine Reihe von Tools zur Erstellung von Webanwendungen. jQuery bietet hauptsächlich Werkzeuge zum Ändern des DOM. Wenn jQuery auf Ihrer Seite vorhanden ist, wird AngularJS es automatisch verwenden. Wenn dies nicht der Fall ist, wird AngularJS mit jQuery Lite geliefert, einer zwar heruntergesetzten, aber dennoch vollkommen brauchbaren Version von jQuery.

Misko mag jQuery und erhebt keinen Einspruch gegen die Verwendung von jQuery. Sie werden jedoch feststellen, dass Sie mit einer Kombination aus Bereich, Vorlagen und Anweisungen ziemlich viel Arbeit erledigen können, und Sie sollten diesen Workflow nach Möglichkeit bevorzugen, da Ihr Code diskreter, konfigurierbarer und mehr ist Eckig.

Wenn Sie jQuery verwenden, sollten Sie es nicht überall verteilen. Der richtige Platz für die DOM-Manipulation in AngularJS ist eine Direktive. Mehr dazu später.

Unaufdringliches JavaScript mit Selektoren vs. deklarativen Vorlagen

jQuery wird normalerweise unauffällig angewendet. Ihr JavaScript-Code ist in der Kopfzeile (oder der Fußzeile) verlinkt, und dies ist der einzige Ort, an dem er erwähnt wird. Wir verwenden Selektoren, um Bits der Seite auszuwählen und Plugins zu schreiben, um diese Teile zu modifizieren.

Das JavaScript hat die Kontrolle. Der HTML hat eine völlig unabhängige Existenz. Ihr HTML bleibt auch ohne JavaScript semantisch. Onclick-Attribute sind sehr schlechte Übung.

Eines der ersten Dinge, die Sie an AngularJS bemerken werden, ist das Benutzerdefinierte Attribute sind überall. Ihr HTML wird mit ng-Attributen übersät sein, die im Wesentlichen onClick-Attribute auf Steroiden sind. Dies sind Direktiven (Compiler-Direktiven) und sind eine der Hauptmethoden, mit denen die Vorlage an das Modell angehängt wird.

Wenn Sie das zum ersten Mal sehen, könnten Sie versucht sein, AngularJS als JavaScript der alten Schule zu schreiben (wie ich es zuerst getan habe). Tatsächlich spielt AngularJS diese Regeln nicht. In AngularJS ist Ihr HTML5 eine Vorlage. Es wird von AngularJS erstellt, um Ihre Webseite zu erstellen.

Dies ist der erste große Unterschied. Für jQuery ist Ihre Webseite ein zu manipulierendes DOM. Für AngularJS ist Ihr HTML Code, der kompiliert werden soll. AngularJS liest Ihre gesamte Webseite ein und kompiliert sie buchstäblich in eine neue Webseite mit ihrem eingebauten Compiler.

Ihre Vorlage sollte deklarativ sein; seine Bedeutung sollte klar sein, indem man sie einfach liest. Wir verwenden benutzerdefinierte Attribute mit aussagekräftigen Namen. Wir erstellen neue HTML-Elemente, wiederum mit aussagekräftigen Namen. Ein Designer mit minimalem HTML-Wissen und ohne Programmierkenntnisse kann Ihre AngularJS-Vorlage lesen und verstehen, was sie tut. Er oder sie kann Änderungen vornehmen. Dies ist der Winkelweg.

Die Vorlage sitzt auf dem Fahrersitz.

Eine der ersten Fragen, die ich mir gestellt habe, als ich AngularJS gestartet und die Tutorials durchgelaufen bin, ist "Wo ist mein Code?". Ich habe kein JavaScript geschrieben, und doch habe ich all dieses Verhalten. Die Antwort ist offensichtlich. Da AngularJS das DOM kompiliert, behandelt AngularJS Ihr HTML als Code. Für viele einfache Fälle reicht es oft aus, eine Vorlage zu schreiben und AngularJS diese in eine Anwendung für Sie zu kompilieren.

Ihre Vorlage steuert Ihre Anwendung. Es ist wie behandelt DSL. Sie schreiben AngularJS-Komponenten, und AngularJS kümmert sich darum, sie einzuziehen und sie zur richtigen Zeit basierend auf der Struktur Ihrer Vorlage zur Verfügung zu stellen. Dies ist sehr unterschiedlich zu einem Standard MVC Muster, wo die Vorlage nur für die Ausgabe ist.

Es ist ähnlich wie XSLT als Ruby auf Schienen beispielsweise.

Dies ist eine radikale Umkehr der Kontrolle, an die man sich gewöhnen muss.

Versuchen Sie nicht, Ihre Anwendung über Ihr JavaScript zu steuern. Lassen Sie die Schablone die Anwendung steuern und AngularJS kümmert sich um die Verdrahtung der Komponenten. Dies ist auch der Winkelweg.

Semantisches HTML vs. Semantische Modelle

Mit jQuery sollte Ihre HTML-Seite semantisch bedeutsamen Inhalt enthalten. Wenn das JavaScript deaktiviert ist (durch einen Benutzer oder eine Suchmaschine), bleibt Ihr Inhalt weiterhin zugänglich.

Weil AngularJS Ihre HTML-Seite als Vorlage behandelt. Die Vorlage sollte nicht semantisch sein, da Ihr Content normalerweise in Ihrem Modell gespeichert ist, das letztendlich von Ihrer API stammt. AngularJS kompiliert Ihr DOM mit dem Modell, um eine semantische Webseite zu erstellen.

Ihre HTML-Quelle ist nicht länger semantisch, stattdessen sind Ihre API und das kompilierte DOM semantisch.

In AngularJS, das heißt lebt im Modell, ist das HTML nur eine Vorlage, nur für die Anzeige.

An dieser Stelle haben Sie wahrscheinlich alle möglichen Fragen SEO und Zugänglichkeit, und das zu Recht. Es gibt offene Probleme hier. Die meisten Bildschirmleseprogramme lesen jetzt JavaScript. Suchmaschinen können auch indexieren AJAXed Inhalt. Nichtsdestotrotz sollten Sie sicherstellen, dass Sie URLs im Pushstate verwenden und Sie eine anständige Sitemap haben. Sehen Sie hier für eine Diskussion des Themas: https://stackoverflow.com/a/23245379/687677

Trennung von Bedenken (SOC) vs. MVC

Trennung von Bedenken (SOC) ist ein Muster, das über viele Jahre der Webentwicklung aus einer Vielzahl von Gründen wie SEO, Barrierefreiheit und Browserinkompatibilität entstanden ist. Es sieht aus wie das:

  1. HTML - Semantische Bedeutung. Der HTML sollte alleine stehen.
  2. CSS - Styling, ohne CSS ist die Seite noch lesbar.
  3. JavaScript - Verhalten, ohne das Skript bleibt der Inhalt erhalten.

Auch hier spielt AngularJS nicht nach ihren Regeln. Auf einen Schlag, AngularJS räumt mit einem Jahrzehnt der empfangenen Weisheit auf und implementiert stattdessen ein MVC-Muster, in dem das Template nicht mehr semantisch ist, nicht einmal ein bisschen.

Es sieht aus wie das:

  1. Modell - Ihre Modelle enthalten Ihre semantischen Daten. Modelle sind normalerweise JSON Objekte. Modelle existieren als Attribute eines Objekts namens $ scope. Sie können auch nützliche Dienstprogrammfunktionen auf $ scope speichern, auf die Ihre Vorlagen dann zugreifen können.
  2. Ansicht - Ihre Ansichten sind in HTML geschrieben. Die Ansicht ist normalerweise nicht semantisch, weil Ihre Daten im Modell enthalten sind.
  3. Controller - Ihr Controller ist eine JavaScript-Funktion, die den Blick auf das Modell hakt. Seine Funktion besteht darin, $ scope zu initialisieren. Abhängig von Ihrer Anwendung müssen Sie möglicherweise einen Controller erstellen oder nicht. Sie können viele Controller auf einer Seite haben.

MVC und SOC sind nicht auf gegenüberliegenden Enden der gleichen Skala, sie sind auf völlig verschiedenen Achsen. SOC macht in einem AngularJS-Kontext keinen Sinn. Du musst es vergessen und weitermachen.

Wenn Sie, wie ich, die Browserkriege durchlebt haben, könnten Sie diese Idee ziemlich beleidigend finden. Komm vorbei, es wird es wert sein, versprochen.

Plugins vs. Richtlinien

Plugins erweitern jQuery. AngularJS Direktiven erweitern die Möglichkeiten Ihres Browsers.

In jQuery definieren wir Plugins, indem wir dem jQuery.prototype Funktionen hinzufügen. Wir hängen diese dann in das DOM ein, indem wir Elemente auswählen und das Plugin auf das Ergebnis aufrufen. Die Idee ist, die Fähigkeiten von jQuery zu erweitern.

Wenn Sie beispielsweise ein Karussell auf Ihrer Seite haben möchten, können Sie eine ungeordnete Liste von Figuren definieren, die möglicherweise in ein Navigationselement eingebettet sind. Sie könnten dann einige jQuery schreiben, um die Liste auf der Seite auszuwählen, und sie als Galerie mit Timeouts neu gestalten, um die gleitende Animation auszuführen.

In AngularJS definieren wir Direktiven. Eine Direktive ist eine Funktion, die ein JSON-Objekt zurückgibt. Dieses Objekt teilt AngularJS mit, nach welchen DOM-Elementen gesucht werden soll und welche Änderungen an ihnen vorgenommen werden sollen. Direktiven werden mit der Vorlage verknüpft, indem Sie entweder Attribute oder Elemente verwenden, die Sie erfunden haben. Die Idee ist, die Möglichkeiten von HTML um neue Attribute und Elemente zu erweitern.

Die AngularJS-Methode besteht darin, die Möglichkeiten von nativem HTML zu erweitern. Sie sollten HTML schreiben, das wie HTML aussieht, erweitert um benutzerdefinierte Attribute und Elemente.

Wenn Sie ein Karussell möchten, verwenden Sie einfach ein <carousel /> Element, dann definieren Sie eine Anweisung, um eine Vorlage zu ziehen, und diesen Sauger arbeiten zu lassen.

Viele kleine Direktiven vs. große Plugins mit Konfigurationsschaltern

Die Tendenz mit jQuery besteht darin, große Plugins wie Lightbox zu schreiben, die wir dann konfigurieren, indem wir zahlreiche Werte und Optionen übergeben.

Dies ist ein Fehler in AngularJS.

Nehmen Sie das Beispiel eines Dropdowns. Wenn du ein Dropdown-Plugin schreibst, bist du vielleicht versucht, Klick-Handler einzuprogrammieren, vielleicht eine Funktion, um einen Chevron hinzuzufügen, der entweder oben oder unten ist, vielleicht ändere die Klasse des entfalteten Elements, zeige das Menü verstecken, alles hilfreiche Sachen.

Bis du eine kleine Veränderung vornehmen willst.

Angenommen, Sie haben ein Menü, das Sie mit dem Hover öffnen möchten. Nun, wir haben ein Problem. Unser Plugin ist in unserem Click-Handler für uns verdrahtet worden, wir müssen eine Konfigurationsoption hinzufügen, damit es sich in diesem speziellen Fall anders verhält.

In AngularJS schreiben wir kleinere Direktiven. Unsere Dropdown-Richtlinie wäre lächerlich klein. Es könnte den gefalteten Zustand beibehalten und Methoden zum Falten (), Entfalten () oder Wechseln () bereitstellen. Diese Methoden würden einfach $ scope.menu.visible aktualisieren, was ein Boolescher Zustand ist, der den Zustand enthält.

Jetzt in unserer Vorlage Das können wir verdrahten:

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

Muss bei Mouseover aktualisiert werden?

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

Die Vorlage steuert die Anwendung, sodass wir die Granularität auf HTML-Ebene erhalten. Wenn wir Ausnahmen von Fall zu Fall machen wollen, macht das Template das einfach.

Closure gegen $ Scope

JQuery-Plugins werden in einem Closure erstellt. Die Privatsphäre wird innerhalb dieser Schließung aufrechterhalten. Es liegt an Ihnen, Ihre Scope-Kette innerhalb dieser Schließung zu halten. Sie haben nur wirklich Zugriff auf die Menge von DOM-Knoten, die von jQuery an das Plugin übergeben werden, sowie auf alle lokalen Variablen, die in der Closure definiert sind, sowie auf alle von Ihnen definierten Globalen Variablen. Dies bedeutet, dass Plugins ziemlich eigenständig sind. Dies ist eine gute Sache, kann aber beim Erstellen einer ganzen Anwendung restriktiv werden. Der Versuch, Daten zwischen Abschnitten einer dynamischen Seite zu übergeben, wird zu einer lästigen Aufgabe.

AngularJS hat $ Scope-Objekte. Dies sind spezielle Objekte, die von AngularJS erstellt und verwaltet werden und in denen Sie Ihr Modell speichern. Bestimmte Direktiven erzeugen einen neuen $ scope, der standardmäßig von seinem umschließenden $ scope mit JavaScript-prototypischer Vererbung erbt. Auf das $ scope-Objekt kann im Controller und in der Ansicht zugegriffen werden.

Das ist der schlaue Teil. Da die Struktur der $ scope-Vererbung ungefähr der Struktur des DOM folgt, haben Elemente Zugriff auf ihren eigenen Bereich und alle Bereiche, die Bereiche enthalten, bis hin zum globalen $ -Bereich (der nicht mit dem globalen Bereich identisch ist).

Dies macht es viel einfacher, Daten herumzugeben und Daten auf einer geeigneten Ebene zu speichern. Wenn ein Dropdown-Fenster geöffnet wird, muss nur der Drop-down-Bereich "$" darüber informiert werden. Wenn der Benutzer seine Einstellungen aktualisiert, möchten Sie möglicherweise den globalen $ scope aktualisieren, und alle verschachtelten Bereiche, die die Benutzereinstellungen überwachen, werden automatisch benachrichtigt.

Das mag sich kompliziert anhören, wenn man sich einmal entspannt, ist es wie fliegen. Sie müssen das $ scope -Objekt nicht erstellen, AngularJS instanziiert und konfiguriert es für Sie korrekt und angemessen basierend auf Ihrer Vorlagenhierarchie. AngularJS stellt es dann Ihrer Komponente mit der Magie der Abhängigkeitsinjektion zur Verfügung (mehr dazu später).

Manuelle DOM-Änderungen im Vergleich zur Datenbindung

In jQuery machen Sie alle Ihre DOM-Änderungen von Hand. Sie konstruieren neue DOM-Elemente programmatisch. Wenn Sie ein JSON-Array haben und es in das DOM einfügen möchten, müssen Sie eine Funktion schreiben, um den HTML-Code zu generieren und einzufügen.

In AngularJS können Sie dies auch tun, aber Sie werden ermutigt, Datenbindung zu verwenden. Ändern Sie Ihr Modell, und da das DOM über eine Vorlage an es gebunden ist, wird Ihr DOM automatisch aktualisiert und es ist keine Intervention erforderlich.

Da die Datenbindung aus der Vorlage mithilfe eines Attributs oder der geschweiften Klammersyntax erfolgt, ist dies sehr einfach. Es ist wenig kognitiver Overhead damit verbunden, so dass Sie es die ganze Zeit tun werden.

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

Bindet das Eingabeelement an $scope.user.name. Durch Aktualisieren der Eingabe wird der Wert in Ihrem aktuellen Bereich aktualisiert und umgekehrt.

Gleichfalls:

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

gibt den Benutzernamen in einem Absatz aus. Es ist eine Live-Bindung, also wenn $scope.user.name Wert wird aktualisiert, die Vorlage wird ebenfalls aktualisiert.

Ajax die ganze Zeit

In jQuery ist es ziemlich einfach, einen Ajax-Aufruf zu machen, aber es ist immer noch etwas, an das man zweimal denken sollte. Es gibt die zusätzliche Komplexität, über die man nachdenken muss, und einen ordentlichen Teil des zu wartenden Skripts.

In AngularJS ist Ajax die Standard-Lösung für Sie und es passiert die ganze Zeit, fast ohne dass Sie es bemerken. Sie können Vorlagen mit ng-include hinzufügen. Sie können eine Vorlage mit der einfachsten benutzerdefinierten Anweisung anwenden. Sie können einen Ajax-Anruf in einem Dienst umbrechen und sich selbst einen erstellen GitHub Service oder a Flickr Service, auf den Sie mit erstaunlicher Leichtigkeit zugreifen können.

Dienstobjekte gegen Hilfsfunktionen

Wenn wir in jQuery eine kleine, nicht-dombezogene Aufgabe erledigen möchten, wie zum Beispiel das Ziehen eines Feeds von einer API, schreiben wir vielleicht eine kleine Funktion, um das in unserer Schließung zu tun. Das ist eine gültige Lösung, aber was ist, wenn wir häufig auf dieses Feed zugreifen möchten? Was, wenn wir diesen Code in einer anderen Anwendung wiederverwenden wollen?

AngularJS gibt uns Service-Objekte.

Dienste sind einfache Objekte, die Funktionen und Daten enthalten. Sie sind immer Singletons, was bedeutet, dass es niemals mehr als einen von ihnen geben kann. Angenommen, wir möchten auf die Stack Overflow API zugreifen, schreiben wir möglicherweise eine StackOverflowService was definiert Methoden dafür.

Nehmen wir an, wir haben einen Einkaufswagen. Wir könnten einen ShoppingCartService definieren, der unseren Warenkorb verwaltet und Methoden zum Hinzufügen und Entfernen von Artikeln enthält. Da der Dienst ein Singleton ist und von allen anderen Komponenten gemeinsam genutzt wird, kann jedes Objekt, das benötigt wird, in den Einkaufswagen schreiben und Daten daraus abrufen. Es ist immer der selbe Wagen.

Service-Objekte sind eigenständige AngularJS-Komponenten, die wir verwenden und wiederverwenden können, wie wir es für richtig halten. Sie sind einfache JSON-Objekte, die Funktionen und Daten enthalten. Es handelt sich immer um Singletons. Wenn Sie also Daten in einem Dienst an einem Ort speichern, können Sie diese Daten an anderer Stelle abrufen, indem Sie den gleichen Dienst anfordern.

Abhängigkeitsspritze (DI) vs. Instatiation - aka De-Spaghettifikation

AngularJS verwaltet Ihre Abhängigkeiten für Sie. Wenn Sie ein Objekt wünschen, beziehen Sie sich einfach darauf und AngularJS wird es für Sie bekommen.

Bis Sie beginnen, dies zu verwenden, ist es schwer zu erklären, was für eine gewaltige Zeit Segen das ist. Nichts wie AngularJS DI existiert in jQuery.

DI bedeutet, dass Sie anstatt Ihre Anwendung zu schreiben und zu verbinden, stattdessen eine Bibliothek von Komponenten definieren, die jeweils durch einen String identifiziert werden.

Angenommen, ich habe eine Komponente namens "FlickrService", die Methoden zum Ziehen von JSON-Feeds von Flickr definiert. Nun, wenn ich einen Controller schreiben möchte, der auf Flickr zugreifen kann, muss ich nur auf den "FlickrService" mit Namen verweisen, wenn ich den Controller deklariere. AngularJS kümmert sich um die Instantiierung der Komponente und stellt sie meinem Controller zur Verfügung.

Zum Beispiel definiere ich hier einen Service:

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

Jetzt, wenn ich diesen Dienst benutzen möchte, beziehe ich mich nur auf seinen Namen wie folgt:

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

AngularJS erkennt, dass ein FlickrService-Objekt benötigt wird, um den Controller zu instanziieren, und stellt einen für uns bereit.

Dies macht die Verdrahtung der Dinge sehr einfach und beseitigt praktisch jede Tendenz zur Spättigung. Wir haben eine flache Liste von Komponenten, und AngularJS übergibt sie uns eins nach dem anderen, wenn wir sie brauchen.

Modulare Servicearchitektur

jQuery sagt sehr wenig darüber, wie Sie Ihren Code organisieren sollten. AngularJS hat Meinungen.

AngularJS bietet Ihnen Module, in die Sie Ihren Code einfügen können. Wenn Sie beispielsweise ein Skript schreiben, das mit Flickr kommuniziert, möchten Sie vielleicht ein Flickr-Modul erstellen, um alle Ihre Flickr-bezogenen Funktionen einzubinden. Module können andere Module (DI) enthalten. Ihre Hauptanwendung ist normalerweise ein Modul, und dies sollte alle anderen Module enthalten, von denen Ihre Anwendung abhängig ist.

Sie erhalten einfache Code-Wiederverwendung, wenn Sie eine andere Anwendung auf Flickr schreiben möchten, können Sie einfach das Flickr-Modul und voila, Sie haben Zugriff auf alle Ihre Flickr verwandten Funktionen in Ihrer neuen Anwendung.

Module enthalten AngularJS-Komponenten. Wenn wir ein Modul einschließen, stehen uns alle Komponenten in diesem Modul als eine einfache Liste zur Verfügung, die durch ihre eindeutigen Strings identifiziert wird. Wir können dann diese Komponenten mithilfe des AngularJS-Mechanismus für die Abhängigkeitsinjektion ineinander injizieren.

Um zusammenzufassen

AngularJS und jQuery sind keine Feinde. Es ist möglich, jQuery in AngularJS sehr gut zu verwenden. Wenn Sie AngularJS gut verwenden (Vorlagen, Datenbindung, $ Scope, Direktiven usw.), werden Sie feststellen, dass Sie eine benötigen Menge weniger jQuery als Sie möglicherweise benötigen.

Die wichtigste Erkenntnis ist, dass Ihre Vorlage Ihre Anwendung antreibt. Hör auf, große Plugins zu schreiben, die alles machen. Schreiben Sie stattdessen kleine Anweisungen, die eine Sache machen, und schreiben Sie dann eine einfache Vorlage, um sie miteinander zu verbinden.

Denken Sie weniger an unaufdringliches JavaScript und denken Sie stattdessen an HTML-Erweiterungen.

Mein kleines Buch

Ich habe mich so sehr über AngularJS gefreut, ich habe ein kurzes Buch darüber geschrieben, das du gerne online lesen kannst http://nicholasjohnson.com/angular-book/. Ich hoffe, es ist hilfreich.


184
2018-05-12 10:22



Können Sie den Paradigmenwechsel beschreiben, der notwendig ist?

Imperativ gegen Deklarativ

Mit jQuery Sie sagen dem DOM Schritt für Schritt, was geschehen muss. Mit AngularJS Sie beschreiben, was Sie wollen, aber nicht wie Sie es tun. Mehr dazu Hier. Schau dir auch Mark Rajcoks Antwort an.

Wie kann ich clientseitige Web-Apps anders gestalten und gestalten?

AngularJS ist ein gesamter clientseitiger Rahmen, der den MVC Muster (überprüfen Sie ihre grafische Darstellung). Es konzentriert sich stark auf die Trennung von Anliegen.

Was ist der größte Unterschied? Was soll ich aufhören / benutzen? Was soll ich stattdessen tun / verwenden?

jQueryist eine Bibliothek

AngularJS ist ein schönes client-seitiges Framework, das hochgradig testbar ist und viele tolle Sachen wie MVC, Abhängigkeitsspritze, Datenbindung und vieles mehr.

Es konzentriert sich auf Trennung von Bedenken und Testen (Komponententest und Ende-zu-Ende-Tests), was die testgetriebene Entwicklung erleichtert.

Der beste Weg, um zu beginnen, ist durch ihr tolles Tutorial. Sie können die Schritte in ein paar Stunden durchlaufen; Wenn Sie jedoch die Konzepte hinter den Kulissen meistern möchten, enthalten sie eine Vielzahl von Referenzen für das weitere Lesen.

Gibt es serverseitige Überlegungen / Einschränkungen?

Sie können es für vorhandene Anwendungen verwenden, in denen Sie bereits reines jQuery verwenden. Wenn Sie jedoch die AngularJS-Funktionen voll ausnutzen möchten, können Sie die Server-Seite mit Hilfe von a codieren RESTful Ansatz.

Auf diese Weise können Sie ihre nutzen Ressourcenfabrik, die eine Abstraktion Ihrer Serverseite RESTful erstellt API und macht serverseitige Anrufe (holen, speichern, löschen, etc.) unglaublich einfach.


152
2018-02-21 04:29



Um den "Paradigmenwechsel" zu beschreiben, kann eine kurze Antwort genügen.

AngularJS verändert die Art und Weise wie Sie finden Elemente

Im jQuery, die du normalerweise benutzt Selektoren Elemente finden und dann verkabeln:
$('#id .class').click(doStuff);

Im AngularJS, Sie nutzen Richtlinien um die Elemente direkt zu markieren, um sie zu verdrahten:
<a ng-click="doStuff()">

AngularJS benötigt (oder möchte) nicht, dass Sie Elemente mithilfe von Selektoren finden - der Hauptunterschied zwischen AngularJS jqLite gegen voll ausgewachsen jQuery ist das jqLite unterstützt keine Selektoren.

Wenn Leute sagen "jQuery überhaupt nicht mit einbeziehen", liegt das hauptsächlich daran, dass sie nicht möchten, dass Sie Selektoren verwenden. Sie möchten, dass Sie stattdessen lernen, Anweisungen zu verwenden. Direkt, nicht auswählen!


84
2018-02-21 07:57



jQuery

jQuery macht lächerlich lange JavaScript-Befehle wie getElementByHerpDerp kürzer und browserübergreifend

AngularJS

AngularJS ermöglicht Ihnen, Ihre eigenen HTML-Tags / Attribute zu erstellen, die Dinge tun, die gut mit dynamischen Webanwendungen funktionieren (da HTML für statische Seiten entwickelt wurde).

Bearbeiten:

Sprich: "Ich habe einen jQuery-Hintergrund, wie denke ich in AngularJS?" ist wie "Ich habe einen HTML-Hintergrund, wie denke ich in JavaScript?" Die Tatsache, dass Sie die Frage stellen, zeigt, dass Sie die grundlegenden Ziele dieser beiden Ressourcen höchstwahrscheinlich nicht verstehen. Deshalb habe ich mich entschieden, die Frage zu beantworten, indem ich einfach auf den grundlegenden Unterschied hindeute, anstatt die Liste durchzugehen: "AngularJS verwendet Direktiven, während jQuery CSS-Selektoren verwendet, um ein jQuery-Objekt zu erstellen, das dies und das usw. tut." . Diese Frage erfordert keine lange Antwort.

jQuery ist eine Möglichkeit, JavaScript im Browser einfacher zu programmieren. Kürzere, browserübergreifende Befehle usw.

AngularJS erweitert HTML, also müssen Sie nicht setzen <div> überall nur um eine Bewerbung zu machen. Es macht HTML tatsächlich für Anwendungen und nicht für das, wofür es entworfen wurde, nämlich statische Lernseiten. Es erreicht dies auf Umwegen mit JavaScript, aber im Grunde ist es eine Erweiterung von HTML, nicht von JavaScript.


69
2018-02-04 05:07



jQuery: Du denkst viel über das 'QUERying the DOM'für DOM-Elemente und etwas tun.

AngularJS: Das Modell ist die Wahrheit, und Sie denken immer von diesem ANGLE.

Wenn Sie beispielsweise Daten vom Server abrufen, die Sie in einem bestimmten Format im DOM anzeigen möchten, müssen Sie in jQuery "1. FIND 'wo im DOM Sie diese Daten platzieren möchten, die' 2. UPDATE / APPEND 'es dort, indem Sie einen neuen Knoten erstellen oder einfach nur dessen setzen innerHTML. Wenn Sie diese Ansicht dann aktualisieren möchten, dann '3. FIND 'den Ort und' 4. AKTUALISIEREN'. Dieser Zyklus von Suchen und Aktualisieren im gleichen Kontext, in dem Daten vom Server abgerufen und formatiert werden, ist in AngularJS verschwunden.

Mit AngularJS haben Sie Ihr Modell (JavaScript-Objekte, an die Sie bereits gewöhnt sind) und der Wert des Modells informiert Sie (offensichtlich) über das Modell und eine Operation auf dem Modell wird automatisch an die Ansicht weitergegeben. Ich muss darüber nachdenken. Sie werden feststellen, dass AngularJS keine Dinge mehr im DOM findet.

Um es anders auszudrücken, müssen Sie in jQuery über CSS-Selektoren nachdenken, dh wo ist das? div oder td das hat eine Klasse oder ein Attribut, etc., so dass ich ihren HTML oder Farbe oder Wert bekommen kann, aber in AngularJS wirst du dich so denken: mit welchem ​​Modell ich mich beschäftige, ich werde den Wert des Modells auf wahr setzen. Sie kümmern sich nicht darum, ob die Ansicht, die diesen Wert widerspiegelt, ein Kontrollkästchen ist oder sich in einem befindet td Element (Details, über die Sie in jQuery oft nachdenken müssten).

Und mit der DOM-Manipulation in AngularJS fügen Sie Direktiven und Filter hinzu, die Sie als gültige HTML-Erweiterungen betrachten können.

Eine weitere Sache, die Sie in AngularJS erleben werden: In jQuery nennen Sie die jQuery-Funktionen viel, in AngularJS wird AngularJS Ihre Funktionen aufrufen, also wird AngularJS Ihnen sagen, wie man Dinge macht, aber die Vorteile sind es wert, also AngularJS zu lernen bedeutet in der Regel, zu lernen, was AngularJS will oder wie AngularJS es erfordert, dass Sie Ihre Funktionen präsentieren und es entsprechend aufrufen. Dies ist einer der Gründe, warum AngularJS eher ein Framework als eine Bibliothek ist.


61
2017-11-02 16:53



Das sind einige sehr schöne, aber lange Antworten.

Um meine Erfahrungen zusammenzufassen:

  1. Controller und Provider (Dienste, Fabriken, etc.) sind für die Änderung des Datenmodells, nicht HTML.
  2. HTML und Direktiven definieren das Layout und die Bindung an das Modell.
  3. Wenn Sie Daten zwischen Controllern austauschen müssen, erstellen Sie einen Service oder eine Factory - es handelt sich um Singletons, die in der gesamten Anwendung gemeinsam genutzt werden.
  4. Wenn Sie ein HTML-Widget benötigen, erstellen Sie eine Direktive.
  5. Wenn Sie Daten haben und jetzt versuchen, HTML zu aktualisieren ... STOP! Aktualisieren Sie das Modell und stellen Sie sicher, dass Ihr HTML an das Modell gebunden ist.

46
2018-05-16 21:50



jQuery ist eine DOM-Manipulationsbibliothek.

AngularJS ist ein MV * Framework.

Tatsächlich ist AngularJS eines der wenigen JavaScript MV * -Frameworks (viele JavaScript MVC-Tools fallen immer noch unter die Kategorie-Bibliothek).

Als Framework hostet es Ihren Code und übernimmt die Verantwortung für Entscheidungen darüber, was wann angerufen werden soll!

AngularJS selbst enthält eine jQuery-lite-Edition. Für einige grundlegende DOM-Auswahl / Manipulation müssen Sie also die jQuery-Bibliothek nicht wirklich mit einschließen (es speichert viele Bytes, um im Netzwerk zu laufen.)

AngularJS hat das Konzept der "Direktiven" für die DOM-Manipulation und das Design wiederverwendbarer UI-Komponenten. Sie sollten es also immer dann verwenden, wenn Sie DOM-Manipulationen benötigen (Directions sind nur der Ort, an dem Sie während der Verwendung von AngularJS jQuery-Code schreiben sollten).

AngularJS beinhaltet eine Lernkurve (mehr als jQuery :-).

-> Für jeden Entwickler, der aus dem jQuery-Hintergrund kommt, wäre mein erster Ratschlag, "JavaScript als eine erstklassige Sprache zu lernen, bevor ich auf ein reichhaltiges Framework wie AngularJS steige!" Ich habe die obige Tatsache auf die harte Art gelernt.

Viel Glück.


45
2017-10-10 08:58



Sie sind Äpfel und Orangen. Sie wollen sie nicht vergleichen. Sie sind zwei verschiedene Dinge. AngularJs hat bereits jQuery lite eingebaut, mit dem Sie grundlegende DOM-Manipulationen durchführen können, ohne die komplette jQuery-Version mit einzubeziehen.

jQuery dreht sich alles um DOM-Manipulation. Es löst all die Cross-Browser-Probleme, mit denen Sie sich sonst auseinandersetzen müssen, aber es ist kein Framework, mit dem Sie Ihre App in Komponenten wie AngularJS aufteilen können.

Eine nette Sache bei AngularJs ist, dass Sie die DOM-Manipulation in den Direktiven trennen / isolieren können. Es gibt integrierte Anweisungen, die Sie verwenden können, z. B. ng-click. Sie können eigene benutzerdefinierte Direktiven erstellen, die all Ihre Ansichtslogik oder DOM-Manipulation enthalten, damit Sie den DOM-Manipulationscode nicht in den Controllern oder Diensten mischen, die sich um die Geschäftslogik kümmern sollten.

Angular bricht Ihre App in - Controller - Dienstleistungen - Ansichten - etc.

und da ist noch eine Sache, das ist die Richtlinie. Es ist ein Attribut, das Sie an ein beliebiges DOM-Element anhängen können, und Sie können mit jQuery verrückt werden, ohne sich Sorgen darüber machen zu müssen, dass Ihre jQuery jemals mit AngularJs-Komponenten in Konflikt gerät oder ihre Architektur durcheinander bringt.

Ich hörte von einem Treffen, an dem ich teilnahm, einer der Gründer von Angular sagte, dass sie wirklich hart gearbeitet haben, um die DOM-Manipulation zu trennen, also versuche nicht, sie wieder einzubinden.


34
2017-08-14 14:19



Höre auf den Podcast JavaScript Jabber: Episode # 32 Dies beinhaltet die ursprünglichen Schöpfer von AngularJS: Misko Hevery & Igor Minar. Sie reden viel darüber, wie es ist, von anderen JavaScript-Hintergründen zu AngularJS zu kommen, besonders von jQuery.

Einer der Punkte, die im Podcast gemacht wurden, machte eine Menge Dinge Klick für mich mit Respekt für Ihre Frage:

Misko: [...] Eines der Dinge, über die wir in Angular kaum nachgedacht haben, ist, wie wir viele Fluchtluken bereitstellen, damit du rauskommen und im Grunde einen Ausweg finden kannst. Für uns lautet die Antwort "Richtlinien". Und mit Direktiven wirst Du quasi zu einem normalen kleinen jQuery-JavaScript, Du kannst machen, was Du willst.

IGOR: Denken Sie also an Direktive als Anweisung an den Compiler, die ihm sagt, wann immer Sie auf dieses bestimmte Element oder dieses CSS in der Vorlage stoßen, und Sie behalten diese Art von Code und dieser Code ist verantwortlich für das Element und alles unter diesem Element in der DOM-Baum.

Eine Abschrift der gesamten Episode ist unter dem oben angegebenen Link verfügbar.

Also, um Ihre Frage direkt zu beantworten: AngularJS ist - sehr eigensinnig und ist ein echtes MV * Framework. Sie können jedoch all die wirklich coolen Sachen, die Sie kennen und lieben, mit jQuery innerhalb von Direktiven machen. Es geht nicht darum, "Wie mache ich das, was ich in jQuery gewohnt bin?" so viel wie es ist eine Frage von "Wie ergänze ich AngularJS mit all den Sachen, die ich in jQuery gemacht habe?"

Es sind wirklich zwei sehr verschiedene Geisteszustände.


31
2017-11-08 16:08