javascript lite „Denken in AngularJS“, wenn ich einen jQuery-Hintergrund habe?




jqlite find (12)

1. Gestalten 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 Erweiterung entwickelt wurde und von dieser einfachen Voraussetzung aus unglaublich gewachsen ist.

In AngularJS müssen Sie jedoch im Hinblick auf Ihre Architektur von vorn anfangen. Anstatt mit dem Gedanken zu beginnen "Ich habe dieses Stück DOM und ich möchte, dass es X macht", müssen Sie mit dem beginnen, was Sie erreichen wollen, dann Ihre Anwendung entwerfen und schließlich Ihre Ansicht entwerfen.

2. Erweitern Sie jQuery nicht mit AngularJS

Beginnen Sie auch nicht mit der Idee, dass jQuery X, Y und Z hat, also füge ich AngularJS für Modelle und Controller hinzu. Dies ist wirklich verlockend, wenn Sie gerade erst anfangen. Deshalb empfehle ich den neuen AngularJS-Entwicklern, jQuery überhaupt nicht zu verwenden, zumindest bis sie sich daran gewöhnt haben, Dinge auf "Angular Way" zu erledigen.

Ich habe viele Entwickler hier und auf der Mailingliste gesehen, die diese aufwendigen Lösungen mit jQuery-Plugins mit 150 oder 200 Codezeilen erstellten, die sie dann mit einer Sammlung von Rückrufen und $apply , die verwirrend und verwunden sind, in AngularJS einkleben. aber sie schaffen es schließlich! Das Problem ist, dass das jQuery-Plugin in den meisten Fällen in einem Bruchteil des Codes in AngularJS umgeschrieben werden kann, wo plötzlich alles verständlich und unkompliziert wird.

Das Fazit lautet: Wenn Sie das Problem lösen, denken Sie zuerst an "AngularJS". Wenn Sie keine Lösung finden, fragen Sie die Community. Wenn es nach all dem keine einfache Lösung gibt, können Sie sich gerne an die jQuery wenden. Aber lassen Sie jQuery nicht zu einer Krücke werden, sonst werden Sie AngularJS niemals beherrschen.

3. Denken Sie immer in Architektur

Zuerst wissen Sie, dass Einseitenanwendungen Anwendungen sind. Sie sind keine Webseiten. Daher müssen wir als serverseitiger Entwickler und nicht als clientseitiger Entwickler denken. Wir müssen uns überlegen, wie wir unsere Anwendung in einzelne, erweiterbare, testbare Komponenten unterteilen können.

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

Die Ansicht ist die "offizielle Aufzeichnung"

In jQuery ändern wir die Ansicht programmgesteuert. Wir könnten ein Dropdown-Menü wie folgt definieren:

<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 mit etwas aktivieren:

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

Wenn wir nur die Ansicht betrachten, ist es nicht sofort offensichtlich, dass hier irgendwelche Funktionen vorhanden sind. Für kleine Anwendungen ist das in Ordnung. Bei nicht trivialen Anwendungen werden die Dinge jedoch schnell verwirrend und schwer zu warten.

In AngularJS ist die Ansicht jedoch die offizielle Aufzeichnung der ansichtsbasierten Funktionalität. Unsere ul Deklaration würde stattdessen so aussehen:

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

Diese beiden machen dasselbe, aber in der AngularJS-Version weiß jeder, der die Vorlage betrachtet, was geschehen soll. Jedes Mal, wenn ein neues Mitglied des Entwicklungsteams an Bord kommt, kann sie sich dies ansehen und dann wissen, dass eine Direktive namens dropdownMenu vorhanden ist. Sie muss nicht die richtige Antwort verstehen oder Code durchforsten. Die Aussicht sagte uns, was geschehen sollte. Viel sauberer

Entwickler, die neu bei AngularJS sind, stellen häufig Fragen 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 tun es nicht. Der Grund, warum Sie das nicht tun, ist, dass dies wie half-jQuery, half-AngularJS und nicht gut ist. Das Problem hierbei ist, dass der Entwickler versucht, "jQuery" im Kontext von AngularJS auszuführen. Das wird nie gut funktionieren. Die Ansicht ist die offizielle Aufzeichnung. Außerhalb einer Direktive (mehr dazu weiter unten) ändern Sie niemals das DOM. Und Richtlinien werden in der Ansicht angewendet, sodass die Absicht klar ist.

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

Datenbindung

Dies ist bei weitem eine der erstaunlichsten Funktionen von AngularJS und macht die Notwendigkeit, die Arten von DOM-Manipulationen auszuführen, die ich im vorigen Abschnitt erwähnt habe, überflüssig. AngularJS aktualisiert Ihre Ansicht automatisch, so dass Sie dies nicht tun müssen! In jQuery reagieren wir auf Ereignisse und aktualisieren dann den Inhalt. So etwas wie:

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

Für eine Ansicht, die so aussieht:

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

Abgesehen von der Vermischung von Bedenken haben wir auch die gleichen Probleme, die ich angedeutet habe. Noch wichtiger war jedoch, dass wir einen DOM-Knoten manuell referenzieren und aktualisieren mussten. Und wenn wir einen Protokolleintrag löschen wollen, müssen wir auch dafür gegen das DOM kodieren. Wie testen wir die Logik neben dem DOM? Und was ist, wenn wir die Präsentation ändern möchten?

Dies ist ein bisschen unordentlich und ein bisschen schwach. In AngularJS können wir Folgendes 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 in dieser Hinsicht könnte unsere Ansicht so aussehen:

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

Anstatt eine ungeordnete Liste zu verwenden, verwenden wir jetzt Bootstrap-Alarmboxen. Und wir mussten den Controller-Code nie ändern! Aber was noch wichtiger ist, egal wo und wie das Protokoll aktualisiert wird, ändert sich auch die Ansicht. Automatisch. Ordentlich!

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

Eindeutige Modellebene

In jQuery ähnelt das DOM dem Modell. In AngularJS haben wir jedoch eine separate Modellebene, die wir auf beliebige Weise verwalten können, völlig unabhängig von der Ansicht. Dies hilft bei der obigen Datenbindung, hält die Trennung der Bedenken aufrecht und führt zu einer weitaus besseren Testbarkeit. Andere Antworten erwähnten diesen Punkt, also lass ich es einfach dabei.

Trennung von Bedenken

Und all das oben erwähnte in diesem übergreifenden Thema: Halten Sie Ihre Anliegen getrennt. Ihre Ansicht dient als offizielle Aufzeichnung dessen, was (zum größten Teil) geschehen soll; Ihr Modell repräsentiert Ihre Daten. Sie haben eine Service-Schicht, um wiederverwendbare Aufgaben auszuführen. Sie führen DOM-Manipulationen durch und erweitern Ihre Ansicht mit Anweisungen. und Sie kleben alles mit Controllern zusammen. 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 besprechen werde.

