Pytanie "Myślisz w AngularJS", jeśli mam tło jQuery? [Zamknięte]


Załóżmy, że jestem obeznany z tworzeniem aplikacji po stronie klienta jQuery, ale teraz chciałbym zacząć korzystać AngularJS. Czy potrafisz opisać zmianę paradygmatu, która jest konieczna? Oto kilka pytań, które mogą pomóc w sformułowaniu odpowiedzi:

  • Jak inaczej projektować i projektować aplikacje internetowe po stronie klienta? Jaka jest największa różnica?
  • Co powinienem przestać robić / używać; Co powinienem zacząć robić / używać zamiast tego?
  • Czy są jakieś względy / ograniczenia po stronie serwera?

Nie szukam szczegółowego porównania między jQuery i AngularJS.


4525
2018-02-21 04:09


pochodzenie


Dla osób znających "ASP.NET MVC" lub "RoR" - po prostu myśl o Angularie jako o "MVC po stronie klienta" i to jest to. - Serge Shultz


Odpowiedzi:


1. Nie projektuj swojej strony, a następnie zmień ją za pomocą DOM manipulacje

W jQuery projektujesz stronę, a następnie zmieniasz ją na dynamiczną. Jest tak dlatego, że jQuery został zaprojektowany z myślą o rozszerzeniu i niesamowicie rozwinął się z tego prostego założenia.

Ale w AngularJS musisz zacząć od podstaw, mając na uwadze swoją architekturę. Zamiast zaczynać od myślenia "Mam ten fragment DOM i chcę go zrobić X", musisz zacząć od tego, co chcesz osiągnąć, a następnie przejść do projektowania aplikacji, a następnie w końcu przejść do projektowania swojego widoku.

2. Nie rozszerzaj jQuery za pomocą AngularJS

Podobnie, nie rozpoczynajmy od pomysłu, że jQuery wykonuje X, Y i Z, więc dodam tylko AngularJS do modeli i kontrolerów. To jest naprawdę Kuszące, gdy dopiero zaczynasz, dlatego zawsze zalecam, aby nowi programiści AngularJS w ogóle nie używali jQuery, przynajmniej dopóki nie przyzwyczają się do robienia rzeczy w "Kątowej drodze".

Widziałem wielu programistów tutaj i na liście mailingowej tworzę te rozbudowane rozwiązania z wtyczkami jQuery z 150 lub 200 liniami kodu, które następnie wklejają do AngularJS z kolekcją callbacków i $applys, które są mylące i zawiłe; ale w końcu sprawiają, że działa! Problem polega na tym, że w większość Przypadek, że wtyczka jQuery mogłaby zostać przepisana w AngularJS w ułamku kodu, gdzie nagle wszystko staje się zrozumiałe i proste.

Najważniejsze jest to, że przy rozwiązywaniu najpierw "myśl w AngularJS"; jeśli nie możesz wymyślić rozwiązania, zapytaj społeczność; jeśli po tym wszystkim nie ma łatwego rozwiązania, następnie nie krępuj się, sięgnij po jQuery. Ale nie pozwól, aby jQuery stała się kulą lub nigdy nie opanujesz AngularJS.

3. Zawsze myśl o architekturze

Najpierw to wiem aplikacje jednostronicowe są Aplikacje. Oni są nie strony internetowe. Musimy więc myśleć jak programista po stronie serwera dodatkowo myśleć jak deweloper po stronie klienta. Musimy zastanowić się, jak podzielić naszą aplikację na indywidualne, rozszerzalne, testowalne komponenty.

A następnie w jaki sposób robisz to? Jak "myślisz w AngularJS"? Oto kilka ogólnych zasad, skontrastowanych z jQuery.

Widok jest "oficjalnym zapisem"

W jQuery programowo zmieniamy widok. Możemy mieć menu rozwijane zdefiniowane jako ul jak na przykład:

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

W jQuery w naszej logice aplikacji aktywowalibyśmy ją czymś takim jak:

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

Kiedy patrzymy na widok, nie jest od razu oczywiste, że istnieje tutaj jakakolwiek funkcjonalność. W przypadku małych aplikacji jest to w porządku. Ale w przypadku nietrywialnych aplikacji, rzeczy szybko stają się mylące i trudne do utrzymania.

W AngularJS jednak widok jest oficjalnym zapisem funkcjonalności opartej na widoku. Nasz ul deklaracja wyglądałaby tak:

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

Ci dwaj robią to samo, ale w wersji AngularJS każdy, kto patrzy na szablon, wie, co ma się wydarzyć. Za każdym razem, gdy pojawia się nowy członek zespołu programistów, może spojrzeć na to i wtedy wiedzieć że istnieje dyrektywa zwana dropdownMenu działające na nim; nie musi intuicyjnie wyczuwać właściwej odpowiedzi ani przejrzeć żadnego kodu. Widok powiedział nam, co ma się wydarzyć. Znacznie czystsze.

Programiści nowi w AngularJS często zadają pytania typu: jak znaleźć wszystkie linki określonego rodzaju i dodać do nich dyrektywę. Deweloper jest zawsze oszołomiony, gdy odpowiadamy: nie robisz tego. Ale powodem, dla którego tego nie robisz, jest to, że to jest jak pół-jQuery, pół-AngularJS i nic dobrego. Problem polega na tym, że programista próbuje "zrobić jQuery" w kontekście AngularJS. To nigdy nie zadziała dobrze. Widok jest oficjalny zapis. Poza dyrektywą (więcej o tym poniżej), nigdy, nigdy, nigdy zmień DOM. I dyrektywy są stosowane w widoku, tak intencyjny jest jasny.

Pamiętaj: nie projektuj, a następnie zaznacz. Musisz zaprojektować, a następnie zaprojektować.

Powiązanie danych

Jest to zdecydowanie jedna z najbardziej niesamowitych cech AngularJS i eliminuje potrzebę wykonywania manipulacji DOM, o których wspominałem w poprzedniej sekcji. AngularJS automatycznie zaktualizuje Twój widok, więc nie musisz! W jQuery odpowiadamy na zdarzenia, a następnie aktualizujemy zawartość. Coś jak:

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

Dla widoku, który wygląda następująco:

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

Poza problemami z miksowaniem mamy te same problemy z oznaczeniem intencji, o których wspomniałem wcześniej. Ale co ważniejsze, musieliśmy ręcznie odwołać i zaktualizować węzeł DOM. A jeśli chcemy usunąć wpis do dziennika, musimy również kodować do DOM. Jak testujemy logikę poza DOM? A co jeśli chcemy zmienić prezentację?

To trochę niechlujne i trochę wątłe. Ale w AngularJS możemy to zrobić:

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

Nasz widok może wyglądać tak:

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

Ale w tym przypadku nasz pogląd mógłby wyglądać tak:

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

Teraz zamiast używać listy nieuporządkowanej używamy pól alertów Bootstrap. I nigdy nie musieliśmy zmieniać kodu kontrolera! Ale co ważniejsze, nieważne gdzie lub w jaki sposób dziennik zostanie zaktualizowany, widok również się zmieni. Automatycznie. Schludny!

Chociaż nie pokazałem tego tutaj, powiązanie danych jest dwukierunkowe. Aby te komunikaty mogły być edytowalne w widoku, wystarczy wykonać następujące czynności: <input ng-model="entry.msg" />. I było wiele radości.

Odrębna warstwa modelu

