Питання "Думаю в AngularJS", якщо у мене є jQuery тло? [ЗАЧИНЕНО]


Припустимо, що я знайомий з розробкою додатків клієнта в jQuery, але тепер я хочу почати користуватися AngularJS. Чи можете ви описати необхідний зрушення в парадигмі? Нижче наведено кілька запитань, які можуть допомогти вам скласти відповідь.

  • Як архітектуру та дизайн веб-програм на стороні клієнта відрізняти? Яка найбільша різниця?
  • Що слід припинити робити / використовувати; Що я повинен почати робити / використовувати замість цього?
  • Чи є якісь міркування чи обмеження на стороні сервера?

Я не шукаю детального порівняння jQuery і AngularJS.


4525
2018-02-21 04:09


походження


Для тих, хто знайомий з "ASP.NET MVC" або "RoR" - просто подумайте про Angular як про "клієнтську сторону MVC", і все це. - Serge Shultz


Відповіді:


1. Не створюйте свою сторінку, а потім змініть її DOM маніпуляції

У jQuery ви створюєте сторінку, а потім робите її динамічною. Це тому, що jQuery призначений для збільшення і неймовірно зросла з цієї простої передумови.

Але в AngularJS, ви повинні почати з нуля з архітектурою на увазі. Замість того, щоб почати, подумавши: "У мене є цей фрагмент DOM, і я хочу зробити це X", ви повинні почати з того, що ви хочете виконати, а потім зайнятися розробкою вашої програми, а потім, нарешті, розробити свій вигляд.

2. Не збільшувати jQuery з AngularJS

Точно так само не починайте з ідеї, що jQuery робить X, Y та Z, тому я просто додам AngularJS на вершині цього для моделей і контролерів. Це дійсно зачаровує, коли ви тільки починаєте роботу, тому я завжди рекомендую, щоб нові розробники AngularJS взагалі не використовували jQuery, принаймні, доки вони не звикне до того, щоб робити щось "кутовий шлях".

Я бачив, як багато розробників тут і в списку розсилки створюють ці складні рішення з плагінами jQuery з 150 або 200 рядками коду, які вони потім склеюють у AngularJS з набором зворотних викликів і $applyякі є заплутаними та заплутаними; але в кінцевому підсумку вони працюють! Проблема в тому, що в Росії найбільше випадки, що jQuery плагін можна було б переписати в AngularJS у частині коду, де раптом все стає зрозумілим і зрозумілим.

Суть полягає в наступному: при вирішенні спершу "подумайте в AngularJS"; якщо ви не можете придумати рішення, попросіть спільноту; якщо після всього цього не буде легкого рішення, потім Не соромтеся дістатися до jQuery. Але не дозволяйте jQuery стати мисливцем або ви ніколи не будете володіти AngularJS.

3. Завжди думайте з точки зору архітектури

Спочатку це знають односторінкові програми є заявки. Вони ні веб-сторінки. Отже, ми повинні мислити як розробник сервера в додаток щоб мислити як розробник на стороні клієнта. Ми повинні думати про те, як розділити наше застосування на індивідуальні, розширювані, тестувальні компоненти.

Так то як ти робиш це? Як ви "думаєте в AngularJS"? Ось деякі загальні принципи, протиставлені jQuery.

Погляд - це "офіційний рекорд"

У jQuery ми програмно змінюємо подання. Ми можемо мати спадне меню, яке визначається як ul подобається так:

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

У jQuery, в нашій логіці застосування, ми б активували його з чимось на кшталт:

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

Коли ми просто дивимося на точку зору, це не відразу очевидно, що тут є будь-яка функціональність. Для невеликих додатків це нормально. Але для нетривіальних додатків речі швидко стають заплутаними і важко підтримувати.

У AngularJS, однак, ця точка зору є офіційним протоколом функціональності на основі перегляду. Наша ul декларація виглядатиме таким чином:

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

Ці два роблять те ж саме, але в версії AngularJS кожен, хто дивиться на шаблон, знає, що повинно відбутися. Кожного разу, коли новий член команди розробників приходить на борт, вона може подивитися на це і тоді знати що є директива називається dropdownMenu працює на ньому; їй не потрібно інтуїтивно правильно відповідати або просіяти через будь-який код. Погляд нам розповів, що повинно було статися. Багато чистих.

Розробники, нові для AngularJS, часто задають питання: як знайти всі посилання певного типу та додати до них директиву. Розробник завжди зривається, коли ми відповімо: у вас немає. Але причина, чому ти не робиш це, полягає в тому, що це схоже на напів-jQuery, half-AngularJS, і нічого хорошого. Проблема полягає в тому, що розробник намагається "зробити jQuery" в контексті AngularJS. Це ніколи не буде добре працювати. Погляд є офіційний рекорд. За межами директиви (докладніше про це нижче) ви ніколи, ніколи не ніколи змінити DOM. І застосовуються директиви на вигляд, тому намір ясний.

Пам'ятайте: не оформляйте, а потім помічайте. Ви повинні архітектор, а потім дизайн.

Зв'язування даних

Це, безумовно, одне з найпрекрасніших функцій AngularJS і виключає багато необхідності виконувати ті види маніпуляцій DOM, про які я згадав у попередньому розділі. AngularJS автоматично оновить ваш погляд так що вам не потрібно! У jQuery ми реагуємо на події, а потім оновлюємо вміст. Щось на зразок:

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

Для перегляду, що виглядає так:

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

Окрім змішування проблем, ми також маємо ті самі проблеми, що свідчать про наміри, про які я вже згадував раніше. Але що більш важливо, нам довелося вручну орієнтувати та оновити вузол DOM. І якщо ми хочемо видалити запис журналу, ми також маємо кодувати проти DOM. Як ми перевіряємо логіку, крім DOM? А що, якщо ми хочемо змінити презентацію?

Цей трохи брудний і дрібниця слабкий. Але в AngularJS ми можемо зробити це:

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

І наша думка може виглядати так:

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

Але в цьому питанні наша думка може виглядати так:

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

І тепер, замість того, щоб використовувати невпорядкований список, ми використовуємо поля попередження Bootstrap. І нам ніколи не довелося змінювати код контролера! Але що більш важливо, не має значення де або як журнал оновлюється, зміна вигляду теж буде. Автоматично. Приємно!

Хоча я тут не показав, зв'язування даних є двостороннім. Таким чином, ці журнальні повідомлення також можуть бути редагованими у вигляді просто: <input ng-model="entry.msg" />. І було багато радощів.

Відмінний модельний шар