Abhängigkeitsspritze

Um uns bei der Trennung von Anliegen zu unterstützen, ist Abhängigkeitsinjektion (DI). Wenn Sie aus einer serverseitigen Sprache (von Java bis PHP ) kommen, kennen Sie dieses Konzept wahrscheinlich bereits. Wenn Sie jedoch auf jQuery von jQuery kommen, kann dieses Konzept von albern überflüssig bis hin zu Hipster wirken . Aber es ist nicht. :-)

Im weitesten Sinne bedeutet DI, dass Sie Komponenten sehr frei deklarieren können, und dann von jeder anderen Komponente aus, fragen Sie nach einer Instanz davon, und diese wird gewährt. Sie müssen nicht über das Laden der Reihenfolge oder Dateispeicherorte oder ähnliches Bescheid wissen. Die Leistung ist möglicherweise nicht sofort sichtbar, aber ich möchte nur ein (allgemeines) Beispiel nennen: Testen.

Angenommen, wir benötigen in unserer Anwendung einen Dienst, der serverseitigen Speicher über eine REST API und, abhängig vom Anwendungsstatus, auch lokalen Speicher implementiert. Wenn wir Tests auf unseren Controllern ausführen, möchten wir nicht mit dem Server kommunizieren. Wir testen den Controller schließlich. Wir können einfach einen Mock-Service hinzufügen, der den gleichen Namen wie unsere ursprüngliche Komponente hat, und der Injektor sorgt dafür, dass unser Controller den gefälschten automatisch erhält - unser Controller weiß nicht und muss den Unterschied nicht 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 seinen eigenen Abschnitt auf oberster Ebene bezeichne.

Wie viele von ihnen hatten bereits eine Vielzahl von jQuery-Plugins, die Sie gesehen, verwendet oder geschrieben haben? Nicht sehr viele, weil jQuery dem nicht sehr zugänglich ist. Aber AngularJS ist.

In jQuery besteht die einzige Möglichkeit zum Testen darin, die Komponente mit einer Muster- / Demo-Seite unabhängig voneinander zu erstellen, auf der unsere Tests die DOM-Manipulation durchführen können. Dann müssen wir eine Komponente separat entwickeln und dann in unsere Anwendung integrieren. Wie unbequem! Bei der Entwicklung mit jQuery entscheiden wir uns häufig für eine iterative anstelle einer testgetriebenen Entwicklung. Und wer könnte uns die Schuld geben?

Da wir jedoch die Bedenken getrennt haben, können wir in AngularJS eine testgetriebene Entwicklung iterativ durchführen! Nehmen wir zum Beispiel an, wir möchten mit einer supereinfachen Direktive in unserem Menü unsere aktuelle Route angeben. Wir können erklären, was wir aus Sicht unserer Bewerbung wollen:

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

Okay, jetzt können wir einen Test für die nicht vorhandene Direktive Direktive schreiben:

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 der Test 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 ist nun bestanden und unser Menü funktioniert wie gewünscht. Unsere Entwicklung ist sowohl iterativ als auch testgetrieben. Verdammt cool.

5. Richtlinien sind konzeptionell nicht in jQuery gepackt

Sie hören oft "nur DOM-Manipulationen in einer Direktive". Das ist eine Notwendigkeit. Behandle es mit gebührender Ehrerbietung!

Aber lass uns tiefer eintauchen ...

Einige Anweisungen verzieren nur das, was sich bereits in der Ansicht befindet (denken ngClass an ngClass ), und machen daher manchmal die DOM-Manipulation sofort und werden dann im Grunde gemacht. Wenn eine Anweisung jedoch wie ein "Widget" ist und eine Vorlage hat, sollte sie auch die Trennung der Bedenken berücksichtigen. Das heißt, auch das Template sollte weitgehend unabhängig von seiner Implementierung in den Link- und Controller-Funktionen bleiben.

AngularJS wird mit einer ganzen Reihe von Tools geliefert, die dies sehr einfach machen. Mit ngClass wir die Klasse dynamisch aktualisieren. ngModel ermöglicht die ngModel Datenbindung. ngShow und ngHide zeigen oder verbergen ein Element programmgesteuert; und viele mehr - einschließlich derer, die wir selbst schreiben. Mit anderen Worten, wir können alle Arten von Großartigkeit ohne DOM-Manipulation ausführen. Je weniger DOM-Manipulationen erforderlich sind, desto einfacher sind die zu testenden Anweisungen, je einfacher sie zu formatieren sind, desto leichter lassen sie sich in der Zukunft ändern und desto mehr können sie wiederverwendet und verteilt werden.

Ich sehe viele Entwickler von AngularJS neu, die Richtlinien verwenden, um eine Menge jQuery zu werfen. Mit anderen Worten, sie denken, "da ich keine DOM-Manipulation im Controller durchführen kann, nehme ich diesen Code in eine Direktive". Während das sicherlich viel besser ist, ist es oft noch falsch .

Denken Sie an den Logger, den wir in Abschnitt 3 programmiert haben. Selbst wenn wir das in eine Direktive schreiben, wollen wir es immer noch "Angular Way" machen. Es bedarf noch keiner DOM-Manipulation! In vielen Fällen ist eine DOM-Manipulation erforderlich, aber es ist viel seltener, als Sie denken! Bevor Sie die DOM-Manipulation irgendwo in Ihrer Anwendung vornehmen, sollten Sie sich fragen, ob Sie dies wirklich benötigen. Es könnte einen besseren Weg geben.

Hier ist ein kurzes Beispiel, das das Muster zeigt, das ich am häufigsten sehe. Wir möchten einen umschaltbaren Knopf. (Hinweis: Dieses Beispiel ist ein wenig durchdacht und ein wenig ausführlich, um kompliziertere Fälle darzustellen, die auf dieselbe 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);
            });
        }
    };
});

Daran sind ein paar Dinge falsch:

  1. Erstens war jQuery nie notwendig. Es gibt nichts, was wir hier gemacht haben, das jQuery überhaupt brauchte!
  2. Zweitens, selbst wenn wir bereits jQuery auf unserer Seite haben, gibt es keinen Grund, es hier zu verwenden. Wir können einfach angular.element und unsere Komponente funktioniert immer noch, wenn sie in einem Projekt abgelegt wird, das nicht über jQuery verfügt.
  3. Drittens, selbst wenn man davon ausgeht, dass für diese Anweisung jQuery erforderlich ist, verwendet jqLite ( angular.element ) immer jQuery, wenn es geladen wurde! Wir brauchen also nicht das $ - wir können einfach angular.element .
  4. Viertens, eng mit dem dritten verwandt, ist, dass jqLite-Elemente nicht in $ - das element , das an die link Funktion übergeben wird, wäre bereits ein jQuery-Element!
  5. Und fünftens, was wir in den vorangegangenen Abschnitten erwähnt haben, warum mischen wir Vorlagen in unsere Logik?