W jQuery DOM jest trochę jak model. Ale w AngularJS mamy oddzielną warstwę modelu, którą możemy zarządzać w dowolny sposób, zupełnie niezależnie od widoku. Pomaga to powyższe powiązanie danych, utrzymuje rozdzielenie obawi wprowadza o wiele większą testowalność. Inne odpowiedzi wspomniały o tej kwestii, więc po prostu to zostawię.

Rozdzielenie obaw

I wszystkie powyższe wiążą się z tym nadrzędnym tematem: zachowajcie swoje obawy oddzielnie. Twój pogląd działa jako oficjalny zapis tego, co ma się wydarzyć (w przeważającej części); twój model reprezentuje twoje dane; masz warstwę usługi do wykonywania zadań wielokrotnego użytku; manipulujesz DOMem i powiększasz swój widok za pomocą dyrektyw; i przyklejasz to wszystko razem ze sterownikami. Zostało to również wspomniane w innych odpowiedziach, a jedyne, co chciałbym dodać, dotyczy testowalności, o czym mówię w innej sekcji poniżej.

Wstrzyknięcie zależności

Pomóc nam w oddzieleniu obaw iniekcja zależności (DI). Jeśli pochodzisz z języka po stronie serwera (od Jawa do PHP) prawdopodobnie już znasz tę koncepcję, ale jeśli jesteś facetem od strony klienta pochodzącym z jQuery, koncepcja ta może wydawać się od głupiego do niepotrzebnego do hipsterskiego. Ale nie jest. :-)

Z szerokiej perspektywy, DI oznacza, że ​​możesz deklarować komponenty bardzo swobodnie, a następnie z dowolnego innego komponentu, po prostu zapytaj o jego instancję, a zostanie przyznany. Nie musisz wiedzieć o kolejności ładowania, lokalizacjach plików ani tym podobnych. Moc może nie być od razu widoczna, ale podam tylko jeden (wspólny) przykład: testowanie.

Załóżmy, że w naszej aplikacji potrzebujemy usługi, która implementuje pamięć po stronie serwera przez ODPOCZYNEK API oraz, w zależności od stanu aplikacji, również pamięć lokalna. Podczas testowania naszych kontrolerów nie chcemy komunikować się z serwerem - testujemy kontroler, po wszystkim. Możemy po prostu dodać fałszywą usługę o tej samej nazwie, co nasz oryginalny komponent, a wtryskiwacz zapewni, że nasz kontroler automatycznie otrzyma fałszywą - nasz kontroler nie potrzebuje i nie musi znać różnicy.

Mówiąc o testowaniu ...

4. Rozwój oparty na testach - zawsze

To naprawdę część sekcji 3 poświęconej architekturze, ale jest tak ważne, że umieszczam ją jako własną sekcję najwyższego poziomu.

Spośród wielu wtyczek jQuery, które widziałeś, używasz lub piszesz, ile z nich miało dołączony zestaw testów? Niezbyt wiele, ponieważ jQuery nie jest do tego przystosowany. Ale AngularJS jest.

W jQuery jedynym sposobem testowania jest często tworzenie komponentu niezależnie za pomocą strony próbnej / demonstracyjnej, wobec której nasze testy mogą wykonywać manipulację DOM. Więc musimy opracować komponent osobno i następnie zintegrować go z naszą aplikacją. Jak niewygodne! Tyle czasu, rozwijając się z jQuery, wybieramy iteracyjne, a nie testowe. I kto może nas winić?

Ale ponieważ rozdzielamy obawy, możemy w iteracyjnie pracować w AngularJS! Na przykład, powiedzmy, że chcemy super-prostej dyrektywy, aby wskazać w naszym menu, jaka jest nasza obecna trasa. Możemy ogłosić, czego chcemy w związku z naszą aplikacją:

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

Okay, teraz możemy napisać test na nieistniejący when-active dyrektywa:

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

A kiedy przeprowadzimy nasz test, możemy potwierdzić, że się nie udało. Dopiero teraz powinniśmy stworzyć naszą dyrektywę:

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

Nasz test teraz przemija i nasze menu działa zgodnie z życzeniem. Nasz rozwój jest obie wielokrotny i testowane. Wicked-cool.

5. Koncepcyjnie, dyrektywy są nie zapakowane jQuery

Często słyszysz "tylko manipulację DOM w dyrektywie". To konieczność. Traktuj to z należytym szacunkiem!

Ale zanurzmy się trochę głębiej ...

Niektóre dyrektywy tylko dekorują to, co już jest w widoku (pomyśl ngClass) i dlatego czasami od razu manipulują DOM, a następnie są wykonywane. Ale jeśli dyrektywa jest jak "widget" i ma szablon, powinna również szanować rozdzielność obaw. To znaczy szablon także powinien pozostać w dużej mierze niezależny od jego realizacji w funkcji łącza i kontrolera.

AngularJS zawiera cały zestaw narzędzi, aby było to bardzo łatwe; z ngClass możemy dynamicznie aktualizować klasę; ngModel umożliwia dwukierunkowe powiązanie danych; ngShow i ngHide programowo pokazać lub ukryć element; i wiele innych - w tym te, które sami piszemy. Innymi słowy, możemy robić wszystkie rodzaje wspaniałości bez Manipulacja DOM. Im mniej manipulacji DOM, tym łatwiejsze dyrektywy mają być testowane, im łatwiej je projektować, tym łatwiej je zmienić w przyszłości, a tym bardziej nadają się do ponownego wykorzystania i dystrybucji.

Widzę wielu nowych programistów w AngularJS przy użyciu dyrektyw jako miejsca, w którym można rzucić kilka jQuery. Innymi słowy, myślą "skoro nie mogę manipulować DOMem w kontrolerze, wezmę ten kod do dyrektywy". Chociaż z pewnością jest znacznie lepiej, to często wciąż źle.

Pomyśl o rejestratorze, który zaprogramowaliśmy w sekcji 3. Nawet jeśli umieścimy to w dyrektywie, my nadal chce to zrobić "Angular Way". To nadal nie przyjmuje manipulacji DOM! Istnieje wiele razy, gdy manipulacja DOM jest konieczna, ale jest to los rzadsze niż myślisz! Przed rozpoczęciem manipulacji DOM gdziekolwiek w swojej aplikacji zadaj sobie pytanie, czy naprawdę tego potrzebujesz. Może być lepszy sposób.

Oto krótki przykład, który pokazuje najczęściej wyświetlany wzór. Chcemy przycisku, który można zmienić. (Uwaga: ten przykład jest trochę wymyślny, a skosh verbose przedstawia bardziej skomplikowane sprawy, które są rozwiązywane dokładnie w ten sam sposób.)

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

W tym jest kilka rzeczy:

  1. Po pierwsze, jQuery nigdy nie był potrzebny. Nie ma tu niczego, co potrzebowalibyśmy jQuery!
  2. Po drugie, nawet jeśli już mamy jQuery na naszej stronie, nie ma powodu, aby używać go tutaj; możemy po prostu użyć angular.element a nasz komponent będzie działał po upuszczeniu do projektu, który nie ma jQuery.
  3. Po trzecie, nawet zakładając jQuery był wymagane do działania tej dyrektywy, jqLite (angular.element) będzie zawsze użyj jQuery, jeśli został załadowany! Więc nie potrzebujemy używać $ - Możemy po prostu użyć angular.element.
  4. Czwarty, ściśle związany z trzecim, jest taki, że elementy jqLite nie muszą być zawijane $ - element który jest przekazywany do link funkcja będzie już być element jQuery!
  5. A po piąte, o którym wspominaliśmy w poprzednich rozdziałach, dlaczego mieszamy elementy szablonu z naszą logiką?