У jQuery, DOM виглядає як модель. Але в AngularJS ми маємо окремий модельний рівень, який ми можемо керувати будь-яким способом, який ми хочемо, повністю незалежно від точки зору. Це допомагає прив'язувати дані вище, підтримує відділення проблем, і вводить набагато більше тестування. Інші відповіді згадували цей пункт, тому я просто залишу це на цьому.

Розподіл проблем

І всі вищесказане пов'язані з цією найважливішою темою: тримайте свої турботи окремо. Ваша думка виступає як офіційний запис про те, що повинно відбутися (здебільшого); ваша модель відображає ваші дані; у вас є службовий рівень для виконання завдань, що повторюються; ви робите маніпуляції з DOM і покращуєте свій погляд директивами; і ви склеюєте все разом з контролерами. Це було також згадано в інших відповідях, і єдине, що я хотів би додати, стосується тестування, про що я обговорюю в іншому розділі нижче.

Залежність ін'єкції

Щоб допомогти нам у вирішенні проблем, є ін'єкція залежності (ДІ). Якщо ви прийшли з мови сервера (від Java до PHP) Ви, мабуть, вже знайомі з цією концепцією, але якщо ви є стороннім клієнтом з jQuery, це поняття може здатися чимось від дурного до зайвого до hipster. Але це не так. :-)

З широкої точки зору, DI означає, що ви можете декларувати компоненти дуже вільно, а потім з будь-якого іншого компонента, просто попросіть його екземпляр і він буде наданий. Вам не потрібно знати про порядок завантаження, місця розташування файлів або подібне. Потужність може бути невидимою, але я надам лише один (загальний) приклад: тестування.

Скажімо, у нашій програмі нам потрібна служба, яка здійснює зберігання на стороні сервера за допомогою Відпочинок API і, залежно від держави додатка, локального сховища. Під час тестування наших контролерів ми не хочемо спілкуватися з сервером - ми тестуємо його контролер, після всього. Ми можемо просто додати макет служби з тим же ім'ям, що і наш оригінальний компонент, і інжектор забезпечить автоматичний контроль нашого контролера - наш контролер не має і не потребує знання різниці.

Говорячи про тестування ...

4. Тестовий розвиток - завжди

Це дійсно частина розділу 3 про архітектуру, але це настільки важливо, що я складаю його як власний розділ вищого рівня.

З усіх численних плагінів jQuery, яких ви бачили, використовували або написали, скільки з них мали супровідний набір тестів? Не дуже багато, тому що jQuery не дуже піддається цьому. Але AngularJS це.

У jQuery єдиним способом перевірки часто є створення компонента незалежно від сторінки зразка / демонстрації, на яку наші тести можуть виконувати маніпулювання DOM. Отже, ми повинні розробити компонент окремо і потім інтегрувати його в нашу програму. Як незручно! Настільки велика частина часу, коли розробляється в jQuery, ми вибираємо ітеративний замість тестування. І хто може нас звинувачувати?

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

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

Гаразд, тепер ми можемо написати тест для неіснуючого when-active директива:

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

І коли ми проводимо наш тест, ми можемо підтвердити, що він не працює. Тільки зараз ми повинні створити нашу директиву:

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

Наш тест зараз проходить і наше меню виконує за запитом. Наш розвиток - це обидва ітеративний і тестування. Злий, крутий.

5. Концептуально, директиви є ні упакований jQuery

Ви часто чуєте, що "в директиві використовуються лише маніпуляції DOM". Це необхідність. Ставись це з належним повагою!

Але давайте пірнути трохи глибше ...

Деякі директиви просто прикрашають те, що вже є на виду (думаю ngClass), і тому іноді робить маніпулювання DOM відразу, а потім в основному зроблено. Але якщо директива нагадує "віджет" і має шаблон, він повинен також поважати відокремлення проблем. Тобто шаблон теж повинен залишатися в значній мірі незалежним від його реалізації в функції зв'язку та контролера.

AngularJS поставляється з цілим набором інструментів, щоб зробити це дуже просто; з ngClass ми можемо динамічно оновлювати клас; ngModel дозволяє двосторонній зв'язування даних; ngShow і ngHide програмно показує або приховує елемент; і багато іншого - в тому числі ті, що ми пишемо самі. Інакше кажучи, ми можемо робити всілякі чарівності без Маніпулювання DOM. Чим менша маніпуляція DOM, тим простіші вказівки мають тестувати, чим легше вони стилювати, тим легше вони змінюватимуться в майбутньому, а тим більше вони будуть повторно використовуватися та розповсюджуватись.

Я бачу багато розробників, нових для AngularJS, використовуючи директиви, як місце, щоб кинути купу jQuery. Іншими словами, вони думають, що "оскільки я не можу робити маніпуляції DOM в контролері, я візьму цей код до директиви". Хоча це напевно набагато краще, це часто все ще неправильно.

Подумайте про реєстратор, який ми запрограмовали в розділі 3. Навіть якщо ми поставимо це в директиві, ми досі хочу зробити це "кутовим шляхом". Це досі не приймає маніпуляції DOM! Є багато разів, коли необхідна маніпуляція DOM, але це а багато рідше, ніж ти думаєш! Перед початком маніпулювання DOM де завгодно у своїй заявці запитайте себе, чи дійсно вам потрібно. Там може бути кращий спосіб.

Ось короткий приклад, який показує шаблон, який я бачу найчастіше. Ми хочемо перемикати кнопку. (Примітка. Цей приклад трохи втілений, і влучний аргумент представляє більш складні випадки, які вирішуються точно так само.)

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

У цьому є кілька помилок:

  1. По-перше, jQuery ніколи не було необхідним. Тут немає нічого, що ми зробили тут, що вимагає jQuery взагалі!
  2. По-друге, навіть якщо у нас вже є jQuery на нашій сторінці, немає підстав використовувати його тут; ми можемо просто використовувати angular.element і наш компонент, як і раніше, працює, коли випадає в проект, який не має jQuery.
  3. По-третє, навіть припускаючи jQuery був необхідна для роботи цієї директиви, jqLite (angular.element) буде завжди використовувати jQuery, якщо він був завантажений! Тому нам не потрібно використовувати $ - ми можемо просто використовувати angular.element.
  4. По-четверте, тісно пов'язана з третьою, полягає в тому, що елементи jqLite не потрібно загорнути $ - the element це передано в link функція буде вже бути елемент jQuery!
  5. І п'яте, про що ми вже згадували у попередніх розділах, чому ми змішуємо матеріали шаблону до нашої логіки?

