javascript - empty - angularjs jquery lite



„Denken in AngularJS“, wenn ich einen jQuery-Hintergrund habe? (10)

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 .

https://src-bin.com


Answer #1

Können Sie den notwendigen Paradigmenwechsel beschreiben?

Imperativ vs deklarativ

Mit jQuery teilen Sie dem DOM Schritt für Schritt mit, was geschehen muss. Mit AngularJS beschreiben Sie, welche Ergebnisse Sie AngularJS möchten, aber nicht, wie Sie dies tun sollen. Mehr dazu here . Schauen Sie sich auch die Antwort von Mark Rajcok an.

Wie kann ich clientseitige Web-Apps unterschiedlich gestalten und entwerfen?

AngularJS ist ein gesamtes clientseitiges Framework, das das MVC Muster verwendet (überprüfen Sie deren grafische Darstellung ). Es konzentriert sich stark auf die Trennung von Anliegen.

Was ist der größte Unterschied? Was soll ich aufhören zu tun / verwenden; was soll ich stattdessen anfangen / verwenden?

jQuery ist eine Bibliothek

AngularJS ist ein wunderschönes clientseitiges Framework, das in hohem Maße überprüfbar ist und eine Menge cooles Material wie MVC, Abhängigkeitsinjektion , Datenbindung und vieles mehr enthält.

Es konzentriert sich auf die Trennung von Bedenken und Tests ( Unit-Tests und End-to-End-Tests), was die testgetriebene Entwicklung erleichtert.

Der beste Weg, um damit anzufangen, ist ein tolles Tutorial . Sie können die Schritte in ein paar Stunden durchgehen. Falls Sie jedoch die Konzepte hinter den Kulissen beherrschen möchten, enthalten sie eine Vielzahl von Referenzen zum weiteren Lesen.

Gibt es serverseitige Überlegungen / Einschränkungen?

Sie können es in vorhandenen Anwendungen verwenden, in denen Sie bereits reines jQuery verwenden. Wenn Sie jedoch die AngularJS-Funktionen voll ausnutzen möchten, sollten Sie in Betracht ziehen, die Serverseite mit einem RESTful Ansatz zu codieren .

Auf diese Weise können Sie ihre Ressourcenfabrik nutzen , wodurch eine Abstraktion der serverseitigen RESTful- API und serverseitige Aufrufe (Abrufen, Speichern, Löschen usw.) unglaublich einfach werden.


Answer #2

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.


Answer #3

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.


Answer #4

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?


Answer #5

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.

Answer #6

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!


Answer #7

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.


Answer #8

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

Bei jQuery dreht sich alles um DOM-Manipulation. Es löst all die Kreuzbrowserschmerzen, die Sie sonst erledigen müssen, aber es ist kein Rahmen, in dem Sie Ihre App in Komponenten wie AngularJS unterteilen können.

Eine schöne Sache von AngularJs ist, dass Sie die DOM-Manipulation in den Direktiven trennen oder isolieren können. Es gibt integrierte Anweisungen, die Sie verwenden können, z. B. ng-click. Sie können Ihre eigenen benutzerdefinierten Direktiven erstellen, die Ihre gesamte Ansichtslogik oder DOM-Manipulation enthalten, damit Sie keinen DOM-Manipulationscode in den Controllern oder Services mischen, die sich um die Geschäftslogik kümmern sollten.

Angular unterteilt Ihre App in - Controller - Dienste - Ansichten - usw.

und noch etwas, das ist die richtlinie. Es ist ein Attribut, das Sie an jedes DOM-Element anfügen können, und Sie können sich mit jQuery darin verrückt machen, ohne sich Gedanken darüber zu machen, dass Ihre jQuery mit AngularJs-Komponenten in Konflikt steht oder die Architektur beeinträchtigt.

Ich habe von einem Meetup gehört, an dem ich teilgenommen habe. Einer der Gründer von Angular sagte, dass sie wirklich hart gearbeitet haben, um die DOM-Manipulation zu trennen.


Answer #9

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


Answer #10

Wenn Sie AngularJS verwenden, benötigen Sie jQuery nicht mehr. AngularJS selbst hat die Bindung und Direktive, die für die meisten Dinge, die Sie mit jQuery machen können, ein sehr guter Ersatz ist.

Normalerweise entwickle ich mobile Anwendungen mit AngularJS und Cordova . Das einzige, was ich von jQuery brauchte, ist der Selector.

Beim Googeln sehe ich, dass es da draußen ein eigenständiges jQuery-Selector-Modul gibt. Es ist Sizzle.

Und ich entschied mich für ein winziges Code-Snippet, mit dem ich schnell eine Website mit AngularJS und jQuery Selector (mit Sizzle) erstellen kann.

Ich habe meinen Code hier veröffentlicht: https://github.com/huytd/Sizzular





angularjs