По мотивам этой трансляции.
Вместо предисловия скажу, что есть такой сайт yeoman.io, где собраны наиболее популярные технологии, автоматизирующие разработку фронтенда (сборку, параметризацию CSS и проч.). Обратите на него внимание в начале работы над проектом.
Некоторое количество разработчиков считают, что директивы захламляют HTML, так же им тяжело изменить старые привычки. Стоит заметить, что директивы существуют в HTML с незапамятных времен. Это всем хорошо знакомые элементы формы: поля ввода, радиокнопки, выпадающие списки и проч. Другое дело, что сделаны они «чтобы отстали». Эту проблему и решает Ангуляр.
Сравним обычный чекбокс
и чекбокс в Ангуляре
Что проще?
Думаю, многие в начале знакомства с HTML недоумевали почему подобного нет в стандартном варианте, почему чекбокс возвращает
Так вот, Ангуляр просто заставляет вести существующие интерактивные элементы понятным образом, унифицирует связь элементов с данным модели и на этой основе дает возможность создавать какие угодно собственные элементы управления, не дожидаясь прихода HTML5, HTML6 или HTML8.
Теперь рассмотрим директиву, аналогов которой в HTML нет
На лицо использование логики в тегах. На самом деле это не совсем так. Основная логика, а она гораздо сложнее, упакована в скрипт, описывающий директиву. В атрибут вынесен только интерфейс взаимодействия. Разработчики Ангуляра полагают (и с ними сложно не согласиться), что разметка должна говорить не только о том, КАКИЕ элементы расположены на странице, но так же о том, ЧТО они делают. А описание того КАК они это делают — удел скрипта.
Разумеется, в директиву можно запихать и сложную логику. Можно, вообще, практически любое поведение организовать из набора стандартных директив. Иногда это оправдано, особенно, когда нужно что-то сделать быстро, но Ангуляр не пропагандирует на 100% такой подход.
Все уже знают, что директивы можно записывать несколькими способами
Так вот, наиболее предпочтительный (близкий к идеологии) первый способ. В ряде случаев (например, для директив, подобной ng-repeat, или для совместимости, в т.ч. психологической) — второй. Третий сделан просто так. Четвертый необходим, чтобы обойти ограничения HTML, например поместить что-либо отличное от
Другими словами, как сделать загрузку страницы более гладкой для пользователя.
Во-первых, размещайте ангуляровские скрипты в конце страницы, чтобы пользователь не смотрел на белый экран, пока они грузятся.
Во-вторых, обратите внимание на директиву
На самом деле, в большинстве простых случаев проблем с мерцанием попросту не возникает.
Контроллеры описывают поведение вида, т.е. отвечают на вопросы, что произойдет, если нажать на кнопку Х и где проводить работу с данными Х. Для каждого вида приложения создается отдельный экземпляр контроллера. В контроллерах ни в коем случае нельзя проводить манипуляции с DOM. Работа с DOM производится только в директивах.
Сервисы содержат основную логику и отвечают на вопрос что и как делает Х. В отличие от контроллеров, сервисы это синглтоны, т. е. во всем приложении может существовать только один экземпляр сервиса. В них так же не стоит работать с DOM, но иногда можно, например, если необходимо сделать глобальное диалоговое окно и т. п. В любом случае, использование DOM-манипуляций в сервисах необходимо ограничить.
Из всего вышесказанного можно определить стратегию борьбы с говнокодом. Во время экспериментов, авралов и проч. простая логика может писаться прямо в HTML, по мере усложнения её необходимо переносить в отдельные директивы и контроллеры. Далее вся, не относящаяся к представлению логика, выносится в сервисы. Получается своего рода локальный рефакторинг.
Область видимости связывает вид с контроллером. Она предназначена только для чтения в шаблонах (виде) и только для записи в контроллерах.
Не стоит путать область видимости с моделью. Область видимости это ссылка на модель. Поэтому неправильно записывать параметры модели в область видимости напрямую. Необходимо создать один параметр и поместить туда модель.
Разница в этих подходах наглядно демонстрируется в этом видео, а так же в первом примере (см. комментарии в коде).
Соответственно, обращение к модели в директивах чаще всего будет выглядеть так:
Вместо предисловия скажу, что есть такой сайт yeoman.io, где собраны наиболее популярные технологии, автоматизирующие разработку фронтенда (сборку, параметризацию CSS и проч.). Обратите на него внимание в начале работы над проектом.
Использование директив
Некоторое количество разработчиков считают, что директивы захламляют HTML, так же им тяжело изменить старые привычки. Стоит заметить, что директивы существуют в HTML с незапамятных времен. Это всем хорошо знакомые элементы формы: поля ввода, радиокнопки, выпадающие списки и проч. Другое дело, что сделаны они «чтобы отстали». Эту проблему и решает Ангуляр.
Сравним обычный чекбокс
<input type="checkbox" name="option1" value="a1" checked>
и чекбокс в Ангуляре
<input type="checkbox" ng-model="myModel">
Что проще?
name/id/class можно не указывать, потому что директивы не привязываются по имени. Начальное состояние задается моделью, поэтому checked не имеет смысла. Но это еще не всё. Последний код можно переписать и так<input type="checkbox" ng-model="myModel" ng-true-value="on" ng-false-value="off" ng-change="change()">
Думаю, многие в начале знакомства с HTML недоумевали почему подобного нет в стандартном варианте, почему чекбокс возвращает
on или пустоту, а не true и false, почему можно изменить только значение on и много других почему.Так вот, Ангуляр просто заставляет вести существующие интерактивные элементы понятным образом, унифицирует связь элементов с данным модели и на этой основе дает возможность создавать какие угодно собственные элементы управления, не дожидаясь прихода HTML5, HTML6 или HTML8.
Теперь рассмотрим директиву, аналогов которой в HTML нет
<ANY ng-repeat="book in books">
На лицо использование логики в тегах. На самом деле это не совсем так. Основная логика, а она гораздо сложнее, упакована в скрипт, описывающий директиву. В атрибут вынесен только интерфейс взаимодействия. Разработчики Ангуляра полагают (и с ними сложно не согласиться), что разметка должна говорить не только о том, КАКИЕ элементы расположены на странице, но так же о том, ЧТО они делают. А описание того КАК они это делают — удел скрипта.
Разумеется, в директиву можно запихать и сложную логику. Можно, вообще, практически любое поведение организовать из набора стандартных директив. Иногда это оправдано, особенно, когда нужно что-то сделать быстро, но Ангуляр не пропагандирует на 100% такой подход.
Все уже знают, что директивы можно записывать несколькими способами
<my-dir></my-dir>
<span my-dir="exp"></span>
<span class="my-dir: exp;"></span>
<!-- directive: my-dir exp -->
Так вот, наиболее предпочтительный (близкий к идеологии) первый способ. В ряде случаев (например, для директив, подобной ng-repeat, или для совместимости, в т.ч. психологической) — второй. Третий сделан просто так. Четвертый необходим, чтобы обойти ограничения HTML, например поместить что-либо отличное от
<td> в тег <tr>. Так же для лучшей совместимости со старыми браузерами рекомендуется начинать имя директивы с какого-либо префикса (напр., my-). Для валидаторов можно добавлять к именам префиксы x- или data- (они будут отброшены Ангуляром).Борьба со вспышками
Другими словами, как сделать загрузку страницы более гладкой для пользователя.
Во-первых, размещайте ангуляровские скрипты в конце страницы, чтобы пользователь не смотрел на белый экран, пока они грузятся.
Во-вторых, обратите внимание на директиву
ng-cloak, которая скрывает шаблон до полной его обработки Ангуляром, а так же используйте ng-bind вместо выражения в фигурных скобках {{ }}.На самом деле, в большинстве простых случаев проблем с мерцанием попросту не возникает.
Отличие контроллеров от сервисов
Контроллеры описывают поведение вида, т.е. отвечают на вопросы, что произойдет, если нажать на кнопку Х и где проводить работу с данными Х. Для каждого вида приложения создается отдельный экземпляр контроллера. В контроллерах ни в коем случае нельзя проводить манипуляции с DOM. Работа с DOM производится только в директивах.
Сервисы содержат основную логику и отвечают на вопрос что и как делает Х. В отличие от контроллеров, сервисы это синглтоны, т. е. во всем приложении может существовать только один экземпляр сервиса. В них так же не стоит работать с DOM, но иногда можно, например, если необходимо сделать глобальное диалоговое окно и т. п. В любом случае, использование DOM-манипуляций в сервисах необходимо ограничить.
Деградация говнокода
Из всего вышесказанного можно определить стратегию борьбы с говнокодом. Во время экспериментов, авралов и проч. простая логика может писаться прямо в HTML, по мере усложнения её необходимо переносить в отдельные директивы и контроллеры. Далее вся, не относящаяся к представлению логика, выносится в сервисы. Получается своего рода локальный рефакторинг.
Области видимости (scope)
Область видимости связывает вид с контроллером. Она предназначена только для чтения в шаблонах (виде) и только для записи в контроллерах.
Не стоит путать область видимости с моделью. Область видимости это ссылка на модель. Поэтому неправильно записывать параметры модели в область видимости напрямую. Необходимо создать один параметр и поместить туда модель.
//неправильно
$scope.param1 = 'hello';
$scope.param2 = 'world';
//правильно
$scope.model = {
param1: 'hello',
param2: 'world'
};
Разница в этих подходах наглядно демонстрируется в этом видео, а так же в первом примере (см. комментарии в коде).
Соответственно, обращение к модели в директивах чаще всего будет выглядеть так:
и можно сформулировать правило: если в обращении к модели нет точки, значит что-то делается неправильно.
Модули
Не стоит разделять модули по особенностям реализации, т.е. на модуль для директив, модуль для контроллеров и т. д. Необходимо группировать модули по функциональности и схожести решаемых ими задач. Каждая библиотека многоразового использования должна быть собрана в один модуль.
При создании и использовании модуля стоит принять во внимание то, что, если он относится к обособленной части вида, то может быть лениво загружен (такая функциональность в планах). Поэтому распределите зависимости таким образом, чтобы он не вызывался когда в этом нет нужды.
Производительность
Для ускорения приложений
- Минифицируйте и объединяйте ява-скрипты
- Используйте GZIP-сжатие (может ускорить загрузку в два раза)
- НЕ кэшируйте index.html, т.к. он содержит ссылки на подключаемые библиотеки и браузер, у которого этот файл закэширован, будет всегда ссылаться на их старые версии.
- Кэшируйте (сохраняя версионность): шаблоны, код, картинки, CSS.
Пока Ангуляр не поддерживает компиляцию шаблонов на сервере и выдачу всей страницы одним запросом (в планах второй версии), поэтому для ускорения рекомендуется объединить все микрозапросы в один самостоятельно. А так же использовать кэширование шаблонов.
Что касается производительности клиентского кода, то она больше всего зависит от двух факторов:
- Как много данных, требующих связывания, располагается на странице (как правило, они заключаются в {{ }}).
- Насколько тяжелые выражения вычисляются для этих данных.
Не используйте медленные функции в $watch и в выражениях {{ }}. Так же не имеет значения сколько данных, требующих связывания, на странице, если в данный момент рендерится только один кусок.
Директивы ng-view и ng-include изменяют DOM-структуру приложения, поэтому не попадают в стандартный цикл перерисовки, тогда как ng-show и ng-hide структуру не меняют. С директивой ng-repeat для генерации списков нужно быть осторожнее, т. к., если при сотнях строк всё хорошо, то при тысячах могут начаться тормоза. В этом случае рекомендуется разбивать данные на страницы, использовать поиск и т. п. Можно использовать фильтры, но иногда они могут оказаться слишком дорогими, особенно, когда запускаются снова и снова. В этом случае можно создать вторую, внутреннюю модель. Сохранять в нее отфильтрованные данные из основной модели и уже вторую модель использовать в ng-repeat. Возможны и другие стратегии.
Для вставки шаблонов в DOM предпочтительнее использовать ng-include вместо innerHTML, т. к. она лучше оптимизирована.
Планы на будущее
В данный момент разработчики Ангуляра работают над ленивой загрузкой скриптов, а так же над реализацией пре-рендеринга страницы на сервере, что должно ускорить начальную загрузку, а так же способствовать индексации страницы поисковиками. Так же планируется упростить API директив и доработать анимацию, которая уже появилась в последних версиях фреймворка.