Ця директива може бути переписана (навіть у дуже складних випадках!) Набагато простіше так:

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

Знову ж таки, шаблони знаходяться в шаблоні, тому ви (або ваші користувачі) можете легко обміняти його на той, який відповідає будь-якому необхідному стилю, і логіка ніколи не треба було торкатися Багаторазовість - бум!

І є ще всі ті інші переваги, як тестування - це просто! Незалежно від того, що знаходиться в шаблоні, внутрішній API дирекції ніколи не торкається, тому рефакторинг легко. Ви можете змінити шаблон так, як хочете, не торкаючись директиви. І незалежно від того, що ви змінюєте, ваші тести все-таки проходять.

w00t!

Отже, якщо директиви - це не просто збірки функцій jQuery, які вони є? Насправді є директиви розширення HTML. Якщо HTML не робить щось, що вам потрібно зробити, ви пишете директиву, щоб зробити це для вас, а потім використовувати його так, як якби вона була частиною HTML.

Поставте інший спосіб, якщо AngularJS не робить щось із коробки, подумайте, як команда виконає це, щоб він відповідав справі ngClick, ngClass, та ін.

Резюме

Не використовуйте jQuery. Не включайте його навіть. Це триматиме вас назад. І коли ви прийдете до проблеми, що, на вашу думку, ви знаєте, як вирішити в jQuery вже, перш ніж досягти $, спробуйте подумати про те, як це зробити в рамках AngularJS. Якщо ти не знаєш, запитай! 19 разів з 20, кращий спосіб зробити це не потребує jQuery і спробувати вирішити це з jQuery результати більше роботи для вас.


7187
2018-02-21 21:26



Я думаю, що включення роботи з JQuery в рамках кутового додатку є важливим випадком використання через всі існуючі JQuery плагіни, які були написані. Я не перезаписував FancyBox в jQuery, щоб зберегти чистий кутовий додаток. - taudep
@taudep Я не думаю, що ми так само розходяться, як ви думаєте. Більшість jQuery плагінів можуть бути переписані в AngularJS дешево, і в таких випадках ми повинні це зробити. Для чогось комплексу, для якого не існує еквівалента, тоді йдіть на це. Цитувати з розділу 2: "Суть в цьому полягає в наступному: при вирішенні спершу" подумайте в AngularJS "; якщо ви не можете придумати рішення, попросіть спільноту; якщо після всього цього немає простим рішенням, то не соромтеся звертатися за допомогою jQuery. Але не дозволяйте jQuery стати мисливцем або ви ніколи не будете володіти AngularJS. ' [наголос додано] - Josh David Miller
китайці перекладають цю чудову відповідь, сподіваюся на користь. hanzheng.github.io/tech/angularjs/2013/10/28/... - Han Zheng
@Benno Що він має на увазі за допомогою "не маніпулювання DOM", це те, що ваш код у директиві не виконує безпосередньо маніпулювання DOM. Цей код нічого не знає про DOM, це просто зміна змінних js у вашій моделі. Так, кінцевий результат полягає в тому, що DOM змінюється, але тому, що поза межами коду, який ми пишемо, існують прив'язки, які реагують на зміни наших змінних, але в директиві ми не знаємо нічого про це, роблячи чітке розмежування між маніпулюванням DOM і бізнес-логіка. У вашому прикладі jQuery ви безпосередньо змінюєте DOM, сказавши "додати цей текст до цього елемента" - wired_in
@trusktr Якщо розробка завжди встановлює значення вхідного елемента, використовуючи jQuery в додатку AngularJS, вона вводить тяжкий помилка Єдиний вид винятком, про який я можу думати, - це вже існуючий плагін jQuery, який занадто складний для порту, який автоматично змінює вхід, у такому разі заклик до зворотного виклику або налаштування годинника абсолютно необхідно вносити зміни в додаток до програми. - Josh David Miller


Імперативний → декларативний

У jQuery селектори використовуються для пошуку DOM елементи, а потім зв'язувати / зареєструвати обробники подій їм. Коли запускається подія, цей (імперативний) код виконується для оновлення / зміни DOM.

У AngularJS ви хочете подумати погляди а не елементи DOM. Перегляди (декларативний) HTML, що містять AngularJS директиви. Директиви налаштовують обробників подій позаду сцен для нас і дають нам динамічне підключення даних. Селектори рідко використовуються, тому потреба в ідентифікаторах (і деяких типах класів) значно зменшується. Перегляди пов'язані з моделі (через сфери). Погляди - це проекція моделі. Моделі змін подій (тобто дані, властивості області) та перегляди, на які проекти цих моделей оновлюються "автоматично".

У AngularJS, подумайте про моделі, а не про вибрані jQuery елементи DOM, які містять ваші дані. Подумайте про перегляди як прогнози тих моделей, а не про реєстрацію зворотних викликів, щоб керувати тим, що бачить користувач.

Розподіл проблем

працює jQuery ненав'язливий JavaScript - поведінка (JavaScript) відокремлена від структури (HTML).

