После года работы с большим проектом на AngularJS, думаю поделиться некоторыми, извлеченными в процессе, уроками. Во-первых, мне нравится Ангуляр. Он отлично удовлетворяет моим потребности и, думаю, полностью перейти на него в обозримом будущем, когда мне потребуется надежный фреймворк для одностраничного «толстого клиента». Он потрясающий. Над ним работает команда мирового уровня, сообщество фантастическое, и он содержит (или предлагает сообщество) целый комбайн функций для создания веб-приложений.
Организация кода
Куча мала. В самом начале мое приложение напоминало шаблонный проект с сайта Ангуляра. Куча массивных не связанных файлов, содержащих слишком много кода. Мы перешли от «Наследования простых классов» Джона Резинга к разделению на обособленные функциональные блоки. Такой подход хорошо работает, пока вы в своем проекте поддерживаете небольшую глубину наследований. Нам же докучала структура массивных папок, содержащих различные типы классов и напоминавшая «ящик с грязными носками»
- project -- controllers --- someController.js --- someOtherController.js --- ... --- someController99.js
Пример папки с контроллерами выносит . Мое новое правило: если поймали себя на том, что перебираете в уме алфавит, чтобы найти конкретный файл, то в папке, вероятно, слишком много файлов.
Сейчас я бы начал строить свой проект более модульным способом. Каждая отдельная часть функциональности или функциональной области, содержит в основном только те файлы/классы/объекты, которые ей необходимы. В идеальном мире, эти модули будут совершенно обособленными и их можно будет использовать в других проектах как «мета-компоненты» многоразового использования. Этого трудно достичь, иногда потому, что, вероятно, также потребуется набор общих утилит, помощников, или другие подобные файлы, от которых будут зависеть ваши модули. Если повторное использование не является обязательным условием, я не буду тратить много времени на абсолютное разделение всего и вся, но когда планка повышается, то думаю о том как это делать.
Клифф Мейерс написал большую статью о организации кода в большом приложение на Ангуляре.
Потрясающие и мощные директивы
Теперь я придерживаюсь мнения, что директивы это убийственная особенность Ангуляра. Это замечательные небольшие пакеты содержащие логику пользовательского интерфейса. Способность расширять синтаксис HTML делает их очень гибкими и мощными. Мы определенно используем директивы, но, возможно, не так часто как могли бы.
Одним из любимых свойств ангуляровских директив является возможность компоновки. Задавая их в качестве атрибутов HTML, можно использовать директивы для создания сложных виджетов с разноуровневой функциональностью. Обратная сторона медали появляется время от времени, когда функциональные уровни пытаются конкурировать друг с другом, но в целом директивы удивительны.
Если бы я начинал проект сегодня, то обратил бы внимание на некоторые серьезные мысли об организации директив, визуальных компонентов и поведения. Уже существуют несколько проектов в которых популярные визуально-ориентированные фреймворки заворачиваются в директивы Ангуляра, но совсем не обязательно думать о том как бы использовать весь этот полномасштабный набор компонентов у себя. Каковы основные компоненты приложения? Как спроектировать директивы, чтобы основные компоненты были бы общими для всего приложения, а не россыпью HTML и CSS копипаста. Как можно использовать эти компоненты для будущей работы?
Если вы еще не смотрели видео о них, то бегом на egghead.io Джона Линдквиста и просмотрите серии о директивах. Все ролики отличные и рассказ о директивах поучителен.
Знай свой фреймворк
Так как я начал этот проект, то, безусловно, копался некоторое время во внутренностях Ангуляра. Исходный код легко читается и хорошо протестирован, так что, для разбирающихся в Яваскрипте чтение будет завораживающим.
Пока копался в нем, старался как можно ближе познакомиться с его устройством. Многие вещи все еще остаются черным ящиком для меня, и не смотря на то, что доверяю разработчикам, все еще чувствую необходимость понять, что же происходит во время создания приложений. Сейчас это одна из моих ближайших целей, так что, надеюсь, в будущем мог бы кое-что рассказать о том, как работает Ангуляр под капотом.
Уходя в сторону, чувствую себя вынужденным сделать то же самое и с Джиквери. Так много кода, так мало времени.
Сборка
К сожалению, в этом проекте мы были обязаны использовать Maven и JAWR для сборки. Это была настоящая борьба, и мы просто не могли осуществить «приличную» сборку. Мы были в состоянии собрать кое-какие инструменты, помогающие переходу, но я не рекомендую использовать Maven для фронтэнда.
Если бы я начинал проект сегодня, то определенно использовал Yeoman, чтобы легко создавать шаблоны и сделать жизнь легче.
CSS
Он не связан с Ангуляр напрямую, но является еще одним важным аспектом проекта на Ангуляре, поэтому хотел бы потратить немного времени на это.
Признаю, что год назад мое отношение было «f CSS» (f — двойка). Он пугал и доводил меня до такой степени отвращения. Очевидно, что оно вытекает из невежества, и я провел последний год, пытаясь играть с CSS-версткой. Мое отношение уже не «f CSS» и звучит скорее как «SCSS» (s — тройка), потому что нашел место, где CSS и я можем жить счастливо.
Синтаксис «SCSS» прикрыл многие болевые точки в моем с простым CSS и сильно повысил уровень четкости. Кроме того, Compass добавляет кучу озорных примесей, которые избавляют от совершенно нового вида боли от работы со стилями.
В будущем хочу вникнуть в SASS/Compass глубже, объединив их выразительные стилевые возможности с модульным и компонентным уровнем работы в Ангуляре, изложенными выше. Хотелось бы использовать более организованный подход к стилевым таблицам, примерно как SMACSS предоставляющий базовый стандарт, который объясняет как работать и организовывать стили.
На данный момент CSS и я полностью помирились. Я поборол свое невежество, что, очевидно, стало ключом к построению прочных отношений. Увидим как пойдет. Однажды за один раз.
Заключение
Если создаете одностраничное веб-приложение, Ангуляр это хороший выбор. Важно как можно раньше принять решение о структуре приложения. Решить, как разбить свой код на модули и компоненты так, что бы можно было использовать всю мощь директив и увеличить по максимуму потенциал повторного использования.
Комментарий к статье можно оставить на Hacker News, если хотите принять участие в дискуссии.
P.S. Для русскоязычной аудитории комментарии, разумеется, здесь :-)
Автор: tamtakoe