Ta dyrektywa może zostać przepisana (nawet w bardzo skomplikowanych przypadkach!) O wiele prostszy:

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

Ponownie, szablon jest w szablonie, więc Ty (lub Twoi użytkownicy) możesz łatwo zamienić go na taki, który spełnia wszelkie niezbędne style, a logika nigdy nie trzeba było tego dotykać. Wielokrotność użycia - bum!

I nadal są te wszystkie inne korzyści, takie jak testowanie - to proste! Bez względu na to, co jest w szablonie, wewnętrzny interfejs API dyrektywy nigdy nie jest dotykany, więc refaktoryzacja jest łatwa. Możesz zmienić szablon tak, jak chcesz, bez dotykania dyrektywy. I bez względu na to, co zmienisz, twoje testy wciąż mijają.

w00t!

Jeśli więc dyrektywy nie są tylko kolekcjami funkcji podobnych do jQuery, to jakie one są? Dyrektywy są w rzeczywistości rozszerzenia HTML. Jeśli HTML nie robi czegoś, czego potrzebujesz, piszesz dyrektywę, aby zrobić to za Ciebie, a następnie używasz go tak, jakby był częścią HTML.

Innymi słowy, jeśli AngularJS nie robi czegoś po wyjęciu z pudełka, zastanów się, w jaki sposób zespół mógłby to osiągnąć, dopasowując się do ngClick, ngClass, et al.

Podsumowanie

Nawet nie używaj jQuery. Nawet go nie dołączaj. To cię powstrzyma. A kiedy dojdziesz do problemu, który wydaje ci się, że już wiesz, jak rozwiązać w jQuery, zanim sięgniesz po $, spróbuj pomyśleć o tym, jak to zrobić w ramach AngularJS. Jeśli nie wiesz, zapytaj! 19 razy na 20, najlepszy sposób na zrobienie tego nie wymaga jQuery i próba rozwiązania go za pomocą jQuery daje więcej pracy dla ciebie.


7187
2018-02-21 21:26



Myślę, że włączenie pracy z JQuery w kanonicznej aplikacji jest ważnym przypadkiem użycia ze względu na wszystkie istniejące wtyczki JQuery, które zostały napisane. Nie przepisuję FancyBox w jQuery, aby zachować czystą aplikację Angular. - taudep
@taudep Nie sądzę, że nie zgadzamy się tak bardzo, jak myślisz. Większość wtyczek jQuery można tanio przepisać w AngularJS, aw takich przypadkach powinniśmy to zrobić. Dla czegoś złożonego, dla którego nie ma odpowiednika, idźcie za nim. Cytat z sekcji 2: "Najważniejsze jest to, że podczas rozwiązania najpierw" pomyśl w AngularJS "; jeśli nie możesz wymyślić rozwiązania, zapytaj społeczność; jeśli po tym wszystkim nie ma łatwego rozwiązania, możesz sięgnąć po jQuery. Ale nie pozwól, aby jQuery stała się kulą albo nigdy nie opanujesz AngularJS. [wyróżnienia dodane] - Josh David Miller
Chińczyk tłumaczy na tę wspaniałą odpowiedź, nadzieja jest pomocna. hanzheng.github.io/tech/angularjs/2013/10/28/... - Han Zheng
@Benno Co oznacza "brak manipulacji DOM" to fakt, że twój kod w dyrektywie nie wykonuje bezpośrednio manipulacji DOM. Ten kod nic nie wie o DOM, tylko modyfikuje zmienne js w twoim modelu. Tak, efekt końcowy jest taki, że DOM zostaje zmodyfikowany, ale to dlatego, że poza kodem, który piszemy, są wiązania, które reagują na nasze zmienne, ale w dyrektywie nic o tym nie wiemy, robiąc czysty rozdział pomiędzy manipulacją DOM a logika biznesowa. W twoim przykładzie jQuery zmieniasz bezpośrednio DOM, mówiąc "dołącz ten tekst do tego elementu" - wired_in
@trusktr Jeśli kiedykolwiek uda się ustawić wartość elementu wejściowego za pomocą jQuery w aplikacji AngularJS, popełnia ona błąd ciężki błąd. Jedynym rodzajem wyjątku, który mogę sobie wyobrazić, jest istniejąca wtyczka jQuery, która jest zbyt trudna do przeniesienia, która automatycznie zmienia dane wejściowe. W takim przypadku absolutnie niezbędne jest podłączenie się do wywołania zwrotnego lub ustawienie zegarka w celu dostosowania zmian do aplikacji. - Josh David Miller


Imperatywny → deklaratywny

W jQuery, selektory są używane do znalezienia DOM elementy, a następnie dołącz do nich funkcje obsługi zdarzeń. Kiedy zdarzenie się uruchamia, ten (imperatywny) kod wykonuje aktualizację / zmianę DOM.

W AngularJS chcesz się zastanowić widoki zamiast elementów DOM. Widoki to (deklaratywny) HTML zawierający AngularJS dyrektywy. Dyrektywy przygotowują dla nas obsługę zdarzeń za kulisami i zapewniają nam dynamiczne wiązanie danych. Selektory są rzadko używane, więc zapotrzebowanie na identyfikatory (i niektóre typy klas) jest znacznie zmniejszone. Widoki są powiązane modele (poprzez lunety). Widoki są rzutowaniem modelu. Zdarzenia zmieniają modele (tj. Dane, właściwości zakresu) oraz widoki, które rzutują te modele na aktualizację "automatycznie".

W AngularJS pomyśl o modelach, a nie elementach DOM wybranych przez jQuery, które przechowują twoje dane. Pomyśl o widokach jako o rzutach tych modeli, zamiast rejestrować wywołania zwrotne, aby manipulować tym, co widzi użytkownik.

Rozdzielenie obaw

jQuery zatrudnia dyskretny JavaScript - zachowanie (JavaScript) jest oddzielone od struktury (HTML).

AngularJS używa kontrolerów i dyrektywy (z których każda może mieć własny kontroler i / lub kompilować i łączyć funkcje), aby usunąć zachowanie z widoku / struktury (HTML). Angular też usługi i filtry aby oddzielić / zorganizować swoją aplikację.

Zobacz też https://stackoverflow.com/a/14346528/215945

Projektowanie aplikacji

Jedno podejście do projektowania aplikacji AngularJS:

  1. Pomyśl o swoich modelach. Utwórz usługi lub własne obiekty JavaScript dla tych modeli.
  2. Zastanów się, jak chcesz zaprezentować swoje modele - swoje poglądy. Twórz szablony HTML dla każdego widoku, używając niezbędnych dyrektyw, aby uzyskać dynamiczne wiązanie danych.
  3. Dołącz kontroler do każdego widoku (używając ng-view i routingu lub ng-kontrolera). Niech kontroler znajdzie / uzyska tylko te dane modelu, których widok potrzebuje do wykonania swojej pracy. Spraw, aby kontrolery były tak cienkie, jak to tylko możliwe.

Prototypowe dziedziczenie

Możesz dużo zrobić z jQuery bez wiedzy o działaniu prototypowego dziedziczenia JavaScript. Podczas tworzenia aplikacji AngularJS unikniesz typowych pułapek, jeśli dobrze zrozumiesz dziedziczenie JavaScriptu. Rekomendowane lektury: Jakie są niuanse zakresu prototypowego / prototypowego dziedziczenia w AngularJS?


408
2018-02-21 04:09



