"Мысленне ў AngularJS", калі ў мяне ёсць фон jQuery?

Выкажам здагадку, што я знаёмы з распрацоўкай кліенцкіх прыкладанняў у jQuery , але цяпер я хацеў бы пачаць выкарыстоўваць AngularJS . Ці можаце вы апісаць зрух парадыгмы, які неабходны? Вось некалькі пытанняў, якія могуць дапамагчы вам сфармаваць адказ:

  • Як мне ствараць і ствараць кліенцкія вэб-прыкладанні па-іншаму? Якая розніца?
  • Што я павінен спыніць рабіць / выкарыстоўваць; Што я павінен пачаць рабіць / выкарыстоўваць замест гэтага?
  • Ці ёсць якія-небудзь меркаванні / абмежаванні на боку сервера?

Я не шукаю падрабязнага параўнання паміж jQuery і AngularJS .

4523
21 февр. зададзены Mark Rajcok 21 февр. 2013-02-21 07:09 '13 у 07: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".

Я бачыў шмат распрацоўнікаў тут і ў спісе рассылання ствараюць гэтыя складаныя рашэнні з ўбудовамі jQuery з 150 або 200 радкоў кода, якія затым склейваюцца ў AngularJS з наборам зваротных выклікаў і $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, часта задаюць пытанне, як: як знайсці ўсе спасылкі пэўнага тыпу і дадаць на іх дырэктыву. Распрацоўшчык заўсёды ашаломлены, калі мы адказваем: вы гэтага не робіце. Але прычына, па якой вы гэтага не робіце, гэта тое, што гэта падобна на half-jQuery, half-AngularJS і нічога добрага. Праблема тут у тым, што распрацоўшчык спрабуе "выканаць jQuery" ў кантэксце AngularJS. Гэта ніколі не будзе працаваць добра. Паказ - афіцыйная запіс. Па-за дырэктывы (падрабязней пра гэта ніжэй) вы ніколі і ніколі не змяняеце DOM. І дырэктывы прымяняюцца ва ўяўленні, таму намер ясна.

Памятаеце: не стварайце, а затым адзначайце. Вы павінны архитектовать, а затым праектаваць.

звязванне дадзеных

Гэта, безумоўна, адна з самых дзіўных асаблівасцяў AngularJS, і выразае шмат неабходнасці рабіць віды маніпуляцый з DOM, пра якія я згадваў у папярэдняй главе. AngularJS аўтаматычна абновіць ваша ўяўленне, каб вам не давялося! У jQuery мы адказваем на падзеі, а затым абнаўляем кантэнт. Нешта накшталт:

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

Акрамя праблем са змешваннем, у нас таксама ёсць тыя ж праблемы, што азначаюць намеры, пра якія я згадаў раней. Але што больш важна, нам прыйшлося ўручную спасылацца і абнаўляць DOM node. І калі мы хочам выдаліць запіс у часопісе, мы павінны таксама скапіяваць код DOM. Як мы тэстуем логіку асобна ад DOM? А што, калі мы хочам змяніць прэзентацыю?

Гэта крыху брудна і дробязь далікатная. Але ў AngularJS мы можам гэта зрабіць:

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

Але ў гэтых адносінах наш погляд можа выглядаць так:

падзел праблем і дае значна большую магчымасць праверкі.  Іншыя адказы згадалі гэты момант, таму я проста пакіну гэта на гэтым. 

падзел праблем

І ўсё вышэйпералічанае звязвае гэтую складаную тэму: захоўвайце свае праблемы паасобнымі. Ваша меркаванне выступае ў якасці афіцыйнай справаздачы пра тое, што павінна адбыцца (па большай часткі); ваша мадэль уяўляе вашыя дадзеныя; ў вас ёсць сэрвісны ўзровень для выканання шматразовых задач; вы выконваеце маніпуляцыі з DOM і разьзяўляеце сваё прадстаўленне з дапамогай дырэктыў; і вы склейваць усё гэта разам з кантролерамі. Гэта таксама згадвалася ў іншых адказах, і адзінае, што я хацеў бы дадаць, адносіцца да тэстоўваную, пра што я распавяду ў іншым раздзеле ніжэй.

ўключэнне залежнасцяў

Каб дапамагчы нам з падзелам праблем, ін'екцыя залежнасцяў (DI). Калі вы выкарыстоўваеце серверны мова (ад Java да PHP ), вы, верагодна, ужо знаёмыя з гэтай канцэпцыяй, але калі вы з'яўляецеся кліенцкім хлопцам з jQuery, гэтая канцэпцыя можа здацца чымсьці ад дурнога да лішняга да хіпстэры. Але гэта не так.: -)

З шырокай пункту гледжання, 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 февр. адказ дадзены Josh David Miller 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

Гл. Таксама lifetop.site.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 у 07:09 2013/02/21 07:09

AngularJS vs. jQuery