Angular *

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

Поиск и якорь

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

Что ж, задание понятно. Приступаем.

Эта статья будет описывать решение одной конкретной задачи, а также на примере показывать как работает $transclude.

Задача такая: сделать директиву, обертку для select-а. Предположим, что мы хотим одним тегом добавлять сразу и селект и label к нему (потом можно будет туда добавить ошибки заполнения, но мы для простоты не будем этого делать). В общем то, на первый взгляд выглядит все просто.

Сделаем директиву и назовем ее field. Использовать будем так:

<field title="Цвет" type="select" ng-model="selectedColor" options="color.id as color.name for color in colors"></field>

Во время разработки проектов мы полюбили AngularJs. Но также мы встретили некоторые трудности в борьбе за чистоту модульности, с которой AngularJs справляется хорошо, но все же порой ему чего-то не хватает. RequireJs оказывается полезным там, где AngularJs оставляет желать лучшего, но использование их вместе — не совсем тривиальная задача.

Итак, опишем наш взгляд на решение проблемы.

Для чего?

Работая с AngularJs вы обязательно задумаетесь о правильной организации кода. Конечно уже существуют отличные примеры решения проблемы. Например можно изучить теоретический пост Брайана Форда или практическое руководство Клиффа Мейерса. Я же поделюсь способом организации кода в приложениях AngularJs с использованием RequireJs.

Данный подход будет полезен, если вы хотите:

• перестать беспокоиться о подключении скриптов в правильном порядке;
• загружать javascript код асинхронно;
• иметь возможность скомпилировать код в один минифицированный JS-файл;

Не так давно я уже писал про поведение ng-if директивы, но тогда я столкнулся с проверкой условия, но сегодня возникла другая проблема.

В проекте достаточно много таких элементов как tooltip, popover, modal windows и так далее. Думаю, все вы понимаете, что это за элементы и рассказывать про них я не буду. Для многих из них используется абсолютное позиционирование. Если бы мы не использовали кастомные директивы, то проблем бы не было — все модальные окна лежали бы в конце body и показывались бы когда нужно. Но так, как все эти элементы объявлены как директивы, возникает проблема с позиционированием, так как у директивы может быть родитель с относительным позиционированием и так далее.

<div style="position: relative; overflow:hidden">
  <button ng-click="visible = true">Greeting</button>

  <modal visible="visible">
      Hello, Habr!
  </modal>
</div>

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

Начнем с простого примера. Создадим страницу с информацией о книге. Контроллер:

В проекте используется angularjs, проект уже достаточно большой, используем очень много кастомных директив, но сегодня столкнулся с проблемой поведения ng-if .

Для меня было ожидаемо, что условие работает так же как и в js, то есть:

if (condition) {
 ...
} else {
 ....
}

В зависимости, что передано — элемент будет скрыт или показан.

После публикации статьи «Яндекс.Карты для angular.js утекло немало воды, а также появились новые возможности. В настоящий момент в модуль angular.js для использования карт „Яндекса“ на ваших страницах добавлена поддержка версии 2.1 yandex map api. Не скажу, что суть модуля сильно поменялась, но все же некоторые изменения были внесены. Хотите знать какие, добро пожаловать под кат.

Магия AngularJS: никогда не вешайте binding на примитивы

Если вы используете AngularJS, скорее всего вы неоднократно сталкивались с правилом «Не вешайте binding на примитивы». В этом посте я подробно разберу пример, в котором использование примитивов создает проблемы: создание списка элементов , в котором каждый из элементов привязан к строке.

Наш пример

Скажем, вы работаете над приложением с книгами, и у каждой книги есть список тегов. Наивным способом предоставления пользователю возможности редактировать теги будет:

<div ng-controller="bookCtrl">
    <div ng-repeat="tag in book.tags">
        <input type="text" ng-model="tag">
    </div>
</div>

5 причин использовать AngularJS в вашем корпоративном приложении

Нынешнюю ситуация в мире корпоративных приложений можно описать одним словом: хаос.

Начиная с устаревшего кода, который в течении N лет переходил от разработчика к разработчику без всякой документации. До слишком сложных интерфейсов, которые слишком усложняют код. До смешивания вместе N технологий в одном единственном приложении. Посмотрим фактам в лицо: когда эти вещи создавались, никто не задумывался об их поддержке. Сегодня мы столкнулись с проблемой – как исправить все эти приложения? С чего начать? Как привнести в них здравый смысл? Как привести их к современному технологическому стеку?

Данный пост будет посвящён вопросу сборки Angularjs приложений. Я рассмотрю возможные пути решения и объясню, почему в итоге решил написать несколько собственных плагинов.

Итак, а как вообще принятно решать проблему сборки в последнее время? Grunt/Gulp плагины, require.js, browserify — самые популярные варианты.

