Что самое неудобное в сборщиках проекта? Правильно! То, что нужно сборку писать самому. Изучать grunt/gulp/webpack, шаманить с плагинами, думать, как разбить конфиг на модули, когда он вырастает до нескольких сотен строчек, потом несколько месяцев радоваться, что всё работает, а когда в проекте появляется критическое изменение, опять лезть в это болото.

Мне тоже всё это порядком надоело, поэтому написал сборщик, лишенный этих недостатков. Его gulpfile.js выглядит так:

var gulp = require('gulp');
var arjs = require('arjs-builder')();

gulp.task('build', arjs.build);
gulp.task('test', arjs.test);
gulp.task('default', arjs.run);

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

gulp #компилит, поднимает локальные серверы
gulp build #билдит проект
gulp test #запускает тесты

Открываете localhost:7000 и наслаждаетесь локальной версией сайта, а в папке build
уже лежит сбилженная версия.

— А как же темплейты, их же надо в js внедрять?
— Конечно! Все внедрено как положено.
— А я стили пишу на less, sass, stylus, их же надо компилить?
— Пишите как писали, всё чудесным образом будет работать.
— А картинки в CSS инклудить?
— Так давно всё в CSS. All included как в пятизвездочном отеле.
— А разбить сбилженный файл на модули?
— Проверьте папку build. Всё по модулям? С уникальными именами, основанными на содержимом файла? Вот, а вы волновались!
— А вот еще там что-то…
— И это тоже работает.

Но как такое возможно? Это мы и рассмотрим в статье. А в конце еще расскажу, почему всё-таки RequireJS

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

Та-дам! (и забавная история вконце)

Немного о контроллерах директив. Зачем они нужны и чем отличаются от функции link.

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

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

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

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

Про директивы много написано, но мало о том как писать их правильно. Поделюсь опытом.

Хорошо написанная директива должна

• решать одну задачу
• легко расширяться
• не конфликтовать с другими директивами

Разберем каждый пункт на примере поля для ввода пароля (думаю, всем знакомо поле с глазиком)

<input ng-model="user.password"
       ng-minlength="6"
       form-password
       form-error="Не менее 6 символов">

Сколько директив используется?

Мишко Хевери, главный разработчик Ангуляра, как-то упомянул, что приложение гарантированно работает без тормозов, если в нем не более 100 активных областей видимости. Такой подход, в общем, применим к любым приложениям. В играх давно не рендерят то, чего игрок не видит и только в вебе пока еще считается нормой отобразить целиком список из нескольких тысяч элементов. С приходом js-фреймворков ситуация должна измениться и лучшим решением станет удаление из DOM того чего нет на экране, нежели отказ от промежуточных тегов, биндингов и других вещей, облегчающих разработку. Поэтому провел небольшой анализ решений для отображения больших списков. Наткнулся на пару статей:

1. The Infinite Path of Scrolling

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

Долгожданный выпуск AngularJS 1.2.0 готов. Ущипните себя, это не сон.

В AngularJS 1.2.0 исправлено множество проблем, найденных в 1.2.0-RC3, и введено несколько новых функций.

Со времени последнего стабильного релиза, наиболее заметными изменениями являются:

Давно писал модуль для загрузки файлов и всё он был не идеальным. И тут подумал, если сейчас не опубликую, то никогда не опубликую, идеал-то не достижим!

При составлении АПИ руководствовался принципом — как можно проще. Поэтому сначала несколько мыслей о загрузке файлов:

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

Загрузка каждого файла отдельным запросом. На любом хостинге существует ограничение на максимальный размер POST-запроса (напр., 10 МБ). Если мы грузим одновременно 10 файлов, значит их вес в сумме не должен превышать 10МБ. В 99% случаев проще пожертвовать производительностью и не иметь проблем с такими ограничениями.

Никаких отложенных загрузок. Файл должен загружаться сразу после добавления (не в 2000 году, чай, живем), поэтому никаких методов работы с очередью — выбрал файл, выбрал еще 5 штук, удалил один, нажал «отправить» — не будет. Зато будет отмена загрузки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Интерес к Javascript MV* фреймворкам вызвал их подъем. Meteor, Ember, Angular, and Backbone, все они действительно популярны на Github. Измерить популярность довольно сложно, но хорошим показателем может быть количество Github-фоловеров. Используя данные из Github-архива, можно продемострировать это визуально (с помощью запроса на BigQuery и некоторых других скриптов).

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

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

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

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

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