AngularJS використовує контролери і директиви (кожен з яких може мати свій власний контролер і / або компілювати та об'єднувати функції), щоб видалити поведінку з перегляду / структури (HTML). У куті також є послуги і фільтри щоб допомогти розділити / організувати вашу заявку.

Дивись також https://stackoverflow.com/a/14346528/215945

Прикладний дизайн

Один з підходів до розробки програми AngularJS:

  1. Подумайте про свої моделі. Створюйте служби або власні об'єкти JavaScript для цих моделей.
  2. Подумайте, як ви хочете представити свої моделі - свої погляди. Створюйте HTML-шаблони для кожного перегляду, використовуючи необхідні директиви для отримання динамічного набору даних.
  3. Прикріпіть контролер до кожного вигляду (за допомогою ng-view і routing, або ng-controller). Контролер повинен знаходити / отримувати лише ті дані моделі, які потребують перегляду для виконання своєї роботи. Зробіть контролери максимально тонкими.

Прототипна спадщина

Ви можете багато чого зробити з jQuery, не знаючи про те, як працює спадщина JavaScript. Під час розробки програм AngularJS ви уникнете деяких загальних підводних каменів, якщо ви добре розумієте спадщину JavaScript. Рекомендоване читання: Які нюанси в області прототипа / прототипна спадщина у AngularJS?


408
2018-02-21 04:09



Ви можете PLS. Поясніть, як елемент dom змінюється з вигляду? - rajkamal
@rajkamal, елемент DOM є (очевидно) єдиним елементом, а в jQuery це часто те, що ми вибираємо / target / маніпулюємо. Кутовий вигляд - це колекція / шаблон відповідних елементів DOM: вид меню, вид заголовка, вид спереду, вид з правого боку, вид профілю, може бути кілька основних переглядів вмісту (перемикається через ng-вид). В основному, ви хочете розбити ваші сторінки (и) в різні думки. Кожна точка зору має власний пов'язаний контролер. Кожна точка зору проектує частину вашої моделі (ів). - Mark Rajcok
jQuery є НЕ імператив on і when є функціями вищого порядку, які працюють на членах об'єкта збору jQuery. - Jack Viers
Тож який код виконується в зворотному дзвінку для on? Імперативний. - cwharris
Цей імператив проти декларативного дійсно просто питання про абстракції. Зрештою, весь декларативний код (що робити) реалізується обов'язково (як це робити) або розробником в підпрограмі на нижньому рівні абстракції, за допомогою системи або компілятора / інтерпретатора. Говорячи про те, що "jQuery є обов'язковим", загалом це досить непарне твердження, особливо з огляду на те, що насправді він набагато більш декларативний API щодо "ручного" маніпулювання DOM. - Alex


AngularJS і jQuery

AngularJS і jQuery приймають дуже різні ідеології. Якщо ви приходите з jQuery, ви можете виявити деякі відмінності. Кутовий може засмутити вас.

Це нормально, ти повинен проштовхнутися. Кутовий це коштує.

Велика різниця (TLDR)

jQuery надає вам інструментарій для вибору довільних бітів DOM та внесення їм спеціальних змін. Ви можете робити майже все, що вам подобається шматочком.

AngularJS замість цього дає вам a компілятор.

Що це означає, що AngularJS зчитує весь ваш DOM зверху вниз і розглядає його як код, буквально як інструкції для компілятора. Коли вона перетинає DOM, вона шукає конкретних директиви (директиви компілятора), які повідомляють компілятору AngularJS, як поводитися і що робити. Директиви - це маленькі об'єкти, повні JavaScript, які можуть відповідати атрибутам, тегам, класам або навіть коментарям.

Коли кутовий компілятор визначає, що частина DOM збігається з певною директивою, вона викликає директивну функцію, передаючи її елемент DOM, будь-які атрибути, поточний діапазон $ (який є локальним магазином змінної) та деякі інші корисні біти. Ці атрибути можуть містити вирази, які можуть бути інтерпретовані Директивою, і які розповідають про те, як їх відтворювати, і коли вона повинна перероблятись сама.

Директиви можуть в свою чергу витягувати додаткові компоненти кутових, такі як контролери, служби тощо. Що виходить з нижньої частини компілятора, це повністю сформований веб-додаток, підключений до мережі та готовий до роботи.

Це означає, що Angular - шаблон Driven. Ваш шаблон керує JavaScript, а не навпаки. Це радикальне відміна ролей, і повна протилежність ненав'язливому JavaScript ми написали протягом останніх 10 років. Це може змусити деякий звикнути.

Якщо це звучить так, як це може бути надмірним і обмежувальним, ніщо не може бути далі від істини. Оскільки AngularJS розглядає ваш HTML як код, ви отримуєте Деталізація рівня HTML у вашому веб-застосунку. Все це можливо, і більшість речей дивно легко, коли ви зробите кілька концептуальних стрибків.

Давайте піднімемося до нечистої піщинки.

Спочатку Angular не замінює jQuery

Кутовий та jQuery роблять різні речі. AngularJS надає вам набір інструментів для створення веб-програм. jQuery в основному дає вам інструменти для модифікації DOM. Якщо jQuery присутній на вашій сторінці, AngularJS буде використовувати його автоматично. Якщо це не так, AngularJS поставляється з jQuery Lite, що є скороченою, але все ще відмінною версією jQuery.

Misko любить jQuery і не заперечує проти вас. Тим не менш, ви переконаєтеся, що ви зможете отримати майже всю свою роботу, використовуючи комбінацію сфер, шаблонів та директив, і вам слід віддавати перевагу цьому робочому процесу, де це можливо, тому що ваш код буде більш дискретним, налаштовується та більше. Кутовий

Якщо ви використовуєте jQuery, ви не повинні посипати його всюди. Правильне місце для маніпулювання DOM в AngularJS в директиві. Більше про ці пізніше.

Ненав'язливий JavaScript із селекторами та декларативними шаблонами

jQuery зазвичай застосовується ненав'язливо. Ваш код JavaScript пов'язаний у заголовку (або нижньому колонтитулі), і це єдине місце, про яке він згадується. Ми використовуємо селектори, щоб вибирати біти сторінки та створювати плагіни для зміни цих частин.

JavaScript знаходиться під контролем. HTML має абсолютно незалежне існування. Ваш HTML залишається семантичним навіть без JavaScript. Атрибути Onclick - це дуже погана практика.

Одне з перших речей, які ви помітите про AngularJS, це те спеціальні атрибути скрізь. Ваш HTML буде засмічено атрибутами ng, які, по суті, є атрибутами onClick на стероїдах. Це директиви (директиви компілятора) і є одним з основних способів, яким шаблон підключений до моделі.

Коли ви вперше побачите це, ви можете спокусити AngularJS вимкнути, як стара школа, нав'язливий JavaScript (як я зробив спочатку). Насправді, AngularJS не грає за цими правилами. У AngularJS ваш HTML5 є шаблоном. Він складається з AngularJS для створення вашої веб-сторінки.

Це перша велика різниця. Для jQuery ваша веб-сторінка - це DOM для маніпулювання. Для AngularJS ваш HTML-код складається. AngularJS читає всю вашу веб-сторінку і буквально збирає її на нову веб-сторінку за допомогою вбудованого компілятора.

Ваш шаблон повинен бути декларативним; його значення має бути зрозумілим просто, прочитавши його. Ми використовуємо власні атрибути з значущими іменами. Ми складаємо нові елементи HTML, знову ж таки із значущими іменами. Дизайнер, який володіє мінімальними знаннями HTML і не має навичок кодування, може прочитати ваш шаблон AngularJS і зрозуміти, що він робить. Він або вона можуть внести зміни. Це кутовий спосіб.

Шаблон знаходиться у воді.

Одним з перших питань, які я поставив собі, коли почав роботу AngularJS і проходить через підручники, є один "Де мій код?". Я не написав JavaScript, і все-таки у мене все це. Відповідь очевидна. Оскільки AngularJS компілює DOM, AngularJS обробляє ваш HTML як код. Для багатьох простих випадків достатньо просто написати шаблон і дозволити AngularJS компілювати його в додаток для вас.

Ваш шаблон керує вашою програмою. Це трактується як DSL. Ви пишете компоненти AngularJS, і AngularJS буде дбати про їх перетягування та доступність у потрібний час, виходячи з структури вашого шаблону. Це дуже відрізняється від стандарту MVC шаблон, де шаблон просто для виведення.

Це більше схоже на XSLT ніж Ruby on Rails наприклад.

Це радикальна інверсія контролю, яка вимагає деякого звикання.

Не намагайтеся запустити вашу програму з вашого JavaScript. Нехай шаблон запускає додаток, і дозволяє AngularJS подбати про встановлення компонентів разом. Це також є кутовий спосіб.

Семантичний HTML проти семантичних моделей

З jQuery ваша HTML-сторінка повинна містити семантичний змістовний вміст. Якщо JavaScript вимкнено (користувач або пошукова система), ваш вміст залишається доступним.

Тому що AngularJS розглядає вашу HTML-сторінку як шаблон. Шаблон не повинен бути семантичним, оскільки ваш вміст зазвичай зберігається у вашій моделі, що в кінцевому підсумку походить від вашого API. AngularJS компілює ваш DOM з моделлю для створення семантичної веб-сторінки.

Ваш HTML-код більше не є семантичним, замість цього ваш API та скомпільований DOM є семантичними.

У AngularJS, тобто життя в моделі, HTML - це лише шаблон, для показу тільки.

На цьому етапі ви, мабуть, стикаються з різними питаннями SEO і доступність, і це правильно. Тут є відкриті питання. Більшість зчитувачів екрана тепер будуть розбирати JavaScript. Пошукові системи можуть також індексувати AJAXed зміст Тим не менш, ви хочете переконатися, що ви використовуєте pushstate URL-адреси, і ви маєте гідну карту сайту. Дивіться тут, щоб обговорити проблему: https://stackoverflow.com/a/23245379/687677

Розподіл проблем (SOC) і MVC

Розподіл проблем (SOC) - це шаблон, який виріс за багато років розробки веб-сайтів з різних причин, включаючи SEO, доступність та несумісність браузера. Це виглядає так:

  1. HTML - семантичне значення. HTML має стояти самостійно.
  2. CSS - стиль, без CSS сторінка все ще читається.
  3. JavaScript - Поведінка, без скрипту вміст залишається.

Знову ж таки, AngularJS не грає за своїми правилами. Під час удару AngularJS відміняє десятиріччя отриманої мудрості і замість цього реалізує шаблон MVC, в якому шаблон більше не є семантичним, навіть небагато.

Це виглядає так:

  1. Модель - ваші моделі містять ваші семантичні дані. Моделі звичайно JSON об'єкти Моделі існують як атрибути об'єкта під назвою $ scope. Ви також можете зберігати зручні функції утиліт на $ scope, які ваші шаблони можуть отримати доступ.
  2. Перегляд - ваші погляди написані у форматі HTML. Погляд зазвичай не є семантичним, оскільки ваші дані зберігаються у моделі.
  3. Контролер - ваш контролер - це функція JavaScript, яка зачіпає представлення моделі. Його функція полягає в ініціалізації $ scope. Залежно від вашої програми, вам може знадобитися або не потрібно створювати контролер. Ви можете мати багато контролерів на сторінці.

MVC та SOC не знаходяться на протилежних кінцях одного масштабу, вони знаходяться на зовсім різних осях. SOC не має сенсу в контексті AngularJS. Ви повинні забути це та продовжити.

Якщо, як і я, ви прожили через браузерні війни, ця ідея може здатися досить образливою. Отримаєте це, це буде варто, я обіцяю.

Плагіни та директиви

Плагіни розширюють jQuery. Директиви AngularJS розширюють можливості вашого браузера.

У jQuery ми визначаємо плагіни, додаючи функції до jQuery.prototype. Потім ми під'єднуємо їх до DOM, вибираючи елементи та викликаючи плагін у результат. Ідея полягає в тому, щоб розширити можливості jQuery.

Наприклад, якщо ви хочете мати карусель на своїй сторінці, ви можете визначити невпорядкований список фігур, який, можливо, буде загорнутий у нативний елемент. Потім ви можете написати деякий jQuery, щоб вибрати список на сторінці, і перетворити його на галерею з тайм-аутами, щоб скористатися анімацією.

У AngularJS ми визначаємо директиви. Дирекція - це функція, яка повертає об'єкт JSON. Цей об'єкт повідомляє AngularJS, які елементи DOM шукати, і які зміни до них потрібно внести. Директиви закріплені в шаблоні за допомогою атрибутів або елементів, які ви винайшли. Ідея полягає в тому, щоб розширити можливості HTML з новими атрибутами та елементами.

Спосіб AngularJS - розширити можливості рідного HTML. Ви повинні написати HTML, який виглядає як HTML, розширений з користувацькими атрибутами та елементами.

Якщо ви хочете мати карусель, просто використовуйте a <carousel /> елемент, потім визначте директиву, щоб витягнути шаблон, і зробити цю присоску роботу.

Багато маленьких директив проти великих плагінів з перемикачами конфігурації

Тенденція з використанням jQuery полягає в тому, щоб написати великі великі плагіни, такі як Lightbox, які ми потім налаштували, передаючи численні значення та параметри.

Це помилка в AngularJS.

Візьмемо приклад спадного меню. Під час написання випадаючого плагіна, можливо, виникне бажання кодувати в обробнику кліків, можливо, функцію додати в chevron, яка є або вгору, так і вниз, можливо, змінити клас розгорнутого елемента, показати приховати меню, всі корисні речі.

Доки ви не хочете зробити невеликі зміни.

Скажімо, у вас є меню, яке ви хочете розгорнути під час наведення курсору. Ну, тепер у нас є проблема. Наш плагін встановлений в нашу обробнику кліків для нас, нам потрібно буде додати параметр конфігурації, щоб в цьому конкретному випадку він поводився по-різному.

У AngularJS ми пишемо менші директиви. Наша випадаюча директива буде смішно маленькою. Він може зберігати зігнутий стан і надати способи складання (), розгорнення () або перемикання (). Ці методи просто оновити $ scope.menu.visible, який є логічним, що містить державу.

Зараз у нашому шаблоні ми можемо провести це:

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

Необхідно оновити наведення курсора миші?

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

Шаблон керує програмою, щоб ми отримали деталізацію рівня HTML. Якщо ми хочемо виключити випадкові винятки, шаблон робить це простим.

Закриття порівняно з обсягом $

Плагіни JQuery створюються в закритті. Конфіденційність зберігається в межах цього закриття. Ви повинні зберегти ланцюг масштабу в межах цього закриття. Ви дійсно маєте доступ до набору вузлів DOM, переданих у плагін за допомогою jQuery, а також будь-яких локальних змінних, визначених у закритті, та будь-яких визначених глобалів. Це означає, що плагіни є досить автономними. Це добре, але може стримуватися під час створення всієї програми. Спроба передавати дані між розділами динамічної сторінки стає справжньою роботою.

AngularJS має об'єми $ scope. Це спеціальні об'єкти, створені та підтримувані AngularJS, в яких ви зберігаєте свою модель. Деякі директиви породжують новий $ scope, який за замовчуванням успадковує від обертання $ scope, використовуючи прототипне спадкування JavaScript. Об'єкт $ scope доступний у контролері та представленні даних.

Це розумна частина. Оскільки структура спадщини $ сфера приблизно відповідає структурі DOM, елементи мають доступ до власної області та без обмеження будь-яких сфер, що доходять до глобального об'єкта $ (який не співпадає з глобальним об'ємом).

