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

В jQuery вы создаете страницу, а затем делаете ее динамической. Это потому, что jQuery был разработан для расширения и невероятно вырос из этой простой предпосылки.

Но в AngularJS вы должны начинать с нуля, имея в виду свою архитектуру. Вместо того, чтобы думать: «У меня есть этот фрагмент DOM, и я хочу, чтобы он выполнял X», вы должны начать с того, чего хотите достичь, затем приступить к разработке приложения и, наконец, приступить к разработке своего представления.

2. Не дополняйте jQuery с помощью AngularJS.

Точно так же не начинайте с идеи, что jQuery выполняет X, Y и Z, поэтому я просто добавлю AngularJS поверх этого для моделей и контроллеров. Это действительно заманчиво, когда вы только начинаете, поэтому я всегда рекомендую новым разработчикам AngularJS вообще не использовать jQuery, по крайней мере, до тех пор, пока они не привыкнут делать вещи "Angular Way". ".

Я видел, как многие разработчики здесь и в списке рассылки создают эти сложные решения с плагинами 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, наполовину 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 , эта концепция может показаться всем, от глупой до хипстерской. Но это не так. :-)

В широком смысле DI означает, что вы можете очень свободно объявлять компоненты, а затем из любого другого компонента просто запрашивать его экземпляр, и он будет предоставлен. Вам не обязательно знать порядок загрузки, расположение файлов или что-то в этом роде. Мощность может быть не сразу видна, но я приведу только один (общий) пример: тестирование.

Допустим, в нашем приложении нам требуется служба, которая реализует хранилище на стороне сервера через REST 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 не нужно заключать в $ - 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 и routing или ng-controller). Попросите контроллер найти / получить только те данные модели, которые необходимы представлению для выполнения своей работы. Делайте контроллеры как можно тоньше.

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

Вы можете многое сделать с jQuery, не зная, как работает прототипное наследование JavaScript. При разработке приложений AngularJS вы избежите некоторых распространенных ошибок, если хорошо разбираетесь в наследовании JavaScript. Рекомендуемая литература: Каковы нюансы прототипа области видимости / прототипное наследование в AngularJS?

AngularJS против jQuery

AngularJS и jQuery придерживаются совершенно разных идеологий. Если вы работаете с jQuery, некоторые отличия могут вас удивить. Angular может вас рассердить.

Это нормально, надо протолкнуться. Angular того стоит.

Большая разница (TL; DR)

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

Вместо этого AngularJS предоставляет компилятор.

Это означает, что AngularJS читает всю вашу DOM сверху вниз и рассматривает ее как код, буквально как инструкции для компилятора. При обходе DOM он ищет определенные директивы (директивы компилятора), которые сообщают компилятору AngularJS, как себя вести и что делать. Директивы - это небольшие объекты, заполненные JavaScript, которые могут соответствовать атрибутам, тегам, классам или даже комментариям.

Когда компилятор Angular определяет, что часть DOM соответствует определенной директиве, он вызывает функцию директивы, передавая ей элемент DOM, любые атрибуты, текущую $ scope (которая является хранилищем локальных переменных) и некоторые другие полезные биты. Эти атрибуты могут содержать выражения, которые могут быть интерпретированы Директивой, и которые сообщают ей, как визуализировать и когда она должна перерисовываться.

Затем директивы могут, в свою очередь, включать дополнительные компоненты Angular, такие как контроллеры, службы и т. Д. То, что выходит в нижней части компилятора, - это полностью сформированное веб-приложение, подключенное и готовое к работе.

Это означает, что Angular основан на шаблоне. Ваш шаблон управляет JavaScript, а не наоборот. Это радикальная смена ролей и полная противоположность ненавязчивому JavaScript, который мы писали последние 10 лет или около того. К этому нужно привыкнуть.

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

Давайте перейдем к мелочам.

Во-первых, Angular не заменяет jQuery.

Angular и 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 и понять, что он делает. Он или она может вносить изменения. Это способ Angular.

Шаблон находится на водительском сиденье.

Один из первых вопросов, который я задавал себе при запуске AngularJS и просмотре руководств, - это «Где мой код?». Я не писал JavaScript, но все же у меня есть такое поведение. Ответ очевиден. Поскольку AngularJS компилирует DOM, AngularJS обрабатывает ваш HTML как код. Для многих простых случаев часто бывает достаточно просто написать шаблон и позволить AngularJS скомпилировать его в приложение за вас.

Ваш шаблон управляет вашим приложением. Он рассматривается как DSL. Вы пишете компоненты AngularJS, а AngularJS позаботится о том, чтобы их загрузить и сделать доступными в нужное время в зависимости от структуры вашего шаблона. Это сильно отличается от стандартного MVC. шаблон, где шаблон предназначен только для вывода.

