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

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

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

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

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

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

2. Не збільшуйте jQuery за допомогою AngularJS

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

Я бачив, як багато розробників тут і в списку розсилки створюють ці вишукані рішення за допомогою плагінів jQuery розміром 150 або 200 рядків коду, які вони потім вклеюють у AngularJS із набором зворотних викликів та $applys, які заплутані та переплутані; але вони з часом спрацьовують! Проблема полягає в тому, що у більшості випадків плагін 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, наполовину 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 та доповнюєте свій погляд за допомогою директив; і ви склеюєте це все разом з контролерами. Про це згадувалося і в інших відповідях, і єдине, що я б додав, стосується передбачуваності, про яку я обговорюю в іншому розділі нижче.

Ін'єкційна залежність

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

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

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

Якщо говорити про тестування ...

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="https://stackoverflow.com/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 не повинні бути загорнуті $- той, 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 результатів для вас більше роботи.

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

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

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

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

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

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

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

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

Дизайн програми

Один із підходів до проектування програми AngularJS:

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

Прототипне успадкування

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

AngularJS vs. jQuery

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

Це нормально, ви повинні просуватися. Кутовий того вартий.

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

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

AngularJS дає вам компілятор .

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

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

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

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

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

Давайте перейдемо до азотної крупки.

По-перше, Angular не замінює jQuery

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

Місько любить 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 . Тим не менш, ви хочете переконатися, що ви використовуєте URL-адреси pushstate і маєте гідну мапу сайту. Дивіться тут для обговорення питання: https://stackoverflow.com/a/23245379/687677

Розмежування проблем (SOC) проти MVC

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

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

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

Це виглядає приблизно так:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

У AngularJS ми пишемо менші директиви. Наша директива, що випадає, була б смішно малою. Він може підтримувати складений стан і надавати методи складання (), розгортання () або переключення (). Ці методи просто оновлюють $ range.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 має $ об’єкти. Це спеціальні об’єкти, створені та підтримувані AngularJS, в яких ви зберігаєте свою модель. Деякі директиви породжують нову область $ range, яка за замовчуванням успадковує свою обтікаючу область $ за допомогою прототипічного успадкування JavaScript. Об'єкт $ range доступний у контролері та представленні.

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

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

Це може здатися складним, насправді, як тільки ви розслабитесь, це як політ. Вам не потрібно створювати об’єкт $ range, 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 у сервісі та створити собі послугу GitHub або послугу Flickr , до якої ви можете отримати доступ з дивовижною легкістю.

Об'єкти обслуговування проти функцій помічника

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

AngularJS дає нам об’єкти обслуговування.

Послуги - це прості об'єкти, що містять функції та дані. Вони завжди одиночні, тобто ніколи їх не може бути більше. Скажімо, ми хочемо отримати доступ до API переповнення стека, ми можемо написати a, 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 і вуалу, у вас є доступ до всіх функцій, пов'язаних з Flickr, у вашій новій програмі.

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

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

