"Мисля в AngularJS", ако имам jQuery фон?

Да предположим, че съм запознат с разработването на клиентски приложения в jQuery , но сега бих искал да започна да използвам AngularJS . Можете ли да опишете промените в парадигмата, които са необходими? Ето няколко въпроса, които могат да ви помогнат да формулирате отговора:

  • Как да създавам и създавам уеб приложения на клиента по различен начин? Каква е разликата?
  • Какво трябва да спра? Какво трябва вместо това да започна / да използвам?
  • Има ли някакви съображения / ограничения на сървъра?

Не търся подробно сравнение между jQuery и AngularJS .

4523
21 февр. определени от Марк Райкок на 21 февруари 2013-02-21 07:09 '13 в 7:09 2013-02-21 07:09
@ 15 отговора

1. Не създавайте страницата си и след това я променяйте с помощта на DOM манипулация

В jQuery създавате страница и я създавате динамично. Това се дължи на факта, че jQuery е проектиран да расте и е израснал невероятно от тази проста предпоставка.

Но в AngularJS трябва да започнете от нулата, имайки предвид архитектурата си. Вместо да мисля, че „имам това парче DOM, и искам да направя това, направете X“, трябва да започнете с това, което искате, и след това да започнете да разработвате приложението си и след това да започнете да се развивате Вашата презентация.

2. Не увеличавайте jQuery с AngularJS

По същия начин, не започвайте с идеята, че jQuery прави X, Y и Z, така че просто ще добавя AngularJS отгоре за това за модели и контролери. Това е наистина изкушаващо, когато започвате, така че винаги препоръчвам новите разработчици на AngularJS да не използват jQuery въобще, поне докато не свикнат с това, което са направили “Angular way”.

Виждал съм много разработчици тук и в пощенския списък да създават тези комплексни решения с jQuery плъгини от 150 или 200 реда код, които след това се залепват заедно в AngularJS с набор от callbacks и $apply които объркват и объркват; но накрая те работят! Проблемът е, че в повечето случаи, когато jQuery плъгинът може да бъде презаписан в AngularJS в кодов фрагмент, където изведнъж всичко става ясно и разбираемо.

Долната линия е, че: при решаването на проблем, първо "мисли в AngularJS"; ако не можете да намерите решение, попитайте общността; ако след всичко това няма просто решение, то тогава не се колебайте да се свържете с jQuery. Но не позволявайте на jQuery да стане патерица или никога няма да овладеете AngularJS.

3. Винаги мислете от гледна точка на архитектурата.

Първо е известно, че приложенията от една страница са приложения. Това не е уеб страница. Затова трябва да мислим като разработчик от страна на сървъра и да не мислим като разработчик на клиент. Трябва да помислим как да разделим нашето приложение на отделни, разширяеми, проверими компоненти.

И така, как го правиш? Какво мислите в AngularJS? Ето някои общи принципи, за разлика от jQuery.

Представянето е "официален протокол"

В jQuery програмно променяме изгледа. Може да има падащо меню с надпис ul :

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

В jQuery, в нашата логика на приложението, бихме го активирали с нещо като:

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

Тези две правят същото, но в версията AngularJS всеки, който гледа шаблона, знае какво трябва да се случи. Всеки път, когато се появи нов член на екипа за разработка, тя може да го разгледа и след това да знае, че директивата dropdownMenu е на място; тя не трябва да въвежда правилния отговор или да пресее някой код. Един поглед ни каза какво ще се случи. Много по-чиста.

Разработчиците, които са нови за AngularJS, често питат как да намерят всички връзки на даден тип и да добавят директиви към тях. Разработчикът винаги е зашеметен, когато отговорим: не го правите. Но причината да не правиш това е, че е като полу-jQuery, полу-AngularJS и нищо добро. Проблемът тук е, че разработчикът се опитва да "изпълни jQuery" в контекста на AngularJS. Тя никога няма да работи добре. Представянето е официално вписване. Извън директивата (повече за това по-долу), никога не променяте DOM. И директивите се прилагат в представянето, така че намерението е ясно.