czy możesz to zrobić. wyjaśnić, w jaki sposób element dom różni się od widoku? - rajkamal
@rajkamal, elementem DOM jest (oczywiście) pojedynczy element, aw jQuery często to, co wybieramy / celujemy / manipulujemy. Widok kątowy to kolekcja / szablon powiązanych elementów DOM: widok menu, widok nagłówka, widok stopki, widok z prawej strony paska bocznego, widok profilu, może wiele widoków głównych treści (przełączanych za pośrednictwem widoku ng). Zasadniczo chcesz podzielić strony na różne widoki. Każdy widok ma swój powiązany kontroler. Każdy widok przedstawia część twojego modelu (modeli). - Mark Rajcok
jQuery jest NIE tryb rozkazujący. on i when są funkcjami wyższego rzędu, działającymi na elementach obiektu kolekcji jQuery. - Jack Viers
Więc jaki rodzaj kodu zostanie wykonany w wywołaniu zwrotnym dla on? Tryb rozkazujący. - cwharris
Ten imperatyw kontra deklaratywny jest po prostu kwestią abstrakcji. Ostatecznie, cały kod deklaratywny (co zrobić) jest implementowany imperatywnie (jak to zrobić) przez programistę w podprogramie na niższym poziomie abstrakcji, przez framework lub kompilator / interpreter. Powiedzieć, że "jQuery jest imperatywem" w ogóle jest dość dziwnym stwierdzeniem, szczególnie biorąc pod uwagę, że w rzeczywistości zapewnia znacznie bardziej deklaratywny interfejs API w odniesieniu do "ręcznej" manipulacji DOM. - Alex


AngularJS vs. jQuery

AngularJS i jQuery przyjmują bardzo różne ideologie. Jeśli pochodzisz z jQuery, niektóre różnice mogą być zaskakujące. Angular może cię rozgniewać.

To normalne, powinieneś przejść. Angular jest tego wart.

Duża różnica (TLDR)

jQuery udostępnia zestaw narzędzi do wybierania dowolnych bitów DOM i wprowadzania w nich zmian ad-hoc. Możesz zrobić prawie wszystko, co chcesz, kawałek po kawałku.

AngularJS zamiast tego daje kompilator.

Oznacza to, że AngularJS odczytuje cały twój DOM od góry do dołu i traktuje go jako kod, dosłownie jako instrukcje dla kompilatora. Gdy przechodzi przez DOM, szuka określonego dyrektywy (dyrektywy kompilacyjne), które informują kompilator AngularJS o tym, jak się zachowywać i co robić. Dyrektywy to małe obiekty pełne JavaScriptu, które można dopasować do atrybutów, tagów, klas, a nawet komentarzy.

Kiedy kompilator Angular określa, że ​​fragment DOM pasuje do konkretnej dyrektywy, wywołuje funkcję dyrektywy, przekazując jej element DOM, dowolne atrybuty, bieżący $ scope (który jest magazynem zmiennych lokalnych) i kilka innych użytecznych bitów. Atrybuty te mogą zawierać wyrażenia, które mogą być interpretowane przez dyrektywę i które mówią, jak renderować, i kiedy powinny się przerysowywać.

Dyrektywy mogą następnie z kolei pobierać dodatkowe komponenty kątowe, takie jak kontrolery, usługi itp. To, co wychodzi na dno kompilatora, to w pełni uformowana aplikacja internetowa, podłączona i gotowa do użycia.

Oznacza to, że Angular jest szablonem napędzanym. Twój szablon napędza JavaScript, a nie na odwrót. Jest to radykalna zmiana ról i zupełne przeciwieństwo dyskretnego JavaScriptu, który pisaliśmy przez ostatnie 10 lat. Może to trochę przyzwyczaić.

Jeśli wydaje się, że może to być zbyt nakazowe i ograniczające, nic nie może być dalej od prawdy. Ponieważ AngularJS traktuje twój kod HTML jako kod, dostajesz Ziarnistość poziomu HTML w aplikacji internetowej. Wszystko jest możliwe, a większość rzeczy jest zaskakująco łatwa, gdy wykonasz kilka skoków pojęciowych.

Przejdźmy do nitty.

Po pierwsze, Angular nie zastępuje jQuery

Angular i jQuery robią różne rzeczy. AngularJS oferuje zestaw narzędzi do tworzenia aplikacji internetowych. jQuery dostarcza głównie narzędzi do modyfikowania DOM. Jeśli jQuery jest obecny na twojej stronie, AngularJS użyje go automatycznie. Jeśli nie jest, AngularJS jest dostarczany z jQuery Lite, która jest przyciętą, ale wciąż doskonale użyteczną wersją jQuery.

Misko lubi jQuery i nie sprzeciwia się, że go używasz. Jednak w miarę postępu będziesz mógł wykonać prawie całą swoją pracę przy użyciu kombinacji zakresu, szablonów i dyrektyw, i powinieneś preferować ten przepływ pracy, gdzie to możliwe, ponieważ twój kod będzie bardziej dyskretny, bardziej konfigurowalny i bardziej Kątowy.

Jeśli korzystasz z jQuery, nie powinieneś zraszać go w każdym miejscu. Prawidłowym miejscem do manipulacji DOM w AngularJS jest dyrektywa. Więcej o nich później.

Nierzucający się w oczy JavaScript z selektorami a szablonami deklaratywnymi

jQuery jest zwykle stosowany dyskretnie. Twój kod JavaScript jest połączony w nagłówku (lub stopce) i jest to jedyne miejsce, o którym jest wspomniane. Używamy selektorów do wybierania bitów strony i pisania wtyczek do modyfikacji tych części.

JavaScript jest pod kontrolą. HTML ma całkowicie niezależne istnienie. Twój HTML pozostaje semantyczny nawet bez JavaScript. Atrybuty Onclick są bardzo złą praktyką.

Jedną z pierwszych rzeczy, które zauważysz na temat AngularJS, jest to niestandardowe atrybuty są wszędzie. Twój HTML będzie zaśmiecony atrybutami ng, które są zasadniczo atrybutami onClick na sterydach. Są to dyrektywy (dyrektywy kompilacyjne) i są jednym z głównych sposobów, w jaki szablon jest podłączony do modelu.

Kiedy po raz pierwszy to zobaczysz, możesz ulec pokusie, by napisać AngularJS jako staromodnego intratnego JavaScript (tak jak zrobiłem to na początku). W rzeczywistości AngularJS nie gra według tych zasad. W AngularJS Twój HTML5 jest szablonem. Jest on opracowywany przez AngularJS w celu stworzenia Twojej strony internetowej.

To pierwsza duża różnica. Do jQuery twoja strona internetowa to DOM do manipulacji. Do AngularJS Twój kod HTML jest skompilowany. AngularJS czyta na twojej stronie internetowej i dosłownie kompiluje ją do nowej strony internetowej przy użyciu wbudowanego kompilatora.

Twój szablon powinien być deklaratywny; jego znaczenie powinno być jasne po prostu przez czytanie. Używamy atrybutów niestandardowych o znaczących nazwach. Tworzymy nowe elementy HTML, ponownie o znaczących nazwach. Projektant posiadający minimalną wiedzę HTML i brak umiejętności kodowania może przeczytać szablon AngularJS i zrozumieć, co robi. On lub ona może dokonać modyfikacji. Jest to metoda kątowa.

Szablon znajduje się na siedzeniu kierowcy.

Jednym z pierwszych pytań zadawałem sobie przy uruchamianiu AngularJS i przeglądaniu samouczków "Gdzie jest mój kod?". Nie napisałem kodu JavaScript, a mimo to mam to wszystko. Odpowiedź jest oczywista. Ponieważ AngularJS kompiluje DOM, AngularJS traktuje twój HTML jako kod. W wielu prostych przypadkach wystarczy napisać szablon i pozwolić AngularJS skompilować go do aplikacji dla ciebie.