Он больше похож на XSLT, чем на Ruby on Rails.

Это радикальная инверсия контроля, к которой нужно привыкнуть.

Перестаньте пытаться управлять своим приложением с помощью JavaScript. Пусть шаблон управляет приложением, а AngularJS позаботится о соединении компонентов вместе. Это тоже способ Angular.

Семантический 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. Модели существуют как атрибуты объекта с именем $ 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, с добавлением настраиваемых атрибутов и элементов.

Если вам нужна карусель, просто используйте элемент <carousel />, затем определите директиву для извлечения шаблона и заставьте эту присоску работать.

Множество маленьких директив против больших плагинов с переключателями конфигурации

Тенденция с jQuery состоит в том, чтобы писать большие большие плагины, такие как лайтбокс, которые мы затем настраиваем, передавая многочисленные значения и параметры.

Это ошибка AngularJS.

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

Пока вы не захотите внести небольшое изменение.

Допустим, у вас есть меню, которое вы хотите развернуть при наведении курсора. Что ж, теперь у нас есть проблема. Наш плагин подключил для нас обработчик кликов, нам нужно будет добавить параметр конфигурации, чтобы он вел себя по-другому в этом конкретном случае.

В AngularJS мы пишем директивы меньшего размера. Наша выпадающая директива была бы смехотворно маленькой. Он может поддерживать свернутое состояние и предоставлять методы для fold (), развертывания () или toggle (). Эти методы просто обновят $ 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. Если мы хотим делать исключения для каждого конкретного случая, шаблон упрощает это.

Закрытие против $ scope

Плагины JQuery создаются при закрытии. В рамках этого закрытия сохраняется конфиденциальность. Вы должны поддерживать свою цепочку областей видимости в рамках этого замыкания. У вас действительно есть доступ только к набору узлов DOM, переданных плагину с помощью jQuery, плюс любые локальные переменные, определенные в замыкании, и любые глобальные переменные, которые вы определили. Это означает, что плагины достаточно автономны. Это хорошо, но может иметь ограничения при создании всего приложения. Попытка передать данные между разделами динамической страницы становится рутиной.

AngularJS имеет объекты $ scope. Это специальные объекты, созданные и поддерживаемые AngularJS, в которых вы храните свою модель. Определенные директивы порождают новую $ scope, которая по умолчанию наследуется от своей оболочки $ scope, используя прототипное наследование JavaScript. Объект $ scope доступен в контроллере и в представлении.

Это умная часть. Поскольку структура наследования $ scope примерно соответствует структуре DOM, элементы имеют доступ к своей собственной области видимости и любым содержащим ее областям, вплоть до глобальной области $ scope (которая не совпадает с глобальной областью).

Это значительно упрощает передачу данных и их хранение на соответствующем уровне. Если раскрывающийся список развернут, только раскрывающийся список $ scope должен знать об этом. Если пользователь обновляет свои предпочтения, вы можете захотеть обновить глобальную $ scope, и все вложенные области, слушающие предпочтения пользователя, будут автоматически предупреждены.

Это может показаться сложным, на самом деле, если расслабиться, это похоже на полет. Вам не нужно создавать объект $ 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 в службу и создать себе службу GitHub или служба Flickr, к которой вы можете получить доступ с удивительной легкостью.

Сервисные объекты и вспомогательные функции

В jQuery, если мы хотим выполнить небольшую задачу, не связанную с dom, такую ​​как получение канала из API, мы могли бы написать небольшую функцию для этого в нашем закрытии. Это правильное решение, но что, если мы хотим часто получать доступ к этому каналу? Что, если мы захотим повторно использовать этот код в другом приложении?

AngularJS предоставляет нам служебные объекты.

Сервисы - это простые объекты, содержащие функции и данные. Они всегда синглтоны, то есть их никогда не может быть больше одного. Скажем, мы хотим получить доступ к API переполнения стека, мы могли бы написать StackOverflowService, который определяет методы для этого.

Допустим, у нас есть корзина для покупок. Мы могли бы определить ShoppingCartService, который поддерживает нашу корзину и содержит методы для добавления и удаления товаров. Поскольку служба является одноэлементной и совместно используется всеми другими компонентами, любой объект, которому необходимо, может записывать данные в корзину и извлекать из нее данные. Это всегда одна и та же тележка.

Сервисные объекты - это автономные компоненты AngularJS, которые мы можем использовать и повторно использовать по своему усмотрению. Это простые объекты JSON, содержащие функции и данные. Это всегда синглтоны, поэтому, если вы храните данные о сервисе в одном месте, вы можете получить эти данные где-то еще, просто запросив ту же услугу.

Внедрение зависимостей (DI) против Instatiation - также известное как де-спагеттификация

AngularJS управляет вашими зависимостями за вас. Если вам нужен объект, просто обратитесь к нему, и AngularJS получит его за вас.