Це полегшує передачу даних та збереження даних на належному рівні. Якщо розкривне вікно розгорнуто, про це має знати лише спадний обсяг $. Якщо користувач оновить свої налаштування, можливо, ви захочете оновити глобальний обсяг $, і будь-які вкладені області, що слухають параметри користувача, будуть автоматично сповіщені.

Це може здатися складним, адже коли ви розслабляєтесь у ньому, це як би літає. Вам не потрібно створювати об'єкт $ scope, тоді AngularJS інстансує і налаштовує його для вас, правильно і належним чином, на основі вашої шаблону ієрархії. AngularJS потім робить його доступним для вашого компонента, використовуючи магію ін'єкцій залежності (докладніше про це пізніше).

Керівництво DOM змінюється або зв'язується з даними

У jQuery ви робите всі ваші DOM зміни вручну. Ви створюєте нові елементи DOM програмно. Якщо у вас є масив JSON, і ви хочете поставити його в DOM, ви повинні написати функцію для створення HTML та вставити її.

У AngularJS ви також можете це зробити, але вам рекомендується використовувати зв'язування даних. Змініть свою модель, і тому, що DOM зв'язаний з ним через шаблон, ваш DOM буде автоматично оновлюватися, жодного втручання не потрібно.

Оскільки зв'язування даних виконується з шаблону, використовуючи як атрибут, так і синтаксис фігурної фігурної дужки, це дуже легко зробити. З нею пов'язані невеликі когнітивні накладні витрати, тому ви завжди будете це робити.

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