AngularJS і jQuery не є ворогами. Можна дуже добре використовувати jQuery в AngularJS. Якщо ви добре використовуєте AngularJS (шаблони, прив'язка даних, $ range, директиви тощо), ви побачите, що вам потрібно набагато менше jQuery, ніж вам може знадобитися інакше.

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

Не думайте про ненав’язливий JavaScript, а замість цього роздумуйте над розширеннями HTML.

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

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

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

Імператив проти Декларативної

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

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

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

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

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

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

Основна увага приділяється розділенню проблем та тестування (тестування одиниць та тестування), що сприяє розробці тестових програм.

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

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

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

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

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

AngularJS змінює спосіб пошуку елементів

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

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

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

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

jQuery

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

КутовийJS

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

Редагувати:

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

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

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

jQuery: ти багато думаєш про те, як "ЗАПИТАТИ DOM " для елементів DOM і зробити щось.

AngularJS: Модель - це правда, і ти завжди думаєш від цього АНГЛЕ.

Наприклад, коли ви отримуєте дані з сервера, які ви маєте намір відображати в якомусь форматі в DOM, в jQuery, вам потрібно "1. ЗНАЙТИ ", де у DOM ви хочете розмістити ці дані," 2. ОНОВЛЮЙТЕ / ДОДАТИ 'його там, створивши новий вузол або просто встановивши його внутрішній HTML . Потім, коли ви хочете оновити цей вигляд, тоді ви '3. ЗНАЙТИ "місцеположення та" 4. ОНОВЛЕННЯ ". Цей цикл пошуку та оновлення всього, що робиться в одному контексті отримання та форматування даних з сервера, відсутній в AngularJS.

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

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

А при маніпуляції з DOM в AngularJS ви виявляєте, що додаєте директиви та фільтри, які можна вважати допустимими розширеннями HTML.

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

Це кілька дуже приємних, але тривалих відповідей.

Підводячи підсумки мого досвіду:

1. Контролери та провайдери (послуги, фабрики тощо) призначені для зміни моделі даних, а не HTML.
2. HTML та директиви визначають компонування та прив'язку до моделі.
3. Якщо вам потрібно обмінюватися даними між контролерами, створіть службу чи фабрику - це одиночні кнопки, які спільно використовуються в додатку.
4. Якщо вам потрібен HTML-віджет, створіть директиву.
5. Якщо у вас є деякі дані, які зараз намагаються оновити HTML ... СТОП! оновіть модель і переконайтеся, що ваш HTML прив’язаний до моделі.

jQuery - це бібліотека маніпуляцій DOM.

AngularJS - це рамка MV *.

Насправді AngularJS - одна з небагатьох фреймворків JavaScript MV * (багато інструментів JavaScript MVC все ще підпадають під бібліотеку категорій).

Будучи фреймворком, він розміщує ваш код і приймає рішення про те, що викликати і коли!

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

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

AngularJS включає деяку криву навчання (більше, ніж jQuery :-).

-> Для будь-якого розробника, що походить з jQuery, моєю першою порадою було б "вивчити JavaScript як мову першого класу, перш ніж стрибати на такий багатий фреймворк, як AngularJS!" Я навчився вищенаведеному факту важким шляхом.

Удачі.

Вони - яблука та апельсини. Ви не хочете їх порівнювати. Це дві різні речі. AngularJs вже вбудований jQuery lite, в якому ви можете виконувати основні маніпуляції з DOM, навіть не включаючи повноцінну версію jQuery.

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

Приємна річ у AngularJs полягає в тому, що він дозволяє розділити / ізолювати маніпуляції з DOM у директивах. Існують вбудовані директиви, готові до використання таких, як ng-click. Ви можете створити власні власні директиви, які містять усю логіку перегляду або маніпуляцію з DOM, щоб ви не змішували код маніпуляції з DOM в контролерах або службах, які повинні дбати про бізнес-логіку.

Кутове розбиває ваше додаток на - Контролери - Послуги - Перегляди - тощо.

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

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

Послухайте подкаст JavaScript Jabber: Епізод №32, який містить оригінальних творців AngularJS: Misko Hevery & Igor Minar. Вони багато говорять про те, що це за приїзд до AngularJS з іншого JavaScript, особливо jQuery.

Один із пунктів, зроблених у подкасті, зробив для мене багато речей, що стосуються вашого питання:

MISKO : [...] одна з речей, про яку ми дуже думали в Angular, - це те, як ми можемо забезпечити безліч евакуаційних люків, щоб ви могли вийти і в основному з'ясувати вихід із цього. Отже, для нас відповідь - це "Директиви". І з директивами ви, по суті, стаєте звичайним маленьким JavaScript JQuery, ви можете робити все, що завгодно.

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

Стенограма всього епізоду доступна за посиланням, поданим вище.

Отже, щоб безпосередньо відповісти на ваше запитання: AngularJS є дуже впевненим і є справжньою рамкою MV *. Тим не менш, ви все одно можете робити всі цікаві речі, які ви знаєте і любите, з jQuery всередині директив. Це не питання "Як зробити те, що раніше використовував у jQuery?" наскільки це питання "Як я доповнюю AngularJS всіма речами, які я раніше робив у jQuery?"

Це дійсно два дуже різних стани душі.

Я вважаю це питання цікавим, оскільки моїм першим серйозним впливом на програмування JavaScript були Node.js та AngularJS. Я ніколи не дізнавався jQuery, і, мабуть, це гарна річ, тому що мені нічого не потрібно навчатися. Насправді я активно уникаю рішень jQuery для своїх проблем, і натомість шукаю лише «AngularJS шлях» для їх вирішення. Отже, я думаю, що моя відповідь на це питання по суті зводиться до "думати, як хтось, хто ніколи не вчився jQuery", і уникати будь-яких спокус включити jQuery безпосередньо (очевидно, AngularJS використовує його певною мірою поза кадром).

AngularJS та jQuery:

AngularJs та JQuery абсолютно різні на кожному рівні, крім функціональності JQLite, і ви побачите це, як тільки ви почнете вивчати основні функції AngularJs (я пояснив це нижче).

AngularJs - це система з боку клієнта, яка пропонує побудувати незалежний додаток на стороні клієнта. JQuery - це клієнтська бібліотека, яка грає навколо DOM.

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

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

Двостороння прив'язка даних є дивовижною: у мене була сітка з усіма функціональними можливостями UPDATE, DELTE, INSERT. У мене є об'єкт даних, який пов'язує модель сітки за допомогою ng-repeat. Вам потрібно лише написати один рядок простого коду JavaScript для видалення та вставки, і це все. сітка автоматично оновлюється, коли модель сітки миттєво змінюється. Функціональність оновлення в режимі реального часу, коду для цього немає. Ви відчуваєте себе дивовижно !!!

Директиви для багаторазового використання - це супер: пишіть директиви в одному місці та використовуйте їх у всьому додатку. О БОЖЕ МІЙ!!! Я використав цю директиву для пейджингу, регулярного вираження, валідацій тощо. Це дійсно круто!

Маршрутизація є сильною: від вашої реалізації залежить те, як ви хочете її використовувати, але для маршрутизації запиту із зазначенням HTML та контролера (JavaScript) потрібно дуже мало рядків коду.

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

Плагіни: Є багато інших подібних функцій, таких як показ накладання у вашій програмі. Для цього вам не потрібно писати код, просто використовуйте плагін накладання, доступний як wc-overlay, і це автоматично забезпечить усі запити XMLHttpRequest (XHR).

Ідеально підходить для архітектури RESTful : Повна рамка робить AngularJS чудовою для роботи з архітектурою RESTful. Викликати API REST CRUD дуже просто і

Послуги : записуйте загальні коди за допомогою служб та менше коду в контролери. Пристрої можуть використовуватися для обміну загальними функціональними можливостями між контролерами.

Розширюваність : Angular розширив директиви HTML, використовуючи кутові директиви. Пишіть вирази всередині html та оцінюйте їх під час виконання. Створіть власні директиви та послуги та використовуйте їх в іншому проекті без зайвих зусиль.

Як початківець JavaScript MV * і зосередився лише на архітектурі додатків (а не на серверних / клієнтських питаннях), я, безумовно, порекомендував би наступний ресурс (про що я дивуюсь, ще не згадувалося): Шаблони дизайну JavaScript , Адді Османі , як вступ до різних шаблонів дизайну JavaScript . Терміни, використані у цій відповіді, взяті з пов'язаного документа вище. Я не збираюся повторювати те, що було сформульовано дуже добре у прийнятій відповіді. Натомість ця відповідь посилається на теоретичне походження які живлять AngularJS (та інші бібліотеки).

Як я, ви швидко зрозумієте, що AngularJS (або Ember.js , та інші MV * для цього питання) - це одна складна рамка, яка збирає багато різних моделей дизайну JavaScript.

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

Наприклад:

• Об'єктно-орієнтоване програмування JavaScript (це посилання на пошук Google). Це не бібліотека, але, безумовно, необхідна умова будь-якого прикладного програмування. Це навчило мене натільних реалізацій моделей прототипу, конструктора, одиночки та декораторів
• jQuery / Підкреслення для фасадного малюнка (як WYSIWYG для маніпуляції з DOM)
• Prototype.js для шаблону прототип / конструктор / mixin
• RequireJS / Curl.js для шаблону модуля / AMD
• KnockoutJS для спостережуваного шаблону, публікація / підписка

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

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

Я зазвичай розробляю мобільні додатки за допомогою AngularJS та Cordova . ТІЛЬКИ, що мені потрібно було від jQuery, це Selector.

За допомогою гугла я бачу, що там є окремий модуль вибору jQuery. Це Sizzle.

І я вирішив зробити крихітний фрагмент коду, який допоможе мені швидко запустити веб-сайт за допомогою AngularJS з потужністю jQuery Selector (за допомогою Sizzle).

Я поділився своїм кодом тут: https://github.com/huytd/Sizzular