Пока вы не начнете использовать это, трудно объяснить, насколько это огромная выгода для времени. Внутри jQuery нет ничего похожего на AngularJS DI.

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 (шаблоны, привязка данных, $ scope, директивы и т. Д.), Вы обнаружите, что вам нужно на намного меньше jQuery, чем могло бы потребоваться в противном случае.

Главное понимать, что ваш шаблон управляет вашим приложением. Перестаньте писать большие плагины, которые все делают. Вместо этого напишите небольшие директивы, которые делают одно, а затем напишите простой шаблон, чтобы связать их вместе.

Меньше думайте о ненавязчивом JavaScript и вместо этого думайте о расширениях HTML.

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

Я был так взволнован AngularJS, что написал об этом небольшую книгу, которую вы можете прочитать в Интернете http://nicholasjohnson.com/angular-book/. Надеюсь, это поможет.

Можете ли вы описать необходимый сдвиг парадигмы?

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

С помощью jQuery вы шаг за шагом сообщаете DOM, что должно произойти. С помощью AngularJS вы описываете, какие результаты вы хотите, но не как их сделать. Это. Подробнее об этом здесь. Также ознакомьтесь с ответом Марка Райкока.

Как по-разному проектировать и проектировать клиентские веб-приложения?

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

Какая самая большая разница? Что мне следует прекратить делать / использовать; что я должен начать делать / использовать вместо этого?

jQuery - это библиотека

AngularJS - это красивый, хорошо тестируемый фреймворк на стороне клиента, который сочетает в себе массу интересных вещей, таких как MVC, внедрение зависимостей, привязка данных и многое другое.

Основное внимание в нем уделяется разделению проблем и тестированию (модульное тестирование и сквозное тестирование), что облегчает разработку через тестирование.

Лучше всего начать с их замечательного руководства. Вы можете пройти все этапы за пару часов; однако, если вы хотите овладеть концепциями за кулисами, они включают множество ссылок для дальнейшего чтения.

Есть ли какие-либо соображения / ограничения на стороне сервера?

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

Это позволит вам использовать их фабрику ресурсов, которая создает абстракцию вашего на стороне сервера RESTful API и выполняет вызовы на стороне сервера (получение, сохранение, удаление и т. д.) невероятно просто.

Я думаю, что для описания «смены парадигмы» будет достаточно короткого ответа.

AngularJS меняет способ поиска элементов

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

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

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

Поэтому, когда люди говорят «вообще не включайте jQuery», это в основном потому, что они не хотят, чтобы вы использовали селекторы; они хотят, чтобы вы вместо этого научились использовать директивы. Прямой, а не отборный!

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.

jQuery: вы много думаете о том, чтобы «запросить DOM для элементов DOM и что-то сделать.

AngularJS: Модель - это правда, и вы всегда думаете с этого УГОЛА.

Например, когда вы получаете данные с сервера, которые вы собираетесь отображать в каком-либо формате в DOM, в jQuery, вам нужно '1. НАЙТИ ', где в DOM вы хотите разместить эти данные,' 2. ОБНОВИТЬ / ДОБАВИТЬ », создав новый узел или просто установив его innerHTML. Затем, когда вы захотите обновить это представление, вы увидите: «3. НАЙТИ 'местоположение и' 4. ОБНОВИТЬ'. Этот цикл поиска и обновления, выполняемый в одном контексте получения и форматирования данных с сервера, отсутствует в AngularJS.

С AngularJS у вас есть ваша модель (объекты JavaScript, к которым вы уже привыкли), и значение модели сообщает вам о модели (очевидно) и о представлении, а операция над моделью автоматически распространяется на представление, поэтому вы не не надо думать об этом. Вы обнаружите, что AngularJS больше не находит ничего в DOM.

Другими словами, в jQuery вам нужно подумать о селекторах CSS, то есть о том, где находится div или td, имеющий класс или атрибут и т. Д., Чтобы я мог получить их HTML, цвет или значение, но в AngularJS, вы обнаружите, что думаете вот так: с какой моделью я имею дело, я установлю значение модели равным true. Вы не беспокоитесь о том, является ли представление, отражающее это значение, флажком или находится в элементе 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 в контроллерах или службах, которые должны заботиться о бизнес-логике.

Angular разбивает ваше приложение на - Контроллеры - Сервисы - Представления и т. Д.

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

На встрече, которую я посетил, я слышал, что один из основателей Angular сказал, что они очень много работали, чтобы отделить манипуляции с DOM, поэтому не пытайтесь снова включить их.

Послушайте подкаст JavaScript Jabber: Episode # 32, который включает оригинальных создателей AngularJS: Миско Хевери и Игоря Минара. Они много говорят о том, каково прийти к AngularJS из других фонов JavaScript, особенно из jQuery.