Diese Direktive kann (auch 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;
            };
        }
    };
});

Das Vorlagenmaterial befindet sich wieder in der Vorlage, sodass Sie (oder Ihre Benutzer) es leicht gegen eines austauschen können, das jedem Stil entspricht, und die Logik musste nie berührt werden. Wiederverwendbarkeit - Boom!

Und es gibt noch alle anderen Vorteile, wie das Testen - es ist einfach! Unabhängig davon, was in der Vorlage enthalten ist, wird die interne API der Direktive nie berührt, sodass das Refactoring einfach ist. Sie können die Vorlage beliebig ändern, ohne die Direktive zu berühren. Und egal, was Sie ändern, Ihre Tests bestehen trotzdem.

w00t!

Wenn Direktiven also nicht nur Sammlungen von jQuery-ähnlichen Funktionen sind, was sind sie dann? Direktiven sind eigentlich Erweiterungen von HTML . Wenn HTML nichts tut, was Sie benötigen, schreiben Sie eine Anweisung, die es für Sie erledigt, und verwenden Sie es dann so, als wäre es Teil von HTML.

Anders ausgedrückt: Wenn AngularJS nichts außerhalb des Kastens unternimmt, denken Sie darüber nach, wie das Team es schaffen würde, genau in ngClick , ngClass ngClick zu passen.

Zusammenfassung

Verwenden Sie nicht einmal jQuery. Binden Sie es nicht einmal ein. Es wird dich zurückhalten. Und wenn Sie zu einem Problem kommen, von dem Sie denken, dass Sie bereits wissen, wie es in jQuery zu lösen ist, bevor Sie nach dem $ suchen, versuchen Sie, darüber nachzudenken, wie es innerhalb der Grenzen des AngularJS erledigt werden kann. Wenn Sie es nicht wissen, fragen Sie! In 19 von 20 Fällen ist der beste Weg, um dies zu tun, nicht mit jQuery verbunden, und wenn Sie versuchen, es mit jQuery zu lösen, ist mehr Arbeit für Sie.

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

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

Ich suche keinen detaillierten Vergleich zwischen jQuery und AngularJS .


AngularJS vs. jQuery

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

Das ist normal, Sie sollten sich durchsetzen. Winkelig ist es wert.

Der große Unterschied (TLDR)

Mit jQuery erhalten Sie ein Toolkit, mit dem Sie beliebige Bits des DOM auswählen und ad-hoc-Änderungen daran vornehmen können. Sie können so ziemlich alles tun, was Sie Stück für Stück mögen.

AngularJS gibt Ihnen stattdessen einen Compiler .

