Angular *

Настройка роутинга в Angular JS — не самая сложная штука. Поэтому я лишь предлагаю одно из возможных решений, которое поможет вам придерживаться принципа “don't repeat yourself” при работе с маршрутами.

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

Демка, песочница (с демкой играются многие, так что данные могут скакать)

Как видно из примера, у нас проблема: куча списков со схожей функциональностью (добавление, удаление, сортировка элементов — что еще может быть у списков :-).

Ангуляр поставляется с различными видами служб или сервисов, каждый из которых применяется в своей ситуации.
Имейте в виду, что сервисы, не зависимо от типа, это всегда синглтоны (одиночки).

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

Перейдем к типам сервисов

Одной из ключевых составляющих практически любого веб-приложения является взаимодействие с сервером. В больших приложениях это далеко не один запрос. При этом запросы часто необходимо объединять для последовательного или параллельного выполнения, а часто сочетать и то и другое. Кроме того, большие приложения обычно имеют многослойную архитектуру — обертка над RESTFul API => бизнес-сущности => более комплексная бизнес-логика (разбиение условно для примера). И на каждом слое необходимо принять данные в одном формате и передать на следующий слой уже в другом.

Вот со всеми этими задачами могут помочь справиться Promise-ы.

За подробностями добро пожаловать под кат.

В AngularJS, как известно, нет возможности штатными средствами сделать многоуровневую маршрутизацию, в которой перезагрузка нижних уровней маршрутов бы не приводила к пересозданию элементов верхнего уровня. Стандартный сервис $route инициализирует вид, контроллер и его scope целиком каждый раз, когда изменяется URL страницы.

Для решения этой проблемы написано несколько сторонних решений, включая известный ui-router. По ряду причин ни одно из решений для некоторых моих проектов не подошло, и я написал собственную библиотеку, которую здесь и представляю: angular-route-segment.

Что она позволяет делать?

При запуске своего кода внутри контроллера или сервиса не приходится беспокоиться о вызове $apply(), поскольку код выполняется внутри контекста Ангуляра. Под этим подразумевается, что Ангуляр понимает, что ваш код находится в процессе выполнения и выполнит грязную проверку (dirty-check) после завершения его работы. Когда же вы находитесь внутри директивы, мировоззрение Ангуляра чуть более ограничено; теперь директива должна заботиться о вызове $apply() (или вызове $apply() с чем-то вроде $timeout), когда необходимо сообщить Ангуляру об изменениях в модели представления (т. е. $scope). Однако, определить когда это нужно делать, немного сложнее, потому что некоторые аспекты директивы фактически выполняются внутри контекста Ангуляра.

Если вы уже создавали свои собственные директивы, можно не сомневаться, что видели одно из двух сообщений:

$apply is already in progress.
$digest is already in progress.

Перевод статьи Александра Хилла CoffeeScript and AngularJS. Это мой первый перевод и буду рад получить любые замечания и исправления.

AngularJS и CoffeeScript это отличная комбинация, не смотря на то, что CoffeeScript не пользуется большой популярностью в комьюнити AngularJS. В статье будут представлены несколько приемов, которые «облегчат» ваш код на AngularJS.

Добрый день уважаемые, хабрачеловеки.
В данной статье я хочу поделиться с вами своим опытом работы с такими фреймворками как AngularJS и Knockout.
Cтатья будет интересна тем, кто хорошо знаком с JavaScript-ом и имеет представление хотя бы об одном из упомянутых фреймворков и естественно желает расширить свой кругозор.

Здравствуйте. Признаюсь честно, я пишу тесты редко. Т.е хотел бы чаще, но все как-то не получается. Вроде и руководство в принципе не против даже, но все равно находятся задачи посрочнее и поважнее. Тем не менее на днях заглянув в redmine обнаружил что задач практически нет (точнее они были, но требовали сперва дождаться бэкэнда).
Что ж, самое время вспомнить про тесты (конечно нужно было раньше о них думать, но лучше поздно чем никогда).
Вообще я до этого уже пробовал писать тесты, в том числе и на бэкэнде, а конкретно django. Я еще тогда подумал что было бы здорово запускать тесты из консоли а не в окне браузера. Ну а поскольку с недавнего времени я активно слежу за развитием angular, то почему бы не посмотреть как это сделано у них. Тем более как-то краем глаза я зацепил момент, что там тесты как раз запускаются в консоли. Плюс к тому же с нуля разбираться в премудростях тестирования не хотелось и я решил взять какой нибудь готовый проект с тестами, посмотреть как оно сделано, и погонять собственно тесты на нем. Мой выбор пал на angular-ui, а точнее на один из его модулей ui-utils.

