Wiązanie danych
Chodzisz dookoła, tworząc swoją stronę internetową i umieszczasz {{wiązania danych}}, gdy tylko czujesz, że masz dynamiczne dane. Angular dostarczy wtedy procedurę obsługi $ scope, którą możesz wypełnić (statycznie lub przez wywołania serwera WWW).
To jest dobre zrozumienie wiązania danych. Myślę, że już to zrozumiałeś.
Manipulacja DOM
Do prostej manipulacji DOM, która nie wymaga manipulacji danymi (np. Zmiana koloru po najechaniu myszą, ukrywanie / pokazywanie elementów po kliknięciu), jQuery lub oldschoolowy js jest wystarczający i czystszy. Zakłada się, że model w mvc angulara jest wszystkim, co odzwierciedla dane na stronie, a zatem właściwości CSS, takie jak kolor, wyświetlanie / ukrywanie itp., Nie wpływają na model.
Widzę tutaj twój punkt widzenia, że „prosta” manipulacja DOM jest czystsza, ale rzadko i musiałaby być naprawdę „prosta”. Myślę, że manipulacja DOM jest jednym z obszarów, podobnie jak wiązanie danych, w którym Angular naprawdę błyszczy. Zrozumienie tego pomoże Ci również zobaczyć, jak Angular traktuje swoje poglądy.
Zacznę od porównania metody Angular z podejściem vanilla js do manipulacji DOM. Tradycyjnie uważamy, że HTML niczego nie „robi” i piszemy go jako taki. Tak więc inline js, takie jak „onclick” itp. Są złą praktyką, ponieważ umieszczają „robienie” w kontekście HTML, który nie „robi”. Angular stawia tę koncepcję na głowie. Pisząc widok, myślisz o HTML jako o możliwości „robienia” wielu rzeczy. Ta możliwość jest wyabstrahowana w dyrektywach kątowych, ale jeśli już istnieją lub je napisałeś, nie musisz zastanawiać się „jak” to się robi, po prostu wykorzystaj moc udostępnioną ci w tym „rozszerzonym” kodzie HTML, kątowy pozwala na użycie. Oznacza to również, że CAŁA logika widoku jest naprawdę zawarta w widoku, nie w plikach javascript. Ponownie, rozumowanie jest takie, że dyrektywy zapisane w twoich plikach javascript można uznać za zwiększające możliwości HTML, więc pozwalasz DOMowi martwić się manipulowaniem sobą (że tak powiem). Pokażę na prostym przykładzie.
To jest znacznik, którego chcemy użyć. Nadałem mu intuicyjną nazwę.
<div rotate-on-click="45"></div>
Po pierwsze, chciałbym tylko skomentować, że jeśli daliśmy naszemu HTML-owi tę funkcjonalność za pośrednictwem niestandardowej dyrektywy Angular, to już zrobiliśmy . To powiew świeżego powietrza. Więcej o tym za chwilę.
Implementacja z jQuery
demo na żywo tutaj (kliknij).
function rotate(deg, elem) {
$(elem).css({
webkitTransform: 'rotate('+deg+'deg)',
mozTransform: 'rotate('+deg+'deg)',
msTransform: 'rotate('+deg+'deg)',
oTransform: 'rotate('+deg+'deg)',
transform: 'rotate('+deg+'deg)'
});
}
function addRotateOnClick($elems) {
$elems.each(function(i, elem) {
var deg = 0;
$(elem).click(function() {
deg+= parseInt($(this).attr('rotate-on-click'), 10);
rotate(deg, this);
});
});
}
addRotateOnClick($('[rotate-on-click]'));
Wdrożenie za pomocą Angular
demo na żywo tutaj (kliknij).
app.directive('rotateOnClick', function() {
return {
restrict: 'A',
link: function(scope, element, attrs) {
var deg = 0;
element.bind('click', function() {
deg+= parseInt(attrs.rotateOnClick, 10);
element.css({
webkitTransform: 'rotate('+deg+'deg)',
mozTransform: 'rotate('+deg+'deg)',
msTransform: 'rotate('+deg+'deg)',
oTransform: 'rotate('+deg+'deg)',
transform: 'rotate('+deg+'deg)'
});
});
}
};
});
Całkiem lekki, BARDZO czysty i to tylko prosta manipulacja! Moim zdaniem podejście kątowe wygrywa pod każdym względem, zwłaszcza w przypadku wyodrębnienia funkcjonalności i zadeklarowania manipulacji domem w DOM. Funkcjonalność jest podłączona do elementu za pomocą atrybutu html, więc nie ma potrzeby odpytywania DOM za pomocą selektora, a mamy dwa ładne zamknięcia - jedno zamknięcie dla fabryki dyrektyw, w której zmienne są wspólne dla wszystkich zastosowań dyrektywy i jedno zamknięcie dla każdego użycia dyrektywy w linkfunkcji (lubcompile funkcji).
Dwukierunkowe wiązanie danych i dyrektywy do manipulacji DOM to dopiero początek tego, co sprawia, że Angular jest niesamowity. Angular promuje modułowość, możliwość wielokrotnego użytku i łatwość testowania całego kodu, a także zawiera system routingu jednostronicowych aplikacji. Należy zauważyć, że jQuery to biblioteka powszechnie potrzebnych wygodnych metod / metod między przeglądarkami, ale Angular to w pełni funkcjonalny framework do tworzenia aplikacji jednostronicowych. Skrypt angular faktycznie zawiera własną „lite” wersję jQuery, dzięki czemu dostępne są niektóre z najważniejszych metod. Dlatego można argumentować, że używanie Angular IS przy użyciu jQuery (lekko), ale Angular zapewnia znacznie więcej "magii", aby pomóc w procesie tworzenia aplikacji.
To jest świetny post zawierający więcej powiązanych informacji: Jak „myśleć w AngularJS”, jeśli mam doświadczenie w jQuery?
Ogólne różnice.
Powyższe punkty odnoszą się do konkretnych obaw PO. Omówię również inne ważne różnice. Proponuję również dodatkowe lektury na każdy temat.
Angular i jQuery nie mogą być rozsądnie porównywane.
Angular to framework, jQuery to biblioteka. Frameworki mają swoje miejsce, a biblioteki swoje. Nie ma jednak wątpliwości, że dobry framework ma większe możliwości pisania aplikacji niż biblioteka. Dokładnie o to chodzi we frameworku. Możesz pisać swój kod w zwykłym JS, możesz dodać bibliotekę typowych funkcji lub możesz dodać framework, aby drastycznie zredukować kod potrzebny do wykonania większości rzeczy. Dlatego bardziej odpowiednie pytanie brzmi:
Dlaczego warto używać frameworka?
Dobre frameworki mogą pomóc w zaprojektowaniu kodu tak, aby był modułowy (a zatem wielokrotnego użytku), SUCHY, czytelny, wydajny i bezpieczny. jQuery nie jest frameworkiem, więc nie pomaga w tym względzie. Wszyscy widzieliśmy typowe ściany kodu spaghetti jQuery. To nie jest wina jQuery - to wina programistów, którzy nie wiedzą, jak zaprojektować kod. Gdyby jednak deweloperzy wiedzieli, jak zaprojektować kod, skończyliby na napisaniu jakiegoś minimalnego „frameworka”, aby zapewnić podstawy (achitekturę itp.), O których mówiłem przed chwilą, albo dodaliby coś do niego. może dodać RequireJS, aby działał jako część twojego frameworka do pisania dobrego kodu.
Oto kilka rzeczy, które zapewniają nowoczesne frameworki:
- Szablony
- Powiązanie danych
- routing (aplikacja pojedynczej strony)
- czysta, modułowa architektura wielokrotnego użytku
- bezpieczeństwo
- dodatkowe funkcje / cechy dla wygody
Zanim przejdę dalej do Angulara, chciałbym zaznaczyć, że Angular nie jest jedyny w swoim rodzaju. Na przykład Durandal to framework zbudowany na bazie jQuery, Knockout i RequireJS. Ponownie, jQuery nie może samo w sobie zapewnić tego, co Knockout, RequireJS i cały framework zbudowany na nich. Po prostu nie da się tego porównać.
Jeśli chcesz zniszczyć planetę i masz Gwiazdę Śmierci, użyj Gwiazdy Śmierci.
Angular (ponownie odwiedzony).
Opierając się na moich poprzednich punktach dotyczących tego, jakie frameworki zapewniają, chciałbym pochwalić sposób, w jaki zapewnia je Angular i spróbuję wyjaśnić, dlaczego jest to kwestia faktycznej przewagi nad samym jQuery.
Odniesienie DOM.
W moim powyższym przykładzie jest absolutnie nieuniknione, że jQuery musi podłączyć się do DOM, aby zapewnić funkcjonalność. Oznacza to, że widok (html) dotyczy funkcjonalności (ponieważ jest oznaczony jakimś identyfikatorem - np. „Suwak obrazu”), a JavaScript jest zaniepokojony o zapewnienie tej funkcjonalności. Angular eliminuje tę koncepcję poprzez abstrakcję. Prawidłowo napisany kod za pomocą Angulara oznacza, że widok jest w stanie zadeklarować swoje własne zachowanie. Jeśli chcę wyświetlić zegar:
<clock></clock>
Gotowe.
Tak, musimy przejść do JavaScript, aby to coś znaczyło, ale robimy to w odwrotny sposób niż w przypadku jQuery. Nasza dyrektywa Angular (która jest w swoim własnym małym świecie) "rozszerzyła" kod HTML, a kod HTML przechwytuje tę funkcjonalność w sobie.
MVW Architecure / Modules / Dependency Injection
Angular daje prosty sposób na uporządkowanie kodu. Widok rzeczy należy do widoku (html), rozszerzona funkcjonalność widoku należy do dyrektyw, inna logika (jak wywołania ajax) i funkcje należą do usług, a połączenie usług i logiki z widokiem należy do kontrolerów. Istnieją również inne komponenty kątowe, które pomagają radzić sobie z konfiguracją i modyfikacją usług itp. Każda utworzona funkcjonalność jest automatycznie dostępna wszędzie tam, gdzie jej potrzebujesz, za pośrednictwem podsystemu Injector, który zajmuje się wstrzykiwaniem zależności w całej aplikacji. Pisząc aplikację (moduł), dzielę ją na inne moduły wielokrotnego użytku, każdy z własnymi komponentami wielokrotnego użytku, a następnie włączam je do większego projektu. Gdy rozwiążesz problem z Angularem, automatycznie rozwiązaliśmy problem w sposób, który jest użyteczny i zorganizowany do ponownego wykorzystania w przyszłości i łatwo można go uwzględnić w kolejnym projekcie. ZAOGROMNYM bonusem do tego wszystkiego jest to, że Twój kod będzie znacznie łatwiejszy do przetestowania.
Nie jest łatwo sprawić, by rzeczy „działały” w Angular.
DZIĘKI BOGU. Wspomniany kod spaghetti jQuery powstał w wyniku pracy programisty, który coś „działało”, a następnie ruszył dalej. Możesz napisać zły kod Angular, ale jest to o wiele trudniejsze, ponieważ Angular będzie z tobą walczył o to. Oznacza to, że musisz skorzystać (przynajmniej w pewnym stopniu) z czystej architektury, którą zapewnia. Innymi słowy, trudniej jest napisać zły kod za pomocą Angulara, ale wygodniej jest napisać czysty kod.
Angular jest daleki od doskonałości. Świat tworzenia stron internetowych nieustannie się rozwija i zmienia, dlatego pojawiają się nowe i lepsze sposoby rozwiązywania problemów. Na przykład React i Flux Facebooka mają kilka wielkich zalet w porównaniu z Angular, ale mają swoje wady. Nic nie jest idealne, ale Angular był i nadal jest niesamowity. Tak jak kiedyś jQuery pomogło w rozwoju świata WWW, tak samo dzieje się z Angularem i wielu innych będzie w przyszłości.