Не забравяйте: не създавайте и маркирайте. Трябва да архитект и след това дизайн.

Свързване на данни

Това определено е една от най-удивителните характеристики на AngularJS и изрязва много от необходимостта да се извършват типовете DOM манипулации, които споменах в предишния раздел. AngularJS автоматично ще актуализира вашата презентация, така че не е нужно! В jQuery отговаряме на събития и след това актуализираме съдържанието. Нещо като:

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

В допълнение към смесването на проблеми, ние също имаме същите проблеми, които означават намерения, които споменах по-рано. Но по-важното е, че трябваше ръчно да извикаме и актуализираме възела DOM. И ако искаме да изтрием запис в дневника, трябва също да копираме DOM кода. Как да тестваме логиката отделно от DOM? А какво, ако искаме да променим представянето?

Това е малко разхвърлян и дреболия крехка. Но в AngularJS можем да го направим:

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

Но в това отношение, нашето мнение може да изглежда така:

разделяне на проблемите и дава много по-голяма възможност за проверка.  Други отговори споменаха този въпрос, така че просто ще го оставя на това. 

Разделяне на проблемите

И всички горепосочени връзки тази сложна тема: поддържайте проблемите си отделни. Вашето мнение служи като официален доклад за това какво трябва да се случи (в по-голямата си част); вашият модел представлява вашите данни; имате ниво на обслужване за изпълнение на задачи за многократна употреба; манипулирате DOM и разширявате мнението си с директиви; и го залепите заедно с контролерите. Това се споменава и в други отговори и единственото, което бих искал да добавя, е свързан с проверяването, което ще разгледам в друг раздел по-долу.

Активиране на зависимости

За да ни помогне с отделянето на проблеми, инжектиране на зависимостта (DI). Ако използвате език от страна на сървъра (от Java до PHP ), вероятно вече сте запознати с тази концепция, но ако сте клиент на jQuery, това понятие може да изглежда като нещо от глупаво до ненужно до hipster. Но това не е така: -)

От широка гледна точка, DI означава, че сте свободни да декларирате компоненти, а след това от всеки друг компонент, просто попитайте за неговото копие, и то ще бъде предоставено. Не е необходимо да знаете реда на зареждане, местоположението на файловете или нещо подобно. Силата може да не бъде веднага видима, но ще дам само един (общ) пример: тестване.

Да предположим, че в нашето приложение се нуждаем от услуга, която изпълнява сървърното съхранение чрез REST API и, в зависимост от състоянието на приложението, съхранението също е локално. Когато извършваме тестове на нашите контролери, ние не искаме да се свързваме със сървъра - все още тестваме контролера. Можем просто да добавим сервизно оформление със същото име като нашия оригинален компонент, а инжекторът ще гарантира, че нашият контролер ще получи фалшив автоматично - нашият контролер не знае и не трябва да знае разликата.

Говорейки за изпитанията ...

4. Тествано развитие - винаги

Това всъщност е част от раздел 3 за архитектурата, но е толкова важно да го поставя в собствената си секция на най-високо ниво.

От многото плъгини на jQuery, които сте видели, използвали или написали, колко от тях имаха пакет за придружаващ тест? Не много, защото jQuery не е много податлив на това. Но AngularJS е.

В jQuery, единственият начин да тествате е да създадете компонент самостоятелно с примерна / демонстрационна страница, с която нашите тестове могат да изпълняват DOM манипулации. Така че, трябва да разработим компонента поотделно и след това да го интегрираме в нашето приложение. Колко неудобно! Толкова много време, когато се разработваме с jQuery, избираме итеративна опция вместо разработка, базирана на тест. И кой може да ни обвинява?

Но тъй като имаме разделение на проблемите, можем да направим итеративното развитие на теста в AngularJS! Например, нека кажем, че искаме свръхпросто директива, която да посочи в нашето меню какво е нашият текущ маршрут. Можем да кажем това, което искаме от гледна точка на нашето приложение:

 

