javascript - применение - почему angular




«Мышление в AngularJS», если у меня есть фон jQuery? (10)

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

Императивный против декларативного

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

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

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

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

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

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

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

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

Существуют ли какие-либо соображения / ограничения на стороне сервера?

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

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

Предположим, что я знаком с разработкой клиентских приложений в 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 с набором обратных вызовов и $apply s, которые запутывают и запутывают; но в итоге они работают! Проблема в том, что в большинстве случаев плагин 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 class="main-menu" dropdown-menu>
    ...
</ul>

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

Разработчики, новые для AngularJS, часто задают такой вопрос, как: как найти все ссылки определенного типа и добавить на них директиву. Разработчик всегда ошеломлен, когда мы отвечаем: вы этого не делаете. Но причина, по которой вы этого не делаете, это то, что это похоже на half-jQuery, half-AngularJS и ничего хорошего. Проблема здесь в том, что разработчик пытается «выполнить jQuery» в контексте AngularJS. Это никогда не будет хорошо работать. Представление - официальная запись. Вне директивы (подробнее об этом ниже) вы никогда и никогда не меняете DOM. И директивы применяются в представлении , поэтому намерение ясно.

Помните: не разрабатывайте, а затем отмечайте. Вы должны архитектовать, а затем проектировать.

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

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

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

Для представления, которое выглядит так:

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

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

Это немного грязно и мелочь. Но в AngularJS мы можем это сделать:

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

И наш взгляд может выглядеть так:

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

Но в этом отношении наш взгляд может выглядеть так:

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

И вместо того, чтобы использовать неупорядоченный список, мы используем ботстрап-оповещения. И нам никогда не приходилось менять код контроллера! Но что более важно, независимо от того, где и как журнал обновляется, вид тоже изменится. Автоматически. Ухоженная!

Хотя я не показал его здесь, привязка данных является двусторонней. Таким образом, эти сообщения журнала также могут быть доступны для редактирования в представлении, только делая это: <input ng-model="entry.msg" /> . И было много радости.

Отличный модельный слой

В jQuery DOM похож на модель. Но в AngularJS у нас есть отдельный слой модели, который мы можем управлять любым способом, который мы хотим, полностью независимо от представления. Это помогает для вышеуказанного связывания данных, поддерживает разделение проблем и дает гораздо большую возможность проверки. Другие ответы упомянули этот момент, поэтому я просто оставлю это.

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

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

Внедрение зависимости

Чтобы помочь нам разобраться в проблемах, это инъекция зависимостей (DI). Если вы используете серверный язык (от Java до PHP ), вы, вероятно, уже знакомы с этой концепцией, но если вы являетесь клиентским парнем из jQuery, эта концепция может показаться от глупых до избыточных до хипстеров , Но это не так. :-)

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

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

Говоря об испытаниях ...

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 программно показывают или скрывают элемент; и многие другие - включая те, которые мы пишем сами. Другими словами, мы можем делать всевозможные awesomeness без 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 и наш компонент по-прежнему будет работать, когда вы 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

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. Представления (декларативные) HTML, содержащие директивы AngularJS. Директивы настраивают обработчики событий за кулисами для нас и дают нам динамическую привязку данных. Селекторы редко используются, поэтому потребность в идентификаторах (и некоторых типах классов) значительно уменьшается. Представления привязаны к моделям (через области). Представления - это проекция модели. Модели изменения событий (т. Е. Данные, свойства области) и представления, которые проектируют эти модели, обновляются автоматически.

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

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

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

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

См. Также https://.com/a/14346528/215945

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

Один подход к разработке приложения AngularJS:

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

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

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


jQuery - это библиотека манипулирования DOM.

AngularJS - это структура MV *.

Фактически, AngularJS является одной из немногих инфраструктур JavaScript MV * (многие инструменты JavaScript MVC по-прежнему попадают под категорию библиотеки).

Будучи основой, он размещает ваш код и принимает на себя ответственность за решения о том, что звонить и когда!

Сам AngularJS включает в себя jQuery-lite edition. Поэтому для некоторых базовых DOM-подборов / манипуляций вам действительно не нужно включать библиотеку jQuery (она экономит много байтов для работы в сети).

У AngularJS есть концепция «Директив» для манипуляций с DOM и разработки многоразовых компонентов пользовательского интерфейса, поэтому вы должны использовать их всякий раз, когда вам кажется, что вам нужно делать манипуляции с DOM (директивы - это только место, где вы должны писать код jQuery при использовании AngularJS).

AngularJS включает в себя некоторую кривую обучения (больше, чем jQuery :-).

-> Для любого разработчика, исходящего из фона jQuery, моим первым советом было бы «изучить JavaScript как язык первого класса, прежде чем переходить на богатую инфраструктуру, такую ​​как AngularJS!» Я усвоил этот факт.

Удачи.


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

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

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

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

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

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


jQuery: вы много думаете о «QUERYing the DOM » для элементов DOM и что-то делаете.

AngularJS: Модель - это правда, и вы всегда думаете об этом ANGLE.

Например, когда вы получаете данные с сервера, который вы собираетесь отображать в некотором формате в DOM, в jQuery вам нужно «1. FIND ', где в DOM вы хотите разместить эти данные, «2. UPDATE / APPEND 'там, создав новый узел или просто установив его 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 основой, а не библиотекой.


Будучи новичком 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 для шаблона prototype / constructor / mixin
  • RequireJS / Curl.js для шаблона модуля / AMD
  • KnockoutJS для наблюдаемой, публикации / подписки шаблона

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


Слушайте подкаст JavaScript Jabber: Episode # 32, в котором представлены оригинальные создатели AngularJS: Misko Hevery & Igor Minar. Они много говорят о том, что это такое, чтобы прийти в AngularJS из других фонов JavaScript, особенно jQuery.

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

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

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

Стенограмма всего эпизода доступна по ссылке, приведенной выше.

Итак, чтобы прямо ответить на ваш вопрос: AngularJS - очень самоуверенный и является истинным MV * framework. Тем не менее, вы все равно можете сделать все действительно классные вещи, которые знаете и любите с помощью jQuery внутри директив. Это не вопрос «Как мне сделать то, что я использовал в jQuery?» насколько это важно: «Как я могу дополнить AngularJS всем, что я использовал в jQuery?»

Это действительно два совершенно разных состояния ума.


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

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

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

Угловое разбивает ваше приложение на - Контроллеры - Услуги - Виды - и т. Д.

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

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





angularjs