Twój szablon napędza Twoją aplikację. Jest traktowany jako DSL. Piszesz komponenty AngularJS, a AngularJS zajmie się ich wciąganiem i udostępnianiem we właściwym czasie w oparciu o strukturę twojego szablonu. To bardzo różni się od standardu MVC wzorzec, w którym szablon jest po prostu dla wyniku.

Jest bardziej podobny do XSLT niż Ruby on Rails na przykład.

Jest to radykalna inwersja kontroli, do której trzeba się przyzwyczaić.

Przestań próbować kierować swoją aplikacją z JavaScript. Niech szablon napędza aplikację i pozwól AngularJS zadbać o okablowanie komponentów razem. Jest to również metoda kątowa.

Semantyczny HTML a modele semantyczne

W przypadku jQuery strona HTML powinna zawierać treści znaczące semantycznie. Jeśli JavaScript jest wyłączony (przez użytkownika lub wyszukiwarkę), twoja treść pozostaje dostępna.

Ponieważ AngularJS traktuje twoją stronę HTML jako szablon. Szablon nie powinien być semantyczny, ponieważ twoja zawartość jest zwykle przechowywana w twoim modelu, który ostatecznie pochodzi z twojego API. AngularJS kompiluje DOM z modelem, aby wytworzyć semantyczną stronę internetową.

Twoje źródło HTML nie jest już semantyczne, zamiast tego twój interfejs API i skompilowany DOM są semantyczne.

W AngularJS, oznaczającym życie w modelu, HTML jest tylko szablonem, tylko do wyświetlania.

W tym momencie prawdopodobnie masz wiele pytań dotyczących SEO i dostępność, i słusznie. Tutaj są otwarte problemy. Większość czytników ekranu będzie teraz parsować JavaScript. Wyszukiwarki mogą również indeksować AJAXed zadowolony. Mimo to będziesz chciał się upewnić, że używasz adresów URL typu "paczep" i masz przyzwoitą mapę witryny. Zobacz tutaj, aby omówić problem: https://stackoverflow.com/a/23245379/687677

Separacja obaw (SOC) a MVC

Rozdzielenie obaw (SOC) to wzorzec, który rozwijał się przez wiele lat tworzenia stron internetowych z różnych powodów, takich jak SEO, dostępność i niekompatybilność przeglądarki. To wygląda tak:

  1. HTML - znaczenie semantyczne. HTML powinien być samodzielny.
  2. CSS - Stylizacja, bez CSS strona jest wciąż czytelna.
  3. JavaScript - zachowanie, bez skryptu treść pozostaje.

Znowu AngularJS nie gra według swoich zasad. W udarze, AngularJS eliminuje dekadę otrzymanej mądrości i zamiast tego implementuje wzór MVC, w którym szablon nie jest już semantyczny, ani nawet trochę.

To wygląda tak:

  1. Model - twoje modele zawierają twoje dane semantyczne. Modele są zwykle JSON obiekty. Modele istnieją jako atrybuty obiektu o nazwie $ scope. Możesz także przechowywać przydatne funkcje na $ scope, do których twoje szablony będą wtedy miały dostęp.
  2. Zobacz - Twoje poglądy są napisane w HTML. Widok zazwyczaj nie jest semantyczny, ponieważ Twoje dane pozostają w modelu.
  3. Kontroler - Twój kontroler to funkcja JavaScript, która podpina widok do modelu. Jego funkcją jest zainicjowanie $ scope. W zależności od aplikacji możesz lub nie musisz tworzyć kontrolera. Możesz mieć wiele kontrolerów na stronie.

MVC i SOC nie znajdują się na przeciwnych końcach tej samej skali, są na zupełnie innych osiach. SOC nie ma sensu w kontekście AngularJS. Musisz o tym zapomnieć i iść dalej.

Jeśli, tak jak ja, przeżyłeś wojny w przeglądarce, ten pomysł może okazać się dość obraźliwy. Przełóż to, to będzie tego warte, obiecuję.

Wtyczki a dyrektywy

Wtyczki rozszerzają jQuery. Dyrektywy AngularJS rozszerzają możliwości przeglądarki.

W jQuery definiujemy wtyczki dodając funkcje do jQuery.prototype. Następnie podłączamy je do DOM, wybierając elementy i wywołując wtyczkę na wyniku. Chodzi o to, aby rozszerzyć możliwości jQuery.

Na przykład, jeśli chcesz mieć karuzelę na swojej stronie, możesz zdefiniować nieuporządkowaną listę figur, być może zapakowaną w element nav. Możesz następnie napisać jQuery, aby wybrać listę na stronie i zmienić ją jako galerię z limitami czasu do wykonania animacji przesuwającej.

W AngularJS definiujemy dyrektywy. Dyrektywa jest funkcją, która zwraca obiekt JSON. Ten obiekt informuje AngularJS, jakie elementy DOM należy szukać i jakie zmiany należy wprowadzić w nich. Dyrektywy są powiązane z szablonem za pomocą atrybutów lub elementów, które wymyślasz. Chodzi o to, aby rozszerzyć możliwości HTML o nowe atrybuty i elementy.

Metoda AngularJS ma na celu rozszerzenie możliwości natywnego HTML. Powinieneś napisać HTML, który wygląda jak HTML, rozszerzony o niestandardowe atrybuty i elementy.

Jeśli chcesz mieć karuzelę, po prostu użyj a <carousel /> element, a następnie zdefiniuj dyrektywę, aby pobrać szablon i spraw, aby ten frajer działał.

Wiele małych dyrektyw w porównaniu z dużymi wtyczkami z przełącznikami konfiguracji

Tendencja z jQuery polega na pisaniu świetnych wtyczek takich jak lightbox, które następnie konfigurujemy, przekazując wiele wartości i opcji.

To jest błąd w AngularJS.

Weź przykład listy rozwijanej. Podczas pisania rozwijanej wtyczki możesz ulec pokusie kodowania w procedurach obsługi kliknięć, być może funkcji dodawania chevronu, który jest albo w górę, albo w dół, może zmienić klasę rozwiniętego elementu, pokazać ukryj menu, wszystkie pomocne rzeczy.

Aż chcesz wprowadzić niewielką zmianę.

Powiedzmy, że masz menu, które chcesz rozwinąć po najechaniu kursorem myszy. Teraz mamy problem. Nasza wtyczka została podłączona do naszego modułu obsługi kliknięć. Będziemy musieli dodać opcję konfiguracji, aby zachowywać się inaczej w tym konkretnym przypadku.

W AngularJS piszemy mniejsze dyrektywy. Nasza dyrektywa dropdown byłaby śmiesznie mała. Może zachowywać złożony stan i zapewnia metody zwijania (), rozwijania () lub przełączania (). Te metody po prostu zaktualizują wartość $ scope.menu.visible, która jest wartością logiczną trzymającą stan.

Teraz w naszym szablonie możemy to połączyć:

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

Potrzebujesz aktualizacji na mouseover?

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

Szablon napędza aplikację, dzięki czemu uzyskujemy szczegółowość na poziomie HTML. Jeśli chcemy tworzyć wyjątki dla poszczególnych przypadków, szablon to ułatwia.

Zamknięcie a $ zasięg