Е, сега можем да напишем тест за несъществуващата, when-active директива:

 

И когато провеждаме теста си, можем да потвърдим, че той не успява. Само сега трябва да създадем нашата директива:

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

Има няколко грешки в това:

  • Първо, никога не се изискваше jQuery. Тук не направихме нищо, което jQuery изобщо трябваше!
  • Второ, дори ако вече имаме jQuery на нашата страница, няма причина да я използваме тук; можем просто да използваме angular.element , а нашият компонент ще продължи да работи, когато влезете в проект, който няма jQuery.
  • Трето, дори ако се приеме, че тази директива изисква jQuery, jqLite ( angular.element ) винаги ще използва jQuery, ако е заредена! Така че ние не трябва да използваме $ - можем просто да използваме angular.element .
  • Четвъртата, тясно свързана с третата, е, че елементите на jqLite не трябва да бъдат опаковани в $ - element който се предава на функцията на link вече ще бъде jQuery елемент!
  • И на пето място, което споменахме в предишните раздели, защо смесваме шаблонен материал в нашата логика?

Тази директива може да бъде пренаписана (дори и за много сложни случаи!) Много по-лесно:

7185
22 февр. Отговор, даден от Джош Дейвид Милър 22 февруари 2013-02-22 00:26 '13 в 0:26 2013-02-22 00:26

Императивно → декларативно

В jQuery селектор се използва за търсене на DOM и след това свързване / регистриране на обработващи събития. Когато дадено събитие се задейства, този (задължителен) код обновява / модифицира DOM.

В AngularJS искате да мислите за мнения , а не за DOM елементи. HTML представяния (декларативни), съдържащи директиви на AngularJS , Директивите създават за нас кулисите за събития и ни придават динамични данни. Селекторите рядко се използват, така че необходимостта от идентификатори (и някои видове класове) е значително намалена. Мненията са свързани с модели (през области). Мненията са проекция на модел. Модели за промяна на събития (т.е. данни, свойства на региони) и изгледи, които проектират тези модели "автоматично".

В AngularJS, помислете за моделите, а не за jQuery избраните DOM елементи, които съдържат вашите данни. Помислете за идеи като прогнози на тези модели, вместо да регистрирате обратни обаждания, за да манипулирате това, което потребителят вижда.

Разделяне на проблемите

jQuery използва ненатрапчивия JavaScript - поведението (JavaScript) е отделено от структурата (HTML).

AngularJS използва контролери и директиви (всяка от които може да има собствени контролер и / или компилира и свързва функции), за да премахне поведението от вида / структурата (HTML). Angular също има услуги и филтри, които спомагат за разделяне / организиране на вашето приложение.

border=0

Вижте също medican.info.site/questions/511 / ...

Дизайн на приложението

Един подход за разработване на приложение на AngularJS:

  • Помислете за вашите модели. Създавайте услуги или собствени JavaScript обекти за тези модели.
  • Помислете как искате да представите вашите модели - вашите възгледи. Създайте HTML шаблони за всяка презентация, като използвате необходимите директиви за получаване на динамично свързване на данни.
  • Прикрепете контролер към всеки изглед (използвайки ng-view и routing или ng-controller). Помолете диспечера да намери / извлече само данни от модела, които трябва да изпълняват изгледите. Направете контролерите възможно най-тънки.

Наследяване на прототипи

Можете да направите много неща с jQuery, без да знаете как работи прототипа на JavaScript. При разработването на приложения на AngularJS ще избегнете някои често срещани грешки, ако имате добро разбиране за наследяването на JavaScript. Препоръчителна литература: Какви са нюансите на прототипния / прототипния обем на наследяване в AngularJS?

408
21 февр. Отговор, даден от Mark Rajcok 21 февруари. 2013-02-21 07:09 '13 в 7:09 2013-02-21 07:09

AngularJS vs. JQuery