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

Загрузка приложения и менеджер состояний

До момента загрузки самого фрэймворка, его зависимостей и отработки всех запросов в бэкграунде приложение может выглядеть весьма удручающе. И даже ng-cloak не сможет помочь в большинстве случаев. Обычно для таких целей используют div имеющий больший z-index чем основной контент сайта и перекрывающий его до загрузки всех компонентов и состояний. Он может выглядеть так:

<div class="loader" ng-show="loader"><div class="loader-content">Loading...</div></div>

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

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

Предпосылки

Информацию об авторизованном пользователе я решил хранить в sessionStorage, копируя её при запуске приложения в $rootScope. Также по рекомендации авторов UI Router я храню в $rootScope значения объекты $state и $stateParam, для удобного доступа. Информацию же о доступе к тому или иному состоянию можно передавать через блок data при описании самого состояния. Поскольку в моем приложении везде закрыт доступ, я решил идти от обратного и добавлять значение noLogin = true для состояний, которые не требуют авторизации, например страницы ввода логина, восстановления пароля или регистрации.

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

Данная публикация является переводом оригинального курса CoodSchool с небольшими дополнениями, которые показались мне уместными в данном контексте. Публикация рассчитана на тех, кто только начинает знакомится с Angular.

Введение

AngularJS — популярная JavaScript библиотека, предназначенная, главным образом, для создания одностраничных веб-приложений с динамически обновляемым содержимым. Библиотека была написана словацким программистом Мишкой Хевери, который, работая в Google, получил от своего шефа задание выучить JavaScript. Он решил, что лучший способ изучить язык — это создать на его основе собственный фреймворк. Angular (звучит как «Ангула» и дословно переводится как «Угловатый») использует концепцию разделения данных и их представления, известную как MVC (M — model (данные), V — view (представление), С — controller (контролер, управляющая прослойка между ними обеспечивающая логику работы приложения).

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

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

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

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

Много воды лить не буду и перейду сразу к советам.

Данный пост будет посвящён вопросу сборки 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 работала без ошибок. Итак, что можно сделать?

На мой взгляд, директивы являются основной изюминкой декларативного стиля Angularjs. Однако, если открыть комментарии пользователей в разделе официальной документации Angularjs, посвященной директивам, то вы увидите, что самый популярный из них: «Пожалуйста, перепишите документацию, сделайте ее более доступной и структурированной. Начинающему разработчику на Angularjs сложно в ней разобраться» («Please rewrite a clearer well structured documentation of directives., this is not friendly to first time angular developers»). С этим трудно не согласится, документация пока еще сыровата и в некоторых моментах приходится прилагать большие усилия, чтобы разобраться в логике и сути функционала. Поэтому я предлагаю вам свой вольный пересказ данной главы в надежде, что кому-то это позволит сэкономить время, а так же рассчитываю на вашу поддержку и участие в комментариях. Итак, поехали!
Часть 1

AngularJS директивы – это клево

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

На мой взгляд, директивы являются основной изюминкой декларативного стиля Angularjs. Однако, если открыть комментарии пользователей в разделе официальной документации Angularjs, посвященной директивам, то вы увидите, что самый популярный из них: «Пожалуйста, перепишите документацию, сделайте ее более доступной и структурированной. Начинающему разработчику на Angularjs сложно в ней разобраться» («Please rewrite a clearer well structured documentation of directives., this is not friendly to first time angular developers»). С этим трудно не согласится, документация пока еще сыровата и в некоторых моментах приходится прилагать большие усилия, чтобы разобраться в логике и сути функционала. Поэтому я предлагаю вам свой вольный пересказ данной главы в надежде, что кому-то это позволит сэкономить время, а так же рассчитываю на вашу поддержку и участие в комментариях. Итак, поехали!

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

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

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

При создании сайтов часто возникает задача создания админки для редактирования контента. Задача, в общем, тривиальная, но сделать удобную админку не так-то просто.

Под удобством в первую очередь подразумевается возможность сортировки таблицы со списком материалов и работа без перезагрузки страницы. Если материалов в таблице становится много, то возникает задача разбивать её на страницы.

Всем известный jQuery-плагин tablesorter с tablesorterPager-ом и менее известный, но гораздо более функциональный DataTables хороши, но обладают некоторыми недостатками. Главный из них — сложность динамического добавления новых строк в таблицу (после добавления строки в таблицу, новая строка потеряется при следующем вызове сортировки). tablesorter вообще не даёт средств для добавления строки в свой кэш, DataTables предоставляет широкое и функциональное API для управления внутренним представлением таблицы, но это API довольно многословно и не очень гибко.

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

Сразу приведу, что получится в итоге (кликабельно):

Не так давно в одном из уже практически написаных проектов возникла необходимость в использовании подобия вэб-компонентов. Хочу расказать что у нас получилось, постараюсь кратко:

Цель:

Начать использовать компонентный подход в HTML верстке(новую семантику), а именно вэбкомпоненты.

Под компонентом я подразумеваю — “независимый модуль программного кода, предназначенный для повторного использования и развертывания”. К примеру в другом проекте.



Тут хочу сделать небольшое отступление и внести ясность – речь пойдет о компонентах, а не о виджетах(функционально обособленных единицах приложения, объединяющих в себе представление, логику и/или данные, конкретного приложения — javascript+html+css).
Разница, по моему мнению, состоит в том что компонент не подвязывается к конкретной модели данных или логике конкретного приложения – и вы можете его без труда перенести в другое приложение. А виджет – это единица конкретного приложения тесно связанная логикой или данными, и перенести его куда либо без внутреннего изменения самого виджета у вас не получится.
В качестве примеров компонента могу привести селект, аккордеон или табки, а виджетов – панель состояния или окно отображения сообщений в чате.

Зачем:

Реюзабельный код и удобство верстки с помощью возможности расширения HTML синтаксиса.

Как сказано в доке к одному известному фреймверку:

“Directives is a unique and powerful feature available only in Angular. Directives let you invent new HTML syntax, specific to your application.”

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

И описанное далее это ни в коем случае не MV* фреймверк, и никогда не задумывался как онный.

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

Дзен Angular

• Хорошо отделять манипуляцию DOM-ом от логики работы приложения. Это существенно улучшает тестируемость кода.
• Хорошо считать, что автоматизированное тестирование приложения настолько же важно, насколько и написание самого приложения. Тестируемость очень сильно зависит от того, как структурирован код.
• Хорошо отделять разработку клиентской части от серверной. Это позволяет вести разработку параллельно и улучшает повторное использование на обеих сторонах.
• Хорошо, когда фреймворк ведет разработчика по всему циклу разработки приложения: от проектирования UI через написание бизнес-логики к тестированию.
• Хорошо, когда распространенные задачи становятся тривиальными, а сложные — упрощаются.

AngularJS представляет собой комплексный фреймворк. В стандартной поставке он предоставляет следующие возможности:

• Все, что вам нужно для создания CRUD-приложений: data-binding, базовые директивы для шаблонов, валидация форм, роутинг, deep linking, повторное использование компонентов, dependency injection, инструменты для взаимодействия с серверными (RESTful) источниками данных.
• Все, что вам нужно для тестирования: средства для модульного тестирование, end-to-end тестирования, mock-и.
• Шаблон типового приложения, включающего в себя структуру каталогов и тестовые скрипты.

AngularJS разрабатывается сотрудниками Google и используется, как минимум, в одном сервисе Google — DoubleClick.

Около 2-х месяцев назад я и TheShock собирали вопросы по JavaScript в теме FAQ по JavaScript: задавайте вопросы. Первая часть, те вопросы, которые достались мне, появилась буквально через несколько дней JavaScript F.A.Q: Часть 1, а вот вторая часть все не выходит и не выходит. TheShock сейчас переезжает в другую страну и поэтому ему не до ответов. Он попросил меня ответить на его часть. Итак вторая часть ответов — те вопросы, которые достались тоже мне.

Несколько дней назад мы с TheShock создали топик в котором собирали ваши вопросы, касательно JavaScript (архитектура, фрэймворки, проблемы). Настало время ответить на них. Мы получили очень много вопросов, как в комментариях так и по email. Эта первая часть ответов — те вопросы, которые достались мне.

Я —.NET разработчик. Но в последнее время всё чаще сталкиваюсь с JavaScript. Причём, процентах в 50 случаев я что-то на нём пишу, в остальных 50 — разбираюсь с чужим кодом, да ещё и прошедшим через минификацию, а иногда и обфускацию. В этой статье захотелось поделиться теми моментами, которые мне показались важными для понимания языка и эффективной работы с ним. Тут не будет ничего нового или неизвестного для людей, уже имевших дело с языком, и не будет чего-то такого, чего нельзя найти в других источниках. Для меня статья будет полезна как способ лучше разобраться в предмете, для читателей, я надеюсь, — как повод освежить знания.

Брендан Айк упоминал, что JavaScript был создан за 10 дней. Думаю, идея вынашивалась дольше. Как бы то ни было, язык получился и с тех пор только набирает популярность. Особенно после появления AJAX.

JavaScript — язык со слабой динамической неявной типизацией, автоматическим управлением памятью и прототипным наследованием.

JavaScript состоит из трёх обособленных частей:

• ядро (ECMAScript),
• объектная модель браузера (Browser Object Model или BOM),
• объектная модель документа (Document Object Model или DOM).

В статье, в основном, пойдёт речь о ядре. Конечно, в примерах кода будут использоваться элементы DOM и BOM, но заострять на них внимание не буду.

Привет, хабр!

Одним прекрасным вечером, не предвещающим ничего интересного, в наш чатик поступило предложение от автора публикации «Переводим в код 5 действительно полезных шаблонов адаптивной разметки», написанной им весной 2012 года, написать статью-ремейк, но с применением FlexBox и сопутствующим пояснением что и как работает. После некоторой доли сомнений, интерес глубже разобраться в спецификации все таки победил и я благополучно сел верстать те самые примеры. В ходе погружения в эту область стало выясняться множество нюансов, что переросло в нечто большее чем просто переверстать макетики. В общем в данной статье хочу рассказать о такой чудесной спецификации, под названием «CSS Flexible Box Layout Module» и показать некоторые ее интересные особенности и примеры применения. Всех кому интересно, любезно приглашаю под хабракат.