Но есть нюанс. Когда вы имеете дело с Angular-приложением, вы сталкиваетесь с необходимостью декларирования зависимостей между модулями для их правильной сборки. Поясню на примере.

Если у вас простейшее приложение, которое состоит из нескольких файлов:

app.js
controllers.js
services.js
directives.js
filters.js

То никаких проблем нет. Вы можете вручную прописать порядок их подключения в том же Grunt/Gulp.

Но, допустим, если вы захотите реализовать такую архитектуру, при которой каждый отдельный сервис, контроллер, директива и т. д. находятся в отдельных файлах, то есть:

app.js
controllers/
	FirstCtrl.js
	SecondCtrl.js
services/
	FirstSrv.js
	SecondSrv.js

То вы столкнётесь с рядом трудностей. Главным образом, трудности будут с тем, как сшить все файлы так, чтобы при этом Angular работала без ошибок. Итак, что можно сделать?

Всем привет!

Пару дней назад мне на почту пришло письмо от Codeschool.com, в котором очень красочно (как можно заметить из картинки в шапке поста) представлялся новый курс по AngularJS. Т.к. платной подписки у меня сейчас нет, я решил отложить просмотр до лучших времён, а сегодня случайно узнал, что курс оказывается «Sponsored by Google», а соответственно бесплатный. Закончив работу над первым уровнем, я поспешил проверить наличие заметки об этом чудном событии на Хабре, но с удивлением обнаружил, что никто до сих пор не поделился этой новостью. Значит придётся взять всё в свои руки.

В дополнение к этому посту.

Кто не знает, есть такая штука ui-router. Замена стандартного роутера Ангуляра. Учитывая, что в Ангуляре 2.0 планируют запилить нечто подобное, вскоре этот роутер станет стандартом.

С помощью него можно строить приложение, например, так:

Нашёл любопытный инструмент для облегчения структуры контроллеров — Angular Classy. Он представляет из себя модуль, размером в 1 килобайт (gzipped and minified), и помимо представления контроллера в виде объекта даёт ряд полезных плюшек, рассказ о которых под катом.

Как-то давно переводил статью «Понимание типов сервисов в AngularJS (constant, value, factory, service, provider)». На практике, конечно, не всё пригождается, поэтому в рамках понижения порога вхождения в Ангуляр, объясню проще.

В процессе использования angular.js трудно обойтись без объекта $q (он же promise/deferred), ведь он лежит в основе всего фреймворка. Deferred механизм является очень простым и мощным инструментом, который позволяет писать лаконичный код. Но чтобы по-настоящему использовать эту мощь, необходимо знать обо всех возможностях данного инструмента.
Вот несколько моментов, о которых вы возможно не знали.

Давным-давно

Раньше все писали много отвратительного JS прямо на страницах, не вдумываясь, и это было очень плохо. Подозреваю, его и до сих пор так пишут, но это делают всё те же люди, которые ни блогов, ни хабра не читают, так что давайте мы не будем о них думать (потом нам, конечно, придётся оказаться с ними в одном проекте и — господи, нет, пожалуйста, только не это)

Самое крутое, классное и волшебное, что было в JS — это то, что никто в больших организациях не хотел с ним иметь дела, оставаясь в своём спокойном мире прекрасно организованных слоёв абстракций из фабрик и волшебных фреймворков инъекций XML.

И это было отлично для тех, кто, как я, хотел получать зарплату больших организаций, не залезая в слои отвратительных «лучших практик» и проблем с производительностью, возникающих из-за неконтролируемого страха давать доступ к базе данных хоть кому-нибудь, кроме DBA.

Мало того, когда все эти проблемы с производительностью возникали, мы могли всех спасти, написав на JS фронтэнд, который делал вид, что никаких проблем не существует и всё это прекрасно работало, несмотря на тоскливое качество бэкэнда.

Мы достигли расцвета JS

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

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

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

В последнем обновлении COLT 2.0 Beta 7 мы добавили еще одну новую фичу для Angular.js

Теперь когда вы будете менять функцию, описывающую вашу директиву Angular, директива будет обновлен в DOM (заново скомпилирована).

Посмотрите видео-демонстрацию:

Раньше автокомлит работал только в JS — в запущенном приложении COLT находил нужный объект и смотрел его структуру. Теперь внутри {{}} и атрибутах директив в списке автокомплита появился выбор всех поля и методов из текущего $scope.

У Emmet есть классная команда — инкрементировать значение в JS/HTML/CSS с шагом 1, 0.1, 10.
При запуске livecoding сессии COLT и новой фичей рекомпиляциии Angular директив на лету, получается настоящий визуальный редактор прямо в браузере.

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

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