Wtyczki JQuery są tworzone w zamknięciu. Prywatność jest utrzymana w tym zamknięciu. Od Ciebie zależy utrzymanie łańcucha zasięgu w ramach tego zamknięcia. Naprawdę masz dostęp tylko do zestawu węzłów DOM przekazanych do wtyczki przez jQuery, plus dowolne zmienne lokalne zdefiniowane w zamknięciu i wszystkie zdefiniowane globale. Oznacza to, że wtyczki są całkowicie niezależne. Jest to dobre, ale może stać się restrykcyjne podczas tworzenia całej aplikacji. Próba przekazania danych między sekcjami strony dynamicznej staje się obowiązkiem.

AngularJS ma obiekty typu $ scope. Są to specjalne obiekty tworzone i utrzymywane przez AngularJS, w których przechowujesz swój model. Niektóre dyrektywy odradzają nowy zakres $, który domyślnie dziedziczy po zawinięciu $ scope przy użyciu prototypowego dziedziczenia JavaScript. Obiekt $ scope jest dostępny w kontrolerze i widoku.

To jest sprytna część. Ponieważ struktura dziedziczenia $ scope z grubsza podąża za strukturą DOM, elementy mają dostęp do własnego zakresu i dowolnych zawierających zakresy, aż do globalnego zakresu $ (który nie jest taki sam jak zasięg globalny).

To znacznie ułatwia przesyłanie danych i przechowywanie danych na odpowiednim poziomie. Jeśli rozwijany jest rozwijany, tylko dropdown $ scope musi o tym wiedzieć. Jeśli użytkownik zaktualizuje swoje preferencje, może być konieczne zaktualizowanie globalnego zakresu $, a wszystkie zagnieżdżone zakresy nasłuchujące preferencji użytkownika zostaną automatycznie ostrzeżone.

To może wydawać się skomplikowane, w rzeczywistości, gdy się w niej zrelaksujesz, to jest jak latanie. Nie musisz tworzyć obiektu $ scope, AngularJS tworzy instancje i konfiguruje je dla ciebie, poprawnie i odpowiednio na podstawie hierarchii szablonów. AngularJS następnie udostępnia go twojemu komponentowi za pomocą magicznego zastrzyku zależności (więcej o tym później).

Ręczne zmiany DOM a wiązanie danych

W jQuery ręcznie zmieniasz wszystkie zmiany DOM. Budujesz nowe elementy DOM programowo. Jeśli masz tablicę JSON i chcesz umieścić ją w DOM, musisz napisać funkcję generującą HTML i wstawić ją.

W AngularJS możesz to również zrobić, ale zachęcamy do korzystania z powiązania danych. Zmień swój model, a ponieważ DOM jest z nim związany za pośrednictwem szablonu, twój DOM zostanie automatycznie zaktualizowany, bez interwencji.

Ponieważ powiązanie danych odbywa się z poziomu szablonu, przy użyciu składni lub składni nawiasów klamrowych, jest to bardzo łatwe. Z tym wiąże się niewielka ilość funkcji poznawczych, dzięki czemu możesz robić to cały czas.

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

Przywiązuje element wejściowy do $scope.user.name. Aktualizacja danych wejściowych spowoduje zaktualizowanie wartości w bieżącym zakresie i na odwrót.

Również:

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

wypisze nazwę użytkownika w akapicie. To połączenie na żywo, więc jeśli $scope.user.name wartość jest aktualizowana, szablon również zostanie zaktualizowany.

Ajax przez cały czas

W jQuery wykonanie połączenia Ajax jest dość proste, ale wciąż jest czymś, o czym możesz pomyśleć dwa razy. Jest jeszcze większa złożoność, o której trzeba pomyśleć, i sporo kawałka skryptu do utrzymania.

W AngularJS, Ajax jest Twoim domyślnym rozwiązaniem, a dzieje się tak przez cały czas, prawie bez zauważenia. Możesz dołączyć szablony z ng-include. Możesz zastosować szablon z najprostszą dyrektywą niestandardową. Możesz zawinąć połączenie Ajax w usłudze i stworzyć sobie GitHub usługa lub Flickr usługę, do której można uzyskać dostęp z zadziwiającą łatwością.

Obiekty usług a funkcje pomocnicze

W jQuery, jeśli chcemy wykonać małe zadanie niezwiązane z domem, takie jak pobranie kanału z interfejsu API, możemy napisać małą funkcję, aby to zrobić w naszym zamknięciu. To poprawne rozwiązanie, ale co jeśli chcemy często uzyskać dostęp do tego kanału? Co jeśli chcemy ponownie użyć tego kodu w innej aplikacji?

AngularJS daje nam obiekty usługowe.

Usługi to proste obiekty, które zawierają funkcje i dane. Są zawsze singletonami, co znaczy, że nigdy nie może być ich więcej niż jeden. Powiedzmy, że chcemy uzyskać dostęp do interfejsu API przepełnienia stosu, możemy napisać a StackOverflowService który definiuje metody.

Załóżmy, że mamy koszyk na zakupy. Możemy zdefiniować ShoppingCartService, która utrzymuje nasz koszyk i zawiera metody dodawania i usuwania przedmiotów. Ponieważ usługa jest singleton i jest dzielona przez wszystkie inne komponenty, każdy obiekt, który musi być w stanie zapisać w koszyku i pobrać z niego dane. To zawsze ten sam wózek.

Obiekty usług są samodzielnymi komponentami AngularJS, z których możemy korzystać i ponownie używać zgodnie z naszym przeznaczeniem. Są to proste obiekty JSON zawierające funkcje i dane. Są one zawsze pojedyncze, więc jeśli przechowujesz dane w usłudze w jednym miejscu, możesz uzyskać te dane w innym miejscu, żądając tej samej usługi.

Wstrzyknięcie zależności (DI) vs. Inforiation - vel de-spaghettification

AngularJS zarządza Twoimi zależnościami. Jeśli chcesz obiekt, po prostu go odnieś i AngularJS dostanie go za Ciebie.

Dopóki nie zaczniesz tego używać, ciężko ci wytłumaczyć, co to jest masowy czas. Wewnątrz jQuery nie ma nic takiego jak AngularJS DI.

DI oznacza, że ​​zamiast pisać aplikację i łączyć ją razem, definiuje się bibliotekę komponentów, z których każdy jest identyfikowany za pomocą łańcucha.

Załóżmy, że mam składnik o nazwie "FlickrService", który definiuje metody pobierania plików JSON z Flickr. Teraz, jeśli chcę napisać kontroler, który może uzyskać dostęp do Flickr, po ogłoszeniu kontrolera muszę po prostu podać nazwę "FlickrService". AngularJS zajmie się instancją komponentu i udostępnieniem go kontrolerowi.

Na przykład tutaj definiuję usługę:

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

Teraz, gdy chcę korzystać z tej usługi, po prostu odwołuję się do niej po imieniu w ten sposób:

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

AngularJS rozpozna, że ​​do utworzenia instancji kontrolera potrzebny jest obiekt FlickrService i dostarczy go dla nas.

Sprawia to, że okablowanie jest bardzo łatwe i praktycznie eliminuje wszelkie tendencje do spagettyfikacji. Mamy płaską listę komponentów, a AngularJS przekazuje je nam jeden po drugim, kiedy i kiedy ich potrzebujemy.

Modularna architektura usług

jQuery mówi bardzo niewiele o tym, jak należy organizować swój kod. AngularJS ma opinie.

AngularJS udostępnia moduły, w których możesz umieścić swój kod. Jeśli piszesz skrypt, który na przykład komunikuje się z Flickr, możesz utworzyć moduł Flickr, aby zawinąć wszystkie funkcje związane z Flickr. Moduły mogą zawierać inne moduły (DI). Główna aplikacja to zazwyczaj moduł, a to powinno obejmować wszystkie inne moduły, od których będzie zależeć twoja aplikacja.