Скачиваем, заходим в корень видим папку test а в ней файл karma.conf.js
Да и в самом ридми написано, что тесты запускаются так karma start —browsers ….
Гуглим karmajs и находим то что нам нужно karma-runner.github.io/0.8/index.html
Утилита для тестирования. Итак что она может?

• Запускать тесты из консоли
• Автоматически прогонять все тесты при каждом сохранении!!!
• Возможность писать тесты на множестве фреймворков, таких как jasmine, qunit и др.
• Прогонять тесты сразу на нескольких браузерах. (в том числе виртуальных, например fantomjs).

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

Большинство web-приложений и web-фреймворков используют архитектуру, не позволяющую разделить ui и backend разработку. Тем самым нет возможности разделить команду на узкоспециализированных frontend и backend разработчиков. Вне зависимости от предпочтений разработчика ему приходится иметь понимание как о слое представления, так и о слое логики. Если ui-разработчик знает только о том, как запустить сервер, и о модели данных — это огромная удача. В плохих случаях ui-разработчику необходимо провести полную сборку проекта чтобы увидеть изменения строчки в javascript файле, или знать о языке jsp файлов чтобы поменять стиль элемента. Формирование и передача на сервер обработанных html файлов так-же пагубно влияет на производительность сервера и сети.

Недавно я перешел с knockout.js на angular.js, оба инструмента мне нравятся, но в каждом из них есть свои преимущества перед «конкурентом».
И тут выпал скучный вечер, решил я, just for fun, слепить свой MV* инструмент.

Мне не очень нравятся разухабистые фреймворки, я отдаю предпочтение библиотекам, и от angular мне в основном нужно было 2 вещи: scope — данные и их мониторинг, applyBindings — привязать этот scope к DOM.

В Ангуляре, дочерняя область видимости обычно прототипически наследуется от родительской. Единственным исключением является директива, в которой используется scope: { ... }, создающая «изолированную» область видимости, не наследуемую прототипически. Такая конструкция часто используется при создании директив для компонентов «многоразового использования»

Документация по Ангуляру отлично подходит для начала работы и ковыряния в API. Однако, она не объясняет как организовать и управлять приложением, когда оно разрастется до десятков или сотен тысяч строк кода. Я собрал здесь некоторые из моих наблюдений и передового опыта по управлению расползающимися приложениями. Сначала взглянем на организацию, затем перейдем к некоторым советам по улучшению производительности и закончим краткой сводкой по инструментам, серверам и процессу сборки. Этот пост будет сосредоточен на больших приложениях, в частности, есть отличная статья по лучшим практикам AngularJS с декабрьской встречи, на которую также стоит взглянуть.

По мотивам этой трансляции.

Вместо предисловия скажу, что есть такой сайт yeoman.io, где собраны наиболее популярные технологии, автоматизирующие разработку фронтенда (сборку, параметризацию CSS и проч.). Обратите на него внимание в начале работы над проектом.

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

Новички в Ангуляре часто путаются из-за того, что быстрые функции $http-сервиса (напр., $http.post()) не взаимозаменяемы с эквивалентными функциями Джиквери (напр., jQuery.post()), не смотря на то, что соответствующие руководства описывают их использование схожим образом. То есть, если код в Джиквери до этого имел вид:

Как упоминалось ранее, Ангуляр предоставляет класс $resource для повышения уровня абстракции между кодом на стороне клиента и серверным API. Поэтому теперь выполнять операции CRUD по сети довольно легко. Но что происходит, когда необходимо выполнить команду для RESTful ресурса, что выходит за пределы стандартных методов CRUD (т. е. создания, чтения, обновления, удаления)? К счастью, Ангуляр достаточно хорошо работает с RESTful «контроллерами».

От переводчика: Думаю, что статьи по архитектуре приложения и организации кода наиболее важны на начальном этапе, т. к., в отличие от всего остального, основу приложения поменять очень трудно. [Оригинал статьи]

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

После года работы с большим проектом на AngularJS, думаю поделиться некоторыми, извлеченными в процессе, уроками. Во-первых, мне нравится Ангуляр. Он отлично удовлетворяет моим потребности и, думаю, полностью перейти на него в обозримом будущем, когда мне потребуется надежный фреймворк для одностраничного «толстого клиента». Он потрясающий. Над ним работает команда мирового уровня, сообщество фантастическое, и он содержит (или предлагает сообщество) целый комбайн функций для создания веб-приложений.

Вчера разработчики выкатили новую (пока еще не стабильную) версию. Основные изменения:

$animator:
добавлена поддержка пользовательских событий анимации [щелк]
добавлена возможность глобально отключать и включать анимацию [щелк]

$http:
добавлена возможность прервать запрос при выполнении обещания (объекта promise) [щелк]
добавлен заголовок по умолчанию для PATCH запросов
добавлена поддержка таймаута для JSONP запросов

$parse: добавлена поддержка тернарного оператора (exp1? exp2: exp3)