Один из моментов, затронутых в подкасте, заставил меня задуматься о вашем вопросе:

MISKO: [...] одна из вещей, о которых мы очень редко думали в Angular, это то, как мы можем предоставить множество аварийных люков, чтобы вы могли выбраться и, по сути, найти выход из этого . Итак, для нас ответ - это то, что называется «Директивы». А с директивами вы, по сути, становитесь обычным маленьким jQuery JavaScript, вы можете делать все, что хотите.

ИГОРЬ: думайте о директиве как о инструкции для компилятора, которая сообщает ему всякий раз, когда вы сталкиваетесь с этим определенным элементом или этим 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 - если вы хотите внести некоторые изменения в свой пользовательский интерфейс, подумайте с точки зрения изменения данных модели. Измените свои данные, и пользовательский интерфейс будет повторно отображаться. Вам не нужно каждый раз экспериментировать с DOM, если и до тех пор, пока это вряд ли понадобится, и это также должно быть обработано с помощью угловых директив.

Чтобы ответить на этот вопрос, я хочу поделиться своим опытом работы с первым корпоративным приложением с AngularJS. Это самые потрясающие функции, которые предоставляет Angular, когда мы начинаем менять свой образ мышления jQuery и получаем Angular как фреймворк, а не библиотеку.

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

Многоразовые директивы - это супер: записывайте директивы в одном месте и используйте их во всем приложении. МОЙ БОГ!!! Я использовал эту директиву для разбиения по страницам, регулярных выражений, проверок и т. Д. Это действительно круто!

Маршрутизация - это надежный инструмент. То, как вы хотите ее использовать, зависит от вашей реализации, но для маршрутизации запроса с указанием HTML и контроллера (JavaScript) требуется очень мало строк кода.

Контроллеры - это прекрасно. Контроллеры заботятся о своем собственном HTML, но это разделение хорошо работает и для общих функций. Если вы хотите вызвать одну и ту же функцию одним нажатием кнопки в главном HTML, просто напишите одно и то же имя функции в каждом контроллере и напишите индивидуальный код.

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

Идеально подходит для архитектуры RESTful: наличие законченной структуры делает AngularJS отличным работать с RESTful архитектурой. Вызывать REST CRUD API очень просто и

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

Расширяемость: Angular расширил директивы HTML с помощью директив angular. Напишите выражения внутри html и оцените их во время выполнения. Создавайте свои собственные директивы и сервисы и используйте их в другом проекте без каких-либо дополнительных усилий.

Как новичок в JavaScript MV * и сосредоточенный исключительно на архитектуре приложения (а не на стороне сервера / клиента), я бы определенно порекомендовал следующий ресурс (который, к моему удивлению, еще не упоминался): JavaScript Design Patterns, автор Addy Osmani, в качестве введения в различные шаблоны дизайна JavaScript. Термины, использованные в этом ответе, взяты из связанного выше документа. Я не собираюсь повторять то, что было хорошо сформулировано в принятом ответе. Вместо этого этот ответ ссылается на теоретические основы, которые используются в AngularJS (и других библиотеках).

Как и я, вы быстро поймете, что AngularJS (или Ember.js, Durandal и другие фреймворки MV * для этого материя) - это один сложный фреймворк, объединяющий множество различных шаблонов проектирования JavaScript.

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

Например:

• Объектно-ориентированное программирование JavaScript (это ссылка на поиск Google). Это не библиотека, но, безусловно, необходимое условие для любого прикладного программирования. Он научил меня нативным реализациям шаблонов прототип, конструктор, синглтон и декоратор.
• jQuery / подчеркивание для паттерна фасада (например, WYSIWYG для управления DOM)
• Prototype.js для шаблона прототипа / конструктора / миксина.
• RequireJS / Curl.js для шаблон модуля / AMD
• KnockoutJS для наблюдаемого шаблона публикации / подписки.

NB: Этот список не является полным и «лучшими библиотеками»; это просто библиотеки, которые я использовал. Эти библиотеки также включают в себя больше шаблонов, упомянутые являются лишь их основными целями или первоначальными намерениями. Если вы чувствуете, что чего-то не хватает в этом списке, укажите это в комментариях, и я буду рад добавить это.

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

Обычно я разрабатываю мобильные приложения с использованием AngularJS и Cordova. ЕДИНСТВЕННАЯ вещь из jQuery, которая мне нужна, - это Селектор.

Погуглив, я вижу, что существует отдельный модуль селектора jQuery. Это Sizzle.

И я решил сделать крошечный фрагмент кода, который поможет мне быстро запустить веб-сайт с использованием AngularJS с мощью jQuery Selector (с использованием Sizzle).

Я поделился своим кодом здесь: https://github.com/huytd/Sizzular