Dies bedeutet, dass AngularJS Ihr gesamtes DOM von oben nach unten liest und es als Code behandelt, wörtlich als Anweisungen an den Compiler. Beim Durchlaufen des DOM sucht es nach bestimmten Direktiven (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 mit einer bestimmten Direktive übereinstimmt, ruft er die Direktive auf und übergibt ihm das DOM-Element, alle Attribute, den aktuellen $ scope (einen lokalen Variablenspeicher) und einige andere nützliche Bits. Diese Attribute können Ausdrücke enthalten, die von der Richtlinie interpretiert werden können und in denen angegeben wird, wie sie gerendert werden sollen und wann sie sich selbst neu zeichnen sollten.

Direktiven können dann wiederum zusätzliche Angular-Komponenten wie Controller, Services usw. einbeziehen. Was am unteren Rand des Compilers herauskommt, ist eine vollständig konfigurierte Webanwendung, die verkabelt und einsatzbereit ist.

Dies bedeutet, dass Angular Template Driven ist . Ihre Vorlage führt das JavaScript aus, nicht umgekehrt. Dies ist eine radikale Umkehrung der Rollen und das komplette Gegenteil des unauffälligen JavaScript, das wir seit etwa zehn Jahren schreiben. Das kann gewöhnungsbedürftig sein.

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

Kommen wir zu den Kleinigkeiten.

Zunächst ersetzt Angular jQuery nicht

Angular und jQuery machen unterschiedliche Dinge. AngularJS bietet Ihnen eine Reihe von Tools zur Erstellung von Webanwendungen. jQuery bietet Ihnen hauptsächlich Werkzeuge zum Ändern des DOM. Wenn auf Ihrer Seite jQuery vorhanden ist, verwendet AngularJS diese automatisch. Ist dies nicht der Fall, wird AngularJS mit jQuery Lite ausgeliefert, was eine reduzierte, aber immer noch perfekt verwendbare Version von jQuery ist.

Misko mag jQuery und hat nichts dagegen, wenn Sie es verwenden. Mit zunehmendem Fortschritt können Sie jedoch feststellen, dass Sie mit einer Kombination aus Geltungsbereich, Vorlagen und Anweisungen einen Großteil Ihrer gesamten Arbeit erledigen können, und Sie sollten diesen Workflow nach Möglichkeit vorziehen, da der Code diskreter, konfigurierbarer und mehr ist Winkelig

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

Unauffälliges JavaScript mit Selectors im Vergleich zu 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 ändern.

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

Eines der ersten Dinge, die Sie bei AngularJS feststellen werden, ist, dass benutzerdefinierte Attribute überall vorhanden sind . Ihr HTML wird mit ng-Attributen übersät, die im Wesentlichen onClick-Attribute für Steroide sind. Dies sind Direktiven (Compiler-Direktiven), und es ist eine der Hauptarten, auf die die Vorlage mit dem Modell verbunden ist.

Wenn Sie das zum ersten Mal sehen, könnten Sie versucht sein, AngularJS als aufdringliches JavaScript der alten Schule abzuschreiben (wie ich es zuerst tat). AngularJS hält sich nicht an diese Regeln. In AngularJS ist Ihr HTML5 eine Vorlage. Es wird von AngularJS zusammengestellt, 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 zu kompilierende Code. AngularJS liest Ihre gesamte Webseite ein und kompiliert sie mithilfe des integrierten Compilers buchstäblich in eine neue Webseite.

Ihre Vorlage sollte deklarativ sein. Seine Bedeutung sollte klar sein, wenn man es einfach liest. Wir verwenden benutzerdefinierte Attribute mit aussagekräftigen Namen. Wir erstellen neue HTML-Elemente mit aussagekräftigen Namen. Ein Designer mit minimalen HTML-Kenntnissen 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 befindet sich auf dem Fahrersitz.

Eine der ersten Fragen, die ich mir stellte, als ich AngularJS startete und durch die Tutorials ging, war "Wo ist mein Code?" . Ich habe kein JavaScript geschrieben, und dennoch habe ich all dieses Verhalten. Die Antwort liegt auf der Hand. Da AngularJS das DOM kompiliert, behandelt AngularJS Ihren HTML-Code als Code. Für viele einfache Fälle reicht es oft aus, eine Vorlage zu schreiben und von AngularJS für Sie in einer Anwendung kompilieren zu lassen.

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

Es ist XSLT ähnlicher als zum Beispiel Ruby on Rails .

Dies ist eine radikale Umkehrung der Kontrolle, die gewöhnungsbedürftig ist.

Stoppen Sie den Versuch, Ihre Anwendung aus Ihrem JavaScript heraus zu fahren. Lassen Sie die Anwendung die Vorlage steuern, und AngularJS kümmert sich um die Verkabelung der Komponenten. Dies ist auch der Winkelweg.

Semantisches HTML vs. semantische Modelle

Mit jQuery sollte Ihre HTML-Seite semantisch sinnvolle Inhalte enthalten. Wenn das JavaScript (von einem Benutzer oder einer Suchmaschine) deaktiviert ist, bleibt Ihr Inhalt zugänglich.

Weil AngularJS Ihre HTML-Seite als Vorlage behandelt. Die Vorlage soll nicht semantisch sein, da Ihr Inhalt normalerweise in Ihrem Modell gespeichert wird, 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 API und kompiliertes DOM semantisch.

In AngularJS bedeutet leben im Modell, HTML ist nur eine Vorlage, die nur zur Anzeige dient.

Zu diesem Zeitpunkt haben Sie wahrscheinlich alle möglichen Fragen zu SEO und zur Zugänglichkeit, und dies zu Recht. Hier gibt es offene Fragen. Die meisten Screenreader analysieren nun JavaScript. Suchmaschinen können auch AJAXed Inhalte AJAXed . Trotzdem sollten Sie sicherstellen, dass Sie Pushstate-URLs verwenden und eine anständige Sitemap haben. Eine Diskussion des Problems finden Sie hier: https://.com/a/23245379/687677

Trennung von Anliegen (SOC) vs. MVC

Die Trennung von Anliegen (SOC) ist ein Muster, das über viele Jahre der Webentwicklung aus verschiedenen Gründen entstanden ist, darunter SEO, Zugänglichkeit und Inkompatibilität von Browsern. Es sieht aus wie das:

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

Auch hier spielt AngularJS nicht nach ihren Regeln. Mit einem Schlaganfall verzichtet AngularJS auf ein Jahrzehnt der empfangenen Weisheit und implementiert stattdessen ein MVC-Muster, in dem die Vorlage nicht mehr semantisch ist, auch nicht 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 praktische Hilfsfunktionen auf $ scope speichern, auf die Ihre Vorlagen zugreifen können.
  2. Ansicht - Ihre Ansichten sind in HTML geschrieben. Die Ansicht ist normalerweise nicht semantisch, da Ihre Daten im Modell gespeichert sind.
  3. Controller - Ihr Controller ist eine JavaScript-Funktion, die die Ansicht mit dem Modell verknüpft. Seine Funktion besteht darin, $ scope zu initialisieren. Abhängig von Ihrer Anwendung müssen Sie möglicherweise keinen Controller erstellen. Sie können viele Controller auf einer Seite haben.

MVC und SOC befinden sich nicht an entgegengesetzten Enden derselben Skala, sondern auf völlig unterschiedlichen Achsen. SOC macht in einem AngularJS-Kontext keinen Sinn. Du musst es vergessen und weitergehen.

Wenn Sie, wie ich, die Browser-Kriege durchlebt haben, werden Sie diese Idee möglicherweise als beleidigend empfinden. Überwinde es, es lohnt sich, versprochen.

Plugins vs. Richtlinien

Plugins erweitern jQuery. AngularJS-Direktiven erweitern die Funktionen Ihres Browsers.

In jQuery definieren wir Plugins durch Hinzufügen von Funktionen zum jQuery.prototyp. Wir haken diese dann in das DOM ein, indem wir Elemente auswählen und das Plugin für 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 Nav-Element eingeschlossen ist. Sie könnten dann ein jQuery schreiben, um die Liste auf der Seite auszuwählen und sie als Galerie mit Timeouts für die gleitende Animation neu zu gestalten.

In AngularJS definieren wir Richtlinien. Eine Direktive ist eine Funktion, die ein JSON-Objekt zurückgibt. Dieses Objekt teilt AngularJS mit, nach welchen DOM-Elementen zu suchen ist und welche Änderungen daran vorgenommen werden sollen. Direktiven werden in die Vorlage eingebunden, und zwar entweder mit Attributen oder Elementen, die Sie erstellen. Die Idee ist, die Fähigkeiten von HTML mit neuen Attributen und Elementen zu erweitern.

Die AngularJS-Methode besteht darin, die Fähigkeiten von nativ aussehendem HTML zu erweitern. Sie sollten HTML schreiben, das wie HTML aussieht und mit benutzerdefinierten Attributen und Elementen erweitert wird.

Wenn Sie ein Karussell möchten, verwenden Sie einfach ein <carousel />Element, definieren Sie eine Direktive, um eine Vorlage einzulesen, und sorgen Sie dafür, dass dieser Trottel funktioniert.

Viele kleine Anweisungen gegenüber großen Plugins mit Konfigurationsschaltern

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

Dies ist ein Fehler in AngularJS.

Nehmen Sie das Beispiel einer Dropdown-Liste. Wenn Sie ein Dropdown-Plugin schreiben, könnten Sie versucht sein, in Click-Handlern Code zu schreiben, vielleicht eine Funktion zum Hinzufügen eines Chevrons, entweder nach oben oder nach unten, vielleicht ändern Sie die Klasse des entfalteten Elements, zeigen das Menü und alle nützlichen Informationen.

Bis Sie eine kleine Änderung vornehmen möchten.

Angenommen, Sie haben ein Menü, das Sie beim Schweben öffnen möchten. Nun haben wir ein Problem. Unser Plugin hat unseren Click-Handler für uns verdrahtet. Wir müssen eine Konfigurationsoption hinzufügen, damit sich diese in diesem speziellen Fall anders verhält.

In AngularJS schreiben wir kleinere Anweisungen. Unsere Dropdown-Direktive wäre lächerlich klein. Es kann den gefalteten Zustand beibehalten und Methoden zum Falten (), Entfalten () oder Umschalten () bereitstellen. Diese Methoden würden einfach $ scope.menu.visible aktualisieren, ein boolescher Wert, der den Status hält.

Jetzt in unserer Vorlage können wir dies verbinden:

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

Müssen Sie bei Mouseover ein Update durchführen?

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

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

Schließung vs.

JQuery-Plugins werden in einer Schließung erstellt. Die Privatsphäre bleibt innerhalb dieser Schließung erhalten. Es liegt an Ihnen, Ihre Scope-Kette innerhalb dieser Schließung zu halten. Sie haben wirklich nur Zugriff auf die Menge von DOM-Knoten, die von jQuery an das Plugin übergeben werden, sowie auf alle im Abschluss definierten lokalen Variablen und auf die von Ihnen definierten Globals. Dies bedeutet, dass Plugins in sich abgeschlossen sind. Dies ist eine gute Sache, kann jedoch beim Erstellen einer gesamten Anwendung restriktiv werden. Der Versuch, Daten zwischen Abschnitten einer dynamischen Seite zu übergeben, wird zur Pflicht.

AngularJS verfügt über $ scope-Objekte. Hierbei handelt es sich um spezielle Objekte, die von AngularJS erstellt und verwaltet werden, in denen Sie Ihr Modell speichern. Bestimmte Anweisungen erzeugen einen neuen $ -Rahmen, der standardmäßig von seinem umschließenden $ -Rahmen mithilfe der prototypischen JavaScript-Vererbung erbt. Auf das $ scope-Objekt kann im Controller und in der Ansicht zugegriffen werden.

Dies ist der clevere Teil. Da die Struktur der $ scope-Vererbung grob der Struktur des DOM entspricht, haben Elemente Zugriff auf ihren eigenen Gültigkeitsbereich und alle enthaltenen Gültigkeitsbereiche nahtlos bis hin zum globalen $ Gültigkeitsbereich (der nicht dem globalen Gültigkeitsbereich entspricht).

Dies erleichtert das Weiterleiten von Daten und das Speichern von Daten auf einer geeigneten Ebene. Wenn eine Dropdown-Liste entfaltet wird, muss nur der Dropdown-Bereich $ darüber wissen. Wenn der Benutzer seine Einstellungen aktualisiert, möchten Sie möglicherweise den globalen Bereich $ aktualisieren, und alle verschachtelten Bereiche, die die Benutzereinstellungen abhören, werden automatisch benachrichtigt.

Das hört sich vielleicht kompliziert an. Wenn Sie sich erst einmal entspannt haben, ist es wie Fliegen. Sie müssen das $ scope-Objekt nicht erstellen. AngularJS instanziiert und konfiguriert es für Sie korrekt und entsprechend Ihrer Vorlagenhierarchie. AngularJS stellt es dann Ihrer Komponente zur Verfügung, indem es die Magie der Abhängigkeitseinspritzung verwendet (mehr dazu später).

Manuelle DOM-Änderungen vs. Datenbindung

In jQuery nehmen Sie alle Ihre DOM-Änderungen von Hand vor. Sie erstellen programmgesteuert neue DOM-Elemente. 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 ihn einzufügen.

In AngularJS können Sie dies auch tun, aber Sie sollten die Datenbindung verwenden. Ändern Sie Ihr Modell. Da das DOM über eine Vorlage an es gebunden ist, wird es automatisch aktualisiert, ohne dass ein Eingriff erforderlich ist.

Da die Datenbindung von der Vorlage aus mit einem Attribut oder der geschweiften Klammer-Syntax erfolgt, ist dies sehr einfach. Es gibt wenig kognitiven Aufwand, so dass Sie es ständig tun werden.

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

Bindet das Eingabeelement an $scope.user.name. Durch das 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 handelt sich um eine Live-Bindung. Wenn der $scope.user.nameWert aktualisiert wird, wird auch die Vorlage aktualisiert.

Ajax die ganze Zeit

In jQuery ist es ziemlich einfach, einen Ajax-Anruf zu tätigen. Es gibt die zusätzliche Komplexität, über die man nachdenken muss, und ein ziemlich großes Skript, das beibehalten werden muss.

In AngularJS ist Ajax die Standardlösung, und dies geschieht ständig, fast ohne dass Sie es merken. Sie können Vorlagen mit ng-include einschließen. Sie können eine Vorlage mit der einfachsten benutzerdefinierten Anweisung anwenden. Sie können einen Ajax-Anruf in einen Dienst einschließen und sich einen GitHub Dienst oder einen Flickr Dienst erstellen , auf den Sie mit erstaunlicher Leichtigkeit zugreifen können.

Serviceobjekte vs. Hilfsfunktionen

Wenn wir in jQuery eine kleine, nicht dom-bezogene Aufgabe ausführen möchten, z. B. das Abrufen eines Feeds aus einer API, schreiben wir möglicherweise eine kleine Funktion, um dies in unserem Abschluss zu tun. Dies ist eine gültige Lösung, aber was ist, wenn wir häufig auf diesen Feed zugreifen möchten? Was ist, wenn wir diesen Code in einer anderen Anwendung wiederverwenden wollen?

AngularJS gibt uns Serviceobjekte.

Services 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 -API zugreifen, schreiben wir eine, Servicedie Methoden dafür definiert.

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

Serviceobjekte sind in sich geschlossene AngularJS-Komponenten, die wir je nach Bedarf verwenden und wiederverwenden können. Sie sind einfache JSON-Objekte, die Funktionen und Daten enthalten. Sie sind immer Singletons. Wenn Sie also Daten an einem Ort an einem Ort speichern, können Sie diese Daten an einem anderen Ort abrufen, indem Sie denselben Dienst anfordern.

Abhängigkeitsinjektion (DI) vs. Instatiation - aka Spaghettifizierung

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

Bis Sie anfangen, dies zu verwenden, ist es schwer zu erklären, was für ein riesiger Zeitvorteil das ist. In jQuery gibt es nichts wie AngularJS DI.

DI bedeutet, dass Sie Ihre Anwendung nicht schreiben und zusammenschreiben, sondern eine Bibliothek von Komponenten definieren, die jeweils durch einen String identifiziert werden.

Angenommen, ich habe eine Komponente namens "FlickrService", die Methoden zum Abrufen von JSON-Feeds von Flickr definiert. Wenn ich nun einen Controller schreiben möchte, der auf Flickr zugreifen kann, muss ich bei der Deklaration des Controllers nur auf den "FlickrService" Bezug nehmen. AngularJS sorgt dafür, dass die Komponente instanziiert und für meinen Controller verfügbar gemacht wird.

Zum Beispiel definiere ich hier einen Dienst:

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

Nun, wenn ich diesen Dienst nutzen möchte, verweise ich mit dem folgenden Namen darauf:

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

AngularJS erkennt, dass ein FlickrService-Objekt erforderlich ist, um den Controller zu instanziieren, und stellt eines für uns bereit.

Dies macht die Verkabelung sehr einfach und beseitigt die Tendenz zur Spagettifizierung. Wir haben eine flache Liste von Komponenten, und AngularJS übergibt sie uns nach und nach, wenn wir sie brauchen.

Modulare Servicearchitektur

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

AngularJS stellt Ihnen Module zur Verfügung, in die Sie Ihren Code einfügen können. Wenn Sie beispielsweise ein Skript schreiben, das mit Flickr kommuniziert, möchten Sie möglicherweise ein Flickr-Modul erstellen, in das alle Ihre Flickr-bezogenen Funktionen eingebunden werden. Module können andere Module (DI) enthalten. Ihre Hauptanwendung ist normalerweise ein Modul, und dies sollte alle anderen Module umfassen, von denen Ihre Anwendung abhängt.

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

Module enthalten AngularJS-Komponenten. Wenn wir ein Modul einschließen, stehen uns alle Komponenten in diesem Modul als einfache Liste zur Verfügung, die anhand ihrer eindeutigen Zeichenfolgen identifiziert wird . Diese Komponenten können dann mithilfe des Abhängigkeitseinspritzmechanismus von AngularJS ineinander injiziert werden.

Um zusammenzufassen

AngularJS und jQuery sind keine Feinde. Es ist möglich, jQuery sehr gut in AngularJS zu verwenden. Wenn Sie AngularJS gut verwenden (Vorlagen, Datenbindung, $ scope, Anweisungen usw.), werden Sie feststellen, dass Sie viel weniger jQuery benötigen, als Sie es sonst benötigen.

Die Hauptsache zu erkennen ist, dass Ihre Vorlage Ihre Anwendung steuert. Hören Sie auf, große Plugins zu schreiben, die alles tun. Schreiben Sie stattdessen kleine Anweisungen, die eine Sache tun, und schreiben Sie dann eine einfache Vorlage, um sie miteinander zu verbinden.

Denken Sie weniger an unauffälliges JavaScript, sondern an HTML-Erweiterungen.

Mein kleines Buch

Ich war so begeistert von AngularJS, ich habe ein kurzes Buch darüber geschrieben, das Sie gerne online lesen können http://nicholasjohnson.com/angular-book/ . Ich hoffe es ist hilfreich.


AngularJS und jQuery:

AngularJs und JQuery sind auf jeder Ebene völlig unterschiedlich, mit Ausnahme der JQLite-Funktionalität. Sie werden es sehen, wenn Sie die Kernfunktionen von AngularJs kennenlernen (ich habe es unten erklärt).

AngularJs ist ein clientseitiges Framework, das die Erstellung der unabhängigen clientseitigen Anwendung ermöglicht. JQuery ist eine clientseitige Bibliothek, die um das DOM herum spielt.

AngularJs Cool-Prinzip - Wenn Sie Änderungen an Ihrer Benutzeroberfläche wünschen, denken Sie aus Sicht der Modelldatenänderung. Ändern Sie Ihre Daten und die Benutzeroberfläche wird sich selbst erneut rendern. Sie müssen nicht jedes Mal um DOM herumspielen, es sei denn, es ist kaum erforderlich und sollte auch durch Angular-Direktiven behandelt werden.

Um diese Frage zu beantworten, möchte ich meine Erfahrungen mit der ersten Unternehmensanwendung mit AngularJS teilen. Dies sind die großartigsten Funktionen von Angular, bei denen wir anfangen, unsere jQuery-Denkweise zu ändern, und wir erhalten das Angular als Framework und nicht als Bibliothek.

Die bidirektionale Datenbindung ist erstaunlich: Ich hatte ein Raster mit allen Funktionen UPDATE, DELTE, INSERT. Ich habe ein Datenobjekt, das das Modell des Gitters mithilfe von ng-repeat bindet. Sie müssen nur eine einzige Zeile einfachen JavaScript-Codes schreiben, um sie zu löschen und einzufügen. Das Gitter wird automatisch aktualisiert, wenn sich das Gittermodell sofort ändert. Update-Funktionalität ist Echtzeit, kein Code dafür. Du fühlst dich fantastisch !!!

Wiederverwendbare Anweisungen sind super: Schreiben Sie Anweisungen an einer Stelle und verwenden Sie sie in der gesamten Anwendung. OH MEIN GOTT!!! Ich habe diese Direktive für Paging, Regex, Validierungen usw. verwendet. Das ist wirklich cool!

Das Routing ist stark: Es liegt an Ihrer Implementierung, wie Sie es verwenden möchten, es sind jedoch nur wenige Codezeilen erforderlich, um die Anforderung zu leiten, um HTML und Controller anzugeben (JavaScript).

Controller sind großartig: Controller kümmern sich um ihren eigenen HTML-Code, aber diese Trennung funktioniert gut mit der üblichen Funktionalität. Wenn Sie dieselbe Funktion auf Knopfdruck in der Master-HTML aufrufen möchten, geben Sie einfach den gleichen Funktionsnamen in jeden Controller ein und schreiben Sie individuellen Code.

Plugins: Es gibt viele andere ähnliche Funktionen wie das Anzeigen einer Überlagerung in Ihrer App. Sie müssen keinen Code dafür schreiben, verwenden Sie einfach ein als wc-overlay verfügbares Overlay-Plugin, das sich automatisch um alle XMLHttpRequest (XHR) -Anfragen kümmert .

Ideal für RESTful Architektur: Da es sich um ein vollständiges Framework handelt, ist AngularJS ideal für die Arbeit mit einer RESTful-Architektur. REST CRUD-APIs aufzurufen ist sehr einfach und

Services : Schreiben Sie allgemeine Codes mit Services und weniger Code in Controllern. Sektoren können verwendet werden, um gemeinsame Funktionen unter den Steuerungen zu teilen.

Erweiterbarkeit : Angular hat die HTML-Direktiven um winklige Direktiven erweitert. Schreibe Ausdrücke in HTML und werte sie zur Laufzeit aus. Erstellen Sie Ihre eigenen Anweisungen und Dienste und verwenden Sie sie ohne zusätzlichen Aufwand in einem anderen Projekt.


jQuery ist eine DOM-Manipulationsbibliothek.

AngularJS ist ein MV * Framework.

AngularJS ist eines der wenigen JavaScript MV * -Frameworks (viele JavaScript MVC-Tools gehören immer noch zur Kategoriebibliothek).

Als Framework beherbergt es Ihren Code und übernimmt die Entscheidung darüber, was wann aufgerufen wird.

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

AngularJS hat das Konzept von "Direktiven" für die DOM-Manipulation und das Entwerfen wiederverwendbarer UI-Komponenten. Sie sollten es daher immer dann verwenden, wenn Sie das Gefühl haben, DOM-Manipulationen zu erledigen.

AngularJS beinhaltet einige Lernkurven (mehr als jQuery :-).

-> Für alle Entwickler mit jQuery-Hintergrund wäre mein erster Rat: "JavaScript als erstklassige Sprache lernen, bevor Sie auf ein reichhaltiges Framework wie AngularJS springen!" Ich habe die obige Tatsache auf die harte Tour gelernt.

Viel Glück.


jQuery

jQuery macht lächerlich lange JavaScript-Befehle wie getElementByHerpDerpkürzere und Cross-Browser.

AngularJS

Mit AngularJS können Sie Ihre eigenen HTML-Tags / -Attribute erstellen, die Funktionen für dynamische Webanwendungen erfüllen (da HTML für statische Seiten entwickelt wurde).

Bearbeiten:

Sagen "Ich habe einen jQuery-Hintergrund, wie denke ich in AngularJS?" ist wie zu sagen "Ich habe einen HTML-Hintergrund, wie denke ich in JavaScript?" Die Tatsache, dass Sie die Frage stellen, zeigt, dass Sie die grundlegenden Zwecke dieser beiden Ressourcen höchstwahrscheinlich nicht verstehen. Deshalb habe ich mich entschieden, die Frage zu beantworten, indem ich einfach auf den grundlegenden Unterschied hinweise und nicht durch die Liste gehe: "AngularJS verwendet Anweisungen, wohingegen jQuery CSS-Selektoren verwendet, um ein jQuery-Objekt zu erstellen, das dies und das usw." . Diese Frage erfordert keine ausführliche Antwort.

jQuery ist eine Möglichkeit, die Programmierung von JavaScript im Browser zu vereinfachen. Kürzere, browserübergreifende Befehle usw.

AngularJS erweitert HTML, so dass Sie nicht <div>nur eine Anwendung erstellen müssen. HTML funktioniert tatsächlich für Anwendungen und nicht für das, wofür es entwickelt wurde, nämlich statische, informative Webseiten. Dies geschieht auf Umwegen mithilfe von JavaScript. Im Wesentlichen handelt es sich jedoch um eine Erweiterung von HTML, nicht um JavaScript.


Als Anfänger von JavaScript-MV *, der sich ausschließlich auf die Anwendungsarchitektur konzentriert (nicht die Server- / Clientseite), würde ich sicherlich die folgende Ressource empfehlen (die ich nicht überrascht habe): JavaScript Design Patterns von Addy Osmani , als Einführung in verschiedene JavaScript-Designmuster . Die in dieser Antwort verwendeten Begriffe stammen aus dem oben verlinkten Dokument. Ich werde nicht wiederholen, was in der akzeptierten Antwort wirklich gut formuliert wurde. Stattdessen verweist diese Antwort auf die theoretischen Hintergründe, die AngularJS (und andere Bibliotheken) unterstützen.

Wie ich, werden Sie schnell feststellen, dass AngularJS (oder Ember.js , Durandal und andere MV * -Frameworks für diese Angelegenheit) ein komplexes Framework ist, das viele der verschiedenen JavaScript-Entwurfsmuster zusammenstellt.

Ich fand es auch einfacher, (1) nativen JavaScript-Code und (2) kleinere Bibliotheken für jedes dieser Muster separat zu testen, bevor in ein globales Framework getaucht wird. Auf diese Weise konnte ich besser verstehen, welche entscheidenden Themen ein Rahmen anspricht (weil Sie persönlich mit dem Problem konfrontiert sind).

Zum Beispiel:

  • JavaScript Objektorientierte Programmierung (dies ist ein Google-Suchlink). Es ist keine Bibliothek, aber sicherlich eine Voraussetzung für jede Anwendungsprogrammierung. Es lehrte mich die nativen Implementierungen der Prototyp-, Konstruktor-, Singleton- und Dekorationsmuster
  • jQuery / Underscore für das Fassadenmuster (wie WYSIWYGs für die Manipulation des DOM)
  • Prototype.js für das Prototyp / Konstruktor / Mixin-Muster
  • RequireJS / Curl.js für das Curl.js/ AMD
  • KnockoutJS für das beobachtbare Publish / Subscribe-Muster

Hinweis: Diese Liste ist weder vollständig noch die "besten Bibliotheken". es sind einfach die Bibliotheken, die ich benutzt habe. Diese Bibliotheken enthalten auch mehr Muster, die genannten sind nur ihre Hauptschwerpunkte oder ursprünglichen Absichten. Wenn Sie der Meinung sind, dass etwas in dieser Liste fehlt, erwähnen Sie dies bitte in den Kommentaren. Ich werde es gerne hinzufügen.


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

Um meine Erfahrungen zusammenzufassen:

  1. Controller und Provider (Dienste, Fabriken usw.) dienen zur Änderung des Datenmodells, NICHT HTML.
  2. HTML und Anweisungen definieren das Layout und die Bindung an das Modell.
  3. Wenn Sie Daten zwischen Controllern gemeinsam nutzen müssen, erstellen Sie einen Service oder eine Factory. Hierbei handelt es 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-Code an das Modell gebunden ist.

Ich finde diese Frage interessant, weil ich Node.js und AngularJS zum ersten Mal ernsthaft mit der JavaScript-Programmierung beschäftigt war . Ich habe jQuery nie gelernt, und ich denke, das ist eine gute Sache, weil ich nichts verlernen muss. Tatsächlich vermeide ich aktiv jQuery-Lösungen für meine Probleme und suche stattdessen lediglich nach einem "AngularJS-Weg", um sie zu lösen. Ich denke, meine Antwort auf diese Frage würde im Wesentlichen auf "Denken wie jemand, der nie jQuery gelernt hat" bedeuten und jede Versuchung vermeiden, jQuery direkt zu integrieren (offensichtlich verwendet AngularJS es hinter den Kulissen in gewissem Umfang).


Um den "Paradigmenwechsel" zu beschreiben, denke ich, dass eine kurze Antwort ausreichen kann.

AngularJS ändert die Suche nach Elementen

In jQuery verwenden Sie normalerweise Selektoren , um Elemente zu suchen, und verbinden diese dann:
$('#id .class').click(doStuff);

In AngularJS verwenden Sie Direktiven , um die Elemente direkt zu markieren und sie zu verkabeln:
<a ng-click="doStuff()">

AngularJS muss (oder möchte) nicht, dass Sie Elemente mithilfe von Selektoren finden. Der Hauptunterschied zwischen jqLite von AngularJS und vollwertiger jQuery besteht darin, dass jqLite keine Selektoren unterstützt .

Wenn die Leute sagen, dass sie "jQuery überhaupt nicht enthalten" haben, dann hauptsächlich, weil sie nicht möchten, dass Sie Selektoren verwenden. Sie möchten, dass Sie stattdessen lernen, Anweisungen zu verwenden. Direkt, nicht auswählen!


Hören Sie sich den Podcast JavaScript Jabber: Episode # 32 an , der die ursprünglichen Ersteller von AngularJS enthält: Misko Hevery & Igor Minar. Sie sprechen viel darüber, wie es ist, aus anderen JavaScript-Hintergründen, insbesondere jQuery, zu AngularJS zu kommen.

Einer der Punkte, die im Podcast angesprochen wurden, hat viele Dinge mit Rücksicht auf Ihre Frage angeklickt:

MISKO : [...] Eines der Dinge, über die wir in Angular kaum nachgedacht haben, ist: Wie stellen wir eine Menge Fluchttüren bereit, damit Sie herauskommen und im Grunde einen Ausweg daraus finden können. Für uns lautet die Antwort also das, was "Richtlinien" genannt wird. Und mit Anweisungen werden Sie im Wesentlichen zu einem kleinen, kleinen JavaScript, das Sie machen können, was Sie wollen.

IGOR : Stellen Sie sich die Anweisung Direktive als Anweisung an den Compiler vor, wenn Sie auf dieses Element oder dieses CSS in der Vorlage stoßen, und Sie behalten diese Art von Code, und dieser Code ist für das Element und alles unter diesem Element zuständig im DOM-Baum.

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

Um Ihre Frage direkt zu beantworten: AngularJS ist sehr gutmütig und ein echtes MV * Framework. Mit jQuery können Sie jedoch auch all die wirklich coolen Dinge, die Sie mit jQuery kennen und lieben, innerhalb von Anweisungen verwenden. Es geht nicht um "Wie mache ich das, was ich bisher in jQuery gemacht habe?" Es ist eine Frage von "Wie kann ich AngularJS mit all dem ergänzen, was ich in jQuery gemacht habe?"

Es sind wirklich zwei sehr unterschiedliche Geisteszustände.


jQuery: Sie denken viel über 'QUERYing the DOM ' nach DOM-Elementen nach und tun etwas.

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

Wenn Sie beispielsweise Daten vom THE-Server erhalten, die im DOM in einem bestimmten Format angezeigt werden sollen, in jQuery, müssen Sie '1. FINDEN 'wo im DOM diese Daten platziert werden sollen, die' 2. UPDATE / APPEND 'dort, indem Sie einen neuen Knoten erstellen oder einfach seine innerHTML . Wenn Sie dann diese Ansicht aktualisieren möchten, müssen Sie '3. FIND 'den Ort und' 4. AKTUALISIEREN'. Dieser Zyklus des Suchens und Aktualisierens von Daten, die im selben Kontext abgerufen und formatiert wurden, ist in AngularJS nicht mehr vorhanden.

Mit AngularJS haben Sie Ihr Modell (JavaScript-Objekte, an die Sie bereits gewöhnt sind), und der Wert des Modells informiert Sie über das Modell (offensichtlich) und über die Ansicht. Eine Operation des Modells wird automatisch in die Ansicht übernommen, so dass Sie nicht fortfahren. Ich muss darüber nachdenken. Sie finden sich in AngularJS nicht mehr im DOM.

Anders ausgedrückt, in jQuery müssen Sie über CSS-Selektoren nachdenken, d. H. Wo sich die Klasse oder das Attribut divoder tdeine Klasse befindet, usw., damit ich deren HTML oder Farbe oder Wert erhalten kann, aber in AngularJS: Sie werden sich so denken: Mit welchem ​​Modell beschäftige ich mich, 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 tdElement befindet (Details, über die Sie in jQuery häufig nachdenken mussten).

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 rufen Sie häufig die jQuery-Funktionen auf. In AngularJS ruft AngularJS Ihre Funktionen auf. AngularJS wird Ihnen also sagen, wie Sie etwas tun müssen In der Regel bedeutet dies, zu lernen, was AngularJS will oder wie es von AngularJS verlangt wird, dass Sie Ihre Funktionen präsentieren und diese entsprechend aufrufen. Dies ist eines der Dinge, die AngularJS eher zu einem Framework als zu einer Bibliothek machen.


Imperativ → deklarativ

In jQuery werden Selektoren verwendet, um DOM Elemente zu finden und Event-Handler an sie zu binden bzw. zu registrieren. Wenn ein Ereignis ausgelöst wird, wird dieser (zwingende) Code zum Aktualisieren / Ändern des DOM ausgeführt.

In AngularJS möchten Sie eher über Ansichten als über DOM-Elemente nachdenken. Views sind (deklarativer) HTML-Code, der AngularJS- Direktiven enthält . Direktiven richten die Event-Handler hinter den Kulissen für uns ein und geben uns dynamisches Datenbinden. Selektoren werden selten verwendet, so dass der Bedarf an IDs (und einigen Arten von Klassen) stark reduziert wird. Ansichten sind an Modelle gebunden (über Bereiche). Ansichten sind eine Projektion des Modells. Ereignisse ändern Modelle (dh Daten, Bereichseigenschaften) und die Ansichten, die diese Modelle "automatisch" projizieren.

Denken Sie in AngularJS eher an Modelle als an jQuery-ausgewählte DOM-Elemente, die Ihre Daten enthalten. Stellen Sie sich Ansichten als Projektionen dieser Modelle vor, anstatt Callbacks zu registrieren, um das zu ändern, was der Benutzer sieht.

Trennung von Bedenken

jQuery verwendet unauffälliges JavaScript - Verhalten (JavaScript) wird von der Struktur (HTML) getrennt.

AngularJS verwendet Controller und Direktiven (von denen jeder einen eigenen Controller und / oder Funktionen zum Kompilieren und Verknüpfen haben kann), um das Verhalten aus der Ansicht / Struktur (HTML) zu entfernen. Angular bietet auch Dienste und Filter zum Trennen und Organisieren Ihrer Anwendung.

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

Anwendungsdesign

Ein Ansatz zum Entwerfen einer AngularJS-Anwendung:

  1. Denken Sie über Ihre Modelle nach. Erstellen Sie Services oder Ihre eigenen JavaScript-Objekte für diese Modelle.
  2. Überlegen Sie, 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 eine dynamische Datenbindung zu erhalten.
  3. Schließen Sie einen Controller an jede Ansicht an (mithilfe von ng-view und routing oder ng-controller). Lassen Sie den Controller nur die Modelldaten finden / abrufen, die die Ansicht für ihre Arbeit benötigt. Controller so dünn wie möglich machen.

Prototypische Vererbung

Sie können mit jQuery viel tun, ohne zu wissen, wie die prototypische Vererbung von JavaScript funktioniert. Bei der Entwicklung von AngularJS-Anwendungen vermeiden Sie einige häufige Fehler, wenn Sie die JavaScript-Vererbung gut verstehen. Empfohlene Lektüre: Was sind die Nuancen der prototypischen / prototypischen Vererbung in AngularJS?





angularjs