Прив'язує вхідний елемент до $scope.user.name. Оновлення входу оновить значення у вашій поточній області, і навпаки.

Аналогічно:

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

виведе ім'я користувача в абзац. Це живий зв'язок, так що якщо $scope.user.name значення оновлюється, шаблон також буде оновлено.

Аякс весь час

У jQuery виклик Ajax досить простий, але це ще те, про що ви можете подумати двічі. Там є додаткова складність, щоб замислитися, і чесна частина сценарію для підтримки.

У AngularJS, Ajax є вашим рішенням за замовчуванням, і це відбувається постійно, майже без вашого відчуття. Ви можете включити шаблони з ng-include. Ви можете застосувати шаблон із найпростішою спеціальною директивою. Ви можете загорнути Ajax виклик у службі і створити себе a GitHub служби або а Flickr сервіс, який ви можете отримати з дивовижною легкістю.

Сервісні об'єкти та допоміжні функції

У jQuery, якщо ми хочемо виконати невелике завдання, яке не пов'язане з доменом, наприклад, потягування каналу з API, ми можемо написати декілька функцій, щоб зробити це в нашому закритті. Це правильне рішення, але що, якщо ми хочемо часто отримувати доступ до цього каналу? Що робити, якщо ми хочемо повторно використовувати цей код у іншій програмі?

AngularJS надає нам сервісні об'єкти.

Послуги - це прості об'єкти, що містять функції та дані. Вони завжди синглетони, а це означає, що ніколи не може бути більше одного з них. Скажімо, ми хочемо отримати доступ до API переповнення стека, ми могли б написати StackOverflowService який визначає методи для цього.

Скажімо, у нас є кошик для покупок. Ми можемо визначити ShoppingCartService, яка підтримує нашу кошик і містить методи додавання та видалення елементів. Оскільки служба є одномандатною, і її використовують всі інші компоненти, будь-який об'єкт, який потребує, може написати в кошик для покупок і витягувати з нього дані. Це завжди однаковий кошик.

Сервісні об'єкти - це автономні компоненти AngularJS, які ми можемо використовувати та використовувати, як ми вважаємо за потрібне. Вони є простими об'єктами JSON, що містять функції та дані. Вони завжди є одноманітними, тому, якщо ви зберігаєте дані на службі в одному місці, ви можете отримати ці дані деінде, просто надіславши таку ж службу.

Залежність ін'єкції (DI) проти інстатівації - така де-спагеттіфікація

AngularJS керує вашими залежностями для вас. Якщо ви хочете об'єкта, просто зверніться до нього, і AngularJS отримає його для вас.

Доки ви не почнете використовувати це, важко пояснити, що саме таке багатовікове благословення. Нічого подібного до AngularJS DI не існує всередині jQuery.

DI означає, що замість написання вашої програми та підключення його разом, ви замість цього визначаєте бібліотеку компонентів, кожен з яких ідентифікується рядком.

Скажімо, у мене є компонент під назвою "FlickrService", який визначає способи витягування каналів JSON з Flickr. Тепер, якщо я хочу написати контролер, який може отримати доступ до Flickr, я просто повинен звернутися до "FlickrService" за назвою, коли я оголошую контролер. AngularJS подбає про те, щоб компонент був складений і доступний моєму контролеру.

Наприклад, тут я визначаю послугу:

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

Тепер, коли я хочу скористатися цією службою, я просто називаю це ім'ям:

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

AngularJS визнає, що об'єкт FlickrService потрібен для інстанцірування контролера, і він забезпечить його для нас.

Це робить з'єднання проводів дуже простим, і в значній мірі усуває будь-яку тенденцію до спагеттіфікації. У нас є плаский список компонентів, і AngularJS передає їх нам по черзі, коли нам це потрібно.

Модульна архітектура обслуговування

jQuery дуже мало говорить про те, як потрібно організувати код. AngularJS має свої думки.