Otrzymasz proste ponowne użycie kodu, jeśli chcesz napisać inną aplikację opartą na Flickr, możesz po prostu dołączyć moduł Flickr i voila, masz dostęp do wszystkich swoich funkcji związanych z Flickr w twojej nowej aplikacji.

Moduły zawierają składniki AngularJS. Kiedy dołączymy moduł, wszystkie komponenty w tym module stają się dostępne dla nas jako prosta lista określona przez ich unikalne ciągi. Możemy następnie wstrzykiwać te komponenty do siebie nawzajem za pomocą mechanizmu iniekcyjnego zależnego od AngularJS.

Podsumowując

AngularJS i jQuery nie są wrogami. Bardzo dobrze można używać jQuery w AngularJS. Jeśli używasz dobrze AngularJS (szablony, wiązanie danych, $ zakres, dyrektywy, itp.) Znajdziesz, że potrzebujesz los mniej jQuery niż możesz wymagać.

Najważniejsze, aby zorientować się, że Twój szablon napędza Twoją aplikację. Przestań próbować pisać duże wtyczki, które robią wszystko. Zamiast tego pisz mało dyrektyw, które wykonują jedną rzecz, a następnie napisz prosty szablon, aby je połączyć.

Mniej myśleć o dyskretnym kodzie JavaScript i zamiast tego myśleć w kategoriach rozszerzeń HTML.

Moja mała książka

Byłem bardzo podekscytowany AngularJS, napisałem na ten temat krótką książkę, którą możesz przeczytać online http://nicholasjohnson.com/angular-book/. Mam nadzieję, że to pomocne.


184
2018-05-12 10:22



Pomysł, że "Separacja obaw" różni się od "MVC (Model, Widok, Kontroler)" jest całkowicie fałszywy. Model języków rozdzielania spraw (HTML, CSS i JS) działa poprzez umożliwienie umieszczania treści na stronie internetowej (znaczniki / HTML) bez dbania o wygląd (styl / layout / CSS) lub o to, co "robi" (Wydarzenia DOM / AJAX / JavaScript). MVC oddziela także obawy. Każda "warstwa" w schemacie MVC ma inną rolę - dane, routing / logikę lub renderowanie. Warstwy są połączone przez wywołania zwrotne, trasy i powiązania modelu. Teoretycznie osoba może specjalizować się w każdej warstwie, co często ma miejsce. - Alexander Pritchard
Jako osoba wywodząca się ze ścisłego środowiska SOC i jako wieloletni obrońca standardów internetowych sięgających czasów wojny z przeglądarkami, początkowo uważałem, że niesinterantyczne szablony Angulara nie sprawdzają poprawności. Chciałem tylko dać jasno do zrozumienia, że ​​aby pisać Angular, konieczne jest odejście od SOC, ponieważ jest to ogólnie praktykowane. To może być trudne przejście. - superluminary
Masz rację. SOC jest pojęciem szerokim, ale w świecie WWW SOC ma (lub może mieć) bardzo konkretne znaczenie: semantyczny HTML, prezentacyjny kod CSS i JavaScript dla zachowania. Podejmuję pewne założenia dotyczące mojej publiczności, które być może nie są rozsądne, więc też powinienem przeprosić. - superluminary
Uważam twoją odpowiedź za najbardziej jasną i pouczającą. Jestem dość początkującym tutaj, więc jeśli mam rozszerzenie, aby zmienić istniejącą stronę (której nie kontroluję), czy powinienem zatrzymać JQuery? - Daniel Möller


Czy potrafisz opisać zmianę paradygmatu, która jest konieczna?

Imperatyw vs Deklaratywny

Z jQuery powiesz DOM, co musi się stać, krok po kroku. Z AngularJS opisujesz, jakie wyniki chcesz, ale nie, jak to zrobić. Więcej na ten temat tutaj. Sprawdź także odpowiedź Marka Rajcoka.

Jak inaczej projektować i projektować aplikacje internetowe po stronie klienta?

AngularJS to cała platforma po stronie klienta, która używa MVC wzór (sprawdź ich Reprezentacja graficzna). W dużym stopniu koncentruje się na oddzieleniu obaw.

Jaka jest największa różnica? Co powinienem przestać robić / używać; co powinienem zacząć robić / używać zamiast tego?

jQueryjest biblioteką

AngularJS to piękna struktura po stronie klienta, wysoce testowalna, która łączy mnóstwo fajnych rzeczy, takich jak MVC, iniekcja zależności, wiązanie danych i wiele więcej.

Skupia się na rozdzielenie obaw i testowanie (testów jednostkowych i testy end-to-end), co ułatwia rozwój oparty na testach.

Najlepszym sposobem na rozpoczęcie jest przejście ich niesamowity samouczek. Możesz przejść przez kolejne etapy w ciągu kilku godzin; Jednak w przypadku, gdy chcesz opanować koncepcje za kulisami, zawierają one niezliczone odniesienia do dalszego czytania.

Czy są jakieś względy / ograniczenia po stronie serwera?

Możesz go używać w istniejących aplikacjach, w których już używasz czystego jQuery. Jednakże, jeśli chcesz w pełni skorzystać z funkcji AngularJS, możesz rozważyć kodowanie strony serwera przy użyciu a Spokojny podejście.

Pozwoli to na wykorzystanie ich fabryka surowców, który tworzy abstrakcję twojego serwera RESTful API i sprawia, że ​​wywołania po stronie serwera (get, save, delete, etc.) są niezwykle łatwe.


152
2018-02-21 04:29



Wydaje mi się, że rozmawiasz o wodzie, mówiąc o tym, że jQuery to "biblioteka", a Angular to "framework" ... po pierwsze, myślę, że można argumentować, że jQuery jest framework ... to abstrakcja manipulacji DOM i obsługi zdarzeń. To nie może być struktura dla tego samego rodzaju rzeczy, co Angular, ale to dylemat, w którym znajduje się pytający: tak naprawdę nie znają różnicy między Angular i jQuery, a dla wszystkich pytających wie, jQuery jest ramy do budowania stron internetowych o dużym obciążeniu klienta. Spór o terminologię nie wyjaśni tego. - Zando
Myślę, że to ty się mylisz. To pytanie dotyczy dokładnie tego stackoverflow.com/questions/7062775. Ponadto ta odpowiedź może pomóc w wyjaśnieniu, czym różni się struktura i biblioteka: stackoverflow.com/a/148759/620448 - Ulises
Biblioteka nie staje się "ramą" tylko dlatego, że jej zbiór funkcji jest szczególnie użyteczny lub duży. Ramy podejmowania decyzji dla Ciebie. Kiedy zaczniesz używać AngularJS, prawdopodobnie dołączysz do niego z natury. (Np. Powinieneś aktualizować DOM tylko w dyrektywach, w przeciwnym razie coś zepsuje.) To dlatego, że AngularJS to framework. Korzystając z narzędzia jQuery, można stosunkowo łatwo mieszać i dopasowywać narzędzia przy minimalnym ryzyku konfliktu. Dzieje się tak dlatego, że jQuery jest biblioteką i przynajmniej w połowie przyzwoitą. - Alexander Pritchard
ZA biblioteka jest kod, do którego dzwonisz. ZA struktura to kod, który wywołuje twój kod. Dzięki tej definicji Angular jest strukturą. Dostarczasz komponenty i Angular widzi, że twoje komponenty są tworzone z zależnościami, których potrzebują. - superluminary


Aby opisać "zmianę paradygmatu", myślę, że wystarczy krótka odpowiedź.

AngularJS zmienia sposób w jaki ty odnaleźć elementy

W jQueryzazwyczaj używasz selektory znaleźć elementy, a następnie je połączyć:
$('#id .class').click(doStuff);

W AngularJS, używasz dyrektywy aby oznaczyć elementy bezpośrednio, aby je połączyć:
<a ng-click="doStuff()">

AngularJS nie potrzebuje (lub nie chce) znaleźć elementów za pomocą selektorów - zasadniczej różnicy między AngularJS jqLite w porównaniu do pełnowymiarowego jQuery czy to jqLite nie obsługuje selektorów.

Kiedy ludzie mówią "nie włączaj w ogóle jQuery", to głównie dlatego, że nie chcą, abyś używał selektorów; chcą, abyś nauczył się używać dyrektyw. Bezpośrednio, nie wybierz!


84
2018-02-21 07:57



Podobnie jak zastrzeżenie, istnieje znacznie więcej istotnych różnic między Angular i jQuery. Ale znajdowanie elementów to ta, która wymaga największej zmiany myślenia. - Scott Rippey
wybacz mi, jeśli się mylę, ale myślałem, że selektor jest tym, czego używasz do znalezienia elementu DOM? Wolisz zachować każdą pojedynczą część swojego nowo załadowanego interfejsu w celu odniesienia, zamiast po prostu wybierać jeden lub dwa elementy, które użytkownik może kliknąć, w locie za pomocą selektora? brzmi trudniej dla mnie .. - RozzA
@AlexanderPritchard Punkt Angular nie jest wybierany ze skryptu JavaScript, bezpośrednio z szablonu. Jest to odwrócenie kontroli, która przekazuje władzę w ręce projektanta. Jest to celowa zasada projektowania. Naprawdę otrzymać Angular musisz myśleć o swoim kodzie w ten sposób. To trudna zmiana. - superluminary
@superluminary Co za wspaniały cytat! "nie wybieraj, bezpośredni!" Poważnie, użyję tego. - Scott Rippey
To jedna z moich ulubionych rzeczy o AngularJS. Nie muszę się martwić, że zespół UX przerywa moją funkcjonalność lub łamie styl. Używają klas, ja korzystam z dyrektyw, kropka. Nie tęsknię za selektorami. - adam0101


jQuery

jQuery tworzy absurdalnie długie polecenia JavaScript, takie jak getElementByHerpDerp krótszy i między przeglądarkami.

AngularJS

AngularJS pozwala tworzyć własne znaczniki / atrybuty HTML, które działają dobrze w dynamicznych aplikacjach internetowych (ponieważ HTML został zaprojektowany dla stron statycznych).

Edytować:

Mówiąc "Mam tło jQuery, jak mam myśleć w AngularJS?" jest jak powiedzenie "Mam tło HTML, jak myślę w JavaScript?" To, że zadajesz pytanie, pokazuje, że najprawdopodobniej nie rozumiesz podstawowych celów tych dwóch zasobów. Właśnie dlatego zdecydowałem się odpowiedzieć na to pytanie, po prostu wskazując na zasadniczą różnicę zamiast przechodząc przez listę, mówiąc: "AngularJS korzysta z dyrektyw, podczas gdy jQuery używa selektorów CSS do stworzenia obiektu jQuery, który robi to i tamto itd." . To pytanie nie wymaga długiej odpowiedzi.

jQuery to sposób na ułatwienie programowania JavaScript w przeglądarce. Krótsze polecenia dla różnych przeglądarek itp.

AngularJS rozszerza HTML, więc nie musisz tego wkładać <div> w całym miejscu tylko po to, aby złożyć wniosek. To sprawia, że ​​HTML faktycznie działa dla aplikacji, a nie dla tego, do czego został zaprojektowany, czyli statycznych, edukacyjnych stron internetowych. Realizuje to w okrężny sposób przy użyciu JavaScript, ale zasadniczo jest rozszerzeniem HTML, a nie JavaScript.


69
2018-02-04 05:07



@Robert zależy od tego, co robisz. $(".myclass") jest niezwykle powszechny i ​​łatwiejszy w jQuery niż PO-Javascript. - Robert Grant


jQuery: dużo myślisz na temat "QUERYing the DOM'dla elementów DOM i robienia czegoś.

AngularJS: Model jest prawdą i zawsze myślisz o tym KĄCIE.

Na przykład, gdy otrzymujesz dane z serwera, który zamierzasz wyświetlać w jakimś formacie w DOM, w jQuery, musisz "1. ZNAJDŹ "gdzie w DOM chcesz umieścić te dane," 2. UPDATE / APPEND "to tam, tworząc nowy węzeł lub po prostu jego ustawienie innerHTML. Następnie, gdy chcesz zaktualizować ten widok, wówczas "3. ZNAJDŹ "lokalizację i" 4. AKTUALIZACJA'. Ten cykl wyszukiwania i aktualizacji przeprowadzany w tym samym kontekście pobierania i formatowania danych z serwera zniknął w AngularJS.

Z AngularJS masz swój model (obiekty JavaScript, do których już się przyzwyczaiłeś), a wartość modelu informuje o modelu (oczywiście) io widoku, a operacja na modelu automatycznie propaguje do widoku, więc nie Trzeba się nad tym zastanowić. Znajdziesz się w AngularJS, nie znajdując już rzeczy w DOM.

Aby umieścić w inny sposób, w jQuery, trzeba pomyśleć o selektorach CSS, czyli gdzie jest div lub td który ma klasę lub atrybut, itd., tak żebym mógł uzyskać ich kod HTML lub kolor lub wartość, ale w AngularJS, zobaczysz, że myślisz w ten sposób: z jakim modelem mam do czynienia, ustawię wartość modelu na true. Nie przejmujesz się tym, czy widok odzwierciedlający tę wartość jest zaznaczony lub znajduje się w td element (szczegóły, o których często trzeba było myśleć w jQuery).

A z manipulacją DOM w AngularJS, dodajesz sobie dyrektywy i filtry, które możesz uznać za prawidłowe rozszerzenia HTML.

Jeszcze jedna rzecz, której doświadczysz w AngularJS: w jQuery bardzo często wywołujesz funkcje jQuery, AngularJS wywoła twoje funkcje, więc AngularJS "powie Ci jak to zrobić", ale korzyści są tego warte, więc ucz się AngularJS Zazwyczaj oznacza to uczenie się tego, czego chce AngularJS lub sposób, w jaki AngularJS wymaga zaprezentowania twoich funkcji i odpowiednio go wywoła. Jest to jedna z rzeczy, która sprawia, że ​​AngularJS jest strukturą, a nie biblioteką.


61
2017-11-02 16:53





To są bardzo ładne, ale długotrwałe odpowiedzi.

Podsumowując moje doświadczenia:

  1. Kontrolery i dostawcy (usługi, fabryki itp.) Służą do modyfikowania modelu danych, a NIE HTML.
  2. HTML i dyrektywy definiują układ i powiązanie z modelem.
  3. Jeśli chcesz udostępnić dane między kontrolerami, utwórz usługę lub fabrykę - są to pojedyncze serwery, które są współużytkowane w całej aplikacji.
  4. Jeśli potrzebujesz widżetu HTML, utwórz dyrektywę.
  5. Jeśli masz jakieś dane i próbujesz teraz zaktualizować HTML ... STOP! zaktualizuj model i upewnij się, że kod HTML jest powiązany z modelem.

46
2018-05-16 21:50