AngularJS надає вам модулі, в які ви можете розмістити свій код. Якщо ви пишете сценарій, що, наприклад, говорить з Flickr, можливо, вам знадобиться створити модуль Flickr, щоб загорнути всі ваші функції, пов'язані з Flickr. Модулі можуть включати інші модулі (DI). Ваша основна програма, як правило, є модулем, і це повинно включати в себе всі інші модулі, від яких залежить ваше застосування.

Ви отримуєте простий код повторного використання, якщо ви хочете написати іншу програму на основі Flickr, ви можете просто включити модуль Flickr і voila, у вас є доступ до всіх ваших функцій Flickr у вашій новій програмі.

Модулі містять компоненти AngularJS. Коли ми включаємо модуль, всі компоненти цього модуля стають доступними для нас як простий список, ідентифікований їх унікальними рядками. Потім ми можемо ввести ці компоненти в один одного, використовуючи механізм впорядкування залежностей AngularJS.

Підсумовуючи

AngularJS і jQuery - це не вороги. JQuery можна використовувати в AngularJS дуже красиво. Якщо ви добре використовуєте AngularJS (шаблони, дані, що зв'язують, $ scope, директиви тощо), вам буде потрібно багато менше jQuery, ніж ви могли б вимагати іншим чином.

Головне зрозуміти, що ваш шаблон керує вашою заявкою. Не намагайтеся писати великі плагіни, які роблять все. Замість цього напишіть маленькі директиви, які виконують одну річ, а потім напишіть простий шаблон, щоб з'єднати їх разом.

Мені менше замислюйтесь про ненав'язливий JavaScript, а замість цього - про розширення HTML.

Моя маленька книга

Я так схвильований щодо AngularJS, я написав коротку книгу про це, про яку ви дуже бажаєте прочитати в Інтернеті http://nicholasjohnson.com/angular-book/. Я сподіваюся, це корисно.


184
2018-05-12 10:22



Ідея, що "Роздільна хвилювання" відрізняється від "MVC (Model, View, Controller)", є цілком фальшивою. Модель веб-мов розділення проблем (HTML, CSS і JS) робить це тим, що дозволяє людям поміщати матеріали на веб-сторінку (розмітку / HTML), не дбаючи про те, як вона виглядає (стиль / макет / CSS) або що він "робить" (Події DOM / AJAX / JavaScript). MVC також відокремлює проблеми. Кожен "шар" у шаблоні MVC має особливу роль - дані, маршрутизація / логіка або рендеринг. Слони поєднуються зворотними викликами, маршрутами та моделями прив'язки. У теорії людина може спеціалізуватися на кожному шарі, що часто буває. - Alexander Pritchard
Як людина, яка виходить із строгого фону SOC, і як давній захисник веб-стандартів, що належить до браузерних воєн, спочатку я виявив, що не є семантичними, не перевіряючими шаблони Angular. Я просто хотів зрозуміти, що для запису Angular необхідно відпустити SOC, як це зазвичай практикується. Це може бути важким переходом. - superluminary
Ви праві. SOC - це широкий термін, але у веб-середовищі SOC мав (або мав) дуже специфічне значення: семантичний HTML, презентаційний CSS та JavaScript для поведінки. Я роблю деякі припущення щодо своєї аудиторії, які, можливо, не є розумними, тому я також повинен вибачитися. - superluminary
Я знаходжу вашу відповідь максимально чітко та зрозуміло. Я тут зовсім новачок, тому, якщо у мене є розширення для зміни існуючої сторінки (яку я не контролюю), чи слід я зберігати JQuery? - Daniel Möller


Чи можете ви описати необхідний зрушення в парадигмі?

Імперативний проти декларативний

З jQuery Ви розповідаєте DOM, що повинно відбутися, крок за кроком. З AngularJS Ви описуєте, які результати ви хочете, але не як це зробити. Детальніше про це тут. Також перевірте відповідь Марка Райкока.

Як по-іншому розробляти та проектувати веб-програми на стороні клієнта?

AngularJS - це цілі клієнтські рамки, які використовують MVC візерунок (перевірте їх графічне представлення) Він сильно зосереджується на розділенні проблем.

Яка найбільша різниця? Що слід припинити робити / використовувати; що я повинен почати робити / використовувати замість цього?

jQueryце бібліотека

AngularJS це прекрасна сторона на стороні клієнта, дуже перевірена, яка поєднує в собі багато тонких товарів, таких як MVC, ін'єкція залежності, зв'язування даних та багато іншого.

Вона зосереджена на відділення проблем і тестування (одиничне випробування і тестування від кінця до кінця), що полегшує розробку на основі тестування.

Найкращий спосіб розпочати - проходить їх чудовий підручник. Ви можете пройти кроки через пару годин; однак, якщо ви хочете освоїти концепції позаду сцен, вони включають безліч довідників для подальшого читання.

Чи є якісь міркування чи обмеження на стороні сервера?

Ви можете використовувати його в існуючих програмах, де ви вже використовуєте чистий jQuery. Однак, якщо ви хочете повністю скористатися перевагами функцій AngularJS, ви можете розглянути можливість кодування серверної сторони за допомогою RESTful підхід

Це дозволить вам використати їх ресурсний завод, який створює абстракцію вашого сервера RESTful API і робить виклики на серверах (отримувати, зберігати, видаляти тощо) неймовірно легко.


152
2018-02-21 04:29



Я думаю, ви заплямуєте воду, розмовляючи про те, як jQuery є "бібліотекою", а "Angular" є "рамкою" ... на одне, я думаю, можна стверджувати, що jQuery є рамка ... це абстракція маніпуляцій DOM та обробки подій. Це не може бути основою для такого самого роду, що є Angular, але це дилема, в якій опитувач запитує: вони насправді не знають різниці між Angular та jQuery, і всім, хто запитує, знає, jQuery є рамки для побудови веб-сайтів, що належать клієнтам. Отже, сперечаючись про термінологію, це не зрозумітиме. - Zando
Я думаю, ти той, хто плутається. Це питання стосується саме цього stackoverflow.com/questions/7062775. Також ця відповідь може допомогти з'ясувати, яка різниця між рамкою та бібліотекою: stackoverflow.com/a/148759/620448 - Ulises
Бібліотека не стає "рамкою" просто тому, що її колекція функцій особливо корисна або велика. Рамки приймають рішення для вас. Коли ви починаєте користуватись AngularJS, ви, ймовірно, поєднаєтесь з нею за своєю природою. (Наприклад: вам слід лише оновити DOM у директивах, інакше щось може зіпсуватись). Це тому, що AngularJS є рамкою. Коли ви використовуєте jQuery, ви можете досить легко змішувати та порівняти інструменти з мінімальним ризиком конфлікту. Це тому, що jQuery - це бібліотека, а також принаймні напівпристойна. - Alexander Pritchard
А. бібліотека це код, який ви телефонуєте. А. рамки це код, який викликає ваш код. За цим визначенням кутовий є основою. Ви постачаєте його компонентами, і Angular бачить в тому, що ваші компоненти є екземплярами з потрібними їм залежностями. - superluminary


Щоб описати «зміну парадигми», я думаю, що короткої відповіді може вистачити.

AngularJS змінює ваш спосіб знайти елементи

В jQuery, як правило, ви використовуєте селектори знайти елементи, а потім підключити їх:
$('#id .class').click(doStuff);

В AngularJS, ти використовуєш директиви щоб позначити елементи безпосередньо, щоб підключити їх:
<a ng-click="doStuff()">

AngularJS не потребує (або не бажає) знаходити елементи за допомогою селекторів - основна різниця між AngularJS jqLite проти повного здуття jQuery чи це jqLite не підтримує селектори.

Тому, коли люди говорять "не включати jQuery взагалі", це головним чином тому, що вони не хочуть, щоб ви використовували селектори; вони хочуть, щоб ви навчилися використовувати директиви. Прямий, не вибирай!


84
2018-02-21 07:57



Так само, як застереження, існує ще багато відмінностей між Angular та jQuery. Але пошук елементів це той, який вимагає найбільшої зміни мислення. - Scott Rippey
пробач мені, якщо я помиляюся, але я думав, що селектором був те, що ви використовуєте, щоб знайти елемент DOM? Ви вважаєте за краще тримати кожну частину вашого нещодавно завантаженого інтерфейсу в довіднику, а не просто вибирати один або два елементи, які користувач може натиснути на літаку за допомогою селектора? звучить складніше для мене .. - RozzA
@AlexanderPritchard Точка Angular - ви не вибираєте зі свого JavaScript, ви прямуєте зі свого шаблону. Це інверсія керування, яка ставить владу в руки дизайнера. Це принцип навмисного дизайну. Дійсно отримати Угловий ви повинні думати про ваш код таким чином навколо. Це важкий зсув зробити. - superluminary
@superluminary Яка чудова цитата! "Не вибирай, прямий!" Серйозно, я збираюся використати це. - Scott Rippey
Це одна з моїх улюблених речей про AngularJS. Мені не доведеться турбуватися про те, що команда UX порушила мою функціональність, або я розбив їхні стилі. Вони використовують класи, я використовую директиви, період. Я не пропускаю селекторів трохи. - adam0101


jQuery

jQuery робить смішно довгі команди JavaScript, як getElementByHerpDerp коротший і крос-браузер.

AngularJS

AngularJS дозволяє створювати власні HTML теги / атрибути, які роблять те, що добре працює з динамічними веб-додатками (оскільки HTML був призначений для статичних сторінок).

Редагувати:

Говорячи: "У мене є флеш jQuery, як я думаю в AngularJS?" схоже на те, що "У мене є HTML-фон, як я думаю в JavaScript?" Той факт, що ви задаєте запитання, показує, що ви, напевно, не розумієте основних цілей цих двох ресурсів. Ось чому я вирішив відповісти на це питання, просто вказавши фундаментальну різницю, а не переходячи через список, говорячи: "AngularJS використовує директиви, тоді як jQuery використовує селектори CSS для створення об'єкта jQuery, який робить це і так далі ..." . Це питання не вимагає тривалої відповіді.

jQuery - це спосіб спростити програмування JavaScript в браузері. Короткі, крос браузерні команди і т. Д.

AngularJS розширює HTML, так що вам не потрібно це робити <div> всюди, щоб зробити заявку. Це робить HTML насправді роботою для додатків, а не те, що вона була призначена для статичних, освітніх веб-сторінок. Це здійснює це кільце, використовуючи JavaScript, але в основному це розширення HTML, а не JavaScript.


69
2018-02-04 05:07



@ Роберт залежить від того, що ти робиш. $(".myclass") надзвичайно поширений, і більш ніж трохи простіше в jQuery, ніж PO-Javascript. - Robert Grant


jQuery: Ви багато чого думаєте про "QUERYing the DOM'для елементів DOM і щось робити.

AngularJS: модель є правдою, і ви завжди думаєте з цього ANGLE.

Наприклад, коли ви отримуєте дані з сервера, який ви збираєтеся відображати у певному форматі в DOM, у jQuery вам потрібно 1. FIND ', де в DOM ви хочете розмістити ці дані,' 2. UPDATE / APPEND 'там, створюючи новий вузол або просто встановивши його внутрішнійHTML. Потім, коли ви хочете оновити цей вигляд, ви потім "3. Знайдіть "місцезнаходження" та "4. UPDATE '. Цей цикл пошуку та оновлення всіх виконаних в рамках одного контексту отримання та форматування даних з сервера вийшов у AngularJS.

З AngularJS у вас є ваша модель (об'єкти JavaScript, з якими ви вже використовували), а значення моделі розповідає вам про модель (очевидно) і про вигляд, а операція на моделі автоматично поширюється на вигляд, ти повинен думати про це. Ви опинитеся в AngularJS, більше не знайшовши речі в DOM.

Щоб поставити іншим способом, у jQuery потрібно подумати про селектори CSS, тобто де є div або td що має клас або атрибут і т. д., так що я можу отримати їх HTML, колір або значення, але в AngularJS, ви побачите, що ми думаєте так: якою моделлю я маю справу, я встановлюю значення моделі для істини. Ви не турбуєтеся, чи є вигляд, що відображає це значення, позначеним полем або знаходиться в a td елемент (деталі, про які вам часто варто було б задуматися в jQuery).

І за допомогою маніпулювання DOM в AngularJS ви можете додавати директиви та фільтри, які можна вважати правильними розширеннями HTML.

Ще одна річ, яку ви будете відчувати в AngularJS: у jQuery ви називаєте функції jQuery дуже багато, у AngularJS AngularJS зателефонує вашим функціям, так що AngularJS скаже вам, як це робити, але переваги це коштують, тому навчання AngularJS зазвичай означає, що потрібно знати AngularJS або як AngularJS вимагає, щоб ви представили свої функції, і це буде називати відповідним чином. Це одна з речей, які роблять AngularJS рамки, а не бібліотеку.


61
2017-11-02 16:53